A sophisticated,threat actor has been compromising major public and private organisations over the past year by exploiting deserialisation flaws in public-facing ASP.NET applications to deploy file-less malware.

Dubbed Praying Mantis, or TG1021, the hacker group puts a strong focus on detection evasion by using a volatile and custom malware toolset built specifically for IIS web servers to perform credential harvesting, reconnaissance and lateral movement. Avoiding detection and evading commercial EDRs by silently awaiting incoming connections rather connecting back C2C is a main significance.

Old and new deserialisation exploits

Serialisation is the process of converting data into a stream of bytes, usually to transmit it over the wire. Deserialisation is the reversal of that process and like with most data parsing operations in software, it can be a source of vulnerabilities if users control the input.

The vulnerabilities exploited by Praying Mantis target deserialisation implementations in ASP.NET, an open-source framework for developing web apps that are hosted on Windows IIS web servers.

Praying Mantis was seen exploiting a RCE vulnerability resulting from unsafe deserialisation in an ASP.NET application called Checkbox that allows website owners to implement user surveys.

This flaw had zero-day status and affected versions 6 and earlier of Checkbox that used a custom implementation of VIEWSTATE functionality. Even though Checkbox version 7 has been available since 2019 and is not affected, official support for Checkbox version 6 did not end until July 1st.

Data is manually handled by the Checkbox Survey code, the ASP.NET VIEWSTATE Message Authentication Code (MAC) setting on the server is ignored. Without MAC, an attacker can create arbitrary data that will be deserialised, resulting in arbitrary code execution.

The group also exploited a session storing mechanism that relies on serialisation. ASP.NET allows applications to store user sessions as serialised objects in an MSSQL database and then assign unique cookies to them. When a user’s browser visits the application again and has one of these cookies saved, the application will load the corresponding session object from the database and deserialise it. Attackers used this technique for a lateral movement by using access to compromised IIS web server leading to load specially crafted packets leading to RCE

A malware framework tailor made for IIS

The hackers exploited these RCE vulnerabilities to reflectively load a malicious DLL in the memory of vulnerable web servers. This DLL then reflectively loaded a malware component that researchers dubbed NodeIISWeb into the w3wp.exe process. This is the IIS worker process that handles web requests sent to the IIS web server for the configured IIS application pool.

Reflective loading is a technique of injecting a rogue DLL into an existing process, hooking its functionality. The benefits of this technique is that certain Windows mechanisms such as registering the DLL as a module at runtime get bypassed and the file is not actually written to disk.

The downside is that the infection lacks persistence. Since the rogue DLL lives only in RAM, it will disappear if its parent process is restarted. Because production web servers are meant to have long uptimes, it is an effective technique to hide a compromise.

Instead of a reflective DLL loader, Praying Mantis also sometimes uses a web shell to load NodeIISWeb. This is more common when the group is exploiting file upload vulnerabilities like CVE-2017-11317 rather than remote code execution ones based on deserialisation, since web shells are essentially malicious web scripts / applications uploaded to a server’s file system and accessible remotely via HTTP.

Praying Mantis’ web shells are usually short-lived, with the group removing them after NodeIISWeb is deployed.

The NodeIISWeb malware hooks into the IIS input validation functions and can read all incoming HTTP traffic to the server. This gives attackers a method of controlling the malware by sending crafted requests to the server with certain cookie names and values that the malware program expects and monitors. NodeIISWeb doesn’t generate C2C connection which could be detected.

The malware program implements several traffic forwarding methods for TCP, HTTP and SQL that allows it to serve as a proxy or command-and-control channel itself for other malware instances running on compromised servers inside the same network and that might not be exposed directly to the Internet. It can also execute JScript payloads and load additional DLL modules that extend its functionality.

NodeIISWeb is often used to deploy another custom Windows backdoor called ExtDLL.dll that can be used to manipulate files and directories, gather system info, load and execute DLLs and implement various attack techniques such as code injection and token manipulation.

This component also hooks into and manipulates various security functions present on the system to hide its activities, including AV scanning functions, event log reporting functions, .NET code trust checks and PowerShell related registry keys.

One of the additional DLL modules loaded by NodeIISWeb and ExtDLL.dll is called PSRunner.dll and allows running PowerShell scripts on a host without spawning a PowerShell process. Another one is called Forward.dll and implements the HTTP traffic forwarding capability.

PotatoEx.dll is a privilege escalation tool and Active Directory mapping tool and E.dll is a component that generates custom HTTP responses that allows attackers to verify that an exploit was successfully executed on a target IIS server.

Praying Mantis used its access to compromised IIS servers to modify login pages for existing applications to capture user credentials and save them in a separate file, and to deploy publicly available offensive security tools including SharpHound and PowerSploit that were loaded directly into memory without leaving traces on disk. The group was also seen accessing shared folders on internal servers over SMB by using compromised domain credentials.

Praying Mantis detection and prevention

Detecting Praying Mantis’ activities is not easy because of the volatile nature of its memory-resident malware and the group’s attention to operational security.

Patching .NET deserialisation vulnerabilities, searching for the indicators of compromise published in their report, scanning internet-facing IIS servers with YARA rules designed to detect the group’s tools and actively hunting for suspicious activity on IIS environments.