{"id":120680,"date":"2022-08-24T10:00:00","date_gmt":"2022-08-24T17:00:00","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/?p=120680"},"modified":"2025-06-25T00:58:02","modified_gmt":"2025-06-25T07:58:02","slug":"magicweb-nobeliums-post-compromise-trick-to-authenticate-as-anyone","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2022\/08\/24\/magicweb-nobeliums-post-compromise-trick-to-authenticate-as-anyone\/","title":{"rendered":"MagicWeb: NOBELIUM\u2019s post-compromise trick to authenticate as anyone"},"content":{"rendered":"\n

April 2023 update<\/strong> \u2013 Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. NOBELIUM is now tracked as Midnight Blizzard<\/a><\/strong>.<\/p>\n\n\n\n

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy<\/a>.<\/p>\n\n\n\n

The Microsoft Detection and Response Team (DART) has been renamed to Microsoft Incident Response (Microsoft IR). For more information on IR services, go to Microsoft Incident Response<\/a><\/p>\n\n\n\n

August 26, 2022 update<\/strong>: Added instructions to enable collection of AD FS event logs<\/a> in order to search for Event ID 501, and added a new resource for AD FS audit logging in Microsoft Sentinel<\/a>.<\/p>\n\n\n\n

\n\n\n\n

Microsoft security researchers have discovered a post-compromise capability we\u2019re calling MagicWeb, which is used by a threat actor we track as NOBELIUM to maintain persistent access to compromised environments. NOBELIUM remains highly active, executing multiple campaigns in parallel targeting government organizations, non-governmental organizations (NGOs), intergovernmental organizations (IGOs), and think tanks across the US, Europe, and Central Asia. The Microsoft Threat Intelligence Center (MSTIC) assesses that MagicWeb was likely deployed during an ongoing compromise and was leveraged by NOBELIUM possibly to maintain access during strategic remediation steps that could preempt eviction.<\/p>\n\n\n\n

NOBELIUM has used abuse of identities and credentialed access as a method for maintaining persistence, and a specialized capability like MagicWeb is not novel for the actor: in September 2021, Microsoft disclosed a post-exploitation capability named FoggyWeb<\/a> with methods and intent similar to MagicWeb. FoggyWeb was capable of exfiltrating the configuration database of compromised AD FS servers, decrypting token-signing certificates<\/a> and token-decryption certificates<\/a>, and downloading and executing additional malware components. MagicWeb goes beyond the collection capabilities of FoggyWeb by facilitating covert access directly. MagicWeb is a malicious DLL that allows manipulation of the claims passed in tokens generated by an Active Directory Federated Services (AD FS) server. It manipulates the user authentication certificates used for authentication, not the signing certificates used in attacks like Golden SAML.<\/p>\n\n\n\n

NOBELIUM was able to deploy MagicWeb by first gaining access to highly privileged credentials and moving laterally to gain administrative privileges to an AD FS system. This is not a supply chain attack. The attacker had admin access to the AD FS system and replaced a legitimate DLL with their own malicious DLL, causing malware to be loaded by AD FS instead of the legitimate binary. The backdoor was discovered by Microsoft\u2019s Detection and Response Team (DART) in coordination with MSTIC and Microsoft 365 Defender Research during an ongoing incident response investigation. Microsoft is sharing this information with consent from the client. At the time of this investigation, MagicWeb appears to be highly targeted.<\/p>\n\n\n\n

Like domain controllers, AD FS servers can authenticate users and should therefore be treated with the same high level of security. Customers can defend against MagicWeb and other backdoors by implementing a holistic security strategy including the AD FS hardening guidance<\/a>. In the case of this specific discovery, MagicWeb is one step of a much larger intrusion chain that presents unique detection and prevention scenarios.<\/p>\n\n\n\n

With all critical infrastructure such as AD FS, it is important to ensure attackers do not gain administrative access. Once attackers gain administrative access, they have many options for further system compromise, activity obfuscation, and persistence. We recommend that any such infrastructure is isolated, accessible only by dedicated admin accounts, and regularly monitored for any changes. Other security measures that can prevent this and other attacks include credential hygiene to prevent lateral movement. AD FS is an on-premises server, and as with all on-premises servers, deployments can get out of date and\/or go unpatched, and they can be impacted by local environment compromises and lateral movement. For these reasons, migration to a cloud-based identity solution such as Azure Active Directory<\/a> for federated authentication is recommended for the robust security it provides. See the mitigation section<\/a> below for more information. Though we assess the capability to be in limited use, Microsoft anticipates that other actors could adopt similar methodologies and therefore recommends customers review hardening and mitigation guidance provided in this blog.<\/p>\n\n\n\n

How MagicWeb subverts authentication<\/h2>\n\n\n\n

MagicWeb is a post-compromise malware that can only be deployed by a threat actor after gaining highly privileged access to an environment and moving laterally to an AD FS server. To achieve their goal of maintaining persistent access to an environment by validating authentication for any user account on the AD FS server, NOBELIUM created a backdoored DLL by copying the legitimate Microsoft.IdentityServer.Diagnostics.dll<\/em> file used in AD FS operations. The legitimate version of this file is catalog signed<\/a> by Microsoft and is normally loaded by the AD FS server at startup to provide debugging capabilities. NOBELIUM\u2019s backdoored version of the file is unsigned. The threat actor\u2019s highly privileged access that allowed them to access the AD FS server meant they could have performed any number of actions in the environment, but they specifically chose to target an AD FS server to facilitate their goals of persistence and information theft during their operations.<\/p>\n\n\n\n

After gaining administrative access to an AD FS server via elevation of privilege and lateral movement, the loading of NOBELIUM\u2019s malicious Microsoft.IdentityServer.Diagnostics.dll<\/em> <\/a>into the AD FS process is possible by editing C:\\Windows\\AD FS\\Microsoft.IdentityServer.Servicehost.exe.config<\/em> to specify a different public token, which controls what loads into the AD FS process when it is started. Because AD FS is a .NET application, it loads the DLLs specified in the config file from the Global Assembly Cache<\/a> (GAC). By changing the token in the configuration, the adversary directed AD FS to load in the malicious DLL. The interception and manipulation of claims by MagicWeb enables the actor to generate tokens that allow the adversary to bypass AD FS policies (role policies, device policies, and network policies) and sign in as any user with any claims, including multifactor authentication (MFA).<\/p>\n\n\n\n

\"Screenshot
Figure 1. C:\\Windows\\AD FS\\Microsoft.IdentityServer.Servicehost.exe.config<\/em> being set to load Microsoft.IdentityServer.Diagnostics.dll<\/em><\/figcaption><\/figure>\n\n\n\n
\"Screenshot
Figure 2. NOBELIUM uses a different public token than the legitimate Microsoft.IdentityServer.Diagnostics.dll<\/em>, telling AD FS to look for a different file in the GAC<\/figcaption><\/figure>\n\n\n\n
\"Partial
Figure 3. Close up from Microsoft.IdentityServer.Servicehost.exe.config<\/em> showing MagicWeb\u2019s malicious PublicKeyToken <\/em>compared to the PublicKeyToken <\/em>of the legitimate version of the DLL<\/figcaption><\/figure>\n\n\n\n
\"Screenshot
Figure 4. The directories in the GAC on a server infected with MagicWeb; the malicious Microsoft.IdentityServer.Diagnostics.dll<\/em> file and the legitimate one are located in different directories<\/figcaption><\/figure>\n\n\n\n

To understand how NOBELIUM can subvert the AD FS process with the MagicWeb malware, it\u2019s important to understand how AD FS claims work. AD FS extends the ability to use single sign-on functionality available within a single security or enterprise boundary to internet-facing applications to provide customers, partners, and suppliers a streamlined user experience while accessing an organization\u2019s web-based applications. AD FS relies on claims-based authentication<\/a> to validate the identity of the user and their authorization claims. These claims are packaged into a token that can be used for authentication. MagicWeb injects itself into the claims process to perform malicious actions outside the normal roles of an AD FS server.<\/p>\n\n\n\n

\"Diagram
Figure 5. How the AD FS claims pipeline issues a token for a user entering a federated application<\/figcaption><\/figure>\n\n\n\n

Security Assertion Markup Language (SAML)<\/a> uses x509 certificates to establish trust relationships between identity providers and services and to sign and decrypt tokens. These x509 certificates contain enhanced key usage (EKU) values that specify what applications the certificate should be used for. For instance, an EKU containing an Object Identifier (OID) value of 1.3.6.1.4.1.311.20.2.2 would allow for the use of a SmartCard logon. Organizations can create custom OIDs to further narrow certificate usage.<\/p>\n\n\n\n

MagicWeb\u2019s authentication bypass comes from passing a non-standard Enhanced Key Usage OID that is hardcoded in the MagicWeb malware during an authentication request for a specified User Principal Name. When this unique hard coded OID value is encountered, MagicWeb will cause the authentication request to bypass all standard AD FS processes (including checks for MFA) and validate the user\u2019s claims. MagicWeb is manipulating the user authentication certificates used in SAML sign-ins, not the signing certificates for a SAML claim used in attacks like Golden SAML.<\/p>\n\n\n\n

\"Screenshot
Figure 6. Example of a user certificate accepted by MagicWeb; the highlighted numbers under \u201cUnknown Key Usage\u201d is one of two OIDs hardcoded into MagicWeb<\/figcaption><\/figure>\n\n\n\n
\"Screenshot
Figure 7. Example of a user certificate chain, which shows an invalid digital signature but still works for authentication<\/figcaption><\/figure>\n\n\n\n

NOBELIUM uses unique tradecraft per target, so it\u2019s highly likely that the OIDs and public tokens are unique per target as well. We\u2019ve redacted these OIDs and tokens in this report. Please see the hunting guidance<\/a> section for information on how to look for variants related to this attack.<\/p>\n\n\n\n

<\/a>How to mitigate this threat<\/h2>\n\n\n\n

NOBELIUM\u2019s ability to deploy MagicWeb hinged on having access to highly privileged credentials that had administrative access to the AD FS servers, giving them the ability to perform whatever malicious activities they wanted to on the systems they had access to.<\/p>\n\n\n\n

It\u2019s critical to treat your AD FS servers as a Tier 0<\/a> asset, protecting them with the same protections you would apply to a domain controller or other critical security infrastructure. AD FS servers provide authentication to configured relying parties, so an attacker who gains administrative access to an AD FS server can achieve total control of authentication to configured relying parties (include Azure AD tenants configured to use the AD FS server). Practicing credential hygiene is critical for protecting and preventing the exposure of highly privileged administrator accounts. This especially applies on more easily compromised systems like workstations with controls like logon restrictions<\/a> and preventing lateral movement to these systems with controls like the Windows Firewall.<\/p>\n\n\n\n

Migration to Azure Active Directory (Azure AD) authentication is recommended to reduce the risk of on-premises compromises moving laterally to your authentication servers. Customers can use the following references on migration:<\/p>\n\n\n\n