
A sophisticated, likely government-sponsored 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, 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 deserialisation exploits
In programming, 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.
Unsafe deserialisation flaws have plagued Java applications for years, but Java is not the only programming language where deserialisation is common.
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. 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 deserialised and validated. ASP.NET provides some security and integrity checking mechanisms to ensure the serialised 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 deserialisation 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 deserialises 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 deserialised, resulting in arbitrary code execution."
Praying Mantis seems to have a good understanding of deserialisation 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 deserialisation 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 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.
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 deserialise it, leading to RCE.
Praying Mantis was also observed exploiting deserialisation vulnerabilities in other apps, for example CVE-2019-18935, an RCE flaw that stems from insecure deserialisation 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 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.
Read more on the next page...