Gorgon Group's Remcos Campaign Hides Behind Three Evasion Layers and a Swiss No-Log VPN

A Financial-Lure ZIP Carrying Three Layers of Evasion Before Remcos Calls Home

A 131-kilobyte ZIP archive named "STATEMENT OF ACCOUNT - JULY'24.zip" is the entry point for a Remcos RAT campaign that layers three distinct anti-analysis mechanisms into its payload before beaconing to a Swiss no-log VPN node — a C2 address that was still receiving fresh TLS certificates as recently as May 2026, roughly six years after the initial payload cluster first appeared on VirusTotal. The combination of PEiD packing, SmartAssembly .NET obfuscation, and active sandbox-timing evasion in a single delivery chain represents an investment in detection suppression that goes well beyond the commodity defaults typically associated with off-the-shelf remote access tooling.

CTX Team has tracked this cluster under threat record CTX6i3wxxjbid, attributing it to Gorgon Group (also tracked as Subaat) with espionage listed as the stated motivation. The confidence on that attribution is medium — the label is present, but no corroborating public evidence was available to elaborate further on current targeting priorities or geopolitical context.

The Delivery Container: A Financial Lure Confirmed by Its Own Recovery Path

The campaign's initial-access mechanism [T1566.001] is a phishing email carrying the ZIP as an attachment. The file's own metadata makes the delivery context unambiguous: one of its recorded paths is /tmp/eml_attach_for_scan/5d5f1b3d7a4f9577ddf392848548a5ac.file — a temporary directory used by email-scanning infrastructure when processing attachments, confirming the file transited an email pipeline before reaching the analysis environment. The archive's alternate name, "STATEMENT OF ACCOUNT - JULY'24.zip," is a financial-document lure calibrated to land in accounts-payable or procurement inboxes, where recipients routinely open external correspondence without the same suspicion they might apply to an unsolicited executable.

The container itself is not a passive wrapper. VirusTotal tags on the ZIP — attachment, spreader, persistence, service-scan, detect-debug-environment, and long-sleeps — indicate that sandbox analysis of the archive, not just its contents, triggered behavioural detections. The Zenbox sandbox returned a malicious verdict with 100% confidence, classifying the container as MALWARE, TROJAN, EVADER, and RAT, with Remcos named explicitly. Fifty-six of 76 scanning engines flagged the archive, with one community vote marking it malicious; nineteen engines, including CrowdStrike, Paloalto, and Trapmine, returned no detection. One Sigma medium-severity rule and one low-severity rule matched against the ZIP, adding a rule-based signal layer on top of the AV consensus.

The archive contains exactly one child file — a single PE executable — with a recorded compression timestamp of 2020-07-23 22:52:34. The uncompressed payload weighs 160,256 bytes. An alternate path recorded for the extracted PE reads C:\Users\user\AppData\Local\Temp\k34fqnrv.hfi\STATEMENT OF ACCOUNT - JULY'24.exe, showing that Windows extraction preserved the financial-document filename through to the dropped executable — a masquerading move [T1036] that keeps the lure coherent even after the archive is opened.

Two Payloads, One Packer, and a .NET Variant That Adds SmartAssembly on Top

The file cohort at the core of this campaign consists of two unsigned Win32 executables that CTX Team's analyst pass grouped under the label "PEiD-packed Remcos PE32 executables." Both cleared the sandbox bar for Remcos RAT classification; both are unsigned, with no code-signing certificate present on any of the four file IOCs in the set. The absence of signing is notable precisely because it means the evasion burden falls entirely on obfuscation and timing mechanics rather than on certificate-based allowlisting.

The native PE (sha256 prefix f73ac78, 92 KB) carries a PE timestamp of 2017-01-05 — more than three years before the payload cluster first appeared on VirusTotal in July 2020. Its .text section registers entropy at 6.06, consistent with PEiD packing but not with the heavier obfuscation applied to its sibling. The C2AE sandbox returned a malicious verdict naming Remcos RAT. Sixty-two of 73 engines flag this sample; ten engines, including Baidu, CMC, and Yandex, still miss it. The YARA rule Remcos from JPCERTCC's MalConfScan ruleset — designed to detect Remcos in memory — fires on this file, providing a named rule anchor that ties the sample to the family at the memory-scan layer rather than relying solely on static signatures.

