Indicators enhancements: Allow/Block by certificates & more

[Efrat Kliger]

Matching Indicators of compromise (IoCs) is essential in every endpoint protection solution. Indicators give SecOps the ability to set a list of IoCs for detection and for blocking (prevention and response).

Today we’re announcing several enhancements to the unified indicators experience:

• You can now set an indicator of type certificate that defines the detection, prevention, and exclusion of .
• The “alert and block” action for custom indicators on files can now be applied to files signed by trusted publishers.
• We increased the total limit of indicators across your organization to15,000!

Let’s get started with some suggested use cases.

Allow certificate: attack surface reduction rules

You may want to deploy blocking technologies, such as attack surface reduction (ASR) rules, and allow behaviours or permissions from signed applications to write to protected folders (for example, Controlled Folder Access (CFA)).

Historically, you could only exclude file paths and folders from attack surface reduction rules. Today, you can create exclusions based on certificates.

To try it out:

1. Enable the specific ASR rule you would like to apply certificate exclusion for into block mode
2. When you execute a file, its activity will be blocked (if block mode was enabled).
3. Sign this file with a valid certificate as defined in the prerequisite section.
4. In the navigation pane, select Settings >Rules > Indicators.
5. Select the Certificate tab
6. Add the .CER or .PEM certificate as an indicator with the ‘allow’ action.
7. The file’s executable content should now be able to run (i.e. ASR does not block the behavior).

Block certificate

There may be instances when you may want to block the use of a specific signed application across your organization. Using the block certificate action, Microsoft Defender AV will prevent file executions (block and remediate) and the automated investigation and remediation behave the same.

Previously, the automated investigation and remediation engine managed a separate allow / block list for certificates. We have now aligned all detection and enforcement means to honor a single unified list. Your previously set certificate rules have been migrated to the new unified Indicator setting page.

Figure: Old Automation certificate list

Block files signed by trusted publishers

You may want to block files signed by trusted publishers for scenarios such as when a version of a signed application has a reported vulnerability (CVE). You may also want to prevent the application’s associated file hashes from executing within your corporate environment.

It's important to understand the requirements before creating indicators for files.
For more information, see Create indicators for files.

Microsoft uniquely combines these powerful methods into an integrated approach that protects endpoints more effectively against both malware and breaches. We will continue to iterate these capabilities to bring Security Operations more flexibility in creating custom indicators to protect their organizations.

As always, we welcome and appreciate your feedback!

[Mayuresh_bhate]

hello @Efrat Kliger 

thanks for nice article. I have a question here. 

When defender definitions are updated, does it includes known bad file's hash as well as an updates?

Mayuresh

[vojinle]

Idea is great, but the implementation isn’t.  The fact that it requires you to have the actual PEM or CER file makes it hard to do because malware signed with stolen but valid certs (e.g WINITI group) might be in a threat intel feed where they provide name on the cert or cert id, but not the actual certicated itself.  (Note that you can block via applocker with that type of detail, and no cer or pem file). 

[Efrat Kliger]

Thank you for the feedback @vojinle, we have on our roadmap to extend the support and enable the block cert flow directly from the portal and based on the identifier. In most cased, the flow you have described, when available in threat intel feed, will result in certificate revocation by the issuing certificate authority (CA) before the scheduled expiration date and should be detected and blocked as a threat. Therefore we have prioritized supporting the whitelisting and blocking on known/unwanted files across the org by cert.  

[vojinle]

And the other thing is that it would be great to enable ASR rule that would allow us to block IPs, URLs and Certificates – but we can’t trust smartscreen since it is often wrong.  For example, it constantly flags our wordpress sites as “phishing” because of CORE wordpress css and/or javascript files.   If they’d provide the ability to block by all of those without including Smartscreen reputation based blocks to boot, it would be better.  If they can’t they should build in some sort of bypass for smartscreen site that we can white list the site for our own user or (better) by Azure AD group. 

[vojinle]

It’s good that it’s on the roadmap, but it still doesn’t help unless we run in block mode, which we wouldn’t be able to enable if smartscreen blocking was also going to apply (and not workaround to not use it existed).