Key Findings
Check Point Research, in collaboration withSygnias Incident Response Team, has been tracking and responding to the activities ofScarred Manticore, an Iranian nation-state threat actor that primarily targets government and telecommunication sectors in the Middle East. Scarred Manticore, linked to the prolific Iranian actor OilRig (a.k.a APT34, EUROPIUM, Hazel Sandstorm), has persistently pursued high-profile organizations, leveraging access to systematically exfiltrate data using tailor-made tools.
In the latest campaign, the threat actor leveraged the LIONTAIL framework, a sophisticated set of custom loaders and memory resident shellcode payloads. LIONSTAILs implants utilize undocumented functionalities of the HTTP.sys driver to extract payloads from incoming HTTP traffic. Multiple observed variants of LIONTAIL-associated malware suggest Scarred Manticore generates a tailor-made implant for each compromised server, allowing the malicious activities to blend into and be undiscernible from legitimate network traffic.
We currently track this activity as Scarred Manticore, an Iranian threat actor that is most closely aligned withDEV-0861. Although the LIONTAIL framework itself appears to be unique and bears no clear code overlaps with any known malware family, other tools used in those attacks overlap with previously reported activities. Most notably, some of those were eventually linked back to historic OilRig or OilRig-affiliated clusters. However, we do not have sufficient data to properly attribute the Scarred Manticore to OilRig, even though we do believe theyre likely related.
The evolution in the tools and capabilities of Scarred Manticore demonstrates the progress the Iranian actors have undergone over the last few years. The techniques utilized in recent Scarred Manticore operations are notably more sophisticated compared to previous activities CPR has tied to Iran.
In this article, we provide a technical analysis of the latest tools and the evolution of Scarred Manticores activity over time. This report details our understanding of Scarred Manticore, most notably its novel malware framework LIONTAIL, but also provides an overview of other toolsets we believe are used by the same actor, some of which were publicly exposed in the past. This includes, but is not limited to, tools used in the intrusion into the Albanian government infrastructure, web shells observed in high-profile attacks in the Middle East, and recently reported WINTAPIX driver-based implants.
While we finalized this blog post, a technical analysis of part of this activity waspublishedby fellow researchers from Cisco Talos. While it overlaps with our findings to some extent, our report provides additional extended information, in-depth insights, and a broader retrospective regarding the threat actor behind this operation.
LIONTAIL is a malware framework that includes a set of custom shellcode loaders and memory resident shellcode payloads. One of its components is the LIONTAIL backdoor, written in C. It is a lightweight but rather sophisticated passive backdoor installed on Windows servers that enables attackers to execute commands remotely through HTTP requests. The backdoor sets up listeners for the list of URLs provided in its configuration and executes payloads from requests sent by attackers to those URLs.
The LIONTAIL backdoor components are the main implants utilized in the latest Scarred Manticore intrusions. Utilizing access from a publicly facing server, the threat actor chains a set of passive implants to access internal resources. The internal instances of the LIONTAIL backdoors weve seen so far either listen on HTTP(s), similar to the internet-facing instances, or in some cases use named pipes to facilitate remote code execution.
We observed 2 methods of backdoor installation on the compromised Windows servers: standalone executables, and DLLs loaded through search order hijacking by Windows services or legitimate processes.
When installed as a DLL, the malware exploits the absence of some DLLs on Windows Server OS distributions: the backdoor is dropped to the system folderC:windowssystem32aswlanapi.dllorwlbsctrl.dll. By default, neither of theseexist on Windows Server installations. Depending on the Windows Server version, the malicious DLL is then loaded either directly by other processes, such as Explorer.exe, or the threat actors enable specific services, disabled by default, that require those DLLs.
In the case ofwlbsctrl.dll, the DLL is loaded at the start of theIKE and AuthIP IPsec Keying Modulesservice. Forwlanapi.dll, the actors enableExtensible Authentication Protocol:
sc.exe config Eaphost start=autosc.exe start Eaphost
In instances where LIONTAIL is deployed as an executable, a noteworthy characteristic observed in some is the attempt to disguise the executable asCyvera Console, a component of Cortex XDR.
The malware starts by performing a one-byte XOR decryption of a structure containing the malware configuration, which is represented with the following structure:
The fieldlisten_urlsdefines particularURL prefixesto which the malware listens for incoming requests.
All of the samples URL lists include the http://+:80/Temporary_Listen_Addresses/URL prefix, a defaultWCF URL reservationthat allows any user to receive messages from this URL. Other samples include multiple URLs on ports 80, 443, and 444 (on Exchange servers) mimicking existing services, such as:https://+:443/autodiscover/autodiscovers/ https://+:443/ews/exchanges/ https://+:444/ews/ews/
Many LIONTAIL samples contain tailor-made configurations, which add multiple other custom URLs that match existing web folders on the compromised server. As the URLs for the existing folders are already taken by the actual IIS service, the generated payloads contain additional random dictionary words in the path. These ensure the malware communication blends into legitimate traffic, helping to make it more inconspicuous.
Thehostelement of all prefixes in the configuration consists of a single plus sign (+), a strong wildcard that matches all possible host names. A strong wildcard is useful when an application needs to serve requests addressed to one or more relative URLs, regardless of how those requests arrive on the machine or what site (host or IP address) they specify in their Host headers.
To understand how the malware configures listeners on those prefixes and how the approach changes with time, we pause for a short introduction to the Windows HTTP stack.
A port-sharing mechanism, which allows multiple HTTP services to share the same TCP port and IP address, was introduced in Windows Server 2003. This mechanism is encapsulated withinHTTP.sys, a kernel-mode driver that assumes the responsibility of processing HTTP requests, listens to incoming HTTP requests, and directs them to the relevant user-mode processes or services for further handling.
On top of the driver layer, Windows provides theHTTP Server API,a user-mode component that provides the interface for interacting with HTTP.sys. In addition, the Internet Information Services(IIS) under the hood relies on HTTP API to interact with the HTTP.sys driver. In a similar fashion, theHttpListenerclass within the .NET framework is a simple wrapper around the HTTP Server API.
The process of receiving and processing requests for specific URL prefixes by an application (or, in our case, malware) can be outlined as follows:
After extracting the configuration, the malware uses the same one-byte XOR to decrypt a shellcode responsible for establishing the C&C communication channel by listening to the provided URL prefixes list. While the concept of passive backdoors on web-facing Windows servers is not new and wasobservedin the wild hijacking the same Windows DLLwblsctrl.dllas early as 2019 (by Chinese-linkedOperation ShadowHammer), the LIONTAIL developers elevated their approach. Instead of using the HTTP API, the malware uses IOCTLs to interact directly with the underlying HTTP.sys driver. This approach is stealthier as it doesnt involve IIS or HTTP API, which are usually closely monitored by security solutions, but is not a straightforward task given that the IOCTLs for HTTP.sys are undocumented and require additional research efforts by the threat actors.
First, the shellcode registers the URL prefixes with HTTP.sys using the following IOCTLs:
After registering the URL prefixes, the backdoor initiates a loop responsible for handling the incoming requests. The loop continues until it gets the request from a URL equal to theend_stringprovided in the backdoors configuration.
The backdoor receives requests from HTTP.sys using 0x124036 UlReceiveHttpRequestIoctlIOCTL.
Depending on the version of the compromised server, the body of the request is received using 0x12403B UlReceiveEntityBodyIoctlor (if higher than 20348) 0x12403A UlReceiveEntityBodyFastIo. It is then base64-decoded and decrypted by XORing the whole data with the first byte of the data. This is a common method of encryption observed in multiple malware families, including but not limited to DEV-0861s web-deployedReverse proxy.
The decrypted payload has the following structure:
The malware creates a new thread and runs the shellcode in memory. For some reason, it uses shellcode_output and shellcode_output_sizein the request message as pointers to the respective data in memory.
To encrypt the response, the malware chooses a random byte, XOR-encodes the data using it as a key, prepends the key to the result, and then base64-encodes the entire result before sending it back to the C&C server using the IOCTL 0x12403F UlSendHttpResponseIoctl.
In addition to PE implant, Scarred Manticore uses a web shell-based version of the LIONTAIL shellcode loader. The web shell is obfuscated in a similar manner to other Scarred Manticore .NET payloads and web shells.
The web shell gets requests with 2 parameters:
Both parameters are encrypted the same way as other communication: XOR with the first byte followed by base64 encoding.
The structure of shellcodes and of arguments sent to the web shell-based shellcode loader is identical to those used in the LIONTAIL backdoor, which suggests that the artifacts observed are part of a bigger framework that allows the dynamic building of loaders and payloads depending on the actors access and needs.
During our research, we also found loaders that have a similar internal structure to the LIONTAIL samples. Instead of listening on URL prefixes, this version gets its payloads from a named pipe and likely is designated to be installed on internal servers with no access to the public web. The configuration of the malware is a bit different:
The main shellcode starts withconvertingthe string security descriptor"D:(A;;FA;;;WD)into a valid, functional security descriptor. As the string starts with D, it indicates a DACL (discretionary access control list)entry, which typically has the following format:entry_type:inheritance_flags(ACE_type; ACE_flags; rights; object_GUID; inherit_object_GUID; account_SID). In this case, the security descriptor allows (A) File All Access (FA) to everyone (WD).
The security descriptor is then used tocreatea named pipe based on the values provided in the configuration. In the samples we observed, the name of the pipe used is\.pipetest-pipe.
Its noteworthy that, unlike the HTTP version, the malware doesnt employ any more advanced techniques for connecting to the named pipe, reading from it, and writing to it. Instead, it relies on standardkernel32.dllAPIs such asCreateNamedPipe, andReadFileWriteFile.
The communication of named pipes-based LIONTAIL is identical to the HTTP version, with the same encryption mechanism and the same structure of the payload which runs as a shellcode in memory.
After the LIONTAIL loader decrypts the payload and its argument received from the attackers C&C server, it starts with parsing the argument. It is a structure that describes a type of payload for the shellcode to execute and it is built differently depending on the type of payload:
The argument for the API execution has the following structure:
To make things more complicated, Scarred Manticore wraps the final payload in nested shellcodes. For example, one of the shellcodes received from the attackers runs another almost identical shellcode, which in turn runs a final shellcode responsible for machine fingerprinting.
The data gathered by this payload is collected by running specific Windows APIs or enumerating the registry keys, and includes these components:
The final structure, which contains all the gathered information, also has a place for error codes for the threat actor to use to figure out why some of the APIs they use dont work as expected:
In addition to using LIONTAIL, Scarred Manticore was observed leveraging other custom components.
On some of the compromised exchange servers, the actors deployed LIONHEAD, a tiny web forwarder. LIONHEAD is also installed as a service using the same phantom DLL hijacking technique as LIONTAIL and utilizes similar mechanisms to forward the traffic directly to Exchange Web Services (EWS) endpoints.
LIONHEADs configuration is different from LIONTAIL:
The backdoor registers thelisten_urlsprefixes in the same way as LIONTAIL and listens for requests. For each request, the backdoor copies the content type, cookie, and body and forwards it to the/:specified in the configuration. Next, the backdoor gets a response fromforward_serverand sends it back to the URL that received the original request.
This forwarder might be used to bypass the restrictions on external connections to EWS, hide the real consumer of EWS data being external, and consequently conceal data exfiltration.
Scarred Manticore deploys multiple web shells, including those previouslyattributedindirectly to OilRig. Some of these web shells stand out due to their obfuscations, naming conventions and artifacts. The web shells retain class and method obfuscation and a similar string encryption algorithm (XOR with one byte, the key is derived from the first byte or from the first 2 bytes) to many other web shells and .NET-based tools used by Scarred Manticore in their attacks over the past few years.
One of those shells is a heavily obfuscated and slightly modified version of an open-source XML/XSL transform web shell,Xsl Exec Shell. This web shell also contains two obfuscated functions that return the string ~/1.aspx. These functions are never called and likely are remnants from other versions, as we observed them in tools used previously by Scarred Manticore, such as FOXSHELL, which is discussed later:
Based on our visibility into the latest wave of attacks that utilize LIONTAIL, the observed victims are located across the Middle East region, including Saudi Arabia, the United Arab Emirates, Jordan, Kuwait, Oman, Iraq, and Israel. The majority of the impacted entities belong togovernment,telecommunications, military, andfinancialsectors, as well as IT services providers. However, we also observed the infection on the Exchange servers belonging to a regional affiliate of a global non-profit humanitarian network.
The geographic region and the targeted profile are aligned with Iranian interests and in line with the typical victim profile that MOIS-affiliated clusters usually target in espionage operations.
Previously, DEV-0861, a cluster we believed aligns with Scarred Manticore, was publiclyexposedfor the initial access to and data exfiltration from the Albanian government networks, as well as email exfiltration from multiple organizations in the Middle Eastern countries such as Kuwait, Saudi Arabia, Turkey, UAE, and Jordan.
Since at least 2019, Scarred Manticore deployed unique tools on compromised Internet-facing Windows servers in the Middle East region. During these years, their toolset went through significant development. It began as open-source-based web-deployed proxies and over time evolved to become a diverse and powerful toolset that utilizes both custom-written and open-source components.
One of the earliest samples related to the threat actors activity is based on a web shell fromTunna, an open-source tool designed to tunnel any TCP communication over HTTP. The Tunna web shell allows to connect from the outside to any service on the remote host, including those that are blocked on the firewall, as all the external communication to the web shell is done via HTTP. The IP and the port of the remote host are sent to the web shell in the configuration stage, and in many cases, Tunna is mostly used to proxy RDP connections.
The web shell used by the threat actor has the internal versionTunna v1.1g(only version 1.1a is available on Github). The most significant change from the open-source version is the encryption of requests and responses by XORing the data with the pre-defined stringszEncryptionKeyand appending the constant stringK_SUFFIXat the end:
Over time, the code was refactored and lost its resemblance to Tunna. We track this and all further versions as FOXSHELL.
The biggest changes resulted from organizing multiple entities into classes using an objective-oriented approach. The following class structure persists in most of the FOXSHELL versions:
All the functionality responsible for encrypting the traffic moved to a separateEncryptionModuleclass. This class loads a .NET DLL embedded in a base64-encoded string inside the body of FOXSHELL and invokes itsencryptanddecryptmethods:
The embedded encryption modules name isXORO.dll, and its classEncryption.XOROimplements decrypt and encrypt methods the same way as the Tunna-based web shell, using the same hardcoded values:
All requests to the web shell are also encapsulated within a class calledPackage, which handles differentPackageTypes: Data, Config, OK, Dispose, or Error. The PackageType is defined by the first byte of the package, and depending on the type of Package, the web shell parses the package and applies the configuration (opens a new socket to the remote machine specified in the configuration and applies a new EncryptionDll if provided), or disposes of the existing socket, or proxies the connection if the package is type Data:
This version of the web shell is still unobfuscated, and its internal version is specified in the code:
The web shell also contains the default EncryptionDll embedded inside. The modules name isBase64.dll, and the encryption class, which is misspelled asBsae64, exposes the encrypt and decrypt methods. However, both are just simple base64 encoding:
Although this simple encoding could be done in the code of the web shell itself, the existence of other embedded DLLs, such asXORO.dll(described previously), and the ability to provide yet another EncryptionDll on the configuration stage, implies that the attackers prefer to control which specific type of encryption they want to use by default in certain environments.
Other changes in this version are the renaming of the PackageTypeConfigtoRDPconfig, andConfigPackagetoRDPConfigPackage, indicating the actors are focused on proxying RDP connections. The code of these classes remains the same:
Finally, another condition in the code handles the case of the web shell receiving a non-empty parameterWV-RESET,which calls a function to shut down the proxy socket and sends anOKresponse back to the attackers:
The versions that were described above, targeted entities in Middle Eastern countries, such as Saudi Arabia, Qatar, and the United Arab Emirates. This version, in addition to being leveraged against Middle Eastern governmental entities, was part of theattackagainst the Albanian government in May 2021. Through the exploitation of an Internet-facing Microsoft SharePoint server, the actors deployedClientBin.aspxon the compromised server to proxy external connections and thus facilitate lateral movement throughout the victims environment.
The details of the samples may vary but in all of them, the FOXHELL is compiled as DLL and embedded inside the base web shell in base64. The compiled DLL is loaded withSystem.Reflection.Assembly.Load, and then theProcessRequestmethod from it is invoked. The DLL is written in .NET and has the name patternApp_Web_.dll, which indicates an ASP.NET dynamically compiled DLL.
TheApp_Web*DLL is affected by the class and method obfuscation, and all the strings are encrypted with a combination of Base64, XOR with the first byte, and AES:
When the web shell is compiled into DLL, it contains the initialization stub, which ensures that the web shell listens on the correct URI. In this case, the initialization happens in the following piece of code:
Or, after deobfuscation:
This initialization sets the FOXSHELL to listen to the requests on the relative path~/1.aspx, which we observed as an unused artifact in other web shells related to attacks involving LIONTAIL.
Internally, the DLL has the same 1.5 version of FOXSHELL, which includes theWV-RESETparameter to stop the proxy and the same defaultBsae64Encryption DLL as in previous versions.
Since mid-2020, in addition to the FOXSHELL as a means to proxy the traffic, we also observed a rather sophisticated standalone passive backdoor, written in .NET and meant to be deployed on IIS servers. It is obfuscated with similar techniques as FOXSHELL and masquerades asSystem.Drawing.Design.dll. The SDD backdoor was previouslyanalyzedby a Saudi researcher but was never attributed to a specific threat actor or campaign.
C&C Communication
The SSD backdoor sets up C&C communication through an HTTP listener on the infected machine. It is achieved using two classes:
ServerManager is used to extract the sites hosted by the IIS server and build the HashSet of URL prefixes to listen on:
In this specific case, the only relative URI configured in the malware sample is Temporary_Listen_Addresses. The malware then uses the HttpListener class to start listening on the specified URL prefixes:
C&C command execution
The backdoor has several capabilities: execute commands usingcmd.exe, upload and download files, execute processes with specified arguments, and run additional .NET assemblies.
First, if the POST request body contains data, the malware parses it and handles the message as one of the 4 commands it supports. Otherwise, if the request contains a parameterVet, the malware simply decodes its value from base64 and executes it withcmd /c. If none of these is true, then the malware handles the heartbeat mechanism: if the request URL contains the stringwOxhuoSBgpGcnLQZxipain lowercase, then the malware sends backUsEPTIkCRUwarKZfRnyjcG13DFAalong with a200 OKresponse.
The data from the POST request is encrypted using Base64 and simple XOR-based encryption:
After decrypting the data of the message, the malware parses it according to the following order:
The possible commands, as named by the threat actors, include:
The response data is built the same way as the request (returns command type, command name, and output) and then encrypted with the same XOR-based algorithm as the request.
Recently, Fortinetrevealeda wave of attacks against Middle Eastern targets (mostly Saudi Arabia, but also Jordan, Qatar, and the United Arab Emirates) that involve kernel mode drivers that the researchers named WINTAPIX. Although the exact infection chain to install the drivers is unknown, they target only IIS servers as they use the IIS ServerManager object. The high-level execution flow is the following:
The final payload is obfuscated with a commercial obfuscator in addition to already familiar class, method, and string obfuscations, and it combines the functionality of the SDD backdoor and FOXSHELL proxy. To achieve both, it listens on two sets of URL prefixes, using ServerManager and HTTPListener similarly to the SSD backdoor.
The FOXSHELL version used within the driver payload is set to1.7. The main enhancement introduced in this version is the Event Log bypass using a known technique of suspending EventLog Service threads. The default EncryptionDll hardcoded in the driver is the same Bsae64.dll, and the core proxy structure remains largely unaltered when compared to FOXSHELL version 1.5.
As an extensive analysis of the WINTAPIX driver and its versionSRVNET2was already provided, here we only highlight the main overlaps between those and other discussed tools that strengthen their affiliation:
LIONTAIL framework components share similar obfuscation and string artifacts with FOXSHELL, SDD backdoor, and WINTAPIX drivers. Currently, we are not aware of any other threat actors utilizing these tools, and we attribute them all to Scarred Manticore based on multiple code overlaps and shared victimology.
For the last few years, Scarred Manticore has been observed carrying out multiple stealthy operations in Middle Eastern countries, including gaining access to telecommunications and government organizations in the region, and maintaining and leveraging this access for months to systematically exfiltrate data from the victims systems. Examining the history of their activities, it becomes evident how far the threat actor has come in improving their attacks and enhancing their approach which relies on passive implants.
While LIONTAIL represents a logical progression in the evolution of FOXSHELL and still bears some distinctive characteristics that allow us to attribute attacks involving LIONTAIL to Scarred Manticore, it stands out from other observed variants. The LIONTAIL framework does not use common, usually monitored methods for implementing listeners: it no longer depends on Internet Information Services (IIS), its modules, or any other options and libraries provided by the .NET framework to manage IIS programmatically. Instead, it utilizes the lowest level of Windows HTTP Stack by interacting directly with the HTTP.sys driver. In addition, it apparently allows the threat actors to customize the implants, their configuration parameters, and loaders file delivery type. All those have enhanced the stealth ability of the implants, enabling them to evade detection for an extended period.
We expect that Scarred Manticore operations will persist and may spread into other regions as per Iranian long-term interests. While most of the recent activity of Scarred Manticore is primarily focused on maintaining covert access and data extraction, the troubling example of the attack on the Albanian government networks serves as a reminder that nation-state actors may collaborate and share access with their counterparts in intelligence agencies.
Check Point Customers remain protected against attacks detailed in this report, while using IPS, Check PointHarmony Endpoint and Threat Emulation.
IPS:
Backdoor.WIN32.Liontail.A/B
Threat Emulation:
APT.Wins.Liontail.C/D
See original here:
From Albania to the Middle East: The Scarred Manticore is Listening ... - Check Point Research
Read More..