Donot Team Hides Cryptominer Behind Tor C2 and Anti-VM Evasion

A Miner in Espionage Clothing: How Donot Team's dekimine Payload Stacks Evasion, Tor, and Cryptomining

A single 7,149-kilobyte Windows executable — packed, obfuscated, and deliberately named to impersonate a core Windows process — encapsulates one of the more analytically provocative payload configurations CTX Team has observed in a recent APTC-35 dataset. The binary, classified as trojan.dekimine and bearing the meaningful installation path %APPDATA%\pwo6\svchost.exe, does not merely steal data or open a remote shell. It checks whether it is being watched, routes its command-and-control traffic through Tor, drops secondary executables into temporary paths, and then — in a move more commonly associated with financially motivated criminal actors than with a state-aligned espionage group — mines cryptocurrency on the compromised host. The combination is operationally unusual, and the evasion stack layered beneath it is sophisticated enough to warrant a close reading of each component.

CTX Team's confidence in the overall dataset is rated low — an evidence score of 25 out of 100, reflecting the fact that 48 of the 58 file SHA-256 hashes in the campaign catalog carry no enrichment whatsoever. What follows is an analysis grounded in the one richly enriched indicator and the single network IOC available, with explicit acknowledgement of where the evidence runs thin.

---

The Evasion Stack: UPX Packing, Name-Squatting, and Timing-Based Anti-VM

The dekimine binary's first line of defence is structural obfuscation [T1027]. Its PE32 executable format is confirmed as UPX-compressed — the YARA rule UPX fires on the sample, and the PE section layout tells the same story: a zeroed UPX0 section sitting alongside a UPX1 section registering entropy of 7.98, the near-theoretical maximum for compressed or encrypted data. The .rsrc section follows close behind at entropy 7.53. Both PEiD and F-PROT packer identifiers are recorded against the file. The build provenance record states it plainly: "packed (PEiD, F-PROT); high-entropy section(s) UPX1, .rsrc." For static analysis tools and signature engines that inspect PE sections without unpacking, the payload's true code is invisible.

The masquerade layer [T1036] compounds this. The binary's meaningful name — the path under which it actually resides on a compromised host — is %APPDATA%\pwo6\svchost.exe. The choice of svchost.exe is deliberate and well-worn: Windows systems routinely run dozens of legitimate svchost.exe instances, each hosting one or more services, making a rogue copy in a user's APPDATA directory easy to overlook in a process listing unless the analyst checks the executable's path. The alt-name list extends the masquerade further, recording bare svchost.exe as an observed name alongside the TEMP-path executables xzgqogif.exe and dbcuwznm.exe — the latter two representing secondary payloads dropped during sandbox execution.

What distinguishes this sample from a routine UPX-packed masquerader is the active anti-analysis logic that fires before the payload deploys. The behavioural tags detect-debug-environment and direct-cpu-clock-access map directly to two MITRE techniques: T1497.002 (Virtualization/Sandbox Evasion: User Activity Based Checks) and T1622 (Debugger Evasion), both of which appear in the campaign's MITRE technique list. The direct-cpu-clock-access tag is particularly telling. Reading the CPU's timestamp counter (RDTSC instruction or equivalent) is a classic timing-based anti-VM technique: the binary measures the elapsed time between two operations and compares it against a threshold. In a virtualised or instrumented environment — a sandbox, a debugger, an emulator — the timing gap is anomalously large, because the hypervisor or instrumentation layer introduces overhead. If the gap exceeds the threshold, the malware can suppress execution, sleep, or exit cleanly, presenting a benign profile to automated analysis.

The detect-debug-environment tag adds a second check: explicit interrogation of the runtime environment for signs of a debugger or analysis tool. Together, these two mechanisms form a pre-execution gate. A payload that passes through both checks before deploying its primary functionality is harder to characterise in automated sandboxing pipelines, because the conditions under which it behaves maliciously may not be reproducible in a standard sandbox run. The Dr.Web vxCube sandbox that did execute the sample returned a malicious verdict, but only one sandbox result is recorded — a thin consensus for a sample that actively tries to detect and defeat analysis environments.

