Detecting CVE-2020–0601 and other attempts to exploit known vulnerabilities using Azure Sentinel
Yesterday, Microsoft has released a security update for Windows which includes a fix to a dangerous bug that would allow an attacker to spoof a certificate, making it look like it came from a trusted source.
The vulnerability (CVE-2020–0601) was reported to Microsoft by the NSA. The root cause of this vulnerability is a flawed implementation of the Elliptic Curve Cryptography (ECC) within Microsoft’s code.
Tal Be’ery, Microsoft’s security research manager, wrote an article explaining the root cause of the vulnerability using a Load Bearing analogy. You can find that here.
Watching the logs
Windows has a function for publishing events when an attempted security vulnerability exploit is detected in your user-mode application called CveEventWrite. To my knowledge, the fix for CVE-2020–0601 is the first code to call this API.
After the Windows update is applied, the system will generate event ID 1 in the eventlog after each reboot under Windows Logs/Application when an attempt to exploit a known vulnerability is detected. This event is raised by a User mode process, and more information can be found in the MSRC guidance for this fix (scroll to the bottom of the article to find it).
Azure Sentinel
By default the Log Analytics workspace powering Azure Sentinel will not collect events from the Application eventlog. You can change this by going to the Advanced Settings for your workspace, and adding Application as a source under Data > Windows Event Logs:
There are two ways of going about creating the Rule. Either you set up detection for event ID 1 in general so that you get alerted for any (future) CVE abuse, or you set up specific rules per CVE.
There will be pro’s or con’s to both approach. In this sample we’ll build a specific Rule to detect potential CVE-2020–0601 abuse so that we can map it to the right MITRE tactics and follow specifically.
Alert rule
Pete Bryan, who works at Microsoft’s Threat Intelligence Center (MSTIC), tweeted a sample KQL query that you can use:
Event
| where Source ==”Microsoft-Windows-Audit-CVE”
| where EventID == “1”
| where RenderedDescription contains “CVE-2020–0601”I was debating with Olaf Hartong from FalconForce which MITRE TTP’s would be most applicable. These make most sense to us:
- T1036 — In case of fake certificates on binaries
- T1189 — In case of man-in-the-middle type of attacks
- T1116 — In case of code signing abuse
That means that we’ll be tagging the rule for Defense Evasion and Initial Access tactics.
AzSentinel powershell
If you want to programmatically push this rule into your Azure Sentinel environment, go have a look at our AzSentinel powershell module. My colleague Pouyan Khabazi built this module to work with alert rules in Azure Sentinel through automation. More information on working with the module can be found here.
Here’s the rule definition you could use with AzSentinel:
Microsoft Defender ATP
If you have Microsoft Defender ATP deployed across your enterprise (which now also supports MacOS), you will get the detection out of the box. The logic was added to MDATP at the same time that Microsoft released the fix:
And because MDATP is now unified with other the other Microsoft ATP products, the detection will also show up in the new Microsoft Threat Protection (MTP):
PRO TIP: Microsoft Defender ATP can also be deployed on servers. For workloads living in Azure: enable Azure Security Center (standard) and the MDATP client will be deployed and configured automatically.
Analyzing your enterprise for CVE-2020–0601 attacks
Today, the Microsoft Defender team also added a dashboard in the Threat Analytics section of MDATP. The dashboard shows you more information about the CVE and whether or not endpoints in your organization were found to have been potentially abused:
However, Microsoft also released the hunting query that you could use to investigate. Here’s the KQL:
DeviceFileCertificateInfoBeta| where Timestamp > ago(30d)| where IsSigned == 1 and IsTrusted == 1 and IsRootSignerMicrosoft == 1| where SignatureType == "Embedded"| where Issuer !startswith "Microsoft" and Issuer !startswith "Windows"| project Timestamp, DeviceName,SHA1,Issuer,IssuerHash,Signer,SignerHash,CertificateCreationTime,CertificateExpirationTime,CrlDistributionPointUrls
Best of suite
In the case that you have MDATP and/or MTP, there is no need to create the Azure Sentinel rule(s). Just enable the Microsoft Defender ATP connector to Azure Sentinel and the alert will be created automatically.
Happy hunting!
— Maarten Goet, MVP & RD
