Phorpiex Worm's Three-Layer Evasion Stack Keeps 20 AV Engines Blind
A 77-kilobyte Windows executable first compiled in 2020 is still generating active C2 feed hits in mid-2026. The sample combines a packed PE with a zeroed import table, svchost.exe masquerading, and a numeric-domain TLS certificate to defeat static clustering and category-based filtering. Twenty of 78 AV engines return no verdict on a sample more than four years old.
A Packed Ghost in the Process List: Phorpiex's Three-Layer Evasion Stack
A 77-kilobyte Windows executable — small enough to be dismissed as a stub, old enough to have first appeared on VirusTotal in October 2020 — is still generating active C2-server feed hits as of mid-2026. The sample, carrying the threat label trojan.phorpiex/zard and the deceptively mundane meaningful name DriveMgr.exe, is not remarkable for its size or age alone. What makes it analytically interesting is the combination of three distinct evasion layers baked into a single, compact binary: a packed PE with a completely zeroed import table that defeats static clustering, a masquerade identity that cycles through Windows system-process names depending on deployment context, and a command-and-control channel anchored to a purely numeric domain provisioned with a free Let's Encrypt certificate — a trio of choices that, taken together, keeps a meaningful fraction of the antivirus landscape blind to the threat years after the tooling was first compiled.
CTX Team has been tracking this campaign record (identifier CTXhjgtwai3gj) since December 2024, with the most recent feed activity logged in June 2026. The geographic signal points toward Guatemala, though no industry vertical is specified and the worm's propagation mechanism means geographic targeting is likely incidental rather than deliberate.
The Binary That Refuses to Show Its Imports
The payload at the centre of this record — SHA-256 e53fd17b02d27e1923b7e03604e76daa33c34d9edcf8546bac247fc51313c81e — is a 32-bit PE executable compiled and first submitted on 2020-10-27, with its most recent VirusTotal submission logged on 2023-02-12. Ten submissions across three unique sources over that span suggest it has circulated through multiple analysis pipelines without being definitively burned from active use.
The build provenance tells the most important part of the story. The binary carries a PEiD-detected packer and, critically, an import count of zero. This is not an artefact of a stripped or corrupted binary; it is a deliberate build choice. By zeroing the import address table and resolving all Windows API calls at runtime through a packed stub, the operator eliminates the import hash (imphash) as a clustering axis. The imphash recorded for this sample — 9668b7091de4529d55cf638b279f602e — is therefore a fingerprint of the packing wrapper rather than the underlying malicious code, making cross-sample clustering via that axis unreliable for any analyst who encounters a differently-packed variant of the same family.
The PE section entropy profile reinforces the packing assessment. The .reloc section registers entropy at 6.31 — elevated, consistent with compressed or encrypted content occupying what is nominally a relocation table section — while the .data section sits at a near-flat 2.38, suggesting minimal plaintext data is exposed in the binary's static layout. The .text section entropy of 5.71 and .rdata at 5.59 are within normal ranges for compiled code, but the .reloc anomaly is the tell: legitimate relocation tables do not carry that entropy signature. The .rsrc section at 50,688 bytes accounts for the majority of the binary's 77 KB footprint, which may indicate embedded resources used in the worm's propagation or payload-staging logic, though no sandbox report is available to confirm this interpretation.
The industry view reflects the evasion's partial effectiveness. Fifty-eight of 78 engines flag the sample as malicious — a strong majority, but one that leaves 20 engines returning no verdict. The flagging set includes well-known vendors across multiple detection paradigms, but the gap in coverage is operationally meaningful: in a heterogeneous enterprise environment, a host running only one of the non-flagging engines would receive no alert on this binary. The community vote count is neutral (zero malicious, zero harmless votes recorded), suggesting the sample has not attracted significant crowdsourced scrutiny despite its age.
Two crowdsourced YARA rules fire on the sample and anchor it firmly to the Phorpiex family regardless of the packing layer. The rule MALWARE_Win_Phorpiex, authored by ditekSHen and sourced from the public detection repository at github.com/ditekshen/detection, is described as detecting Phorpiex variants broadly. The rule win_phorpiex_auto, attributed to Felix Bilstein via the Malpedia platform at malpedia.caad.fkie.fraunhofer.de, targets the win.phorpiex family specifically. The co-firing of both rules on a packed binary with a zeroed import table demonstrates that the packing layer does not fully defeat signature-based detection when the signatures are written against the unpacked code's structural or string characteristics rather than its import profile — a meaningful limitation of the operator's chosen evasion approach.
The sample's popular names in the VirusTotal ecosystem — phorpiex, zard, and mint — reflect the family's documented alias set. Its popular categories span trojan, worm, and downloader, a multi-role classification consistent with Phorpiex's architecture as a platform that can spread autonomously, receive payload instructions from a C2 server, and execute secondary stages on demand.
svchost.exe Is Not Always svchost.exe
The second evasion layer operates at the filesystem and process-name level. The sample has been observed under the following paths across submissions: C:\Windows\6eu2g01ry.exe, C:\8631674119019\svchost.exe, C:\3610186882146\svchost.exe, and DriveMgr.exe alongside the canonical submission path. This is a textbook application of masquerading [T1036]: by placing a copy of itself at C:\8631674119019\svchost.exe or C:\3610186882146\svchost.exe, the binary adopts the name of one of Windows' most ubiquitous and legitimately multi-instance processes.
The numbered directory names — 8631674119019 and 3610186882146 — are algorithmically generated rather than semantically meaningful, a pattern consistent with Phorpiex's documented self-copying behaviour in which the worm replicates itself to arbitrary filesystem locations using programmatically constructed path names. The DriveMgr.exe meaningful name serves a different social-engineering function: it reads as a plausible Windows driver management utility, the kind of name that might pass a cursory review by a user or a first-tier analyst without triggering immediate suspicion.
The masquerade is not limited to naming. The packed PE's zeroed import table means that a static analysis tool examining the binary at C:\8631674119019\svchost.exe would find no recognisable API imports to cross-reference against known-good svchost.exe behaviour — the binary presents an almost featureless static profile [T1027]. The runtime import resolution that the packing stub performs is invisible to static analysis and would only be captured by a sandbox executing the binary, which is precisely the gap that the 20 non-flagging engines represent.
The MITRE metadata associated with this campaign record includes T1070 (Indicator Removal) and its sub-techniques T1070.004, T1070.006, and T1070.010, alongside T1562 (Impair Defenses) including T1562.001 and T1562.004. These suggest the sample attempts to suppress forensic artefacts and disable security tooling after installation — behaviours consistent with Phorpiex's documented operational profile. However, no sandbox behavioural report is available to confirm which specific artefacts are targeted or which security tools are impaired; these technique attributions should be treated as hedged inferences from the campaign's MITRE metadata rather than directly observed behaviours.
Persistence is similarly inferred rather than directly evidenced. The campaign record includes T1547.001 (Registry Run Keys / Startup Folder) and T1547.009 (Shortcut Modification) in its MITRE set, consistent with Phorpiex's well-documented autostart mechanisms. Without a sandbox execution trace, the specific registry key or shortcut path written by this particular variant cannot be confirmed.
The Numeric Domain and the Bulletproof Node
The third evasion layer is infrastructural. The primary C2 node at 45.141.233.6 sits in AS201814, operated by MEVSPACE sp. z o.o. — a Polish-registered hosting provider whose allocation for this address block is geo-tagged to Bulgaria by RIPE NCC records. The node's TLS certificate, last seen on 2020-01-07, was issued by Let's Encrypt Authority X3 under the serial number 3dc20284566c9b431e42e2e00f3a5133411. The certificate's subject is CN=www.02151696915.com, with subject alternative names covering both 02151696915.com and www.02151696915.com. The validity window ran from 2019-12-09 to 2020-03-08 — a 90-day Let's Encrypt certificate, provisioned approximately four weeks before it was first observed in VirusTotal's certificate index.
The domain 02151696915.com is purely numeric: fifteen digits with no lexical content, no brand reference, no keyword that a URL-category or domain-reputation system could use to classify it against a known threat taxonomy. This is the operational logic of the technique. Category-based web filtering — the kind deployed at enterprise network perimeters and in many endpoint security stacks — relies on classifying domains by their apparent purpose or by their appearance in threat-intelligence feeds. A domain that is a random string of digits has no category to block, and if it has not yet appeared in a feed, it passes through. The Let's Encrypt issuance model, which requires no identity verification and costs nothing, means the operator can provision a new numeric-domain certificate in minutes whenever the current one ages out or gets burned [T1071, T1071.002].
The WHOIS record for the /24 block 45.141.233.0/24 introduces a temporal anomaly worth noting. The RIPE record shows created: 2025-07-17T07:21:18Z and last-modified: 2025-12-23T18:53:12Z, with the route object created 2025-10-15T17:27:21Z. The TLS certificate on the same IP was last seen in January 2020 — more than five years before the block's RIPE creation date. This discrepancy most likely reflects RIPE record updates or re-allocation of the address block rather than infrastructure reuse across that time span, but it is a provenance gap that warrants attention: the block's current operator (netname razinet, described as Razinet Dedicated Servers, with an admin contact listing a Seattle, Washington address despite the block's country tag of GB) may not be the same entity that operated the C2 node when the certificate was active.
The detection ratio for 45.141.233.6 is 14 of 91 engines — moderate recognition as malicious, but well below the consensus threshold that would trigger automatic blocking in most enterprise environments. This is consistent with the node's role as a purpose-built C2 endpoint in a hosting environment that the analyst fingerprints as "bulletproof-adjacent": MEVSPACE has appeared in threat-intelligence contexts as a provider tolerant of abuse complaints, though that characterisation is not independently verified for this specific allocation.
A Second Node That Doesn't Fit the Pattern
The secondary C2 node at 64.70.78.32 is structurally anomalous relative to the MEVSPACE primary. It sits in AS3561, operated by CenturyLink Communications, LLC — a legacy commercial network block originally associated with Savvis, a major US hosting and colocation provider that was acquired by CenturyLink. The specific sub-allocation, NET-64-70-78-0-1, is assigned to Worldsite.WS within the broader CENTURYLINK-LEGACY-SAVVIS-BLK216 range covering 64.70.0.0 - 64.70.111.255.
This is not a bulletproof hosting environment. CenturyLink/Savvis is a mainstream commercial carrier, and Worldsite.WS is a legacy web-hosting sub-allocatee within that block — the kind of hosting arrangement that predates the modern bulletproof-provider ecosystem. The threat signal for this node is correspondingly thin: zero AV detections across 91 engines, a community reputation score of -1, and a single malicious community vote. The negative reputation and the malicious vote indicate that threat-intelligence feeds have flagged this IP, but no AV engine has independently confirmed it as malicious.
The operational reading of this asymmetry is inferential but analytically coherent. An operator running a primary C2 on a MEVSPACE node — which carries moderate AV detection and is recognisable to threat-intelligence feeds as a higher-risk hosting environment — may deliberately route secondary or fallback traffic through a node in a mainstream commercial block precisely because that block's reputation is cleaner. A network-layer block targeting MEVSPACE's AS201814 would not catch traffic to AS3561. The two nodes together present a more resilient C2 architecture than either would alone, though this interpretation rests on the co-listing of both IPs in the campaign record rather than on observed traffic patterns between them.
The three URL paths at tsrv2.top — /1, /2, and /3 — constitute a third infrastructure tier that cannot be fully characterised. Without HTTP response data or detection verdicts for any of these URLs, the tier's current role remains uncharacterised. Their sequential numeric structure is consistent with Phorpiex's documented pattern of numbered payload-fetch endpoints, where the worm component retrieves staged payloads from incrementally numbered paths on a staging server [T1105]. This interpretation is structurally plausible but unverified: without live HTTP response data or a sandbox execution trace that captures the fetch behaviour, the tsrv2.top tier remains an open question in the infrastructure picture.
Critically, the two C2 IPs and the tsrv2.top URLs share no imphash, certificate serial, A-record, or registrar relationship beyond their co-appearance in this campaign record. The infrastructure assessment therefore rests on per-node fingerprints rather than a demonstrated shared provisioning pattern — a meaningful limitation on the confidence with which the full C2 architecture can be described.
Propagation Logic and the Worm's Self-Copying Footprint
The attack chain begins, most likely, with Phorpiex's worm propagation mechanism [T1091] — though this stage is inferred from the sample's classification and path artefacts rather than directly observed. The binary is categorised as both worm and trojan, and the numbered-directory path names (C:\8631674119019\svchost.exe, C:\3610186882146\svchost.exe) are consistent with Phorpiex's documented behaviour of self-copying to algorithmically generated filesystem locations as part of its spreading routine. Phorpiex's propagation via removable media and network shares is a well-established characteristic of the family in general security literature, but no sandbox execution report is available for this specific sample to confirm the exact propagation path or enumerate the shares and devices targeted.
Once resident on a host, the execution flow moves through the defence-evasion layer described above: the packed stub unpacks the malicious code in memory [T1027], the process presents itself as svchost.exe or DriveMgr.exe in the filesystem and process list [T1036], and the zeroed import table ensures that static analysis tools examining the binary on disk find nothing to cluster against known-malicious import profiles.
The C2 communication stage [T1071.002] routes outbound traffic to 45.141.233.6 over TLS, with the numeric domain 02151696915.com serving as the certificate's subject. This means that on a host with TLS inspection enabled, the SNI field in the ClientHello would reveal 02151696915.com — a string that is meaningless to a category filter but would match a threat-intelligence feed entry if the domain has been indexed. On a host without TLS inspection, the connection appears as encrypted traffic to a Bulgarian IP address with a valid certificate, indistinguishable from legitimate HTTPS at the network layer.
The MITRE metadata also includes T1497 and T1497.003 (Virtualization/Sandbox Evasion: Time-Based Evasion), T1559.002 (Inter-Process Communication: Dynamic Data Exchange), T1553.005 (Subvert Trust Controls: Mark-of-the-Web Bypass), T1564.001 and T1564.004 (Hide Artifacts: Hidden Files and Directories / NTFS File Attributes), and T1590 (Gather Victim Network Information) and T1622 (Debugger Evasion). This is a broad technique set, and the absence of sandbox behavioural data means these attributions cannot be individually confirmed for this variant. They are best read as the campaign-level technique envelope associated with the Phorpiex family in the threat record, rather than as a confirmed behavioural profile for this specific binary.
The discovery techniques in the metadata — T1010 (Application Window Discovery), T1012 (Query Registry), T1106 (Native API) — suggest the sample performs environmental reconnaissance after execution, consistent with Phorpiex's documented behaviour of enumerating the host environment before deciding whether to proceed with payload delivery. T1115 (Clipboard Data) appears in the metadata as well, which aligns with Phorpiex's documented cryptocurrency-clipping capability — intercepting clipboard contents to substitute attacker-controlled wallet addresses for legitimate ones — though this specific behaviour is not confirmed and should be treated as a hedged inference from the family's known capability set.
What Five Years of Persistence Signals About the Phorpiex Ecosystem
The most analytically significant aspect of this campaign record is not any single technical choice but the temporal arc it describes. A binary compiled on 2020-10-27, first submitted to VirusTotal the same day, last submitted in February 2023, is still generating active C2-server feed entries as of June 2026. That is a minimum of five and a half years from compilation to last observed C2 activity — an operational lifespan that is unusual even by the standards of commodity malware families.
No specific actor or operator group is attributed to this campaign, and no motivation is formally assigned. In the broader security literature, the Phorpiex family has been associated with financially motivated operations — spam distribution, cryptocurrency clipping, and payload delivery-as-a-service — but none of these motivations are established for this specific campaign instance, and CTX Team makes no attribution claim beyond the family identification established by the YARA rule hits.
The long tail of activity suggests one of two operational readings, and the evidence cannot definitively distinguish between them. The first is long-tail persistence: hosts infected in 2020 or 2021 that were never remediated continue to beacon outbound to the C2 infrastructure, generating feed hits years after the initial infection wave. This is consistent with Phorpiex's worm propagation model, which is designed to maximise the number of infected hosts rather than to target specific high-value victims — a broad infection base means a long persistence tail even if the operator has moved on to newer tooling. The second reading is active operator reuse: the same or a successor operator continues to deploy this aged binary because its evasion posture remains effective enough against a meaningful fraction of deployed AV engines. The 20-engine detection gap, persisting years after the sample's first submission, supports this reading.
The infrastructure architecture reinforces the picture of a low-cost, low-maintenance operation. Let's Encrypt certificates cost nothing and can be provisioned in minutes. MEVSPACE hosting is inexpensive relative to dedicated bulletproof providers. The numeric domain 02151696915.com requires no creative effort to generate and no ongoing maintenance to keep category-clean. The secondary node in the CenturyLink/Savvis legacy block costs the operator nothing beyond whatever access arrangement exists with Worldsite.WS, and its clean commercial reputation provides a degree of network-layer cover that a second MEVSPACE node would not.
The structural dissimilarity between the two C2 nodes — one in a purpose-built hosting environment with moderate AV recognition, one in a mainstream commercial block with zero AV detections — is consistent with deliberate infrastructure diversification rather than opportunistic selection. An operator who understood that AS201814 would eventually be blocked at the network layer by threat-intelligence-fed firewalls would have reason to maintain a secondary node in a cleaner AS as a fallback. Whether this reflects sophisticated operational planning or simply the accumulation of infrastructure over time is not determinable from the available evidence.
The evidentiary ceiling for this campaign record is genuinely low. One strong indicator — the fully-enriched e53fd17b sample — anchors the record, but the remaining five indicators (two file hashes, two IP addresses, and three URLs) carry no sandbox context or HTTP response data, leaving the campaign's full scope uncertain. The tsrv2.top payload tier is the most significant open question: if live payloads are being staged at /1, /2, and /3, the campaign's impact scope is materially different from a scenario in which those endpoints are dormant or retired. The sequential numeric structure is suggestive, but suggestion is not confirmation.
What this campaign record ultimately illustrates is the durability of a well-tuned commodity evasion stack. The three layers — packed import-zeroed PE, system-process masquerade, numeric-domain TLS C2 — are individually well-understood techniques. Their combination, applied consistently across a long operational window with minimal infrastructure investment, produces a threat that remains partially invisible to the AV landscape years after its first appearance. The Phorpiex ecosystem's persistence is not a function of technical sophistication; it is a function of the gap between the evasion techniques the operator chose and the detection capabilities of the engines that still miss it. That gap, documented here at 20 of 78 engines on a sample that is more than four years old, is the operational signal that matters.