Windows SmartScreen Security Feature bypass (CVE-2023–24880)

15 min readApr 26, 2024

Screenshots from the blog posts

Summary

Microsoft Windows SmartScreen contained a security feature bypass vulnerability that could enable an attacker to circumvent Mark of the Web (MOTW) defenses through a specially crafted malicious file.

Description

Introduction

CVE-2023–24880 represents a zero-day vulnerability that impacts Windows desktops (Windows 10 and newer) as well as server editions (Server 2016, 2019, and 2022).

The vulnerability (CVSS3 score of 5.4) exploits the Microsoft Mark of the Web (MOTW), an integral Windows security feature designed to prevent users from downloading or accessing malicious MSI files from the internet. MOTW achieves this by creating a zone identifier Alternate Data Stream (ADS), enabling Windows SmartScreen to obstruct access to security features on devices. However, threat actors can skillfully construct a malicious file that circumvents MOTW, leading to a compromise in device integrity and the deactivation of security features in Microsoft Office, including Protected View, which relies on MOTW tags.

This particular vulnerability had been exploited by financially driven threat actors to deploy the Magniber ransomware. The threat actor, motivated by financial gain leveraged CVE-2023–24880 to disseminate specifically crafted MSI files. These files bear an Authenticode signature that, while invalid, triggers an error in SmartScreen.

The security issue is also a result of a limited fix issued by Microsoft to address a different SmartScreen bypass vulnerability (see CVE-2022–44698) that was discovered in 2022.

As per Microsoft’s security advisory,

An attacker can craft a malicious file that would evade Mark of the Web (MOTW) defenses, resulting in a limited loss of integrity and availability of security features such as Protected View in Microsoft Office, which rely on MOTW tagging.

As Benoit Sevens said in a report,

"Because the root cause behind the SmartScreen security bypass was not addressed, the attackers were able to quickly identify a different variant of the original bug."

In this analysis we will talk about MOTW, Magniber ransomware and also take a deeper look into the vulnerabilities behind this attack, focusing on CVE-2023–24880.

Timeline

September 2022: malicious actors began to exploit the Windows SmartScreen Bypass vulnerability identified as CVE-2022–44698, utilizing JavaScript as a means to deploy malware. In response to this threat, Microsoft issued a patch to address and rectify the vulnerability in December 2022. Following this, HP Threat Research highlighted Magniber campaigns in October.
October 28, 2022: research and recommended patches (source).
Mid-November, 2022: other threat actors adopted the same bypass to propagate the Qakbot malware.
December 13, 2022: Microsoft has released a security patch (see CVE-2022–44698).
January 2023: Google’s Threat Analysis Group (TAG) identified the exploitation of this vulnerability.
February 2023: The researchers promptly communicated their findings to Microsoft, leading to the release of a fix as part of the latest Patch Tuesday updates.
March 14, 2023: the Microsoft Security Response Center (MSRC) released a blog post addressing a zero-day vulnerability identified as CVE-2023–24880. This security bypass vulnerability impacts recent versions of the Windows operating system, including Windows 10, 11, and Server 16, as well as subsequent releases.

The players unveiled

To understand the background, we should clarify some basic terms and talk about the “players”.

Windows SmartScreen Security Feature

Windows SmartScreen is a security feature in Microsoft Windows operating systems designed to protect users from potentially malicious content and websites. This important security layer helps protect users by identifying and blocking potentially harmful files, applications, and websites and prevents users from unintentionally downloading and running malicious software. It contributes to the overall security of the Windows operating system by providing an additional defense against various forms of malware and phishing threats.

Here’s how SmartScreen works:

File reputation checks**:** When a user attempts to download a file from the internet, Windows SmartScreen checks the reputation of that file. If the file is recognized and has a positive reputation, it is allowed to proceed. If the file is unknown or has a questionable reputation, Windows SmartScreen may display a warning message to the user.
Application reputation checks**:** For executable files, Windows SmartScreen also checks the reputation of the application itself. If the application is known to be safe, the download and execution are allowed. If the application is not recognized or has a poor reputation, a warning may be shown to the user.
URL reputation checks**:** When users visit a website, Windows SmartScreen checks the reputation of the website’s URL. If the website is known to host malicious content, the user may be warned or prevented from accessing the site.
Mark of the Web (MOTW): Windows adds a zone identifier or Mark of the Web to files downloaded from the internet. This information is used to determine if a file originated from the internet, triggering additional security checks.

