APT group hits IIS web servers with deserialization flaws and memory-resident malware

A sophisticated, likely government-sponsored threat actor has been compromising major public and private organizations over the past year by exploiting deserialization flaws in public-facing ASP.NET applications to deploy fileless malware. Dubbed Praying Mantis, or TG1021, by researchers from incident response firm Sygnia, the hacker group puts a strong focus on detection evasion by using a volatile and custom malware toolset built specifically for Internet Information Services (IIS) web servers to perform credential harvesting, reconnaissance and lateral movement.

“The nature of the activity and general modus-operandi suggest TG1021 to be an experienced stealthy actor, highly aware of OPSEC (operations security),” the Sygnia researchers said in a detailed report. “The malware used by TG1021 shows a significant effort to avoid detection, both by actively interfering with logging mechanisms, successfully evading commercial EDRs and by silently awaiting incoming connections, rather than connecting back to a C2 channel and continuously generating traffic. Furthermore, the threat actor actively removed all disk-resident tools after using them, effectively giving up on persistency in exchange for stealth.”

Old and new deserialization exploits

In programming, serialization is the process of converting data into a stream of bytes, usually to transmit it over the wire. Deserialization 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. Unsafe deserialization flaws have plagued Java applications for years, but Java is not the only programming language where deserialization is common.

The vulnerabilities exploited by Praying Mantis target deserialization implementations in ASP.NET, an open-source framework for developing web apps that are hosted on Windows IIS web servers. ASP.NET has a mechanism called VIEWSTATE that’s used by the framework to store the state and controls of a web page when sent to a client during a POST request. It is stored as a hidden input field called _VIEWSTATE. When the client performs the POST action and sends the page back to the server, the VIEWSTATE is deserialized and validated. ASP.NET provides some security and integrity checking mechanisms to ensure the serialized data is valid, but their correct usage comes down to developer implementation.

Praying Mantis was seen exploiting a remote code execution (RCE) vulnerability resulting from unsafe deserialization in an ASP.NET application called Checkbox that allows website owners to implement user surveys. At the time of the group’s attacks, 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.

“Prior to version 7.0, Checkbox Survey implements its own VIEWSTATE functionality by accepting a _VSTATE argument, which it then deserializes using LosFormatter,” analysts from CERT/CC said in an advisory in May. “Because this 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 deserialized, resulting in arbitrary code execution.”

Praying Mantis seems to have a good understanding of deserialization flaws in general, exploiting the mechanism in several ways for lateral movement and persistence. For example, even if new versions of ASP.NET support VIEWSTATE integrity checking and encryption, if the encryption and validation keys are stolen or leaked, they can be used to reinfect the server or infect other servers from the same cluster that host the same application because the secret keys are shared.

“During one of Sygnia’s investigations, TG1021 leveraged stolen decryption and validation keys to exploit IIS web servers,” the researchers said. “The flow of the VIEWSTATE deserialization exploit is almost identical to the VSTATE exploit explained above, with the adjustment of encrypting and signing the VIEWSTATE data instead of compressing it.”

The group also exploited a session storing mechanism that relies on serialization. ASP.NET allows applications to store user sessions as serialized 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 deserialize it.

The attackers exploited this feature for lateral movement by using their access to an IIS web server compromised through one of the previous vulnerabilities to generate a malicious session object and associated cookie and store it in the Microsoft SQL database. They then sent requests to other IIS servers that were part of the same infrastructure and were using the same database and included the rogue cookie in the requests. This forced the application instances running on those servers to load the maliciously crafted session object from the database and deserialize it, leading to RCE.

Praying Mantis was also observed exploiting deserialization vulnerabilities in other apps, for example CVE-2019-18935, an RCE flaw that stems from insecure deserialization in JSON parsing and affects a product called Telerik UI for ASP.NET AJAX. Telerik is a suite of user interface components that is widely used in web applications. An exploit for an older arbitrary file upload flaw impacting Telerik (CVE-2017-11317) was also used by the group.

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 deserialization, 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 for. Since attackers can send instructions through this HTTP mechanism, NodeIISWeb does not generate outgoing connections to a command-and-control server that could potentially be detected by traffic monitoring solutions.

That said, 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. The Sygnia researchers recommend patching .NET deserialization 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.

Validating the usage of ASP.NET VIEWSTATE or custom implementations of the same mechanism—like the compressed VSTATE in Checkbox Survey—is critical to protecting ASP.NET applications against VIEWSTATE deserialization flaws. The enableViewStateMac variable in the IIS configuration should be set to “True” and the aspnet:AllowInsecureDeserialization variable should be set to “False”. The registry key AspNetEnforceViewStateMac should be set to “1” and encryption and validation keys should be handled with care. Servers should use auto-generated keys or machine keys on IIS servers should be routinely rotated to reduce the likelihood of abuse via stolen or leaked keys.

“If ASP.NET session state is used by your web applications, make sure access to the database can only be done from legitimate network locations,” the researchers said. “Separate session state MSSQL databases between different IIS servers/web applications as much as possible or create different SQL users with proper minimal CRUD permissions. Make sure your .NET web applications are running with a designated application pool identity with the lowest privileges possible. This would create an additional obstacle for TG1021.”

In addition to the Sygnia paper, there’s an advisory published by the Australian government’s Cyber Security Center (ACSC) last year that contains indicators of compromise and attack techniques that partially overlap with the Praying Mantis activities observed by Sygnia. The advisory was posted in response to what ACSC called at the time “a sustained targeting of Australian governments and companies by a sophisticated state-based actor” that represented “the most significant, coordinated cybertargeting against Australian institutions the Australian Government has ever observed.”