The .NET variant (sha256 prefix 9d57d55, 156 KB, PE timestamp 2020-07-23) is the more operationally significant sample. Its magic string — "PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows" — identifies it as a managed-code binary, and the YARA rule INDICATOR_EXE_Packed_SmartAssembly authored by ditekSHen fires against it, confirming SmartAssembly obfuscation on top of the PEiD packing that both samples share. The practical consequence of this double layer is visible in the .text section entropy: 7.6, compared to 6.06 in the native PE. At 7.6, the section is approaching the theoretical maximum for random data, indicating aggressive packing or encryption of the code region [T1027.013]. Two Sigma medium-severity rules match against this sample, and both C2AE and Yomi Hunter sandboxes returned malicious verdicts — the only file in the set to achieve two independent sandbox confirmations. Sixty-one of 77 engines flag it; sixteen miss, including Acronis, Antiy-AVL, Avast-Mobile, and Webroot.

The imphash for the .NET PE is f34d5f2d4577ed6d9ceec516c1f5a744; the native PE carries d3a62971944197f0701c7049a9c739d1. The two values differ, meaning the import-table linkage axis that would most cleanly demonstrate a shared builder is absent here. The only confirmed cross-file binding is the PEiD packer detection — a shared packing pipeline that is suggestive of a common build environment but not conclusive on its own, given how widely PEiD-detectable packers are distributed. Two of the four files in the set lack imphash values entirely, making build-pipeline clustering unreliable.

The PE timestamp divergence — 2017-01-05 for the native binary versus 2020-07-23 for the .NET variant — suggests the operator either maintains parallel build pipelines for different payload formats or reuses older compiled tooling alongside newer obfuscated variants. PE timestamps can be forged, so this gap should be treated as a data point rather than a definitive build chronology, but the three-year spread is wide enough to warrant noting.

The Evasion Stack: Debug Checks, CPU Clock Reads, and Deliberate Long Sleeps

The most analytically distinctive feature of this campaign is not the payload family — Remcos is commercially available and widely deployed across the threat landscape — but the layered anti-analysis stack baked into the delivery chain. Three distinct evasion mechanisms are evidenced across the PE samples and the delivery ZIP, each targeting a different layer of the analysis pipeline.

The first layer is structural obfuscation [T1027.013]: PEiD packing on both PE files, with SmartAssembly layered on top for the .NET variant. SmartAssembly is a commercial .NET obfuscator that applies string encryption, control-flow obfuscation, and resource compression; its presence is confirmed not by heuristic inference but by the named YARA rule INDICATOR_EXE_Packed_SmartAssembly firing against the sample. The 7.6 .text entropy is the measurable artefact of this obfuscation: a section that dense with apparent randomness will resist static disassembly and pattern-matching at the byte level.

The second layer targets the analysis environment itself. The tag detect-debug-environment appears on both the .NET PE (9d57d55) and the delivery ZIP (2948503), mapping to MITRE T1497.002 — checks that query the runtime environment for indicators of a debugger, virtual machine, or sandbox harness. If such indicators are found, the payload can abort, sleep indefinitely, or execute a benign code path, producing a clean sandbox report. This technique is common enough to be expected in commodity RAT deployments, but its presence across both the container and the extracted PE suggests it is implemented at the payload level and not merely an artefact of the archive's metadata.

The third layer is timing-based evasion [T1497.003]. The tags direct-cpu-clock-access and long-sleeps appear on both PE files and on the ZIP container. Direct CPU clock access — reading the timestamp counter (RDTSC instruction or equivalent) — allows the payload to measure elapsed time with nanosecond precision, detecting the artificial time compression that some sandbox environments apply to accelerate execution. Long sleeps serve a complementary purpose: if the payload waits longer than the sandbox's maximum analysis window before executing its malicious logic, it will appear benign in the sandbox report. Together, these two mechanisms are designed to defeat both time-compressed and time-limited sandbox environments — the two most common sandbox configurations in enterprise security stacks.

The combination of all three layers in a single campaign is the signal worth noting. An operator deploying only packing is making a minimal investment in evasion; one deploying packing, environment detection, and timing evasion simultaneously is demonstrating either operational maturity or a learned response to sandbox detection rates improving over the campaign's lifespan. Given that the payload cluster first appeared in mid-2020 and the infrastructure was still being actively maintained in 2026, the latter interpretation is consistent with the evidence.

Execution and Persistence: AppData Residency and a BAT Stub That Raises Questions

Upon user execution of the embedded PE [T1204.002], the payload drops to C:\Users\<USER>\AppData\Roaming\FolderN\name.exe — a non-system directory that avoids the write-permission requirements of Program Files while remaining persistent across reboots if a run-key or startup-folder entry is established. The AppData\Roaming path is a well-worn Remcos deployment convention, and its appearance here is consistent with the broader MITRE T1547.001 technique.

