Signed Process Hacker Driver Now Anchors a Four-Stage Attack Chain

A Vulnerable Kernel Driver Just Became Part of a Bigger Story

A signed kernel driver that Microsoft's own trust chain still vouches for is quietly doing double duty as a privilege-escalation primitive, and it is not travelling alone. The newest indicators added to a long-tracked Process Hacker 2 file set — both the x86 and x64 builds of kprocesshacker.sys (0f97f6d53fff…, 70211a3f9037…) — fire the LOLDrivers-catalogued rule PUA_VULN_Driver_Wj_Kprocesshacker_7021 despite carrying a fully valid DigiCert code-signing chain. That single fact reframes what had previously read as a story about an expired certificate on a diagnostic tool. It is now a four-stage toolkit: disable the endpoint's defenses, escalate through a vulnerable driver, enumerate and kill processes, then lift credentials — built almost entirely from legitimately-signed freeware rather than custom malware.

What makes this cluster worth a second look isn't novelty of technique — BYOVD and dual-use hacktool abuse are well-worn tradecraft — but the fact that 20 file-level indicators, spanning four distinct signer identities, now line up into an ordered sequence that the analyst's own reconstruction of the kill chain lays out stage by stage. None of it involves a single custom implant. Every binary in this set began life as legitimate software: a system-monitoring utility, a Windows Defender toggle, a password-recovery tool, a packet sniffer. The operational value here comes from assembly, not authorship.

Chronology of the Chain: Evasion, Escalation, Discovery, Theft

The reconstructed sequence opens with defense evasion. A file that presents itself under names including "DefenderControl.exe" and "1.exe" (5161a16217b9…) is AutoIT-compiled, matches the rule INDICATOR_TOOL_PET_DefenderControl, and carries a certificate chain that — in Microsoft's own validation language — "terminated in a root certificate which is not trusted by the trust provider." That is a deliberate choice: a Sordum Software-signed Defender-disabling utility bought the operator a window where the rest of the toolkit can land without triggering signature-based defenses immediately, at the cost of a certificate that fails validation the moment anyone checks it — a tradeoff that favors speed over stealth durability. Its behavioural tags include calling WMI and checking whether a debugger is attached [T1562.001], consistent with a tool built to tamper with security posture rather than perform any legitimate administrative task.

With Defender's guardrails weakened, the operator turns to kernel access. Both kprocesshacker.sys builds mentioned above are legitimately signed by Wen Jia Liu under a DigiCert High Assurance chain — the same signer behind the entire Process Hacker 2.39 release — yet independently flagged as a LOLDrivers-listed vulnerable driver. This is the defining characteristic of bring-your-own-vulnerable-driver tradecraft [T1068]: rather than write a malicious kernel component that antivirus vendors will fingerprint immediately, the operator loads a driver Microsoft already trusts and exploits its known weakness. The driver buys kernel-mode primitives without the operator ever having to forge a signature — but it also means the tool's presence on disk is permanently traceable to a name (kprocesshacker.sys) that defenders and threat-hunting rulesets already watch for. That's the cost of reusing someone else's vulnerable code: it never stops being recognizable.

From inside a monitored environment, this stage is where detection has the best chance of surfacing — a security team watching driver-load events would see a legitimately-signed .sys file appear that nonetheless triggers a "known-vulnerable driver" alert rather than a straightforward malware verdict, a pattern that reads as ambiguous unless the analyst already knows to cross-reference LOLDrivers. That ambiguity is exactly what makes BYOVD durable as a technique: the file itself looks clean by every certificate check, and only rule-based correlation catches it.

Once kernel-level footing is secured, discovery and process termination follow through the main Process Hacker binaries themselves. The x64 build (bd2c2cf0631d881ed382817a…) and the x86 build (d4a0fe56316a2c45b9ba9ac1…) both carry the "legit" tag in the underlying metadata — Process Hacker is, after all, a genuine open-source process-management tool — yet Zenbox independently classifies both as EVADER and Dr.Web vxCube / Yomi Hunter return outright MALWARE verdicts. Both builds also trigger the Sekoia rule hacktool_win_processhacker [T1057]. That split verdict is itself the analytical signal: a tool that is simultaneously "legit" by reputation and "EVADER" by sandbox behaviour is not being used to check system performance — it is being used to enumerate and kill security processes, the textbook administrative-tool-as-AV-killer pattern. The choice to use Process Hacker instead of a bespoke discovery tool buys near-total plausible deniability on static inspection, since the binary is a real, widely-distributed utility; it costs the operator nothing until behavioural telemetry — sandbox execution, EDR process-hollowing detection — catches the divergence between what the tool claims to be and what it is doing at runtime.

