Updated SIEM ESM with Windows Content Pack updates.
To receive email notification when this article is updated, click Subscribe on the right side of the page. You must be logged on to subscribe.
McAfee Enterprise is aware of the recent Windows CryptoAPI Spoofing vulnerability (CVE-2020-0601). We have technology in development to detect the vulnerability and are currently conducting rigorous quality assurance and efficacy testing.
We strongly advise rapid deployment of the Microsoft patches released on January 14. McAfee Enterprise products are compatible with all updates released in the January Patch Tuesday update.
We have also published an Extra DAT that is attached to this article for download. We strongly recommend that customers deploy this Extra DAT.
The following McAfee Enterprise products detect this threat and provide organizations with the means to respond in a timely manner:
SIEM can detect exploit attempts for this vulnerability. When a customer deploys the Windows update to fix the vulnerability in CVE-2020-0601, the operating system begins generating a Windows event when an attempted exploit is detected. The Event Source is either "Audit-CVE" or “Microsoft-Windows-Audit-CVE”.
New rules have been uploaded to the content server with new signature IDs that customers can now use to create alarms. Customers can automatically get this rule on their next update, or they can manually initiate a rule update for faster updates. For more information, see the "Check for rule updates" section in the Enterprise Security Manager 11.3.x Product Guide. The new signature IDs are 43–458000010 and 43–459000010.
If a customer does not have the latest rules, the SIEM auto-learns the event and assigns it a signature ID of either 43–2978558213 or 43–3364295324. The assigned signature ID depends on which Event Source is being used.
The SIEM Microsoft Windows Content Pack version 2.2.0 and later are updated with a preconfigured alarm that customers can enable. McAfee Enterprise advises that customers update to the latest Content Pack version.
The new signature IDs to monitor are:
Signature ID
Rule Message
43–2978558213
1-audit-cve
43–3364295324
1-microsoft-windows-audit-cve
43–458000010
Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601)
43–459000010
Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601)
McAfee Active Response can detect exploit attempts for this vulnerability. To identify devices that have been involved recently in an exploit attempt, you can use Active Response Catalog to create a custom collector. Then use Active Response Search to execute a query using that collector.
The custom collector created by the customer retrieves Windows event log information from Microsoft-Windows-Audit-CVE provider.
Type the following expression in the search box:HostInfo hostname and NSACryptEvents where NSACryptEvents id not equals ""
Result interpretation
The result is the list of devices where a security update was applied and there was recently some exploit attempt of this vulnerability.
Only devices with a connection status of online or quarantine respond to the search.
Search for devices with the security update applied
Log on to ePO.
Go to Menu, Active Response Search.
Type the following expression in the search box: InstalledUpdates where InstalledUpdates hotfix_id equals "KB4528760"
Result interpretation
The result is the list of devices with KB4528760 applied.
Only devices with a connection status of online or quarantine respond to the search.
Replace with the following list of KB numbers and you can obtain the list of devices with the security update applied:
The Network Security Platform team released an emergency signature set release version 10.8.3.3 on January 15, 2020, to detect this vulnerability.
The signature has the following attack name and ID:
Attack Name: HTTP: Microsoft Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601)
Attack ID: 0x45273900
See KB55446 - Network Security Signature Set Update for release notes and additional information about the emergency signature set release. NOTE: The referenced content is available only to logged in ServicePortal users. To view the content, click the link and log in when prompted.
The following signatures for CVE-2020-0601 were released as part of the daily content (DAT/AMCORE) update on January 24, 2020:
V2: 9510 (VSE)
V3: 3961.0 (ENS)
This detection depends on GTI, and occurs only when GTI is enabled. For systems where GTI is not enabled, or for environments that are not connected to the internet, use the Extra.DAT attached with this article.
Extra.DAT
NOTE: The Extra.DAT that was uploaded to this article on January 16, 2020 has been removed. An updated Extra.DAT(released January 21, 2020) is now available for download in the Attachment section of this KB.
McAfee Enterprise has created a generic detection to protect endpoints against exploitation of this vulnerability (CVE-2020-0601). This Extra.DAT can be deployed to endpoints that run VSE and ENS.
McAfee Enterprise strongly recommends that you test this Extra.DAT on a small group of systems before you deploy it to the wider organization. If there are any issues, such as false positives, or if you have any questions about this Extra DAT, open a Service Request (SR) with Technical Support.
Extra.DAT Download and Deployment
Extract the EXTRA.zip file attached to this article.
Open the Endpoint Security Client.
From the Action menu, select Load Extra.DAT.
Click Browse, go to the location where you downloaded the Extra.DAT file, and click Open.
Result
The new detections in the Extra.DAT take effect immediately. The detection name CVE2020-0601.his displayed once you deploy the Extra DAT and run a scan.
MVISION EDR can detect exploit attempts for this vulnerability. To identify devices that have been involved recently in an exploit attempt, you can use Real Time Search dashboard and execute a query using NSACryptEvents collector. The NSACryptEvents collector retrieves Windows events log information from Microsoft-Windows-Audit-CVE provider.
Search for exploit attempt
Log on to EDR.
Go to Menu, Real-Time Search.
Type the following expression in the search box: HostInfo hostname and NSACryptEvents where NSACryptEvents id not equals ""
Result interpretation
The result is the list of devices where security update was applied and there was recently some exploit attempt of this vulnerability.
Only devices with a connection status of online or quarantine respond to the search.
Search for devices with security update applied
Log on to EDR.
Go to Menu, Real-Time Search.
Type the following expression in the search box: InstalledUpdates where InstalledUpdates hotfix_id equals "KB4528760"
Result interpretation
The result is the list of devices with KB4528760 applied. Only devices with a connection status of online or quarantine respond to the search.
Replace with the following list of KB numbers, and you can obtain the list of devices with the security update applied:
To protect from exploitation via Authenticode-signed Windows binaries, the Web Protection team has released a Gateway Anti-Malware (GAM) DAT update on January 16, 2020 (at 1900 UTC), version 6974 (or newer). It includes a new detection, named “BehavesLike.Win32.MaybeSpoofedCert.*”, for exploits of signed binaries against CVE-2020-0601. Customers of Web Gateway, and other products using GAM (NSP, ATD), receive this DAT update automatically. If your update cadence is infrequent, you can also trigger a DAT update manually.
NOTE: The Web Gateway SSL Scanner (HTTPS proxy) verifies certificates. It also protects browsers that are using the CryptAPI of vulnerable and unpatched Windows versions - on clients deployed behind the Web Gateway SSL Scanner - from visiting pages that use faked certificates.
How to configure SSL certificate verification when the SSL Scanner is not used
To enable the certificate verification capabilities of the Web Gateway product without enabling SSL inspection, use the following steps. This approach allows Web Gateway to add another layer of security by checking a website's certificate against a list of known and trusted certificate authorities. This action prevents users from accessing websites that run insecure or spoofed certificates.
NOTE: If you already have HTTPS Scanning (also known as SSL Scanning or SSL Inspection) in place, there is no need to follow these instructions. Certificate verification is part of the HTTPS Scanning rule set, so certificate verification is enabled if not explicitly disabled. You can follow the below steps to validate that certificate verification is still enabled in your policy.
IMPORTANT: It is strongly recommended that you either import an existing certificate authority that is already trusted by the browsers, or generate a new certificate authority and make sure it is trusted by clients in your network. The configured certificate authority is used to sign the connection when Web Gateway intercepts a connection and needs to display HTML templates to the clients. For more details, see the product guide.
Access the Web Gateway User Interface. Instructions to access the User Interface are available from the product documentation.
Switch to the Policy tab at the top of the User Interface.
Ensure that the Rule Set tab is selected on the upper-left corner.
Under Rule Sets, click Add. In the drop-down field, select Top Level Rule Set.
In the dialog box that opens, select Import rule set from rule set library.
Open the category HTTPS Scanning and select the rule set HTTPS Scanning.
NOTE: If you can't find HTTPS Scanning, the rule set might be found as SSL Scanner.
After you select the rule set, Web Gateway will validate the rule set for the object that exists within your policy. Because in a default policy “HTTPS Scanning” is already present, it is likely that existing lists, settings, or rule sets were found. Resolve the conflicts by referring to existing objects or creating new objects with a different name. For this specific use case, the recommendation is to use the Auto-Solve Conflicts wizard and select Solve by copying and renaming to suggested.
When all conflicts are resolved, click OK to import the rule set into your policy.
After the import, select Unlock View to switch from the wizard to the full, rule-based view.
Move the rule set toward the top of your policy. There is no need to put it at the very top of your policy. Place it where the “HTTPS Scanning” rule set could usually be found. As a generic recommendation, place the rule set after “Global” allow and block lists have been applied and before “Common Rules” such as Web Cache, Openers, Progress Indication are called.
Select the HTTPS Scanning, Handle CONNECT Call rule set.
For the rule Set Client Conext, on the right, find the Enable SSL Client Context with CA event. Click the associated setting to open the settings for this event.
In the setting, you can do one of two things. Either import an already trusted, subordinate certificate authority. Or, use the generate button to create a new certificate authority, which needs to be rolled out to clients as indicated earlier.
Select the HTTPS Scanning, Content Inspection rule set.
Remove the checkbox next to Enable on the top of the right rule set pane to completely disable the whole Content Inspection rule set. Make sure it is grayed out on the left pane listing all rule sets. This action is done because, otherwise, Web Gateway would not only perform certificate verification, but also enable content inspection to look into SSL connections. You do not want to enable this inspection at this stage, you only want to enable certificate verification.
Save the changes.
From now on, certificate verification on the Web Gateway is enabled. If a user hits an untrusted, insecure, or spoofed certificate, the browser shows an HTML website generated by the Web Gateway outlining the problem with the certificate. In this case, the connection is secured with a certificate signed by the certificate authority and imported or generated at step 13.
For more details about “HTTPS Scanning,” see the product documentation, the McAfee Enterprise Communities, or contact Technical Support.
If you are a registered user, type your User ID and Password, and then click Log In.
If you are not a registered user, click Register and complete the fields to have your password and instructions emailed to you.
Threat Intelligence Exchange (TIE) can help to identify file signing abuse before patching by providing a workflow to pivot into spoofed CAs and their signed binaries already run in the environment.
Search for fraudulent signed binaries:
Log on to ePO.
Go to Menu, TIE Reputations page.
Click the Certificate Search tab and use Quick find with ‘Microsoft ECC’.
Results:
For each listed CA certificate, look for fraudulent intermediate certificates using Actions -> Signed Certificates.
For each listed intermediate certificate, look for fraudulent signed files using Actions -> Associated File Details.
For each listed fraudulent signed binary, look for affected systems using Actions -> Where Was File Used.