Mark of the Web (MOTW)

Security measures like SmartScreen and Protected View in Microsoft Office rely on the Mark of the Web (MOTW). Consequently, circumventing these security features simplifies the task for threat actors seeking to propagate malware through carefully crafted documents and other compromised files that would typically be intercepted by SmartScreen.

So again, the Mark of the Web (MOTW) is a security feature in Microsoft Windows that helps identify and manage files downloaded from the internet. When a file is downloaded from the web, Windows adds a special tag or identifier known as the Mark of the Web to that file. This identifier is stored as an Alternate Data Stream (ADS) in the file’s metadata.

An Alternate Data Stream (ADS) is a feature in the NTFS (New Technology File System) file system used by Windows. ADS allows additional data to be associated with a file in addition to its main data stream. In simpler terms, it enables the attachment of metadata or other information to a file, beyond what is typically seen by users.

The primary purpose of MOTW is to indicate the file’s origin — whether it came from a potentially untrusted source. Files marked with MOTW trigger additional security checks in Windows, especially when they are executed or opened. Here’s how MOTW is typically used:

Zone identification: The MOTW includes information about the security zone from which the file originated. For example, if a file is downloaded from the internet, it will have a specific MOTW indicating that it is from the “Internet Zone.”
Security checks: SmartScreen checks for the presence of MOTW when a user tries to run or open a file. If a file has the MOTW tag indicating it came from the internet, SmartScreen may perform additional reputation checks to determine if the file is potentially harmful.
Protected view in Microsoft Office: In Microsoft Office applications, such as Word and Excel, files with the MOTW tag may be opened in a restricted or protected view. This is an additional security measure to prevent potentially malicious content from affecting the system.

By using MOTW, Windows aims to provide users with a visual indication of the file’s origin and enable security features to apply additional scrutiny to files downloaded from the internet.

Authenticode signatures, SignedData, and Signerinfo structures

Authenticode signatures are a mechanism used in Microsoft Windows to digitally sign executable files, scripts, and software components. These signatures are employed to verify the integrity and authenticity of the signed content. When an application or file is digitally signed using Authenticode, it indicates that the software has not been altered or tampered with since the time of signing and that it originates from a known and trusted source.

The process of creating an Authenticode signature involves generating a digital signature using a private key. This signature is then embedded within the file or its associated structure. The verification of the signature involves using the corresponding public key to ensure the signature is valid and that the file has not been modified.

SignedData structures are a key component in the Authenticode signature process. These structures are part of the Cryptographic Message Syntax (CMS) standard and are used to encapsulate the cryptographic signature along with the original data. In the context of Authenticode, the SignedData structure includes information about the signer, the digital signature itself, and the hash values of the signed content.

The SignerInfo structure is also a component of this Cryptographic Message Syntax (CMS) standard, which is used in various security protocols and applications to represent digitally signed data. Each SignerInfo structure represents the information associated with a specific signer, including the digital signature created by that signer. The SignedData structure encapsulates one or more SignerInfo structures along with other relevant information. This encapsulation allows for the representation of multiple signers if the data is signed by more than one entity. Keep this in mind, because will have some relevance in the attack.

In summary, the SignedData structure acts as a container for the entire signed message, including content and signatures, while the SignerInfo structure provides signer-specific information within that container. Together, they enable the representation of a digitally signed message with multiple signers, each contributing their own SignerInfo structure to the overall SignedData.

By using SignedData structures in conjunction with Authenticode signatures, Windows operating systems can verify the authenticity and integrity of executable files and other software components, helping users and systems to make informed decisions about the trustworthiness of the code they are executing.

Magniber ransomware

First of all, let’s clarify what is a ransomware.

Ransomware is a type of malicious software designed to block access to a computer system or files until a sum of money, often in the form of cryptocurrency like Bitcoin, is paid to the attackers. It is a form of cyber extortion where the victim’s files or system are encrypted, making them inaccessible. The attackers then demand a ransom from the victim in exchange for providing the decryption key or tool to restore access. Ransomware attacks can target individuals, businesses, or even entire networks, and the motives behind such attacks are often financial gain. These attacks can occur through various means, including phishing emails, malicious websites, or exploiting vulnerabilities in software and systems.