The detection picture across the broader engine population reflects this evasion success partially. Of 77 engines queried, 47 flag the sample — a majority, but one that leaves 25 engines returning clean results and one timing out. The dossier's industry view notes that engines including CrowdStrike Falcon, SentinelOne, AhnLab-V3, Avira, F-Secure, and Elastic are among those not flagging the sample. The community vote tally is minimal: two malicious votes, zero harmless. The reputation score sits at -2. For a sample first submitted to VirusTotal in February 2014 and last seen as recently as May 2026, the persistence of misses across modern engines after more than a decade of circulation is itself a signal about the effectiveness of the packing and evasion combination.

The Sigma rule coverage adds context. The dossier records 16 Sigma matches against the sample — one critical, ten high, three medium, two low — spread across both the SOC Prime Threat Detection Marketplace and the Sigma Integrated Rule Set on GitHub. The presence of a critical-severity Sigma match alongside the YARA hits suggests that behavioural detection logic, rather than static signatures, is the more reliable detection surface for this family.

---

Tor-Anonymised Command and Control: IDS Fingerprints and the Nuremberg Endpoint

The network behaviour recorded during sandbox execution is where the dekimine sample's operational security discipline becomes most apparent. Two Proofpoint Emerging Threats IDS rules fired during the sandbox run: ET TOR Known Tor Relay/Router (Not Exit) Node Traffic group 240 and ET POLICY TLS possible TOR SSL traffic. The first rule identifies traffic to or from a known Tor relay or router node — specifically one in group 240 of the Emerging Threats Tor node list, which is maintained against published Tor consensus data. The second rule flags TLS traffic exhibiting characteristics consistent with Tor's SSL layer. Together, they establish that the malware was communicating through the Tor anonymisation network during execution, routing its C2 traffic [T1090] through a chain of relays rather than connecting directly to an operator-controlled server.

A Snort registered-user ruleset alert also fired: (port_scan) TCP filtered portsweep, categorised as attempted-recon. This indicates the sample conducted host or network discovery [T1046] during execution — sweeping TCP ports in a pattern that Snort's portsweep detection logic recognised. An PROTOCOL-ICMP Unusual PING detected alert from the same Snort ruleset adds to the reconnaissance picture. The combination of Tor-routed C2 and active network reconnaissance from a single sandbox run suggests a payload designed not just to phone home but to map its environment once deployed.

The sole network IOC in the entire campaign dataset is 212.112.245.170. Its WHOIS record, queried on 6 May 2026, assigns the specific /24 block — 212.112.245.0 - 212.112.245.255, netname IPX-Server-NET — to IPX Server GmbH, located at Am Tower 5, 90475 Nuremberg, Germany. The broader network block is 212.112.224.0/19, registered to NorthC Deutschland GmbH under AS 15598, with the /24 assignment to IPX Server GmbH recorded in RIPE NCC since 27 May 2005. This is a commercial colocation and hosting provider operating in Nuremberg's data centre ecosystem — a legitimate infrastructure business with no inherent malicious profile.

The detection signal for this IP is near-zero: 1 of 91 engines flag it, the community vote tally is zero malicious and zero harmless, and the reputation score is neutral at 0. CTX Team's analyst findings correctly flag this IP as an outlier: it occupies a unique ASN not shared by any other indicator in the dataset, and its near-zero independent detection signal means its C2 role is inferred from campaign association rather than directly observed network traffic. There are no co-occurring domains, no shared TLS certificate serials, and no second IP in the same AS to corroborate the association. Analysts should treat the attribution of 212.112.245.170 as a working hypothesis pending additional network telemetry.

What the infrastructure choice does suggest — and this is an inferential reading — is consistent with a pattern of using legitimate European commercial hosting to reduce geographic suspicion and avoid AS-level blocklists. A German colocation provider in a well-connected Nuremberg data centre presents a very different network-layer profile than infrastructure in a jurisdiction more commonly associated with threat actor hosting. Combined with Tor routing that obscures the true operator endpoint, the architecture is designed to make network-layer attribution difficult: even if a defender identifies traffic to 212.112.245.170, the Tor layer between the infected host and any actual operator infrastructure means the IP may represent a relay node rather than the terminal C2 server.

