Owowa: A malicious IIS module for data theft.

- Posted in Vulnerability by

Owowa is an Microsoft web server (IIS) module currently tuned to intercept outlook web app (OWA) login requests. The exact method of how Owowa makes its way onto servers isn't yet fully known as of publishing of this post, but it is possible that it is deployed as a reconnaissance tool/sniffer during an initial attack on a network. Once it is deployed to a server it is designed to intercept login requests to the target outlook web instance and to funnel the login credentials found to whomever deployed it. This means that if your exchange server is infected, just logging into outlook to check your email can comprise your email account, give the attacker direct control of your email account, and lead to phishing campaigns by pretending to be you. Currently, Owowas targeted have reportedly been governments or government controlled entities in the asia pacific region, but that can change at any time.

Owowa currently works by monitoring HTTP requests on the infected server and responses for OWA traffic by triggering the “PreSendRequestContent” flag, this flag is suspected to be only triggered when a web application hosted by IIS is about to send content to a client application, such as an outlook client. It also verifies that the login was successful by grabbing data from authentication tokens sent as a access confirmation back to the client which contains the user login credentials, IP address and timestamp. It is suspected that the attacker can enter certain strings into the owa login pages username field on an infected server to retrieve the servers credentials log, delete said log, or use the owa login page password field to remotely execute powershell commands remotely.

The IIS "IHttpModule" is used for packet sniffing. According to Microsoft, using the string with the associated flag triggered within the IHttpModule is not recommended as it can lead to server instability/crashes. MS warning The attacker, however, is using this exploit to retrieve information despite Microsoft considering that this is not how it should be used.

Another part of the danger regarding Owowa is that without having a security regime tuned to looking for the type of traffic that Owowa sends the only real way to determine if Owowa is on your server is a manual investigation of the loaded modules in IIS. We are informed that most/all security platforms are not designed to search for vulnerabilities like Owaowa at the time of this post.

Currently talk about Owowa is just that, talk; even Kaspersky researchers, who first discovered Owowa and made its existence public, have not yet taken any protective action. In addition, there is no current discussion as to what Owaowa can be turned into, since it is a snooping tool for IIS currently tuned to steal exchange credentials, modifications to its programming likely would, and could allow it to grab any sort of data being sent to/from an IIS server. Such a vulnerability could mean that the entire IIS ecosystem is a continuous threat risk.

Part of my concern around Owowa and about how dangerous it can be, is that it has been reported that Owowa has unused empty modules within its code that could be potentially - maybe already have been - could be used to enhance its current capability.


Owowa may not yet be commonplace but the threat is significant enough that immediate action should be taken. Verification of the IIS backend, its configuration, on a regular basis. Checks should be done regularly to look for the module and remove it. It is thought that Owowa is currently a reconnaissance tool for an ongoing attack, post exploit, or information grabber for the dark web that will lead to additional exploits, phishing and scams. So proactive steps need to be implemented to assist in preventing the exploit.

FoggyWeb: Targeted NOBELIUM malware leads to persistent backdoor

- Posted in Vulnerability by

Microsoft is continuing to develop solutions against the malware attack on its Office365 and Azure products. The malicious actor they coined FoggyWeb, is built on the NOBELUM codebase to create malicious sets of code that can draw from significant operational resources, including custom-built malware and tools, to attack systems and obtain credentials. The code creates a backdoor to Microsoft security and and employs multiple tactics including attaching to multiple DLL's. Once compromised an attacker pursues 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 using FoggyWeb to remotely exfiltrate the configuration database of compromised AD FS servers, decrypted token-signing certificate and token-decryption certificates, as well as downloading and executing additional components.

Microsoft recommends that if you think you are compromised you should immediately:

  1. 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
  2. Remove user and app access, review configurations for each, and re-issue new, strong credentials following documented industry best practices.
  3. Use a hardware security module (HSM) as described in securing AD FS servers to prevent the exfiltration of secrets by FoggyWeb.

We think you should do this anyway to be on the safe side.

Microsoft has implemented checks and balances into their security defender products and we recommend that you use these rather than third party applications from third party virus vendors. These vulnerabilities are not yet well understood by the third party vendors who are lagging behind Microsoft fixes and investigations.

Technical analysis Courtesy: Ramin Nafisi - Microsoft Threat Intelligence Center can be read here: https://www.microsoft.com/security/blog/2021/09/27/foggyweb-targeted-nobelium-malware-leads-to-persistent-backdoor/

Indicators of compromise (IOCs) For IT professionals you can test for compromise by checking the indicators below:

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 (encrypted) e9671d294ce41fe6dbb9637dc0157a88
SHA-1 FoggyWeb Backdoor (encrypted) 85cfeccbb48fd9f498d24711c66e458e0a80cc90
SHA-256 FoggyWeb Backdoor (encrypted) 568392bd815de9b677788addfc4fa4b0a5847464b9208d2093a8623bbecd81e6


While Microsoft continues to work on solutions and monitor the threat, the following actions are recommended:

  • Customers should review their AD FS Server configuration and implement changes to secure these systems from attacks - https://docs.microsoft.com/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs

  • 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.