The chain closes on credential access. Two NirSoft utilities repackaged into this set — BulletsPassView, present in both a 32-bit build (b19dfe440e51…) and a 64-bit build (e71cda5e7c01…), and SmartSniff (d6831d36184a…) — all share an identical, now-revoked Nir Sofer certificate chain issued through COMODO Code Signing CA 2. Each carries the tag "was signed with a certificate that has since been revoked," and each is flagged under threat labels of hacktool.bulletspassview/passview or pua.sniffpass/smartsniff. SmartSniff goes one step further: it also matches CN_Honker_smsniff_smsniff and Smartniff, rules tied to a documented Chinese pentest hacktool set [T1555]. Two different kinds of evidence converge on the same reading here — a revoked certificate that no longer validates, plus a rule authored specifically to catch a known Chinese hacktool repackaging of the same freeware — and together they point toward this credential-harvesting stage being lifted wholesale from an established toolkit rather than assembled fresh for this operation.

It is worth being precise about what this ordering actually claims. The four stages line up cleanly on paper, and the co-occurrence of rule hits, signer identities, and behavioural tags makes a plausible case for a defense-evasion → escalation → discovery → credential-theft progression. But this is a reconstruction built from file metadata that shares no timestamps, execution logs, or infection chain telemetry connecting one stage to the next — it is a inference about what the toolkit is capable of doing in sequence, not a confirmed observation of it being deployed that way in a single incident.

One Signer, Fifteen Files: The Process Hacker Release Wave

Strip away the credential and Defender-disabling additions and the bulk of this catalog — 15 of the 20 dossiers — traces to a single signer identity: Wen Jia Liu, certified through two successive generations of DigiCert code-signing authorities (DigiCert High Assurance Code Signing CA-1 for the core binaries and driver, DigiCert SHA2 High Assurance Code Signing CA for the plugin DLLs), all signed at the identical moment of 01:35 AM on 03/29/2016. Nine bundled plugin DLLs — ExtendedTools, SbieSupport, WindowExplorer, NetworkTools, UserNotes, Updater, DotNetTools, HardwareDevices, and ExtendedServices — carry that exact same signing timestamp. This is not fifteen separate campaigns or fifteen independently-developed tools; it is one shipping bundle, Process Hacker 2.39, that has been sitting in file-reputation databases for close to a decade and keeps getting flagged, unflagged, and repackaged into new intrusion toolkits as it circulates.

That consistency is itself the finding. The cohort evidence shows the x86 and x64 kprocesshacker.sys builds co-firing the same two rules against each other, and the two ProcessHacker.exe builds co-firing hacktool_win_processhacker against each other — architecture pairs, not independent artifacts. One outlier sits apart from this cluster entirely: a PortableApps.com wrapper (d6eea8eb72d1…) signed instead by "Rare Ideas, LLC" through a COMODO RSA chain, tagged "corrupt" and "nsis," with only 5 of 76 engines flagging it. That file shares no imphash, signer, or threat label with its quasi-namesake peers — a reminder that "Process Hacker" as a search term in file repositories pulls in genuinely distinct build lineages, and that lineage matters more than filename when assessing whether artifacts belong to the same operational bundle.

Detection Gaps Inside a Single Release

The detection-ratio spread inside this one signer cohort is worth sitting with. The main ProcessHacker.exe builds land at 33/75 and 28/75; the kernel driver sits around 27-30/75; but the nine bundled plugin DLLs — same signer, same 2016-03-29 signing timestamp, same release — cluster tightly between 7/75 and 11/75. ExtendedServices.dll and HardwareDevices.dll, for instance, draw as few as 7 and 8 flags respectively out of 75 engines, while the loader binary shipped in the identical bundle draws four times that detection volume. Two different evidence textures converge on the same conclusion here: identical signer metadata plus wildly divergent engine coverage indicates that AV vendors weight the primary executable far more heavily than the auxiliary plugin DLLs distributed alongside it — an inference, not a documented vendor policy, but one consistent enough across nine separate files to read as a structural blind spot rather than noise.