Using a bare IP directly as C2 with no domain layer leaves no certificate or registration trail, frustrating infrastructure tracking. The "German Hosting IP" fingerprint stands entirely alone.

---

Persistence and Payload Deployment: WMI, Dropped Executables, and the Mining Endgame

Once the dekimine binary passes its pre-execution evasion checks, its persistence mechanism is straightforward but effective. The behavioural tags executes-dropped-file, calls-wmi, and persistence — all recorded against the sample — map to T1547 and T1547.001 in the campaign's MITRE technique list. The sandbox execution observed the binary writing secondary payloads to TEMP paths: C:\Users\user\AppData\Local\Temp\xzgqogif.exe and C:\Users\user\AppData\Local\Temp\dbcuwznm.exe. The randomised, eight-character names of these dropped executables — xzgqogif and dbcuwznm — are consistent with runtime-generated filenames designed to avoid static detection by name. The runtime-modules tag on the parent binary supports this: the sample loads or generates modules at runtime rather than carrying them as static embedded resources.

WMI invocation (calls-wmi) is the persistence mechanism of choice. Windows Management Instrumentation offers multiple persistence vectors — WMI event subscriptions, for instance, can execute arbitrary commands when system events occur, surviving reboots without registry modifications that some endpoint tools monitor specifically. The T1547.001 mapping in the MITRE list references Boot or Logon Autostart Execution, and the combination of WMI calls with dropped executables suggests the payload establishes a run-on-logon or run-on-event mechanism that re-executes the dropped components after system restart or user login.

The terminal impact stage is where the payload's unusual dual-purpose nature becomes most explicit. The YARA rule CoinMiner_Strings — from Florian Roth's pua_cryptocoin_miner ruleset, hosted in the Neo23x0 signature-base repository — fires on the binary. The rule's description is precise: it detects mining pool protocol strings in executables. Mining pool protocol strings are the structured communication patterns used by cryptocurrency mining software to communicate with pool servers — they include stratum protocol handshakes, job requests, and share submissions. Their presence in a binary's static content is a reliable indicator of embedded mining capability [T1496].

The direct-cpu-clock-access tag, which earlier served as evidence of timing-based anti-VM checks, has a second operational reading in the context of a miner: CPU clock access is also a natural component of mining software, which needs to measure hash rates and manage CPU utilisation. The runtime-modules tag similarly fits a miner that loads its hashing algorithm as a runtime component. The popular category fields list trojan, miner, and downloader — a multi-role classification that reflects the sample's observed capability profile.

The checks-user-input tag adds a further behavioural dimension. Monitoring user input can serve multiple purposes: a miner might throttle CPU usage when the user is active (to avoid detection through performance degradation) and ramp up when the system is idle. This is consistent with the overlay tag, which in PE analysis typically indicates data appended after the end of the last PE section — a common technique for embedding additional payloads, configuration data, or mining pool credentials that are not visible in the primary PE structure.

The Sigma rule coverage for the persistence and impact stages is substantial. Ten high-severity Sigma matches and one critical-severity match suggest that behavioural detection logic for WMI-based persistence and mining activity is well-represented in community rule sets — but the evasion stack described above means that reaching the stage where those Sigma rules fire requires first defeating the pre-execution anti-analysis gate.

---

The Anomalous Second File and the 48 Unenriched Hashes

The campaign dataset contains 58 file SHA-256 hashes and one IP address. Of the 58 files, only two carry any VirusTotal metadata. The second enriched file — f02285fb90ed8c81531fe78cf4e2abb68a62be73ee7d317623e2c3e3aefdfff2 — is a zero-kilobyte ASCII text file with no line terminators, first seen on VirusTotal in January 2015 and last seen in January 2026. Its meaningful name is /tmp/d0bx2z3x, with alt names including /tmp/t56yjw8f, /tmp/etq1z99f, /tmp/b8i630yw, and 01i0s7wj. It carries the behavioural tags idle, text, and long-sleeps. The Zenbox sandbox returned a clean verdict with 99% confidence. Zero of 75 engines flag it. The community vote is one malicious, zero harmless.

