17-Year-Old Kernel Driver Powers 2026 Telecom Cryptomining Campaign
A dropper compiled in April 2026 pairs a LOLDrivers-catalogued kernel driver signed with an expired 2008 certificate with an embedded cryptominer beaconing to a zero-detection HashVault endpoint. The campaign targets telecommunications providers across nine countries and carries attribution to Lazarus Group at 85% confidence.
A 17-Year-Old Kernel Driver and a Fresh Dropper Walk Into a Telecom Network
Compiled on April 16, 2026, and submitted to VirusTotal just two days later, an unsigned 2.5-megabyte Windows executable is doing something that should give pause to every security team protecting telecommunications infrastructure: it is loading a kernel driver that was signed in 2008, whose Authenticode certificate expired that same year, and whose vulnerabilities have been publicly catalogued for years — and using that driver to claw its way to ring-zero privilege before beaconing out to a cryptomining pool endpoint that carries zero detections across 91 scanning engines. The combination is not novel in any single dimension. What makes it operationally significant is the deliberate assembly of commodity parts into a chain that, taken together, slips past the layers defenders have built to catch exactly this kind of intrusion.
The campaign, tracked by CTX Team under identifier CTXgc45dh7lxa, targets telecommunications providers across nine countries — Argentina, Bulgaria, Brazil, Greece, India, Sri Lanka, Peru, Poland, and South Africa — and carries attribution to Lazarus Group at a confidence score of 85, with an espionage motivation. The observed terminal payload, however, is a cryptominer, a dual-use posture that is consistent with the broader financial dimension associated with Democratic People's Republic of Korea-aligned activity, where revenue generation and intelligence access are not mutually exclusive objectives. The attribution is noted briefly: the tradecraft combination is the story, not the attribution label.
The Kernel Driver That Time Forgot: BYOVD With an Expired GlobalSign Certificate
The privilege-escalation vehicle at the centre of this campaign is WinRing0x64.sys — a 14-kilobyte kernel driver from the OpenLibSys project, first seen on VirusTotal on February 16, 2009, and now carrying 29,355 submissions from 3,663 unique sources. Its presence in a 2026 campaign is not an accident of recycling. It is a deliberate operational choice, and understanding why requires looking at what the driver still offers an attacker despite its age.
WinRing0x64.sys is signed. Its leaf certificate was issued to "Noriyuki MIYAZAKI" by GlobalSign ObjectSign CA, with serial number 01 00 00 00 00 01 15 37 24 21 A8, valid from September 24, 2007 to September 24, 2008. The signing event itself is timestamped July 26, 2008 — the driver was signed roughly two months before its own certificate expired. Today, the certificate chain carries multiple validity failures: the leaf cert is not time-valid, the revocation status across the chain is unknown or stale, and VirusTotal tags the file invalid-signature. Yet on older or misconfigured Windows systems where driver-signing enforcement is relaxed or where legacy kernel-mode code-signing policy applies, the structural presence of an Authenticode signature — even an expired one — can be sufficient to pass the driver load check. That is the BYOVD [T1543.003] premise: the signature does not need to be currently valid to be operationally useful; it needs to be structurally present and associated with a driver whose vulnerabilities enable kernel-mode exploitation.
The YARA rule PUA_VULN_Driver_Openlibsysorg_Winringsys_Winring_11BD, authored by Florian Roth from the Neo23x0 signature-base repository, fires on this file and confirms its membership in the LOLDrivers catalogue — a community-maintained list of drivers with known vulnerabilities that adversaries can exploit for privilege escalation [T1548.002]. The rule's description is precise: "Detects vulnerable driver mentioned in LOLDrivers project using VersionInfo values from the PE header — WinRing0.sys, WinRing0x64." The driver's PE timestamp reads 2008-07-26, consistent with the signing date, and its internal name and original name fields both read WinRing0.sys, with copyright string "Copyright (C) 2007-2008 OpenLibSys.org. All rights reserved."
The industry detection picture for this driver is instructive. Only 4 of 76 engines flag it — Cylance, DrWeb, Microsoft, and Rising — while 68 engines return clean. The community vote split tells a different story: 91 malicious votes against 56 harmless, a reputation score of -430, suggesting the security research community has long understood what this file is, even as the majority of AV engines do not flag it. Zenbox returns a clean verdict; C2AE returns unknown; only Dr.Web vxCube classifies it as malware. That 1-of-3 sandbox consensus is not a data quality problem — it is evidence of the driver's sandbox evasion posture working as intended.
Both WinRing0x64.sys and the companion dropper carry the VirusTotal tags detect-debug-environment and long-sleeps, implementing the analyst-identified tradecraft signal for time-based sandbox evasion [T1497.003]. The driver additionally carries the idle tag. The operational logic is straightforward: a sandbox that runs a sample for a fixed window and observes no malicious behaviour will return a clean or unknown verdict. Long-sleep delays, combined with active detection of debugging environments, are sufficient to defeat two of three sandbox environments — exactly the split observed here. For a 17-year-old driver that an operator wants to use without triggering automated detection pipelines, this evasion posture is the difference between a commodity tool and a deployable one.
The driver's build provenance carries imphash d41fa95d4642dc981f10de36f4dc8cd7 — a null imphash value, indicating zero imports in the import address table, consistent with a kernel-mode driver that resolves its dependencies through the kernel's own export table rather than through the standard PE import mechanism. Its PE sections show a .text section at entropy 5.39 and a .data section at entropy 0.3, a flat, unobfuscated profile consistent with a legitimate utility driver rather than a purpose-built malicious artifact. The driver's certificate thumbprint is CDA98AC4019456095593902E4B4A87AC283ED54A — a value that, if blocked by thumbprint across an enterprise fleet, would neutralise this specific BYOVD vehicle regardless of the expired-signature bypass.
The Dropper: Fresh Build, Embedded Payload, Evasion by Design
Where the kernel driver is a recycled artifact, the dropper is new. SHA-256 68f955172c0aac5de8048c2dab757fecb8c387c6697692899418d3dbe8df8173 carries a PE timestamp of April 16, 2026, and first appeared on VirusTotal on April 18 — a two-day gap from compile to first submission that suggests either early-stage targeted delivery or a very narrow initial distribution window. It has been submitted only twice, from two unique sources, yet 55 of 76 engines already flag it. That detection rate for a sample this fresh is unusually high, and the explanation is in the classification labels: engines are returning generic heuristic verdicts — trojan.krypt, fvkl, gqcb — rather than specific family signatures. The dropper is not yet named in the way that WannaCry or Cobalt Strike are named; it is being caught by shape, not by identity.
The file is unsigned. At 2,571 kilobytes, it is roughly 183 times the size of the kernel driver it works alongside. The size is not accidental. The dropper's .data section alone accounts for 2,587,136 bytes — essentially the entire file — at an entropy of 6.47. For reference, random data approaches entropy 8.0; compressed or encrypted content typically sits between 7.0 and 7.9; packed or encoded payloads often land in the 6.0–7.0 range. An entropy of 6.47 across a 2.5-megabyte .data section is consistent with an embedded binary — in this case, the miner payload — that has been stored in a lightly encoded or compressed form rather than in plaintext. The .text section, by contrast, is 34,304 bytes at entropy 6.16, suggesting the dropper's own executable logic is also moderately obfuscated.
The dropper's imphash is de41d4e0545d977de6ca665131bb479a, and its vhash is 026076651d65151d051bza1f=z. Neither value is shared with the kernel driver, confirming that the two components are structurally isolated: no shared builder fingerprint, no common import table, no linkage axis connecting them beyond their co-appearance in this campaign.
The sandbox verdict for the dropper is unambiguous: the C2AE environment returns malicious with 50% confidence, naming the family "Tedy." The Elastic Security YARA rule Windows_Generic_Threat_e8abb835 fires on the file. Eight Sigma rules match, including one critical-severity hit from the Joe Security rule set and two high-severity hits from the Sigma Integrated Rule Set. The Proofpoint Emerging Threats Open IDS rule ET COINMINER CoinMiner Domain in DNS Lookup (pool .hashvault .pro) fires during sandbox execution — the first direct link between the dropper's runtime behaviour and the C2 infrastructure.
The dropper's execution path [T1059] is documented in its meaningful name and alternate names: C:\ProgramData\gmudskkqoqpw\dxhhoonxacrd.exe. The directory name gmudskkqoqpw and the executable name dxhhoonxacrd.exe are both randomly generated strings — a masquerading technique [T1036] designed to ensure that the payload path does not match any known-bad string in a blocklist or SIEM rule. The executes-dropped-file and calls-wmi tags confirm that the dropper spawns its secondary payload via WMI-based process execution, a technique that routes process creation through the Windows Management Instrumentation service rather than through a direct CreateProcess call, complicating process-tree analysis [T1059]. The spreader tag on the dropper is the most operationally significant single tag in the campaign: it indicates that the dropper does not simply install a miner on the initial victim machine but attempts to propagate across the network, expanding the mining footprint — and, by extension, the operator's access footprint — laterally.
The detection gap on the dropper is also worth noting. TrendMicro, ClamAV, Webroot, Zoner, and Yandex are among the 20 engines still returning clean verdicts on a file that 55 others flag as malicious. For a telecommunications network where endpoint protection may be heterogeneous across a large device estate, the probability that at least some endpoints are running one of those missing engines is not negligible.
The C2 Endpoint: A Self-Signed Certificate With a Century of Validity
The sole network indicator in this campaign is the IP address 94.26.239.93. It sits within the Selectel-assigned subnet 94.26.224.0/20, registered to JSC Selectel under AS-49505, with the RIPE NCC WHOIS record showing the subnet was created on February 1, 2021. Selectel is a Russian commercial cloud provider headquartered in Saint Petersburg; it is a known hosting choice for operators seeking low-cost, high-bandwidth infrastructure with limited abuse-response overhead.
The TLS certificate presented by this IP is the most distinctive element of the entire infrastructure picture. Serial number 652748562401ae35e9a97f04708b5eaabdcdf163, last observed on June 1, 2026. Issuer fields: C=IT, ST=HashVault, L=HashVault, O=HashVault, CN=HashVault. Subject fields: identical. The certificate is self-signed — the issuer and subject are the same entity — and every field that would normally carry geographic or organisational information has been set to the string "HashVault." The validity window runs from September 26, 2019 to September 2, 2119: one hundred years.
A 100-year self-signed certificate with all fields set to the operator's own service name is not a mistake or an oversight. It is a deliberate infrastructure choice characteristic of operator-controlled mining pool nodes. Commercial TLS certificates are rotated annually or biennially; bulletproof hosting operators often leave certificates absent or use throwaway self-signed certs that expire in weeks. A century-validity self-signed certificate, by contrast, signals that the operator intends this endpoint to remain stable and identifiable — it is infrastructure the operator controls and does not plan to rotate. The HashVault mining pool is a real service; the certificate's CN is not a spoofed brand but a direct declaration of the endpoint's function.
The IDS rule linkage closes the loop between the dropper and the C2 IP. The Proofpoint ET COINMINER rule fires on a DNS lookup for pool.hashvault.pro during sandbox execution of the dropper. The IP 94.26.239.93 presents a certificate with CN "HashVault." The inference that this IP is the mining pool endpoint to which the dropper beacons [T1071] is corroborated by both the DNS behaviour and the certificate fingerprint — two independent evidence streams pointing to the same conclusion.
What makes the C2 picture operationally significant is the detection gap. Despite the self-signed HashVault certificate, the confirmed IDS coinminer rule hit, and the direct linkage to a known cryptomining service, 94.26.239.93 carries zero detections across 91 scanning engines. Its reputation score is 0. The community vote count is 0 malicious, 0 harmless — the IP has not been voted on at all. This is not a case of a malicious IP that has been cleaned up and re-evaluated; it is a case of an IP that has never been flagged, despite carrying a distinctive fingerprint that directly links it to cryptomining activity. Mining pool IPs are systematically under-represented in IP-reputation feeds, because the feeds are built primarily around command-and-control infrastructure for traditional malware families, not around the pool endpoints that miners beacon to. An operator who routes their miner's C2 through a legitimate mining pool — rather than through a custom C2 server — inherits that detection gap by design.
The infrastructure picture is deliberately sparse: a single IP, no domains, no URLs, no additional network indicators. Each component is structurally isolated from the others. Two additional file IOCs — SHA-256 values beginning e1acce7b and fefc7a06 — are present but cannot be characterised or linked to either the kernel driver or the dropper cluster; their infrastructure role, if any, remains unknown.
Execution to Impact: Walking the Attack Chain Through the Evidence
The attack chain reconstructed from the available evidence follows five stages, each grounded in distinct evidence.
Execution begins with the dropper. Compiled April 16, 2026, first seen April 18 — the two-day gap from PE timestamp to first VirusTotal submission is consistent with a targeted or controlled initial delivery rather than broad phishing distribution. The dropper is launched from its randomised C:\ProgramData\gmudskkqoqpw\ path, using WMI-based process spawning [T1059] to execute the secondary payload embedded in its .data section. The calls-wmi tag is the behavioural evidence; the randomised directory and executable names are the masquerading layer [T1036] that keeps the path out of string-based detection rules.
Privilege escalation follows via the BYOVD technique. WinRing0x64.sys is loaded as a kernel driver service [T1543.003]. The expired GlobalSign leaf certificate — valid only to September 24, 2008, signed July 26, 2008 — is structurally present and allows the driver to pass signing policy checks on systems where enforcement is relaxed or where legacy policy applies. Once loaded, the driver grants kernel-mode access, enabling the operator to disable security tooling, escalate process privileges for the miner, or perform any of the other kernel-level operations that the driver's documented vulnerabilities permit. The YARA rule PUA_VULN_Driver_Openlibsysorg_Winringsys_Winring_11BD is the rule-match evidence; the LOLDrivers catalogue membership is the public-record confirmation of the driver's exploitability.
Defense evasion is implemented at both components simultaneously [T1497.003]. The detect-debug-environment and long-sleeps tags appear on both the driver and the dropper — a shared evasion posture that is the most structurally cohesive link between the two components. The driver's 1-of-3 sandbox verdict (Zenbox clean, C2AE unknown, Dr.Web vxCube malicious) is the empirical result of that evasion working: two of three automated analysis environments were defeated. The dropper's evasion is less successful at the AV level — 55 of 76 engines flag it — but the sandbox family label "Tedy" and the generic heuristic classification suggest that engines are catching the dropper by shape rather than by specific behavioural signature, which means evasion variants that preserve the dropper's function while altering its structural fingerprint could reduce that detection rate substantially.
Command and control is established over TLS to 94.26.239.93 [T1071]. The DNS lookup for pool.hashvault.pro fires the Proofpoint ET COINMINER IDS rule during sandbox execution. The IP's self-signed HashVault certificate (serial 652748562401ae35e9a97f04708b5eaabdcdf163, valid 2019–2119) confirms the endpoint identity. The C2 channel is not a traditional implant beacon — it is a mining pool protocol connection, which means it carries the traffic characteristics of legitimate cryptocurrency mining software rather than the characteristics of a RAT or backdoor. Network-layer detection that relies on protocol anomaly or known-bad C2 patterns will not catch this traffic; only the DNS lookup for pool.hashvault.pro and the IP's certificate fingerprint provide reliable detection anchors.
Impact is cryptomining resource hijacking [T1496]. The dropper's popular categories include "miner"; the .data section's 2.5-megabyte, entropy-6.47 profile is consistent with an embedded miner binary; the IDS coinminer rule and the HashVault C2 endpoint confirm the mining pool destination. The spreader tag indicates that the operator does not intend to limit the mining footprint to the initial victim: the dropper attempts lateral movement to propagate across the target network, consistent with the multi-country telecommunications targeting profile where a single compromised endpoint in a carrier network may provide access to a large internal device estate.
The campaign's MITRE set also includes T1485 (Data Destruction) and T1489 (Service Stop) — techniques associated with destructive capability. No direct evidence of destructive activity was observed. Those techniques may reflect the attributed actor's broader documented capability set rather than observed behaviour in this specific campaign, and they should be read as potential capability indicators rather than confirmed behaviours.
Why Telecommunications, and What the Sector Targeting Reveals
The nine-country targeting profile — Argentina, Bulgaria, Brazil, Greece, India, Sri Lanka, Peru, Poland, South Africa — is geographically diffuse in a way that argues against a single geopolitical objective. These are not the countries one would select for a targeted intelligence collection operation against a specific government or military capability. They are, however, a reasonable cross-section of mid-tier telecommunications markets where carrier infrastructure may be less hardened than in the primary targets of well-resourced nation-state campaigns, where internal network segmentation may be less mature, and where a spreader-capable miner can propagate across a large device estate before detection.
The financial logic is straightforward. Telecommunications providers operate large fleets of servers, network appliances, and management systems — compute resources that, when hijacked for cryptomining, generate meaningful revenue at scale. A single compromised carrier network with thousands of internal hosts represents a substantially larger mining yield than the same number of individual consumer endpoints. The spreader capability is the mechanism that converts a single initial compromise into a fleet-scale mining operation.
The espionage motivation sits in tension with the observed cryptomining payload, but the tension is not irreconcilable. The campaign is attributed to Lazarus Group with a confidence score of 85 and an espionage motivation. The observed terminal impact is financial — cryptomining resource hijacking. This dual-use posture is consistent with the broader operational pattern associated with Democratic People's Republic of Korea-aligned activity, where revenue generation through financially motivated operations funds the broader intelligence and offensive capability programme. A telecommunications network compromised for mining also provides persistent access to communications infrastructure — an access footprint that could be repurposed for intelligence collection without requiring a separate initial access operation.
The MITRE set's inclusion of T1055 (Process Injection), T1070 (Indicator Removal), T1112 (Modify Registry), and T1562.001 (Impair Defenses: Disable or Modify Tools) alongside the cryptomining techniques suggests a capability set that extends beyond passive resource hijacking. Whether those capabilities are deployed in this specific campaign or represent the actor's broader toolkit cannot be determined from current evidence. The evidence has gaps: the IP's malicious role is inference-dependent on the certificate CN and IDS rule linkage, and the driver's low detection rate and split sandbox verdict reduce confidence in its active-campaign role versus commodity reuse. CTX Team has assessed the overall campaign confidence at medium.
The Cost-Optimisation Signal: What This Combination Says About Operational Maturity
The most analytically significant observation is not the BYOVD technique itself — that is well-documented and widely deployed — but the specific cost-optimisation logic that the combination of components reveals.
WinRing0x64.sys is already signed. It already passes basic AV checks at 4 of 76 detections. It is already documented in LOLDrivers, meaning any defender who has specifically blocked it by hash or certificate thumbprint has already done so — and any defender who has not is still exposed. The operator did not need to source, sign, or test a new vulnerable driver. They used one that has been publicly available for 17 years, whose signing certificate expired in 2008, and whose vulnerabilities are well-understood. The cost of this component, in terms of operational effort, is essentially zero.
The dropper, by contrast, is fresh. Compiled April 16, 2026, with a PE timestamp that places it two days before first submission — this is new tooling, built for this operation. Its evasion posture (debug-environment detection, long sleeps, WMI-based process spawning, randomised ProgramData paths) is not sophisticated in the sense of being technically novel, but it is deliberately assembled. The 55-of-76 detection rate suggests that the evasion is partially effective at the AV level, and the single sandbox verdict (C2AE, family "Tedy") indicates that the dropper is not yet well-characterised by automated analysis infrastructure.
The C2 infrastructure completes the picture. A self-signed certificate with a 100-year validity window on a Russian commercial cloud provider, beaconing to a legitimate mining pool service whose DNS name triggers an IDS rule but whose IP carries zero detections — this is not sophisticated infrastructure in the sense of fast-flux domains or multi-hop proxy chains. It is infrastructure that is cheap, stable, and invisible to the specific detection layer (IP reputation) that most network security teams rely on for outbound C2 identification.
The operational logic that emerges from this combination is deliberate cost-optimisation at each layer: a free, already-signed kernel driver for privilege escalation; a freshly compiled but structurally simple dropper for payload delivery and propagation; a zero-detection mining pool endpoint for C2. No custom kernel exploits. No bespoke implant framework. No expensive infrastructure. The operator has assembled a chain that achieves kernel-level access, evades the majority of automated detection layers, and generates revenue — using components that are either publicly available or trivially constructed.
This is the shift that matters for the telecommunications sector specifically. The combination of kernel-level access via BYOVD, lateral movement capability via the spreader tag, and a C2 channel that blends with legitimate mining traffic represents a dwell-time risk that endpoint-only detection strategies will systematically underestimate. The kernel driver's 4-of-76 detection rate means that on a heterogeneous enterprise fleet, the privilege-escalation component may execute without triggering any alert. The dropper's randomised ProgramData paths mean that string-based detection rules will miss the payload location. The mining pool C2 means that outbound traffic to 94.26.239.93 looks, at the network layer, like legitimate cryptocurrency mining software — a traffic pattern that is increasingly common in enterprise environments where employees run mining software, making anomaly-based detection harder to calibrate.
For the nine telecommunications markets in this campaign's targeting profile, the implication is that the initial access event — whatever delivery mechanism preceded the dropper's execution — may already have occurred before these samples were identified. The dropper's two-submission, two-source VirusTotal profile suggests very limited initial distribution; the spreader capability suggests that limited initial distribution is the design, not the constraint. One compromised endpoint in a carrier network, propagating laterally across internal infrastructure, is the operational model. The detection gap at the IP-reputation layer means that the C2 channel may be active and undetected on networks that have not specifically deployed IDS rules for coinminer DNS activity or certificate-fingerprint-based TLS inspection.
The broader signal this campaign sends about the current threat landscape is that the BYOVD technique has matured from a sophisticated nation-state tool into a cost-optimised commodity component — available to any operator willing to spend the time to identify a suitable LOLDrivers candidate and pair it with a fresh dropper. The 17-year age of WinRing0x64.sys is not a weakness in the operator's tradecraft; it is evidence that the technique works well enough with old material that there is no operational incentive to invest in newer drivers. When a 2008-signed, expired-certificate kernel driver can still achieve kernel-mode access in 2026, the economics of BYOVD favour the attacker in a way that is structurally difficult to reverse without systematic enforcement of driver-signing policy and proactive LOLDrivers catalogue blocking across enterprise fleets.