That gap matters operationally. An operator dropping the full Process Hacker 2.39 bundle onto a target machine is statistically far more likely to have the main executable flagged than the plugin DLLs sitting quietly in the same folder — which means the plugins can persist on disk, and potentially execute functionality via the loader, well after the headline binary has been quarantined. From inside a monitored environment, an analyst who quarantines ProcessHacker.exe and calls the incident contained may be leaving eight or nine low-detection DLLs untouched in the same directory, each one carrying the identical signer chain that made the parent binary suspect in the first place.

Borrowed Trust: What Revoked and Untrusted Certificates Buy an Operator

Three separate signer identities now sit inside this one file catalog, and each tells a slightly different story about how trust decays over time. Wen Jia Liu's DigiCert chain expired on schedule in January 2017 but the files it signed keep circulating a decade later, still carrying a valid signature chain even though the underlying certificate's validity window has long closed. Nir Sofer's COMODO-issued certificate for the NirSoft tools has gone further: Microsoft's own validation explicitly marks trust "revoked," the certificate "explicitly distrusted." And the DefenderControl sample's Sordum Software certificate terminates in a root that trust providers simply do not recognize at all. None of these three failure modes are equivalent — expired, revoked, and untrusted-root are three distinct trust-chain breakdowns — but all three land in the same catalog, which suggests an operator (or a toolkit assembler) who is either indifferent to signature validity or actively relying on the fact that a broken signature chain still often passes casual inspection, since the presence of any code signature at all tends to lower scrutiny relative to an unsigned binary.

An Attribution Question the Evidence Doesn't Settle

The record attached to this catalog lists two named actors — Royal Ransomware and a cluster tracked under aliases including Comment Crew and APT1 — but no signer, rule match, or cohort linkage inside this file set actually ties the toolkit to either group specifically. That gap is worth stating plainly rather than working around: current evidence here is too thin to support an attribution claim, and the two named groups represent fundamentally different motivations — one financially-driven ransomware operation, one state-aligned espionage cluster — that would use a defense-evasion-plus-credential-harvesting toolkit for very different end goals. The dataset's own tags lean toward espionage and government-sector targeting, but a Defender-killer paired with credential-recovery tools is generic enough tradecraft to serve either an intelligence-gathering operation or pre-encryption staging ahead of a ransomware deployment; the toolkit composition alone does not disambiguate between them.

What a Toolkit Built From Freeware Signals

The absence of any IP, domain, or URL telemetry in this snapshot means the delivery and command-and-control layers of this operation remain entirely unobserved — this is a file-reputation view of a toolkit, not a traced intrusion. What that file-reputation view does show is a low-cost operational pattern: an operator who can lean on trusted vendor signatures, dual-use administrative tools, and freely available freeware to assemble something that functions like a bespoke implant chain — defense evasion, kernel privilege escalation, discovery, credential theft — without writing a single custom payload from scratch. Every component here was, at some point, legitimate software built by a real developer for a real purpose; the operational value comes entirely from combination and repurposing, not from novel code.

That composition is itself the signal worth carrying forward. Security teams have spent years building detection logic tuned to catch bespoke malware — unusual imports, high-entropy packed sections, custom C2 protocols. A toolkit built instead from Process Hacker, DefenderControl, and NirSoft freeware sidesteps much of that tuning by looking, at the file level, exactly like the legitimate tools it was cloned from. The kernel driver alone illustrates the point: a real, once-useful diagnostic component, still carrying a technically valid signature chain, now doubling as a documented vulnerable-driver exploitation primitive. As long as legitimate dual-use tooling keeps shipping with known weaknesses that outlive their original certificates, this kind of assembly-over-authorship approach will keep giving operators a way to build something that behaves like custom malware while looking, on paper, like nothing more than a diagnostics folder.