Dual-Certificate PCHunter Stack Hits Finance and Telecom Across 14 Nations
A VMProtect-packed, DigiCert EV-signed executable paired with a Microsoft WHQL-cross-signed kernel driver is active against financial services, technology, and telecommunications targets across fourteen countries. The two components form a deliberate evasion stack in which expired-but-valid-at-signing certificates defeat application controls while the kernel driver purchases ring-0 access Windows still honours. Detection gaps persist across major endpoint platforms and C2 infrastructure remains almost entirely uncharacterised.
A Dual-Certificate Evasion Stack Turns a Chinese System Utility Into a Ring-0 Espionage Platform
A VMProtect-packed, DigiCert EV-signed executable and a Microsoft WHQL-cross-signed kernel driver — both components of the PCHunter Windows inspection utility, both carrying certificates that expired years ago but were valid at the moment of signing — are circulating in active operations against financial services, technology, and telecommunications organisations across fourteen countries. The combination is not accidental: the two components form a deliberate, layered evasion stack in which one layer defeats static antivirus and application allow-listing while the other purchases ring-0 kernel access through a trust chain that Windows still honours for legacy cross-signed drivers. The result is a hacktool deployment that, as of mid-2026, 50 of 76 engines catch in its EXE form and 32 of 76 catch in its driver form — leaving meaningful gaps across major endpoint platforms — while the network-layer C2 activity it generates remains almost entirely uncharacterised beyond two Proofpoint Emerging Threats IDS rule matches.
CTX Team has been tracking this cluster under threat record CTXg2dbhoy7zm since March 2025. What follows is a technical account of how the evasion stack is assembled, what the certificate and build evidence reveals about the operator's sourcing and deployment discipline, and what the near-total absence of network IOCs implies about the infrastructure posture of whoever is wielding it.
The Two-Component Toolkit: PCHunter Repurposed as a Hacktool
PCHunter is a Windows system-information and process-inspection utility originally developed by Epoolsoft — copyright registered to 一普明为（北京）信息技术有限公司 (Beijing) across the 2013–2020 period. In its legitimate form it provides kernel-level process, driver, and registry visibility to system administrators and forensic analysts. In the configuration documented here, it has been repurposed as a hacktool: the GUI executable generates IDS-detectable command-and-control traffic [T1071], the kernel driver provides ring-0 access that the operator can leverage to suppress security tooling and manipulate the host at a level that user-mode defences cannot reliably observe, and the deployment pipeline randomises the driver's drop path to defeat path-based detection rules.
The toolkit resolves into two distinct binary components. The first is PCHunter.exe (sha256: 2b214bddaab130c274de6204af6dba5aeec7433da99aa950022fa306421a6d32), a 10.6 MB PE32+ GUI executable for x86-64 Windows, version 1.0.0.5, first submitted to VirusTotal on 2019-01-31 and last seen as recently as June 2026. Its 306 submissions from 264 unique sources indicate wide distribution — the file has propagated broadly enough to accumulate a substantial telemetry footprint. The second is PCHunter.sys (sha256: 32726fa33be861472d0b26286073b49500e3fd3bd1395f63bc114746a9195efb), a 624 KB PE32+ native kernel-mode driver for x86-64 Windows, same version, first submitted on the same date but with only 9 submissions from 6 unique sources across its entire observed lifetime. That submission disparity — 306 versus 9 — is one of the more operationally significant signals in this dataset, and it will be addressed in detail below.
A third SHA-256 value (fa329c85842c878b7f195aea2e805ab2d1b056df1d5a6ea195368fd13ea8fdde) appears in the indicator catalog but cannot be assessed. CTX Team treats it as unverified for the purposes of this analysis.
The threat record tags this activity to "Royal Ransomware" (alias: Team One) with an espionage motivation — an internally inconsistent attribution pairing that substantially reduces confidence in the actor assignment. The tooling evidence is a more reliable analytical anchor than the actor label, and the article proceeds on that basis. The targeting profile — financial services, technology, and telecommunications across Austria, Canada, Chile, China, Germany, Hungary, Indonesia, Italy, South Korea, Mexico, Romania, Turkey, the United States, and Vietnam — is consistent with a broad-access pre-positioning or intelligence-collection operation rather than a narrowly scoped ransomware campaign, though the presence of T1489 (Service Stop) in the technique metadata indicates a disruptive capability is available to the operator if needed.
Certificate Architecture: Two Trust Chains, One Signing Date, Deliberate Bifurcation
The most structurally interesting feature of this toolkit is not any individual certificate but the deliberate bifurcation of the trust chain across the two components. The GUI executable and the kernel driver were signed on the same calendar date — 30 January 2019 — but via entirely separate certificate hierarchies, each chosen to confer a specific type of trust on its respective component.
PCHunter.exe carries a DigiCert Extended Validation code-signing certificate issued to 一普明为（北京）信息技术有限公司, serial number 07 09 31 FD C3 D5 21 73 43 15 40 39 04 19 F8 8A, valid from 29 May 2018 to 3 June 2019. The signing event on 30 January 2019 falls comfortably within that validity window — the certificate was eight months old at signing time, well within its one-year lifespan. EV code-signing certificates carry elevated trust in Windows application control frameworks: they bypass SmartScreen reputation warnings immediately upon issuance and are treated as higher-assurance than standard OV certificates by many enterprise allow-listing policies. The certificate is now expired, but because the file was signed within the validity window and the timestamp is embedded, the signature remains verifiable as "valid at time of signing" on systems that perform countersignature validation — which is the standard Windows behaviour. The practical effect is that the expired certificate continues to function as a trust anchor for application control bypass [T1553.002] on a large proportion of deployed Windows configurations.
PCHunter.sys takes a different trust path. It carries a Microsoft Windows Hardware Compatibility Publisher WHQL cross-signature, serial number 33 00 00 00 25 3A 27 38 69 0A 34 51 C1 00 00 00 00 00 25, issued by Microsoft Windows Third Party Component CA 2014, valid from 6 September 2018 to 6 September 2019. Again, the 30 January 2019 signing date falls within the validity window. WHQL cross-signing is the mechanism by which third-party kernel-mode drivers obtain a Microsoft-anchored trust chain that Windows will honour for kernel loading — the driver loader verifies the cross-signature against the Microsoft root rather than requiring a separate Authenticode check. On Windows systems that have not enforced the post-2015 WHQL policy changes (which revoked trust for cross-signed drivers on systems with Secure Boot and HVCI enabled), a validly cross-signed driver loads into ring-0 without additional prompts or policy exceptions. This is the BYOVD-adjacent technique pattern: the driver is not a vulnerable third-party driver being exploited, but a legitimately cross-signed driver whose trust is being leveraged for kernel access [T1543.003] in a context the original certification was not intended to authorise.
The bifurcation is deliberate. EV code-signing certificates are commercially available from DigiCert and other CAs to registered businesses; obtaining one requires a legal entity, a registered address, and a verification process — all of which 一普明为（北京）信息技术有限公司 completed. WHQL cross-signing requires submitting a driver to Microsoft's Hardware Lab Kit testing process. These are two entirely separate trust acquisition pipelines, and the operator — or the entity that originally obtained the certificates on behalf of Epoolsoft — navigated both. The result is a toolkit where the user-mode component is trusted by commercial application control and the kernel-mode component is trusted by the Windows kernel driver loader, simultaneously.
Both certificates are now expired. The signing infrastructure that produced them is a historical artefact of Epoolsoft's legitimate software development operation. What the current operator has done is repurpose those legitimately obtained trust anchors for adversarial deployment — a pattern that is substantially harder to detect than self-signed or stolen certificate abuse, because the certificates were never revoked and the signatures are technically valid at signing time.
VMProtect Obfuscation and the Sandbox Evasion Profile of the GUI Executable
The EV certificate handles trust-based allow-listing. VMProtect handles the static analysis problem. The YARA rule INDICATOR_EXE_Packed_VMProtect fires against PCHunter.exe, and the PE section map confirms why: the .pdata section registers entropy at 7.92 and the .vmp0 section at 7.10 — both well above the threshold at which meaningful static disassembly becomes impractical without first defeating the VM layer [T1027.002]. The .vmp0 section name is a VMProtect artefact; the packer virtualises selected code regions by translating them into a proprietary bytecode executed by an embedded interpreter, making static signature extraction substantially harder and forcing dynamic analysis as the primary characterisation path.
The build provenance data adds further texture. The imphash for the EXE is 444d210cea1ff8112f256a4997eed7ff — an import table hash that, in a heavily VMProtect-packed binary, reflects the imports visible to the PE loader rather than the full import surface of the protected code. The import count is zero, consistent with VMProtect's import obfuscation: the packer resolves API calls dynamically at runtime, removing them from the static import table and defeating imphash-based clustering on the protected code. The vhash is 017076651d1577751561e051z78c00d2z32z4e2d5zf0b01f7032801027z and the ssdeep is 98304:ec2woDnsJL7vEGeQECPKHvf5M3Tj2bg1pFNAlVu8kBQxC6yZKylLj:L2woDnwL7884f5Am01pElVu8kCI6GNj — carried for correlation purposes but not directly actionable without companion samples to compare against.
The dynamic analysis picture is where the evasion engineering becomes most visible. PCHunter.exe carries four behavioural tags that map directly to sandbox and debugger evasion: detect-debug-environment, long-sleeps, direct-cpu-clock-access, and checks-user-input. These correspond to MITRE T1497.002 (User Activity Based Checks) and T1497.003 (Time Based Evasion) — a multi-method evasion profile that probes the execution environment from several angles simultaneously. The long-sleeps technique introduces timing delays that cause automated sandbox environments with fixed execution windows to terminate the sample before it reaches its active payload phase. The direct-cpu-clock-access technique reads the processor's time-stamp counter (RDTSC instruction) to detect the timing discrepancies that virtualised environments introduce. The detect-debug-environment tag covers standard anti-debugging checks — IsDebuggerPresent, NtQueryInformationProcess, and similar API calls that return different values under a debugger than on a clean host. The checks-user-input tag indicates the binary monitors for mouse movement, keyboard activity, or similar user-interaction signals before proceeding — a technique that defeats sandboxes that do not simulate user activity.
The sandbox verdict split is the empirical result of this evasion stack in action. Zenbox classifies the file as TROJAN/EVADER — the EVADER classification is particularly notable, as it indicates Zenbox's analysis pipeline detected the anti-analysis behaviour itself. Dr.Web vxCube returns MALWARE. C2AE returns undetected. Two of three sandboxes reach a malicious verdict; one does not. That one clean result is not noise — it is the evasion working as designed against at least one automated analysis environment. The AI behaviour summary embedded in the Zenbox verdict reinforces the TROJAN/EVADER classification, consistent with a tool that has been hardened against automated characterisation beyond its original legitimate design.
The static detection picture for the EXE is 50 of 76 engines flagging as malicious. Among the engines that still miss the file are Microsoft Defender, AhnLab-V3, ESET-NOD32, Elastic, and Avira — a set of widely deployed endpoint platforms whose absence from the flagging list represents a meaningful detection gap for organisations relying on those products as their primary endpoint control. The community vote is split evenly at 5 malicious to 5 harmless, reflecting the genuine ambiguity of a legitimately signed, commercially distributed utility that has been repurposed for adversarial use.
The Kernel Driver: Ring-0 Access Staged With Surgical Restraint
The kernel driver tells a different operational story. PCHunter.sys is a 624 KB PE32+ native executable — the native tag confirms kernel-mode rather than user-mode execution — with a clean PE section entropy profile: .text at 6.36, .rdata at 5.33, .data at 2.86, .pdata at 5.73. There is no packing, no VMProtect, no entropy anomaly. The driver does not need obfuscation because its trust comes from the WHQL cross-signature rather than from defeating static analysis. The Microsoft Windows Hardware Compatibility Publisher certificate chain is the evasion mechanism; the binary itself can be structurally transparent.
The imphash for the driver is dc8acd7d20149d09a6c261c7a5f609c4, and the import count is again zero — consistent with a kernel-mode driver that resolves its kernel API calls through the standard kernel import mechanism rather than a user-mode import table. The vhash is 065076655d155655151iz3exz. The ssdeep is 6144:Wy09BXuHDcDxIEQd/isJUGnRH6TW9+DLkS1nwjEggpBSebWvXi/fsGeU9M61P:Wy0fuDES3asiGkgYggpBSebokfszm. Neither the imphash nor the vhash overlaps with the companion EXE — there is no shared clustering axis between the two files. Their co-occurrence in this threat record is grounded in the shared PCHunter family label and the shared signing date rather than any directly observed infrastructure or build-system link.
The deployment pattern for the driver is where the adversary-controlled orchestration becomes most visible. The alt-name list for PCHunter.sys includes: C:\nhzdjrj\dobwovxrndwpjtef.sys, C:\clcdmoe\feytealvriikeofz.sys, nohxfnizxbonebwi.sys, C:\szewddsg\bhzaphoxmhxkjmx.sys, and lfujvatsxdwjbaack.sys. These are not user-assigned names. The directory names (nhzdjrj, clcdmoe, szewddsg) and the filenames (dobwovxrndwpjtef, feytealvriikeofz, bhzaphoxmhxkjmx) are clearly programmatically generated random strings — the pattern of consonant-heavy, vowel-sparse pseudorandom identifiers is consistent with a deployment script that generates a random directory name and a random filename at runtime before dropping and registering the driver as a Windows service [T1543.003]. Path-based detection rules that look for PCHunter.sys in known locations will not fire against any of these paths. Behaviour-based rules that look for unsigned or anomalously signed kernel driver loads will also not fire, because the WHQL cross-signature is genuine.
The sandbox verdict for the driver is 0 of 1 malicious — Zenbox returns CLEAN. This is expected: a kernel-mode driver that does not exhibit overtly malicious behaviour in isolation, that carries a valid Microsoft trust chain, and that performs legitimate system-inspection functions when executed in a standard environment will not trigger sandbox heuristics. The driver's malicious potential is contextual — it depends on the operator's use of the ring-0 access it provides, not on any behaviour the driver itself exhibits in an isolated sandbox run.
The static detection picture for the driver is 32 of 76 engines flagging, with 40 engines returning undetected. Among the engines that miss the driver are AVG, Avast, Avira, ESET-NOD32, Elastic, ClamAV, and Cynet. The community vote is 2 malicious to 0 harmless — a thin signal, but directionally consistent with the broader detection consensus. The reputation score of -91 is the most negative of the two files, suggesting the driver's association with adversarial use is well-established in reputation databases even where static detection lags.
The submission volume disparity — 9 submissions from 6 unique sources for the driver versus 306 from 264 for the EXE — is the most operationally significant outlier in this dataset. A WHQL-cross-signed kernel driver is a high-privilege trust anchor. If the operator were deploying it broadly, submission telemetry would reflect that. Nine submissions across the entire observed lifetime of the file, from only six distinct sources, is consistent with selective, controlled deployment against a small number of high-value targets rather than broad distribution. The EXE may function as a first-stage tool deployed widely to establish access and generate C2 traffic; the kernel driver appears to be staged selectively, reserved for targets where ring-0 access is specifically required — perhaps to suppress endpoint detection tools [T1562.001] or to achieve persistence mechanisms [T1547.001] that require kernel-level registry manipulation [T1112] or file hiding [T1564.001, T1564.004].
The C2 Signal: IDS Rules Without Network IOCs
The network layer of this campaign is almost entirely dark. No IP addresses, domains, or URLs have been observed, leaving C2 infrastructure entirely uncharacterised. This is worth examining as an operational signal rather than simply a gap.
What does exist is two Proofpoint Emerging Threats IDS rule matches against the GUI executable: ET POLICY PCHunter Download Observed and ET POLICY PCHunter CnC activity. These rules fire on network traffic patterns associated with PCHunter's operation — the download rule on the retrieval of the tool itself, the C2 activity rule on the traffic the tool generates during operation [T1071]. The MITRE technique metadata includes T1071.002 (Application Layer Protocol: File Transfer), suggesting the C2 channel uses a file-transfer protocol rather than raw HTTP or DNS. Beyond that, the protocol and endpoint characteristics remain unknown.
The absence of network IOCs alongside 306 EXE submissions and confirmed IDS rule matches is itself informative. Several explanations are consistent with the available evidence. The C2 infrastructure may be well-compartmentalised — endpoints that are not exposed to broad internet scanning, hosted in network ranges that do not generate passive DNS or certificate transparency records, or accessed through proxies or relay nodes that absorb the attribution surface. The operator may be rotating C2 endpoints faster than submission telemetry can capture — a pattern that produces IDS rule matches in sensor networks without producing stable, attributable network IOCs. Or the network IOCs may simply not have been submitted to common telemetry sources, leaving a gap that does not reflect the actual infrastructure footprint.
The ingress tool transfer technique (T1105) suggests the operator uses the C2 channel to push additional tooling to compromised hosts — a capability that, combined with the kernel-level access provided by the driver, would allow the operator to deploy secondary payloads, exfiltration tools, or lateral movement utilities without those artefacts being visible in the current dataset. The registry query (T1012) and registry modification (T1112) techniques indicate the operator uses the kernel-level access to interact with the Windows registry for discovery and persistence. The indicator removal techniques (T1070, T1070.004) suggest the operator cleans up artefacts after operations — a tradecraft discipline that would contribute to the low submission volume of the kernel driver and the absence of network IOCs.
The signing infrastructure is the only cross-file linkage available, and it is bifurcated rather than shared: the two files use entirely different certificate chains and there is no shared cert serial, imphash, or vhash between them. Their co-occurrence in this threat record rests on the shared PCHunter family label, the shared signing date of 30 January 2019, and the shared copyright string referencing Epoolsoft Corporation. That is a meaningful operational link — both components were clearly produced as part of the same software release — but it is a provenance link rather than a campaign infrastructure link. The upstream delivery mechanism, the C2 endpoint, and the lateral movement infrastructure remain unobserved.
Targeting Geometry and the Inconsistent Actor Attribution
The geographic and sector targeting profile documented in the threat record spans fourteen countries: Austria, Canada, Chile, China, Germany, Hungary, Indonesia, Italy, South Korea, Mexico, Romania, Turkey, the United States, and Vietnam. The industries targeted are financial services, technology, and telecommunications. This is a broad, multi-continental targeting footprint that encompasses major financial centres (the United States, Germany, South Korea), technology hubs (the United States, South Korea, China), and telecommunications infrastructure across both developed and emerging markets (Indonesia, Vietnam, Romania, Turkey).
The breadth of this targeting profile is more consistent with a persistent-access or intelligence-collection operation than with a narrowly targeted ransomware campaign. Ransomware operations typically concentrate on sectors with high ransom-payment propensity and low tolerance for operational downtime — healthcare, manufacturing, logistics — and tend to operate within more geographically constrained victim pools during any given campaign phase. A fourteen-country, three-sector footprint spanning financial services, technology, and telecommunications across four continents suggests either a broad pre-positioning operation designed to establish access across a wide attack surface, or a tool that has been deployed by multiple operators across different campaigns and whose victim telemetry has been aggregated into a single threat record.
The actor attribution — "Royal Ransomware" (alias: Team One) with an espionage motivation — is internally inconsistent in a way that reduces confidence in the assignment to near-negligible levels. Royal Ransomware is a ransomware operation; espionage is not a standard motivation for ransomware actors. The combination could reflect a dual-use operator that conducts both financially motivated ransomware campaigns and state-aligned espionage operations, a mislabelling in the upstream threat record, or an aggregation artefact where activity from multiple operators using the same publicly available PCHunter toolkit has been attributed to a single actor label. CTX Team treats the actor assignment as provisional. The tooling evidence — the specific certificate choices, the VMProtect obfuscation layer, the WHQL driver deployment pattern, the randomised drop paths — is the more reliable analytical anchor for tracking this activity.
The espionage motivation tag, taken at face value, is consistent with the kernel-level access capability and the targeting of financial services and telecommunications infrastructure. Ring-0 access via a WHQL-signed driver provides the operator with the ability to query and modify the registry [T1012, T1112], suppress security services [T1562.001, T1489], hide files and artefacts [T1564.001, T1564.004], and establish persistence via autostart mechanisms [T1547.001] — a capability set that is well-suited to long-term, low-visibility access rather than the rapid encryption and ransom-demand cycle of a ransomware operation. The Service Stop technique (T1489) in the metadata does indicate a disruptive capability is present, but its inclusion in a technique set that is otherwise oriented toward stealth and persistence is more consistent with pre-ransomware staging or a contingency capability than with active destructive intent.
What the Evasion Stack Signals About Operator Capability and Ecosystem Shift
The operational significance of this case lies less in the actor attribution question — which is unresolved and may remain so — and more in what the specific combination of evasion techniques reveals about the operator's sourcing capability and deployment discipline.
Assembling this evasion stack required navigating three distinct trust acquisition pipelines: obtaining a DigiCert EV code-signing certificate for a Beijing-registered legal entity, obtaining a Microsoft WHQL cross-signature for a kernel-mode driver, and sourcing or developing VMProtect licensing for the obfuscation layer. Each of these is a non-trivial operational step. EV certificate issuance requires identity verification of the subscribing organisation. WHQL cross-signing requires submitting a driver through Microsoft's Hardware Lab Kit testing process. VMProtect is a commercial product with licensing controls. The operator — or the entity that originally built PCHunter — completed all three processes legitimately, producing a toolkit whose trust anchors are technically genuine rather than stolen or forged.
This is a materially different threat model from the more common pattern of stolen code-signing certificates or self-signed drivers. Stolen certificates can be revoked when discovered, immediately degrading the evasion capability. Legitimately obtained certificates that were valid at signing time and have since expired cannot be revoked retroactively in a way that invalidates the embedded timestamp — the signature remains verifiable as "valid at time of signing" indefinitely. The operator's evasion capability is therefore durable in a way that stolen-certificate abuse is not.
The selective deployment of the kernel driver — 9 submissions versus 306 for the EXE — suggests the operator understands the exposure risk of a high-privilege component and manages it accordingly. Broad deployment of a WHQL-signed kernel driver would generate submission telemetry, sandbox analysis, and detection signatures that would eventually degrade the driver's utility. By staging it selectively against targets where kernel-level access is specifically required, the operator preserves the driver's effectiveness for longer. This is a form of operational security discipline that is more characteristic of a sophisticated, persistent operator than of a commodity tool user.
The complete absence of network IOCs alongside confirmed IDS rule matches and 306 EXE submissions points toward C2 infrastructure that is either well-compartmentalised or rapidly rotating. Either condition represents a significant challenge for network-layer detection: the IDS rules ET POLICY PCHunter Download Observed and ET POLICY PCHunter CnC activity represent the most actionable network-layer detection surface currently available, but they fire on traffic patterns rather than specific endpoints, meaning they will produce alerts without providing attribution or blocking capability against the specific infrastructure in use.
The sector that will feel this evasion stack most acutely is financial services — specifically organisations that rely on trust-based application control as a primary endpoint defence layer. EV code-signing certificates are explicitly designed to bypass SmartScreen and similar reputation-based controls; an operator who has sourced a legitimately obtained EV certificate for a Beijing-registered entity and wrapped a known hacktool in VMProtect obfuscation has specifically engineered around the trust model that financial services organisations often deploy as a compensating control for environments where full application allow-listing is operationally impractical. The telecommunications and technology sectors face a parallel risk from the kernel-driver component: organisations in those sectors frequently operate infrastructure where kernel-level visibility tools are legitimately deployed, making the presence of a WHQL-signed driver harder to distinguish from authorised system administration activity without behavioural context.
The broader ecosystem implication is that the PCHunter toolkit — a legitimately developed, legitimately signed Chinese system utility — has become a vehicle for adversarial operations in a way that its original certificate infrastructure was not designed to prevent and cannot now retroactively block. This is a pattern that extends well beyond PCHunter: any legitimately signed utility whose certificates were valid at signing time and have since expired without revocation carries the same residual trust. The question for the threat landscape is not whether this specific toolkit will be detected — file-level detection at 50/76 and 32/76 is already substantial — but whether the trust model that makes expired-but-valid-at-signing certificates effective as evasion anchors will be systematically addressed before a wider class of operators learns to exploit it.