This file is anomalous in every dimension. A zero-byte text file with Linux /tmp path names appearing in a Windows-focused APT campaign dataset attributed to APTC-35 raises immediate questions about its inclusion. The long-sleeps tag — indicating a process or file associated with extended sleep intervals — and the idle tag suggest a staging artifact, a placeholder, or a file that was included in the campaign metadata through a false-positive association rather than genuine operational linkage. CTX Team's analyst findings flag it explicitly as an outlier: its presence "may represent a dropper staging artifact, a decoy, or a false positive inclusion." No determination is possible from current evidence.

The 48 entirely unenriched file hashes represent a more consequential blind spot. These SHA-256 values carry no type information, no detection data, no tag data, and no submission history. They constitute 83% of the file IOC population in this campaign. If they include additional ehdevel-family components — loaders, stagers, reconnaissance tools, or secondary implants — the true capability profile of this operation may be substantially broader than the single enriched dekimine sample suggests. The ehdevel malware family is listed as the campaign family, but the only file that can be directly characterised as ehdevel-associated is the dekimine binary. The relationship between the 48 unenriched hashes and the ehdevel family designation cannot be confirmed from current evidence.

Neither of the two enriched files carries a code-signing certificate, leaving no signing-authority trail for build-pipeline attribution. Build-pipeline clustering via imphash is partially available — the dekimine binary carries imphash 01b1c9ea1a29292053e19bce0321e74c — but with only one file carrying an imphash in the dataset, cross-file clustering on this axis is not possible. The vhash for the dekimine sample is 07603e0f7d7bz6nz15z17z; the ssdeep is 196608:wB3e0E5MGzr3RhdJFk2kKVxpH8PIQJXOS/2JSNYPA:whMmGzFt22fpIZOS/A4. These fuzzy hashes provide a basis for similarity matching against future samples but cannot be used for intra-campaign clustering when the peer files carry no metadata.

The PE timestamp on the dekimine binary reads 23 March 2013 — a date that predates the file's first VirusTotal submission of 6 February 2014 by approximately ten months. PE timestamps are trivially manipulated and should not be treated as reliable build dates, but the combination of a 2013 timestamp, a 2014 first submission, and a last-seen date of May 2026 indicates a sample with over a decade of observed circulation. Its continued association with an active APTC-35 campaign dataset in 2026 is either evidence of long-term tooling reuse or an artefact of how the campaign metadata was assembled.

---

APTC-35 Attribution and the Espionage-Miner Tension

The campaign metadata attributes this activity to APTC-35, also tracked as Donot Team and SectorE02, with espionage listed as the sole stated motivation and Poland as the targeted region. The attribution is assessed at medium confidence. Current evidence is too thin to corroborate APTC-35's historical operations beyond what is directly stated here; any broader characterisation would require hedging against uncorroborated public background reporting.

What the evidence does establish is a tension at the heart of this campaign's payload design. A state-aligned espionage actor — one whose stated motivation is intelligence collection — is deploying a payload that actively mines cryptocurrency on compromised hosts. These two objectives are not inherently incompatible, but they pull in different operational directions. Cryptocurrency mining is noisy: it consumes CPU cycles, generates heat, degrades system performance, and can trigger performance-monitoring alerts in enterprise environments. An espionage operator typically wants to minimise the footprint of a compromised host, not maximise its computational load. The presence of active CPU mining [T1496] alongside Tor-routed C2 [T1090] and sophisticated anti-analysis evasion [T1497.002, T1622] creates an unusual operational profile.

