Microsoft in its continuous effort to protect its customers started analysing the Notorious Nobelium threat actors. Due to its constant effort it has come across the new backdoor campaign used by the threat actor dubbed “FoggyWeb” targeting to gain admin level access to Active directory federation service on victim organisation.
“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.” reads the blogpost.
FoggyWeb is a highly targeted backdoor capable of remotely exfiltrating sensitive data from a compromised ADFS server with additional capability to download malicious components from a C2 server to compromised server. Once after the compromise Nobelium has dropped two files as below:-
“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. “reads the blogpost
Microsoft recommends below listed recommendations for the customers:
- 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.
Indicators of compromise:
|Type||Threat Name||Threat Type||Indicator|