Magniber ransomware was initially detected in late 2017, utilizing the Magnitude Exploit Kit for malvertising campaigns targeting South Korean users. Despite its early identification, Magniber has stayed operational, consistently adapting by incorporating new ways to hide its true nature and avoid detection. In April 2022, Magniber made headlines by pretending to be a Windows update file, tricking victims into installing it. Later, in September 2022, it switched to using JavaScript for its propagation method. This showcases Magniber’s ongoing efforts to evolve its strategies and maintain its presence in the cyber threat landscape.

Here are some key points about Magniber Ransomware that are of course not unique in case of ransomware:

Distribution: Magniber is typically distributed through malvertising campaigns and exploit kits. Malicious website advertisements may redirect users to sites hosting exploit kits, which then deliver the ransomware payload.
Payload Delivery: The ransomware payload is often delivered using various methods, including phishing emails, malicious websites, or malvertising. Once a system is infected, Magniber encrypts the files on the victim’s computer, rendering them inaccessible.
Encryption: Magniber employs strong encryption algorithms to encrypt files on the victim’s system. Commonly targeted file types include documents, images, videos, and other important data.
Ransom Note: After completing the encryption process, Magniber typically leaves a ransom note on the victim’s desktop or in folders with encrypted files. This note contains instructions on how to pay the ransom to obtain the decryption key.
Payment in Bitcoin: Like many ransomware variants, Magniber typically demands payment in cryptocurrency, often Bitcoin. Victims are instructed to make the payment to a specific Bitcoin address provided by the attackers.
Evolution: Magniber has evolved, adapting its tactics and techniques to avoid detection and improve its infection capabilities. This includes changes in delivery methods and evasion techniques.
Targeting: While Magniber has predominantly targeted users in South Korea and Taiwan, it’s important to note that ransomware threats can potentially spread to other regions or be adapted for broader targeting.

The original SmartScreen vulnerability (CVE-2022–44698)

We underlined that CVE-2023–24880 is not an isolated vulnerability; rather, it stems from a preceding SmartScreen Bypass vulnerability, CVE-2022–44698, specifically identified in smartscreen.exe so first let's see the original issue and its semi-patch. But before that, clarify how the different components involved in this attack work.

As you may know, the explorer.exe is the Windows File Explorer process responsible for managing the desktop, file management, and the graphical user interface. It plays a crucial role in the Windows operating system, allowing users to navigate files, folders, and applications.

The shdocvw.dll is a dynamic-link library (DLL) file associated with the Shell Doc Object and Control Library. This library provides components and functions essential for the Windows shell's functioning (graphical user interface).

The AppReputationService interface is a component related to security features in Windows. It is involved in evaluating the reputation of applications to determine their trustworthiness or potential risk. This interface is likely connected to explorer.exe and shdocvw.dll through various mechanisms such as API calls or function calls.

In a simplified sequence of events, when a user interacts with files or applications through the Windows File Explorer (which is managed by explorer.exe), security checks may be initiated. These checks could involve components like shdocvw.dll, which may utilize the AppReputationService interface to assess the reputation of an application. This assessment helps the system decide whether to proceed with the requested action or present a security warning if the application is deemed potentially risky.

According to information in the 0patch blog, when the explorer.exe process executes a file, the shdocvw.dll module initiates a request to the AppReputationService interface, which is implemented in smartscreen.exe, to obtain a judgment.

The DoSafeOpenPromptForShellExec function in shdocvw.dll does not show a security warning by default. However, when smartscreen.exe runs into an error for any reason, DoSafeOpenPromptForShellExec continues with the default option so it executes the file without presenting any security warnings to the user.

In short, the case was: the bad actors sent out MSI files that had a fake signature. This fake signature messes up SmartScreen, causing it to make an error. As a result, the security warning that usually pops up when you download a suspicious file from the internet (marked with a MotW) doesn’t show up in this case.

More specifically, the security flaw is found in the DoSafeOpenPromptForShellExec function within the shdocvw.dll module. By default, this function does not trigger a security warning. Nevertheless, in the event of an error during the SmartScreen request, the function proceeds to execute the file without providing any warning to the user.

The Google Threat Analysis Group (TAG) also provided a pseudocode of the shdocvw.dll's related part (also, we rely on their analysis deeply):

The case in this attack was to let SmartScreen return with an error with a malformed signature of a JS file. This led to a bypass of the security warning.