Several interpretations are consistent with the available evidence, though none can be confirmed at the current data quality level. The first is deliberate multi-mission tooling: the operators have instrumented the payload to collect intelligence and generate cryptocurrency revenue simultaneously, treating the compromised host as a dual-use resource. The Tor C2 channel, which adds operational security discipline well beyond what a purely financially motivated miner would typically implement, lends some weight to this interpretation — a criminal miner operator rarely needs Tor anonymisation for pool communications. The second interpretation is tooling reuse from a shared criminal ecosystem: the dekimine binary may have originated in or been adapted from a criminal toolset, with the espionage operator incorporating it for its evasion capabilities while accepting the mining payload as a secondary component. The third is misclassification: the campaign metadata may have aggregated indicators from distinct operations, and the mining payload may not represent the espionage actor's primary tooling.

Current evidence is too thin to adjudicate between these interpretations with confidence. The evidence score of 25 out of 100 reflects a dataset where the analytically richest indicator is a single file, the network infrastructure is a single IP with near-zero independent detection signal, and 48 of 58 file hashes carry no enrichment at all.

---

What the Evasion Architecture Signals About Operational Maturity

The operationally significant observation in this dataset is not the actor attribution or even the mining payload — it is the specific combination of evasion mechanisms layered into a single binary and what that combination implies about the operators' awareness of defensive tooling.

UPX packing alone is a commodity technique, trivially detected by any engine that unpacks before scanning. The value of UPX in this context is not that it defeats modern AV engines — 47 of 77 flag the sample despite the packing — but that it raises the cost of static analysis and may defeat engines that do not unpack before scanning. The 25 engines that return clean results for a sample with over a decade of circulation suggest that the packing continues to provide some marginal evasion benefit even against contemporary tools.

The timing-based anti-VM layer [T1497.002] is more operationally meaningful. Automated sandbox pipelines are the primary mechanism by which new malware samples are characterised and signatures are generated. A payload that detects the sandbox environment and suppresses its malicious behaviour during automated analysis can delay or prevent signature generation, extending the window during which it operates without detection coverage. The detect-debug-environment check [T1622] adds a second gate against manual analysis: a reverse engineer attaching a debugger to the process triggers the check and may see a clean execution path rather than the malicious one.

The Tor C2 routing [T1090] is the most operationally sophisticated element of the stack. Tor provides two distinct defensive benefits for a threat actor: it anonymises the operator's true network location, making infrastructure attribution difficult even when the malware's network traffic is observed; and it leverages a large, legitimate network of relay nodes, making IP-based blocking ineffective without blocking Tor exit nodes and relays wholesale — a measure that most enterprise networks cannot implement without significant collateral impact on legitimate Tor usage.

The combination of these three layers — static obfuscation, pre-execution environment detection, and anonymised C2 — represents a defence-in-depth approach to evasion that is more typically associated with sophisticated, resource-rich operators than with commodity malware. Applied to a payload that also mines cryptocurrency, the architecture suggests either an operator with significant tooling investment who has chosen to monetise compromised hosts as a secondary objective, or a payload that has accumulated evasion capabilities over its decade-plus operational lifespan through iterative development.

The 48 unenriched file hashes remain the most consequential unknown in this picture. If they represent additional implants with comparable or greater capability — loaders, credential harvesters, keyloggers, or lateral movement tools consistent with the broader MITRE technique list for this campaign, which includes T1056 (Input Capture), T1055 (Process Injection), T1485 (Data Destruction), and T1486 (Data Encrypted for Impact) — then the dekimine binary may represent only the initial-access or persistence layer of a substantially more capable operation. The MITRE technique list's inclusion of T1485 and T1486 is particularly notable: data destruction and ransomware-style encryption are not consistent with a pure espionage or mining operation, and their presence in the campaign metadata suggests either a broader capability set than the enriched sample reveals or metadata aggregation from multiple operational phases.

For the organisations in Poland that represent the stated target region, the svchost.exe masquerade and APPDATA persistence path indicate a focus on standard enterprise Windows workstation environments. No industry vertical is specified, so the targeting cannot be further narrowed. What the evasion architecture does imply is that the operators anticipated detection by endpoint and network monitoring tools and designed the payload to operate beneath those detection thresholds — a level of operational planning that warrants treating the 48 unenriched hashes not as noise but as an uncharacterised capability population that future telemetry may reveal to be substantially more significant than the single enriched sample alone suggests.