Co-located at the same AppData\Roaming\FolderN path is a near-zero-byte ASCII text file with the extension .bat: C:\Users\<USER>\AppData\Roaming\FolderN\name.exe.bat. This file — sha256 prefix 2ebc1ac — carries only 9 of 76 engine detections and has no sandbox verdict. Its role in the execution chain is inferred rather than directly observed. The co-location with the Remcos PE at an identical directory path, combined with the delivery ZIP's persistence tag and the presence of T1059.003 (Windows Command Shell) and T1547.001 in the threat metadata, is consistent with a BAT-based launcher or persistence stub — a script that either invokes the PE on startup or chains execution from the initial user action. However, this file is technically isolated from all other file clusters, with no shared imphash, signer, or threat label linking it to the PE cohort. The BAT stub's role should be treated as a plausible inference, not an established fact.

The detection gap on the BAT file is operationally significant in its own right. At 9/76, it sits well below the near-universal consensus achieved by the PE payloads. Fifty-two engines return no detection; fourteen mark the file type as unsupported. The nine engines that do flag it include Avira, Comodo, ESET-NOD32, Fortinet, and Qihoo-360 — a mixed set that suggests detection is based on contextual heuristics (path, filename pattern, content association) rather than a clean signature match. If the BAT stub functions as a persistence mechanism [T1059.003], its low detection profile means it is the component most likely to survive an endpoint scan that catches the PE payloads.

The C2 Node: Six Years of Infrastructure Continuity Behind a No-Log VPN Wall

The campaign's entire observed network footprint resolves to a single IP address: 79.134.225.21. This address sits within the 79.134.225.0/27 netblock registered under the netname PRIVACYFIRST-EU, assigned to AS6775 (Fink Telecom Services GmbH, Switzerland). The WHOIS record for this block is not merely a registration artefact — it is an operational statement. The remarks field reads, in part: "we keep no logs of user activities and only share data when it is legally required under our jurisdiction, it is very unlikely for a demand of user information to be successful." This is a provider that has built its service model around frustrating law-enforcement data requests, and the operator's choice to route C2 traffic through this specific netblock [T1571] reflects a deliberate infrastructure decision rather than incidental hosting selection.

The IP carries only 8 of 91 engine detections on VirusTotal, with a reputation score of zero and no community votes — a profile consistent with a node that has not been widely blocklisted despite its operational role. The low detection rate on the C2 IP, combined with the high detection rates on the file payloads, suggests that network-layer blocking would need to be the primary defensive signal here, since the endpoint detections on the PE files are already near-universal.

The TLS certificate observed on this IP on 2026-05-11 — the most recent certificate observed — is the detail that transforms this from a historical campaign record into an active infrastructure concern. The certificate carries serial number 54841a34c1525009b4978c5b12c8ba5a7d, issued by Let's Encrypt's E7 intermediate CA, with a validity window of 2026-05-10 to 2026-08-08: an 89-day span, consistent with Let's Encrypt's standard issuance policy. The subject CN is ciesnik.de, but the Subject Alternative Names field covers twelve entries across six base domains: *.aftv.info, *.ciesnik.de, *.enlightme.app, *.enlightme.info, *.t-aga.in, *.trufel.de, plus the non-wildcard versions of each. The certificate presents two anomalies: a short-lived cert (89 days) and a wildcard SAN — the latter indicating that a single certificate is being used to cover multiple operator-controlled or operator-leased domains simultaneously.

The multi-domain SAN pattern is consistent with shared hosting or a multi-tenant infrastructure arrangement where one certificate serves several hostnames from the same IP. It also provides a pivot surface: any of the six base domains covered by this certificate could represent additional operator infrastructure, and the wildcard entries mean subdomains are covered without requiring separate certificate issuance. The certificate's issuance date — May 2026 — falls approximately six years after the payload cluster's earliest first-seen date of 2020-07-23. That gap is the most operationally significant temporal signal.

Two readings of this gap are plausible. The first is sustained operator use: the same actor has maintained this C2 node continuously across a multi-year campaign window, periodically re-provisioning the TLS certificate as each 89-day Let's Encrypt cert expires. The second is infrastructure reuse: the node was repurposed by the same or a different operator for a later campaign wave, with the 2020 payload cluster representing an earlier phase and the 2026 certificate representing a current or recent operation that may involve different payloads not yet observed. The available evidence does not distinguish between these two scenarios. What it does establish is that this IP address, in this no-log VPN netblock, was receiving active TLS maintenance as recently as May 2026 — and that the operator has not abandoned it.

Detection Landscape and the Gaps That Matter