The specific error occurred during the parsing of the file’s signature within the function windows::security::signature_info::retrieve in the smartscreen.exe process that invokes the WTGetSignatureInfo function in wintrust.dll that obtains the CERT_CONTEXT structure pointer (cert_context) and the wvt_state_data. The cert_context will then reference to the signer certificate which is typically the initial certificate in the certificate chain. Subsequently, the function utilizes WTHelperProvDataFromStateData on wvt_state_data, resulting in a CRYPT_PROVIDER_DATA structure pointer (crypt_provider_data). In the scenario where crypt_provider_data and its member hMsg are both non-NULL, but cert_context is NULL, an E_INVALIDARG error is triggered.

As we mentioned above, the SignerInfo structure contains information related to a specific signer or entity involved in the digital signature process. Here are the key components typically found in a SignerInfo structure:

Signer Identifier (Issuer and Serial Number): This component identifies the entity (signer) associated with the signature. It includes the issuer’s distinguished name and the serial number of the signer’s certificate. This information helps establish the signer’s identity.
Digest Algorithm: Specifies the hashing algorithm used to generate the message digest (hash) of the signed content. The hash is a crucial part of the digital signature process, ensuring the integrity of the signed data.
Authenticated Attributes: These are additional pieces of information that are included in the signature and are authenticated during the signature verification process. Examples include the signing time, the content type, and the message digest algorithm.
Digest Encryption Algorithm: Describes the algorithm used to encrypt the message digest. In public key cryptography, this involves using the signer’s private key to create the digital signature.
Encrypted Digest: This field contains the result of encrypting the message digest with the signer’s private key. It forms the actual digital signature that can be decrypted and verified using the corresponding public key.

The combination of these components allows the SignerInfo structure to provide comprehensive information about a specific signer, facilitating the verification of the digital signature's authenticity, integrity, and the signer's identity. In the context of protocols like Authenticode, the SignerInfo structure plays a crucial role in ensuring the trustworthiness of digitally signed executable files and software components.

Now, the attackers successfully obtained a NULL cert_context with an Authenticode signature in which the certificate serial number from SignerInfo cannot be located among the certificates in SignedData. As a result, wintrust.dll is unable to locate the certificate associated with the signer, causing WTGetSignatureInfo to return a cert_context value of NULL.

The first patch

In this section, we will show why the first patch was not enough and how it allowed one to still exploit the same issue in another way.

Microsoft addressed CVE-2022–44698 by modifying its behavior: instead of raising an error in the specific case described, the software now follows another path. This patch is not effective because smartscreen.exe uses THROW_HR in many situations when it encounters different errors. An attacker can exploit this by returning an error to shdocvw.dll, which will not show a security warning and allow the attack to proceed.

This is how the new bypass works. The signature in this case is valid, so the CVE-2022–44698 patch does not apply. Later, windows::security::signature_info::retrieve calls windows::security::authenticode_information::create. This function checks if crypt_provider_data->pPDSip->psIndirectData has a value. If it does not, it calls THROW_HR, which again returns an error to shdocvw.dll. Now, the attackers changed the ASN1 numerical identifier (NID) of the SPC_INDIRECT_DATA_OBJID, which is a special code that Authenticode uses to store information like the message digest of the signed file. This made crypt_provider_data->pPDSip->psIndirectData empty.

And this is how we reached CVE-2023–24880. Notably, in previous campaigns, the Magniber actors employed JS files, whereas in the later campaign, they used MSI files with a distinct type of malformed signature.

Mitigation

To mitigate the risks associated with this actively exploited vulnerability, it is strongly recommended to patch systems.

Final thoughts

In concluding this analysis, it’s evident that the cybersecurity landscape continues to face evolving threats that exploit intricate vulnerabilities in widely used operating systems. CVE-2023–24880, stemming from the earlier CVE-2022–44698, exemplifies the persistence and adaptability of threat actors seeking financial gains through ransomware attacks.

The timeline of events reveals a cat-and-mouse game between threat actors and security responders. The initial exploitation of CVE-2022–44698 in September 2022 led to Microsoft’s patch in December of the same year. However, the attackers swiftly identified a new variant of the vulnerability, emphasizing the need for comprehensive and foresighted security measures. As seen in the SmartScreen case, a narrow patch may temporarily address one aspect, but without tackling the core problem, it paves the way for inventive attackers to uncover new variants.

The security community’s collaborative efforts, exemplified by Google’s Threat Analysis Group (TAG) promptly identifying and reporting the exploitation, highlight the importance of information sharing in mitigating such threats. However, the dual-pronged nature of the vulnerability, with its roots in both SmartScreen bypass and Authenticode signature manipulation, demands a holistic approach to future mitigation strategies.

Stay vigilant, stay updated, and stay secure!