As of May 14, 2024, Knowledge Base (KB) articles will only be published and updated in our new Trellix Thrive Knowledge space.
Log in to the Thrive Portal using your OKTA credentials and start searching the new space. Legacy KB IDs are indexed and you will be able to find them easily just by typing the legacy KB ID.
Response to Windows CryptoAPI spoofing vulnerability
Technical Articles ID:
KB92322
Last Modified: 2024-02-07 05:45:01 Etc/GMT
Environment
Endpoint Detection and Response (EDR)
SIEM Enterprise Security Manager (ESM) 11.x
Skyhigh Web Gateway (SWG) 9.x, 8.x
Summary
Recent updates to this article
Date
Update
February 6, 2024
Removed category tags for End of Life product versions.
December 13, 2023
Minor formatting changes; no content updates.
December 8, 2023
Minor formatting changes; no content 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.
We're 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, 2020. Our products are compatible with all updates released in the January Patch Tuesday update.
We've also published an Extra DAT that's attached to this article for download. We strongly recommend that customers deploy this Extra DAT.
The following 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 ESM 11.5.x Product Guide. The new signature IDs are 43–458000010 and 43–459000010.
If a customer doesn't 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. We advise that customers update to the latest Content Pack version.
The new signature IDs to monitor are shown below:
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)
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 the Microsoft-Windows-Audit-CVE provider.
Type the following expression in the Search field: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 field: 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 IPS 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 - Trellix Intrusion Prevention System Signature Set Updates 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 isn't enabled, or for environments that aren't 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 article.
We've 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.
We strongly recommend 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.
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 the NSACryptEvents collector. The NSACryptEvents collector retrieves Windows events log information from the 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 field: 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 security update applied
Log on to EDR.
Go to Menu, Real-Time Search.
Type the following expression in the Search field: 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 SWG, 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 SWG 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 fake certificates.
How to configure SSL certificate verification when the SSL Scanner isn't used
To enable the certificate verification capabilities of SWG without enabling SSL inspection, use the following steps. This approach allows SWG 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's 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 steps below to validate that certificate verification is still enabled in your policy.
IMPORTANT: It's strongly recommended that you either import an existing certificate authority that's already trusted by the browsers, or generate a new certificate authority and make sure that it's trusted by clients in your network. The configured certificate authority is used to sign the connection when SWG intercepts a connection and needs to display HTML templates to the clients. For details, see the Product Guide.
Access the SWG 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.
Make sure that the Rule Set tab is selected at the upper-left corner.
Under Rule Sets, click Add. In the drop-down field, select Top Level Rule Set.
In the dialog window 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, SWG validates the rule set for the object that exists within your policy. Because in a default policy, "HTTPS Scanning" is already present, it's likely that existing lists, settings, or rule sets are 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's no need to put it at the very top of your policy. Place it where the "HTTPS Scanning" rule set can 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 Context, 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.
Unselect 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 that it's grayed out on the left pane listing all rule sets. This action is done because, otherwise, SWG wouldn't only perform certificate verification, but also enable content inspection to look into SSL connections. You don't want to enable this inspection at this stage, you only want to enable certificate verification.
Save the changes.
From now on, certificate verification on SWG is enabled. If a user hits an untrusted, insecure, or spoofed certificate, the browser shows an HTML website generated by SWG 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 in step 13.
For details about "HTTPS Scanning," see the Product Documentation, our Communities site, 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.
