Microsoft’s Threat Intelligence Center (MSTIC) have recently discovered a new malware capability that NOBELIUM are using called MagicWeb. Highly active threat actor NOBELIUM are known for targeting organisations across Europe, Central Asia, and the USA. First detected in 2020, they use unique malware that is usually tailored to their current target. The MagicWeb malware is deployed by the threat actors in already compromised systems, in order to create a backdoor to maintain access, and prevent future remediation by the target organisation that could precede eviction of the attacker.  

MagicWeb is not the first of its type to be used by NOBELIUM. In 2021, a similar piece of malware known as FoggyWeb was used to exfiltrate the configuration of Active Directory Federated Services (AD FS) servers, decrypt tokens, and download and execute additional components. FoggyWeb, like MagicWeb, exists as a persistent backdoor into previously compromised networks, to actively prevent the threat actor’s access from being repaired and the attackers evicted. Both versions of this malware target the AD FS servers, but unlike FoggyWeb, MagicWeb has been found to have the ability to facilitate the covert access for the attackers directly, rather than needing additional capabilities to establish a backdoor.  

Before NOBELIUM can deploy MagicWeb in a network, they first need to obtain highly privileged credentials and administrative privileges in the AD FS system. In their initial attack, NOBELIUM will execute elevation of privilege, then move laterally to obtain administrative access to an AD FS server. They can then implement MagicWeb as a post-compromise attack that allows them to authenticate as anyone. It is currently believed that MagicWeb is highly targeted, however other threat actors could use similar methodologies now that this information has been publicly disclosed. Microsoft have released a security blog post this week, after they discovered one of these backdoors during an ongoing incident response investigation with one of their clients. 

The target of this malware, the AD FS server, is a .NET application that evaluates  authentication claims coming from Security Assertion Markup Language (SAML) Single Sign-On (SSO) websites and web-based applications. It uses claims-based authentication to validate the identity of the user that is attempting to gain access. MagicWeb works by injecting itself into the claims process, before a security token is packaged and sent to the user to authenticate the sign-on. MagicWeb uses a hardcoded non-standard key during the authentication request process, in order to bypass the standard AD FS processes for validating a user, including bypassing any multi-factor authentication (MFA) checks.  

NOBELIUM create the backdoor with MagicWeb by copying the legitimate AD FS dynamic link library (DLL) file, Microsoft.IdentityServer.Diagnostics.dll. A copy can be identified as the legitimate file will be catalog signed by Microsoft, but the backdoored version of the file is unsigned. They do this by editing C:WindowsADFSMicrosoft.IdentityServer.Servicehost.exe.config and add malicious code to the TraceLog class, which adds a static constructor. This is used to guarantee that the malicious code is run before any legitimate code during the startup, as a different public token is specified, which controls what loads in the AD FS startup process. The DLL file is specified in the config file from the Global Assembly Cache (GAC), a code cache that stores assemblies needed to be shared by several different application on the same machine. 

The legitimate DLL file is normally loaded during AD FS startup to perform debugging capabilities. Instead, the threat actors modified file is executed, which contains a reference to the Initialize() method from the AuthLog class. AuthLog is a malicious class added by the threat actor, and the Initialize() method it contains references another NOBELIUM-added malicious class, RuntimeHelper. This is used to hook legitimate AD FS methods at runtime, through the use of its OverloadMethod() method. This hook allows the backdoor to intercept calls to legitimate methods, and instead run its own malicious methods. It can then bypass all policies, including role policies, device policies, and network policies, to sign in any user with any claims, including bypassing any need for MFA.  

No indicators of compromise (IOCs) have been shared for this malware, however as NOBELIUM customise their attacks for each target, it is likely that any previously identified IOCs would not match the static IOCs in an ongoing attack. Microsoft advise that one way to check for an infection with this sort of malware is through the presence of an unsigned DLL in the GAC. Through a PowerShell query, the catalog signature on the legitimate DLL can be viewed when the DLL is loaded. By crafting a list of servers to scan in a .txt file, a script containing get-authenticodesignature can be run to enumerate any non-Microsoft signed DLLs. As the copy used by MagicWeb is unsigned, this search can identify its presence in the network. A similar search can also be performed in Microsoft 365 Defender rather than in PowerShell.  

Clues that your network has been compromised can also be found in the event logs (as is always the case!) provided the AD FS logging is configured correctly.  According to Microsoft, you can: 

Hunt across Windows Event Logs by enabling AD FS verbose logging. Enable security auditing to allow collection of the AD FS event logs, and specifically look for Event ID 501. This event specifies all the EKU attributes on a claim. Hunt across these logs to look for EKU values which your PKI infrastructure isn’t configured to issue. 

AD FS servers are considered critical infrastructure, as they provide authentication, so they need to be protected with the same levels of protection used for a domain controller or other critical security infrastructure. Attackers gaining administrative access can not only perform the actions targeted by MagicWeb, but also have the ability to compromise the system further, and obfuscate their activity. To prevent administrative access, critical infrastructure in AD FS environments can be isolated, and regularly monitored with dedicated admin accounts as the only point of access. Guidance on AD FS hardening can be found on Microsoft’s website. Another consideration when using AD FS systems is that they use on-premises servers, so it is essential for the security of these systems that these servers do not become out of date or go unpatched, to best mitigate the risks of on-site compromise and lateral movement.