Microsoft’s Threat Intelligence Center has been analyzing a custom-built backdoor that has been used by the Nobelium group since April 2021.
The backdoor that aims to steal the configuration database of a server has been dubbed FoggyWeb by Microsoft.
As we’ve seen in previous cases, Nobelium uses various methods to steal credentials with the objective of gaining administrator level access to Active Directory Federation Services (AD FS) servers. Once this level of access has been accomplished, FoggyWeb is one of the tools that allows the attackers to gain persistence and deploy further malware.
FoggyWeb is a very targeted backdoor that is capable of exfiltrating information from an affected Active Directory Federation Services (AD FS) server. To establish persistence and enable further compromise it drops two files on the server. That action requires administrator privileges in the first place, so this backdoor builds on an earlier established compromise or stolen credentials.
DLL search order hijacking method
One of the two files that are initially dropped uses the DLL search order hijacking technique to gain persistence. All Windows systems use a common method to look for required dynamic-link libraries (DLLs) to load into a program. They all use the same search order to find a DLL. The first two locations in an environment that use the SafeDllSearchMode are:
- The directory from which the application loaded
- The system directory
So, the file %WinDir%\ADFS\version.dll is dropped in the ADFS directory to make sure it gets loaded before the legitimate version.dll located in %WinDir%\System32\.
To avoid any error messages, the backdoor version.dll behaves as a proxy for all legitimate version.dll export function calls. It exports the same 17 function names as the legitimate version of version.dll.
What it actually does for all the 17 functions is exactly the same:
- Calling a function that loads 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
Basically, it adds one extra step to the original execution process, which is designed to run the second file that was dropped on the affected server: C:\Windows\SystemResources\Windows.Data.TimeZones\pris\Windows.Data.TimeZones.zh-PH.pri. This file is the encrypted backdoor that gets decrypted and executed by the malicious version.dll.
When loaded, this acts as the actual backdoor. It starts an HTTP listener that listens for specific HTTP GET and POST requests. In this way it can be used to communicate with a C2 server and to retrieve the token-signing certificate of the compromised AD FS server and other files and information. For a much more detailed analysis of the decrypted backdoor we advise reading the full Microsoft blog.
Mitigation and detection
Microsoft provided some advice to server administrators that could help harden and secure AD FS deployments:
- 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. Secure admin workstations are limited-use client machines that are built to substantially reduce the risk of compromise from malware, phishing attacks, bogus websites, and pass-the-hash (PtH) attacks, among other security risks
- Place AD FS server computer objects in a top-level Organizational Unit (OU) that doesn’t also host other servers
- Ensure that all Group Policy Objects (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. This is one of the targets the backdoor is after
- 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
- Update to the latest AD FS version for security and logging improvements (as always, test first)
Please read the Microsoft blog for a full list of IOCs.
Stay safe, everyone!