Microsoft continues to work with partners and customers to track and expand our knowledge of the threat actor we refer to as NOBELIUM, the actor behind the [SUNBURST backdoor, TEARDROP malware, and related components](). As we stated before, we suspect that NOBELIUM can draw from significant operational resources often showcased in their campaigns, including custom-built malware and tools. In March 2021, we profiled NOBELIUM’s [GoldMax, GoldFinder, and Sibot malware](), which it uses for layered persistence. We then followed that up with another post in May, when we analyzed the actor’s early-stage toolset comprising [EnvyScout, BoomBox, NativeZone, and VaporRage](). This blog is another in-depth analysis of newly detected NOBELIUM malware: a post-exploitation backdoor that Microsoft Threat Intelligence Center (MSTIC) refers to as **FoggyWeb**. As mentioned in previous blogs, NOBELIUM employs multiple tactics to pursue credential theft with the objective of gaining admin-level access to Active Directory Federation Services ([AD FS]()) servers. Once NOBELIUM obtains credentials and successfully compromises a server, the actor relies on that access to maintain persistence and deepen its infiltration using sophisticated malware and tools. NOBELIUM uses FoggyWeb to remotely exfiltrate the configuration database of compromised AD FS servers, decrypted [token-signing certificate](), and [token-decryption certificate](), as well as to download and execute additional components. Use of FoggyWeb has been observed in the wild as early as April 2021. Microsoft has notified all customers observed being targeted or compromised by this activity. If you believe your organization has been compromised, we recommend that you * Audit your on-premises and cloud infrastructure, including configuration, per-user and per-app settings, forwarding rules, and other changes the actor might have made to maintain their access * Remove user and app access, review configurations for each, and re-issue new, strong credentials following documented industry best practices. * Use a _[hardware security module (HSM)]()_ as described in [securing AD FS servers]() to prevent the exfiltration of secrets by FoggyWeb. Microsoft security products have implemented detections and protections against this malware. Indicators of compromise (IOCs), mitigation guidance, detection details, and hunting queries for Azure Sentinel and Microsoft 365 Defender customers are provided at the end of this analysis and in the product portals. Active Directory Federation Services ([AD FS]()) servers run on-premises and customers can also follow detailed guidance on [securing AD FS servers ]()against attacks. ## FoggyWeb: Backdoor targeting AD FS FoggyWeb is a passive and highly targeted backdoor capable of remotely exfiltrating sensitive information from a compromised AD FS server. It can also receive additional malicious components from a command-and-control (C2) server and execute them on the compromised server. After compromising an AD FS server, NOBELIUM was observed dropping the following two files on the system (administrative privileges are required to write these files to the folders listed below): * _%WinDir%\ADFS\version.dll_ * _%WinDir%\SystemResources\Windows.Data.TimeZones\pris\Windows.Data.TimeZones.zh-PH.pri_ FoggyWeb is stored in the encrypted file _Windows.Data.TimeZones.zh-PH.pri_, while the malicious file _version.dll_ can be described as its loader. The AD FS service executable _Microsoft.IdentityServer.ServiceHost.exe_ loads the said DLL file via the [DLL search order hijacking]() technique that involves the core Common Language Runtime (CLR) DLL files (described in detail in the FoggyWeb loader section). This loader is responsible for loading the encrypted FoggyWeb backdoor file and utilizing a custom Lightweight Encryption Algorithm (LEA) routine to decrypt the backdoor in memory. After de-obfuscating the backdoor, the loader proceeds to load FoggyWeb in the execution context of the AD FS application. The loader, an unmanaged application, leverages the CLR hosting interfaces and APIs to load the backdoor, a managed DLL, in the same Application Domain within which the legitimate AD FS managed code is executed. This grants the backdoor access to the AD FS codebase and resources, including the AD FS configuration database (as it inherits the AD FS service account permissions required to access the configuration database). ![Diagram showing structure of Microsoft.IdentityServer.ServiceHost.exe after loading version.dll](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig1-FoggyWeb-NOBELIUM.png) When loaded, the FoggyWeb backdoor (originally named _Microsoft.IdentityServer.WebExtension.dll_ by its developer) functions as a passive and persistent backdoor that allows abuse of the Security Assertion Markup Language (SAML) token. The backdoor configures HTTP listeners for actor-defined URIs that mimic the structure of the legitimate URIs used by the target’s AD FS deployment. The custom listeners passively monitor all incoming HTTP GET and POST requests sent to the AD FS server from the intranet/internet and intercept HTTP requests that match the custom URI patterns defined by the actor. This version of FoggyWeb configures listeners for the following hardcoded URI patterns (which might vary per target): * HTTP GET URI pattern: * _/adfs/portal/images/theme/light01/profile.webp_ * _/adfs/portal/images/theme/light01/background.webp_ * _/adfs/portal/images/theme/light01/logo.webp_ * HTTP POST URI pattern: * _/adfs/services/trust/2005/samlmixed/upload_ Each HTTP GET/POST URI pattern above corresponds to a C2 command: * When the AD FS server receives an HTTP GET request containing the URI pattern _/adfs/portal/images/theme/light01/profile.webp_, the backdoor retrieves the **_token signing certificate_** of the compromised AD FS server and then obfuscates and returns the certificate to the issuer of the request. * Similarly, when the AD FS server receives an HTTP GET request containing the URI pattern _/adfs/portal/images/theme/light01/background.webp_, the backdoor retrieves the **_token decryption certificate_** of the compromised AD FS server and then obfuscates and returns the certificate to the issuer of the request. * When the AD FS server receives an HTTP GET request containing the URI pattern _/adfs/portal/images/theme/light01/logo.webp_, the backdoor retrieves the AD FS configuration data of the compromised server, obfuscates the data, and returns the obfuscated data to the issuer of the request. * When the AD FS server receives an HTTP POST request containing the URI pattern _/adfs/services/trust/2005/samlmixed/upload_, the backdoor treats the obfuscated and compressed POST data as either .NET assembly or source code. If assembly, the backdoor executes the assembly in the execution context of the AD FS process. If source code, the backdoor dynamically compiles the source code and proceeds to execute the resulting memory-resident assembly in the execution context of the AD FS process. The diagram below illustrates the methodology used by the actor to communicate with the FoggyWeb backdoor located on a compromised internet-facing AD FS server. ![Diagram showing FoggyWeb attack chain](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig2-FoggyWeb-NOBELIUM.png) Since FoggyWeb runs in the context of the main AD FS process, it inherits the AD FS service account permissions required to access the AD FS configuration database. This contrasts with tools such as _ADFSDump_ that must be executed under the user context of the AD FS service account. Also, because FoggyWeb is loaded into the same application domain as the AD FS managed code, it gains programmatical access to the legitimate AD FS classes, methods, properties, fields, objects, and components that are subsequently leveraged by FoggyWeb to facilitate its malicious operations. For example, this allows FoggyWeb to gain access to the AD FS configuration data without connecting to the WID named pipe or manually running SQL queries to retrieve configuration information (for example, to obtain the _EncryptedPfx_ blob from the configuration data). FoggyWeb is also AD FS version-agnostic; it does not need to keep track of legacy versus modern configuration table names and schemas, named pipe names, and other version-dependent properties of AD FS. ### FoggyWeb loader The file _version.dll_ is a malicious loader responsible for loading an encrypted backdoor file from the file system, decrypting the backdoor file, and loading it in memory. This malicious DLL, which shares a name with a legitimate Windows DLL located in the _%WinDir%\System32\_ folder, is meant to be placed in the main AD FS folder _%WinDir%\ADFS\_, where the AD FS service executable _Microsoft.IdentityServer.ServiceHost.exe_ is located (for reasons described later in this section). When the AD FS service (_adfssrv_) is started, the service executable _Microsoft.IdentityServer.ServiceHost.exe_ gets executed. As a .NET-based managed application, _Microsoft.IdentityServer.ServiceHost.exe_ imports an unmanaged Windows DLL named _mscoree.dll_. ![Screenshot showing Microsoft.IdentityServer.ServiceHost.exe importing mscoree.dll.](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig3-FoggyWeb-NOBELIUM.png) The file_ mscoree.dll_ dynamically loads another unmanaged Windows/CLR DLL named _mscoreei.dll_. As shown below, _mscoreei.dll_ has a delay load import (Delay Import) named _version.dll_. ![Screenshot showing mscoreei.dll has a delay load import \(Delay Import\) named version.dll](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig4-FoggyWeb-NOBELIUM.png) NOBELIUM, with existing administrative permissions, was observed to drop a malicious loader named _version.dll_ in the _%WinDir%\ADFS\_ folder where the AD FS service executable _Microsoft.IdentityServer.ServiceHost.exe_ is located. Once the system or the AD FS service is restarted, _Microsoft.IdentityServer.ServiceHost.exe_ loads _mscoree.dll_, which in turn loads _mscoreei.dll_. As mentioned above, _mscoreei.dll_ has a delay load import named _version.dll_. Once loaded, instead of loading the legitimate _version.dll_ from the _%WinDir%\System32\_ folder _mscoreei.dll_ loads the malicious _version.dll_ planted by the attacker in _%WinDir%\ADFS\_ folder (referred to as [DLL search order hijacking]()), as shown in the call stack below. ![Screenshot of call stack showing folder mscoreei.dll loads the malicious version.dll planted by the attacker in %WinDir%\\ADFS\\ folder ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig5-FoggyWeb-NOBELIUM.png) The malicious loader _version.dll_ behaves as a proxy for all legitimate _version.dll_ export function calls. As shown below, it exports the same 17 function names as the legitimate version of _version.dll_. ![Screenshot of dump of the legitimate version.dll ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig6af-FoggyWeb-NOBELIUM.png) ![Screenshot of the malicious version.dll ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig6b-FoggyWeb-NOBELIUM.png) The export functions of the malicious _version.dll_ are all short stubs that call a single trampoline function labeled _TrampolineFunction_, as seen in the screenshot below. ![Screenshot of the export functions of the malicious version.dll ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig7-FoggyWeb-NOBELIUM.png) Below is a pseudocode for the trampoline function. ![Screenshot of pseudocode for the trampoline function](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig8-FoggyWeb-NOBELIUM.png) This trampoline function is responsible for the following: * Calling a function (labeled as _LoadDecryptExecuteBackdoor()_ by the analyst) to load a backdoor file from the file system, and then decrypting and executing the file in memory * Transferring execution to the initially called target function from the legitimate version of _version.dll_. The trampoline function preserves the value of the arguments/registers intended for the function from the legitimate version of _version.dll_ by saving the value of certain CPU registers. It first pushes them onto the stack before calling the _LoadDecryptExecuteBackdoor()_ function above and then restoring them before transferring execution to the function from the legitimate version of _version.dll_. ![Screenshot of code showing trampoline function preserves the value of the arguments/registers intended for the function from the legitimate version of version.dll by saving the value of certain CPU register](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig9-FoggyWeb-NOBELIUM.png) When called, _LoadDecryptExecuteBackdoor()_ attempts to create a Windows event named _{2783c149-77a7-5e51-0d83-ac0566daff96}_ to ensure that only one copy of the loader is actively running on the system. In a new thread, it then checks if the following file is present (hardcoded path string): _C:\Windows\SystemResources\Windows.Data.TimeZones\pris\Windows.Data.TimeZones.zh-PH.pri_ _Windows.Data.TimeZones.zh-PH.pri_ is an encrypted backdoor file that is placed in the folder above. MSTIC refers to this backdoor file as FoggyWeb, and our analysis is in the next section. _Microsoft.IdentityServer.ServiceHost.exe_ in and of itself is an unmanaged Windows executable that is generated when the high-level AD FS managed code is compiled. When executed, the unmanaged code inside _Microsoft.IdentityServer.ServiceHost.exe_ leverages Common Language Runtime (CLR) to run the managed AD FS code within a virtual runtime environment. This virtual runtime environment is comprised of one or more application domains, which provide a unit of isolation for the runtime environment and allow different applications to run inside separate containers within a process. The managed AD FS code is executed within an application domain inside the virtual runtime environment. The FoggyWeb backdoor (also a managed DLL) is intended to run alongside the legitimate AD FS code (that is, within the same application domain). This means that for the FoggyWeb loader to load the backdoor alongside the AD FS code, it needs to gain access to the same application domain that the AD FS code is executed within. Since the FoggyWeb loader _version.dll_ is an unmanaged application, it cannot directly access the virtual runtime environment that the managed AD FS code is executed within. The loader overcomes this limitation and loads the backdoor alongside the AD FS code by leveraging the CLR hosting interfaces and APIs to access the virtual runtime environment within which the AD FS code is executed. The loader performs the following high-level actions: * Enumerate all CLRs loaded in the AD FS process _Microsoft.IdentityServer.ServiceHost.exe_ * For each CLR, enumerate all running application domains and perform the following actions for each domain: * Read the contents of the following encrypted FoggyWeb backdoor file into memory: _C:\Windows\SystemResources\Windows.Data.TimeZones\pris\Windows.Data.TimeZones.zh-PH.pri_ * Decrypt the encrypted FoggyWeb backdoor file using the Lightweight Encryption Algorithm (LEA). The LEA-128 key schedule uses the following hardcoded master key to generate the round keys: ![Screenshot of hardcoded master key to generate the round keys](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig10-FoggyWeb-NOBELIUM.png) After decrypting each 16-byte cipher block, the loader uses the following XOR key to decode each individual decrypted/plaintext block: ![Screenshot of XOR key to decode each individual decrypted/plaintext block](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig11-FoggyWeb-NOBELIUM.png) This is equivalent to first LEA decrypting the entire file and then XOR decoding the decrypted data (instead of decrypting and XOR decoding each individual 16-byte block). * * Create a Safe Array and copy the decrypted FoggyWeb backdoor bytes to the array. It then calls the _Load()_ function for the current application domain to load the FoggyWeb DLL into the application domain. After the FoggyWeb DLL is loaded into the current application domain, the loader invokes the following method from the DLL: _Microsoft.IdentityServer.WebExtension.WebHost_. At this point in the execution cycle, the FoggyWeb DLL is loaded into one or more application domains where the legitimate AD FS code is running. This means the backdoor code runs alongside the AD FS code with the same access and permissions as the AD FS application. Because the backdoor is loaded in the same application domain as the AD FS code, it gains programmatical access to the legitimate classes, methods, properties, fields, objects, and components used by various AD FS modules to carry out their legitimate functionality. Such access allows the FoggyWeb backdoor to directly interact with the AD FS codebase (that is, not an external disk-resident tool) and selectively invoke native AD FS methods needed to facilitate its malicious operations. ### FoggyWeb backdoor This malicious memory-resident DLL (originally named _Microsoft.IdentityServer.WebExtension.dll_ by its developer) functions as a backdoor targeting AD FS. It is loaded by the main AD FS service process _Microsoft.IdentityServer.ServiceHost.exe_ through a malicious loader component. When loaded, the backdoor starts an HTTP listener that listens for HTTP GET and POST requests containing the following URI patterns: * HTTP GET URI pattern: _/adfs/portal/images/theme/light01/_ * HTTP POST URI pattern: _/adfs/services/trust/2005/samlmixed/upload_ As shown below, the URI patterns are hardcoded in the backdoor and mimic the structure of the legitimate URIs used by the target’s AD FS deployment. ![Screenshot of backdoor structure that mimic the structure of the legitimate URIs used by the target’s AD FS deployment.](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig12-FoggyWeb-NOBELIUM.png) Once the backdoor receives an HTTP request that contains one of the URI patterns above, the listener proceeds to handle the request using either an HTTP GET or HTTP POST callback/handler method (_ProcessGetRequest()_ and _ProcessGetRequest()_, respectively). ![Screenshot of code showing the listener handling the request using either an HTTP GET or HTTP POST callback/handler method ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig13-FoggyWeb-NOBELIUM.png) #### HTTP GET handler The incoming HTTP GET requests that contain the URI pattern _/adfs/portal/images/theme/light01/_ are handled by backdoor’s _ProcessGetRequest()_ method. ![Screenshot of ProcessGetRequest\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig14-FoggyWeb-NOBELIUM.png) If an incoming HTTP GET request is issued for a file/resource with the file extension of _.webp_, the _ProcessGetRequest()_ method proceeds to handle the request. Otherwise, the request is ignored by the backdoor. Also, if the requested file name matches one of the three hardcoded names below, the backdoor treats the request as a C2 command issued by the attacker. ![Screenshot of code showing hardcoded names](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig15-FoggyWeb-NOBELIUM.png) The following URL patterns are treated as C2 commands: * _/adfs/portal/images/theme/light01/profile.webp_ * _/adfs/portal/images/theme/light01/background.webp_ * _/adfs/portal/images/theme/light01/logo.webp_ The first two C2 commands, _profile.webp_ and _background.webp_ (_UrlGetFileNames[0]_ and _UrlGetFileNames[1]_ in the screenshot above), are handled by calling the backdoor’s _Service.GetCertificate()_ method. ![Screenshot of code for Service.GetCertificate\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig16-FoggyWeb-NOBELIUM.png) As the name suggests, this method is responsible for retrieving an AD FS certificate (either the token- signing or the token encryption certificate, depending on the value of the _certificateType_ parameter passed to the method) from the AD FS service configuration database. **_Analyst note:_**_ Refer to the Appendix for an in-depth analysis of the __Service.GetCertificate() method and how it obtains and decrypts either the token signing or encryption certificate._ As shown in the screenshot above, when the C2 command _profile.webp_ (_UrlGetFileNames[0]_) is issued to the backdoor (by issuing an HTTP GET request for the URI _/adfs/portal/images/theme/light01/profile.webp_), the backdoor retrieves the **_token-signing certificate_** of the compromised AD FS server. Similarly, when the C2 command _background.webp_ (_UrlGetFileNames[1]_) is issued to the backdoor (by issuing an HTTP GET request for the URI _/adfs/portal/images/theme/light01/background.webp_), the backdoor retrieves the **_token encryption certificate_** of the compromised AD FS server. The third C2 command, _logo.webp_ (_UrlGetFileNames[2]_), is triggered by sending an HTTP GET request to the following URI: _/adfs/portal/images/theme/light01/logo.webp_. The C2 command is handled by calling the backdoor’s _GetInfo()_ method. ![Screenshot of code for the backdoor’s GetInfo\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig17-FoggyWeb-NOBELIUM.png) The _GetInfo()_ method is responsible for dumping the AD FS service configuration data of the compromised server. ![Screenshot of GetInfo\(\) method dumping the AD FS service configuration data ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig18-FoggyWeb-NOBELIUM.png) As shown above, the AD FS service configuration data is obtained via the _ServiceSettingsData_ property, which retrieves the data from the AD FS service configuration database, Windows Internal Database (WID). Before returning the output of the C2 commands (that is, the token-signing certificate, the token encryption certificate, or the AD FS service configuration data) to the C2 in an HTTP 200 response, the backdoor first obfuscates the output by calling its method named _GetWebpImage()_. ![Screenshot of code for GetWebpImage\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig19-FoggyWeb-NOBELIUM.png) The _GetWebpImage()_ method is in charge of masquerading the output of the C2 commands as a legitimate WebP file (by adding appropriate RIFF/WebP file header magic/fields) and encoding the resulting WebP file. ![Screenshot of code for GetWebpImage\(\) method masquerading the output of the C2 ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig20-FoggyWeb-NOBELIUM.png) _GetWebpImage()_ uses the following helper methods to create and encode the fake WebP file that contains the C2 command output: * _GetWebpImage()_ first invokes the _Webp.GetFrame()_ method, which is responsible for compressing the output of the C2 command and copying the compressed version to a new array (0 padded to a multiple of 32 bytes). The length of the compressed data is added as the first four bytes of the new array. ![Screenshot of code for GetWebpImage\(\) first invoking the Webp.GetFrame\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig21-FoggyWeb-NOBELIUM.png) To compress the data, _GetFrame()_ invokes the _Common.Compress()_ method, which is used to compress the data by leveraging the C# GZipStream compression class. ![Screenshot of code for GetFrame\(\) invokes the Common.Compress\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig22-FoggyWeb-NOBELIUM.png) For demonstration purposes, assume the C2 command yields the following data (a 256-byte pseudo-randomly generated byte array). _![Screenshot of a 256-byte pseudo-randomly generated byte array](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig23-FoggyWeb-NOBELIUM.png)_ Given the data above (that is, sample C2 command output), _GetFrame()_ returns the following byte array. ![Screenshot of byte array returend by GetFrame\(\) ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig24-FoggyWeb-NOBELIUM.png) * Next, _GetWebpImage()_ invokes the _Webp.GetWebpHeader()_ method, passing in the size of the byte array returned by _GetFrame()_ in the step above. _GetWebpHeader()_ is responsible for creating and returning an array containing custom RIFF WebP file magic/header bytes. ![Screenshot of code for GetWebpImage\(\) invoking the Webp.GetWebpHeader\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig25-FoggyWeb-NOBELIUM.png) The array variable above contains the following 32-byte hardcoded RIFF/WebP header bytes. ![Screenshot of 32-byte hardcoded RIFF/WebP header bytes](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig26-FoggyWeb-NOBELIUM.png) If the size of the array passed to _GetWebpHeader()_ (returned by _GetFrame()_) exceeds 8,192 bytes, the bytes at index 26 and 28 of the header bytes (initially set to 0x00) are replaced with 0x80. Otherwise, the bytes at index 26 and 28 are replaced with 0x40, as shown below. ![Screenshot showing the bytes at index 26 and 28 being replaced with 0x40](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig27-FoggyWeb-NOBELIUM.png) _ __GetWebpHeader()_ then returns the custom RIFF/WebP header above to _GetWebpImage()_. * Next, _GetWebpImage()_ creates a new array by appending the custom RIFF/WebP header bytes returned by _GetWebpHeader()_ to the array returned by _GetFrame()_ (the array containing the compressed version of the C2 command output). _![Screenshot of new array creating GetWebpImage\(\) ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig28-FoggyWeb-NOBELIUM.png) _ _GetWebpImage()_ calls the _Common.ProtectData()_ method of the backdoor to encode the portion of the new array that contains the compressed bytes (that is, it does not encode the custom RIFF/WebP header). As the second argument, _GetWebpImage()_ passes the offset of the first compressed byte to _ProtectData()_ (as shown in the table above, 0x20 or 32 is the offset of the first compressed byte in this case). _ProtectData()_ uses a _dynamic_ XOR key and a custom XOR methodology to XOR encode the compressed data. _![Screenshot of code for ProtectData\(\) using a dynamic XOR key and a custom XOR methodology to XOR encode the compressed data](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig29-FoggyWeb-NOBELIUM.png) _ Initially, the 12-byte hardcoded XOR key array contains the following (seed) bytes. ![Screenshot of seed bytes](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig30-FoggyWeb-NOBELIUM.png) As shown in the screenshot above, each byte of compressed data is XOR’d with a byte from the XOR key array. The first byte of the compressed data (0x17) is XOR’d with the XOR key byte located at offset 8 of the key array (0x77). ![Screenshot showing the first byte of the compressed data](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig31-FoggyWeb-NOBELIUM.png) After XOR’ing the first byte of the compressed data with the XOR key byte located at offset 8 of the key array, the XOR key byte itself gets overwritten with a new value. ![Screenshot of the XOR key byte overwritten with a new value](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig32-FoggyWeb-NOBELIUM.png) For example, the XOR key byte located at offset 8 of the XOR key array (0x77) gets overwritten with 0xEE via the following operations. ![Screenshot of XOR key byte located at offset 8 of the XOR key array \(0x77\) overwritten with 0xEE](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig33-FoggyWeb-NOBELIUM.png) The second byte of the compressed data (0x01) is XOR’d with the XOR key byte located at offset 9 of the key array (_33 % 12 = 9_) and so on until the key rolls to the first byte of the XOR array (as mentioned above, the XOR key bytes get overwritten after each encoding operation). Below is the XOR encoded version of the sample compressed array. ![Screenshot of the second byte of the compressed data ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig34-FoggyWeb-NOBELIUM.png) After the steps outlined above, _GetWebpImage()_ returns the following sample data to the method that invokes it to obfuscate and conceal the output of each C2 command (_ProcessGetRequest()_). ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig35g-FoggyWeb-NOBELIUM.png) As previously mentioned, _ProcessGetRequest()_ returns the fake RIFF/WebP file generated above (containing stolen token-signing certificate, token encryption certificate, or the AD FS service configuration data) to the C2 in an HTTP 200 response. ![Screenshot of code for ProcessGetRequest\(\) returning the fake RIFF/WebP file to the C2 in an HTTP 200 response](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig36-FoggyWeb-NOBELIUM.png) If the backdoor cannot execute a C2 command successfully, it returns an HTTP 404 response to the C2 instead. #### HTTP POST handler Incoming HTTP POST requests that match the URI pattern _/adfs/services/trust/2005/samlmixed/upload_ are handled by the _ProcessPostRequest()_ method. ![Screenshot of code for the ProcessPostRequest\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig37-FoggyWeb-NOBELIUM.png) This method ensures that the _ContentType_ value of an incoming HTTP POST request ends with “xml” (case-insensitive), and the HTTP POST data contains two XML elements named _X509Certificate_ and _SignatureValue_ (for example, a blob that starts with the string “_<X509Certificate>_” and ends with the string _“__</X509Certificate>_”). ![Screenshot of ProcessPostRequest\(\) method ensuring that the ContentType value of an incoming HTTP POST request ends with “xml” ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig38-FoggyWeb-NOBELIUM.png) If the XML data contains the two elements, the backdoor performs the following actions: * Decode the values of the _SignatureValue_ and _X509Certificate_ elements by first decoding the values using Base64 and then calling the _Common.UprotectData()_ method on each decoded value. ![Screenshot of code for decoding the values of the SignatureValue and X509Certificate elements ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig39-FoggyWeb-NOBELIUM.png) The _UprotectData()_ method treats the first two bytes of the Base64 decoded value as a two-byte XOR key. It invokes the _Common.ProtectData()_ method (covered in the previous section) on the rest of the data (that is, third byte on) and then uses the two-byte XOR key to XOR decode the data returned by _Common.ProtectData()_. In other words, _UprotectData()_ leverages _Common.ProtectData()_ to remove the first layer of XOR encoding and then another XOR routine to remove the second layer of XOR encoding applied to the data. ![Screenshot of code for UprotectData\(\) leveraging Common.ProtectData\(\) to remove the first layer of XOR encoding and then another XOR routine ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig40-FoggyWeb-NOBELIUM.png) * Invoke the _Service.ExecuteAssembly()_ method to handle the decoded _SignatureValue_ and _X509Certificate_ values. As shown below, the decoded _X509Certificate_ value is the first GZip decompressed/inflated by calling the _Common.Decompress()_ method. ![Screenshot of decoded X509Certificate value, the first GZip decompressed/inflated by calling the Common.Decompress\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig41-FoggyWeb-NOBELIUM.png) In a new thread, _Service.ExecuteAssembly()_ calls _Service.ExecuteAssemblyRoutine()_ method to handle the data. ![Screenshot of Service.ExecuteAssembly\(\) calling Service.ExecuteAssemblyRoutine\(\) method ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig42-FoggyWeb-NOBELIUM.png) * _ExecuteAssemblyRoutine()_ checks if the decoded _X509Certificate_ value starts with _“MZ”_ (or the bytes _0x4D __0x5A_, the hexadecimal representation of the decimal numbers _77_ and _90_, as seen in the screenshot below). ![Screenshot showing decoded X509Certificate value that starts with “MZ” or the bytes 0x4D 0x5A, the hexadecimal representation of the decimal numbers 77 and 90](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig43-FoggyWeb-NOBELIUM.png) * If the decoded _X509Certificate_ value starts with “MZ,” the backdoor treats the decoded data as a .NET-based assembly/payload and proceeds to call its _Service.ExecuteBinary()_ method to load and execute the DLL payload in memory. After loading the DLL in memory, _ExecuteBinary()_ proceeds to invoke a specific method from the loaded DLL. The method name and parameters needed to invoke the method are supplied to the backdoor within the decoded _SignatureValue_ data. ![Screenshot of code for Service.ExecuteBinary\(\) method, which loads and execute the DLL payload in memory](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig44-FoggyWeb-NOBELIUM.png) If the decoded _X509Certificate_ value _does not_ start with MZ, the backdoor treats the decoded _X509Certificate_ value as source code for a C#-based payload and calls its _Service.ExecuteSource()_ method to dynamically compile and execute the payload in memory. ![Screenshot of code for Service.ExecuteSource\(\) method, which dynamically compiles and executes the payload in memory](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig45-FoggyWeb-NOBELIUM.png) After handling the HTTP POST request containing the XML elements _X509Certificate_ and _SignatureValue_, the backdoor responds to the request with an HTTP 204 response code. If the HTTP POST does not have the elements mentioned above, the backdoor responds to the request with an HTTP 404 response code. ## Appendix: Obtaining and decrypting AD FS tokens As the name suggests, the _Service.GetCertificate() _method is responsible for retrieving an AD FS certificate (either the token- signing or the token encryption certificate, depending on the value of the _certificateType_ parameter passed to the method) from the AD FS service configuration database. ![Screenshot of code for Service.GetCertificate\(\) method, responsible for retrieving an AD FS certificate](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig46-FoggyWeb-NOBELIUM.png) The method performs the following actions to retrieve the desired certificate: * Invoke another one of its methods named _GetServiceSettingsDataProvider()_ to create an instance of type _Microsoft.IdentityServer.PolicyModel.Configuration.ServiceSettingsDataProvider_ from the already loaded assembly _Microsoft.IdentityServer_. ![Screenshot of code for invoking the GetServiceSettingsDataProvider\(\) method ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig47-FoggyWeb-NOBELIUM.png) ![Screenshot of code for GetServiceSettingsDataProvider\(\) method ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig48-FoggyWeb-NOBELIUM.png) * Invoke the _GetServiceSettings()_ member/method of the above _ServiceSettingsDataProvider_ instance to obtain the AD FS service configuration settings. ![Screenshot of code for invoking the GetServiceSettings\(\) method](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig49-FoggyWeb-NOBELIUM.png) * Obtain the value of the AD FS service settings (from the _SecurityTokenService_ property), extract the value of the _EncryptedPfx_ blob from the service settings, and decode the blob using Base64. ![Screenshot of code for extracting the value of the EncryptedPfx blob ](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig50-FoggyWeb-NOBELIUM.png) * Invoke another method named _GetAssemblyByName()_ to enumerate all loaded assemblies by name and locate the already loaded assembly _Microsoft.IdentityServer.Service_. This method retrieves the value of two fields named __state_ and __certificateProtector_ from an object of type _Microsoft.IdentityServer.Service.Configuration.AdministrationServiceState_ (from the _Microsoft.IdentityServer.Service_ assembly). ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig51-FoggyWeb-NOBELIUM.png) ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig52-FoggyWeb-NOBELIUM.png) The _AdministrationServiceState_ class/object contains configuration information necessary for the execution and handling of client requests. The field __state_ is used to maintain the current state of the _AdministrationServiceState_ class/object (screenshot from _Microsoft.IdentityServer.Service.dll_). ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig53-FoggyWeb-NOBELIUM.png) The _AdministrationServiceState_ object (stored in the __state_ field) contains another field named __certificateProtector_. ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig54-FoggyWeb-NOBELIUM.png) The field __certificateProtector_ stores an instance of the Data Protector class _DkmDataProtector_ for Distributed Key Management (DKM). The _DkmDataProtector_ class implements a method named _Unprotect()_, which ultimately calls the _Unprotect()_ method of DKM/IDKM (screenshot from _Microsoft.IdentityServer.dll_). ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig55-FoggyWeb-NOBELIUM.png) The DKM _Unprotect()_ method inherits a method named _Unprotect()_ from _Microsoft.IdentityServer.Dkm.DKMBase_ (screenshot from _Microsoft.IdentityServer.Dkm.dll_). ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig56-FoggyWeb-NOBELIUM.png) The _Unprotect()_ method from _Microsoft.IdentityServer.Dkm.DKMBase_ (shown above) provides the functionality to decrypt the encrypted certificate (a PKCS12 object) stored in the _EncryptedPfx_ blob. Armed with the knowledge about the availability of the _Unprotect()_ method accessible via the __certificateProtector_ field, the backdoor invokes the _Unprotect()_ method to decrypt the encrypted certificate stored in the _EncryptedPfx_ blob of the desired certificate type (either the AD FS token signing or encryption certificate). ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig57-FoggyWeb-NOBELIUM.png) A variant of the technique described in this Appendix was publicly presented by Douglas Bienstock and Austin Baker at the TROOPERS conference in 2019 ([I am AD FS and so can you: Attacking Active Directory Federated Services]()). However, the method used by FoggyWeb differs from the publicly presented method, in that FoggyWeb leverages the __state_ and __certificateProtector_ fields from the _AdministrationServiceState_ class/object to facilitate access to the Data Protector class _DkmDataProtector_ (used to gain access to and invoke the _Unprotect()_ method). ## Indicators of compromise (IOCs) **Type** | **Threat Name** | **Threat Type** | **Indicator** ---|---|---|--- MD5 | FoggyWeb | Loader | 5d5a1b4fafaf0451151d552d8eeb73ec SHA-1 | FoggyWeb | Loader | c896ece073dd01191cbc1d462bc2f47161828a83 SHA-256 | FoggyWeb | Loader | 231b5517b583de102cde59630c3bf938155d17037162f663874e4662af2481b1 MD5 | FoggyWeb | Backdoor (encrypted) | 9ff9401315d0f7258a9fcde0cfdef02b SHA-1 | FoggyWeb | Backdoor (encrypted) | 4597431f26424cb814c917168fa8d74d01ab7cd1 SHA-256 | FoggyWeb | Backdoor (encrypted) | da0be762bb785085d36aec80ef1697e25fb15414514768b3bcaf798dd9c9b169 MD5 | FoggyWeb | Backdoor (decrypted) | e9671d294ce41fe6dbb9637dc0157a88 SHA-1 | FoggyWeb | Backdoor (decrypted) | 85cfeccbb48fd9f498d24711c66e458e0a80cc90 SHA-256 | FoggyWeb | Backdoor (decrypted) | 568392bd815de9b677788addfc4fa4b0a5847464b9208d2093a8623bbecd81e6 ## Mitigations Customers should review their AD FS Server configuration and implement changes to secure these systems from attacks: * [Best Practices for securing AD FS and Web Application Proxy]() We strongly recommend for organizations to harden and secure AD FS deployments through the following best practices: * Ensure only Active Directory Admins and AD FS Admins have admin rights to the AD FS system. * Reduce local Administrators’ group membership on all AD FS servers. * Require all cloud admins to use multi-factor authentication (MFA). * Ensure minimal administration capability via agents. * Limit on-network access via host firewall. * Ensure AD FS Admins use Admin Workstations to protect their credentials. * Place AD FS server computer objects in a top-level OU that doesn’t also host other servers. * Ensure that all GPOs that apply to AD FS servers apply only to them and not to any other servers. This limits potential privilege escalation through GPO modification. * Ensure that the installed certificates are protected against theft. Don’t store these on a share on the network and set a calendar reminder to ensure they get renewed before expiring (expired certificate breaks federation auth). Additionally, we recommend protecting signing keys or certificates in a [hardware security module (HSM)]() attached to AD FS. * Set logging to the highest level and send the AD FS (and security) logs to a SIEM to correlate with AD authentication as well as Azure AD (or similar). * Remove unnecessary protocols and Windows features. * Use a long (>25 characters) and complex password for the AD FS service account. We recommend using a [Group Managed Service Account (gMSA)]() as the service account, as it removes the need for managing the service account password over time by managing it automatically. * Update to the latest AD FS version for security and logging improvements (as always, test first). * When federated with Azure AD follow the best practices for [securing]() and [monitoring]() the AD FS trust with Azure AD. ## Detections Protecting AD FS servers is key to mitigating NOBELIUM attacks. Detecting and blocking malware, attacker activity, and other malicious artifacts on AD FS servers can break critical steps in known NOBELIUM attack chains. Microsoft Defender Antivirus detects the new NOBELIUM components discussed in this blog as the following malware: * **Loader: **_Trojan:Win32/FoggyWeb.A!dha_ * **Backdoor: **_Trojan:MSIL/FoggyWeb.A!dha_ ### Microsoft 365 Defender Endpoint detection and response (EDR) capabilities in Microsoft Defender for Endpoint detect malicious behavior related to this malware which is surfaced as alerts with the following titles: * A suspicious DLL was loaded by the ADFS service * Suspicious service launched * Suspicious file dropped ![](https://www.microsoft.com/security/blog/uploads/securityprod/2021/09/Fig58-FoggyWeb-NOBELIUM.png) ### Azure AD Identity Protection This kind of attack can also be detected in the cloud using Azure AD Identity Protection. It is recommended that you monitor the [Azure AD Identity Protection]() Risk detections report for the [“Token Issuer Anomaly” detection](). This detection looks for anomalies in the SAML token presented to the Azure AD tenant. ## Advanced hunting queries ### Microsoft Defender for Endpoint To locate related activity, run the following advanced hunting queries in Microsoft 365 Defender: `DeviceImageLoadEvents | where FolderPath has @"C:\Windows\ADFS" | where FileName has @"version.dll"` ### Azure Sentinel Azure Sentinel customers can use the following detection queries to look for this activity: Detection query: [https://github.com/Azure/Azure-Sentinel/tree/master/Detections/MultipleDataSources/Nobelium_FoggyWeb.yaml]() Indicator file: The post [FoggyWeb: Targeted NOBELIUM malware leads to persistent backdoor]() appeared first on [Microsoft Security Blog]().