Across the three primary file IOCs with meaningful detection data, the AV consensus is strong: 62/73 on the native PE, 61/77 on the .NET PE, and 56/76 on the delivery ZIP. These are not low-detection samples that rely on evasion to avoid the AV layer — the evasion stack appears to be targeted primarily at sandbox and behavioural analysis environments rather than at static signature engines. The implication is that the operator's primary concern is not bypassing traditional AV but avoiding sandbox-based classification that would accelerate blocklisting and threat-intelligence sharing.

The engines that miss across the three samples are not uniformly the same set, but several names appear repeatedly in the missing lists: Baidu, CMC, Avast-Mobile, and Trustlook are absent from detections on multiple samples. These are not the engines that typically drive enterprise security decisions, but their consistent absence is worth noting for environments that rely on them as a primary layer.

The BAT stub (2ebc1ac) is the outlier in the detection landscape: 9/76, no sandbox verdict, no YARA or named-rule match. If this file functions as the persistence mechanism — and the path co-location evidence suggests it might — then it represents the weakest link in the detection chain. An endpoint that catches the Remcos PE at execution but misses the BAT stub may clear the active malware while leaving a persistence mechanism in place.

The C2 IP's 8/91 detection rate on VirusTotal's network-IOC scanning is a separate concern. Network-layer detections on IP addresses tend to lag behind file detections, and a no-log VPN provider's IP is unlikely to accumulate the community votes and reputation signals that drive blocklist inclusion. The PRIVACYFIRST-EU netblock's explicit no-log policy compounds this: even if the IP is flagged, the operator can continue using it without meaningful disruption from law-enforcement action.

Two additional files in the set — sha256 prefixes d8f0fb00 and df761c9e — carry no metadata, meaning the full tooling picture may be broader than current evidence supports. Any conclusions about the campaign's payload diversity should be qualified accordingly.

Infrastructure Longevity as the Campaign's Defining Operational Signal

The most significant analytical observation is not the payload family, the obfuscation stack, or even the evasion techniques — all of which are documented Remcos deployment patterns. It is the six-year gap between the earliest payload first-seen date and the most recent infrastructure maintenance activity.

Commodity RAT campaigns typically exhibit one of two infrastructure patterns: rapid turnover, where C2 nodes are rotated frequently to avoid blocklisting, or long-term stability, where a single node is maintained across extended campaign windows because the operator has confidence in its resilience to takedown. The PRIVACYFIRST-EU netblock is structurally optimised for the second pattern. A no-log provider in a jurisdiction that explicitly warns law-enforcement agencies that data requests are unlikely to succeed offers the kind of operational continuity that makes long-term C2 node reuse rational. The 89-day Let's Encrypt certificate cycle means the operator is actively maintaining the node — not just leaving an old IP address running on inertia — and the wildcard SAN covering six domains suggests the infrastructure serves more than one operational purpose.

The layered obfuscation stack — SmartAssembly on the .NET payload, PEiD packing on both PEs, and timing-based sandbox evasion across the entire delivery chain — is consistent with an operator who has observed their payloads being detected and has incrementally added evasion layers in response. The .NET variant's SmartAssembly obfuscation, confirmed by the named YARA rule INDICATOR_EXE_Packed_SmartAssembly, represents a more sophisticated investment than the PEiD packing alone on the native PE. If the native PE (PE timestamp 2017) predates the .NET variant (PE timestamp 2020-07-23), the progression from single-layer to double-layer obfuscation across the build timeline is consistent with an operator adapting to improved sandbox coverage over time.

The financial-document lure — accounts-payable language, a July 2024 date in the filename despite the payload cluster originating in 2020 — points toward broad opportunistic targeting of organisations that receive external financial correspondence by email. The "STATEMENT OF ACCOUNT" framing is not sector-specific; it is designed to be plausible in any commercial or government environment where invoices and account statements arrive from external counterparties. The absence of any region or industry restriction reinforces the opportunistic read: this is not a precision-targeted campaign against a named sector but a wide-net operation relying on volume and lure credibility to generate infections.

What this campaign signals, taken as a whole, is an operator with a long time horizon and a preference for infrastructure stability over tradecraft novelty. The PRIVACYFIRST-EU netblock, the wildcard SAN domains, and the six-year maintenance window on a single C2 node all point toward an actor who has built their operational infrastructure around resilience to attribution and takedown rather than around the kind of rapid rotation that characterises more tactically agile threat groups. The evasion stack is sophisticated enough to suggest operational maturity, but the payload family — commercially available Remcos — indicates the operator is not investing in custom tooling development. That combination, commodity payload plus hardened infrastructure plus layered evasion, is a profile worth tracking: it describes an actor who has optimised for sustained access and operational continuity rather than for the kind of high-complexity intrusions that generate the most public attention.