WinPEAS-Named Binary Flags Vault Credential Hooks, Splits Sandboxes

A Recon Tool That Can't Decide What It Is

A binary distributed under the name winPEAS.exe — one of the most widely used open-source Windows privilege-escalation enumeration tools — has turned up carrying YARA hits for Windows Vault credential objects and confidential-data-store queries, alongside two sandboxes that can't agree on what it actually is. CAPE Sandbox classifies the payload as Rhadamanthys, a well-known credential-stealing malware-as-a-service family; Zenbox instead labels it "PEASS HackTool" and flags it as a trojan/evader. The file — hash a2f0c35f766bd87f740ddeefe0d1d04e9ce5edd3534c932559a4b9894a4892a8 — sits at the center of a small indicator set the feed ties to APT29, but the interesting story here isn't the attribution. It's the payload's identity crisis, and what that crisis suggests about how stealer logic gets dressed up as a recognizable, "less alarming" red-team tool.

The sample carries 53 of 76 detections and a threat label of trojan.msil/winpeas, with popular-name tags "msil," "winpeas," and "zusy" spanning categories from trojan to hacktool to adware. That range of classification isn't cosmetic. It's the fingerprint of a tool that either got repackaged with stealer functionality bolted onto a legitimate enumeration base, or that triggered a labelling collision upstream that muddies what defenders are actually looking at when this file lands in a sandbox queue.

Inside the Binary: Packing, Timestamps, and Credential-Store Hooks

The build provenance is where the divergence starts to make sense. The file's .text section registers an entropy of 7.41 against a nearly empty .rsrc (3.94) and .reloc (0.08), with zero resolved imports and a PEiD packer signature attached — a single high-entropy section masking whatever logic sits underneath, consistent with defense evasion through packing [T1027]. That kind of construction is unusual for a stock WinPEAS build, which is typically distributed with a readable import table and standard .NET resource layout. Here, the near-total absence of imports paired with maximum packing on the code section reads more like a wrapper concealing additional functionality than a plain enumeration script.

That additional functionality has a name in the YARA hits. Two rules — INDICATOR_SUSPICIOUS_EXE_VaultSchemaGUID and INDICATOR_SUSPICIOUS_EXE_SQLQuery_ConfidentialDataStore, both authored by ditekSHen — fire on the sample, and both are documented by their author as patterns "observed in infostealers." One targets references to Windows Vault credential objects, the other targets SQL queries against confidential data stores. Neither belongs in a stock privilege-escalation utility, and together they explain why CAPE Sandbox reached for the Rhadamanthys label rather than a generic hacktool classification — the binary appears to combine host-enumeration routines consistent with credential targeting [T1555.003] on top of whatever WinPEAS-branded discovery logic it also carries.

The build also carries a compile timestamp that doesn't belong to any real point in time: the PE header records 2054-12-19, a value three decades into the future. Forged or corrupted compile timestamps are a known evasion and anti-analysis artifact, and while a single anomalous field isn't proof of anything on its own, paired with the packing and the credential-store YARA hits it adds another data point suggesting the build metadata was deliberately manipulated rather than left to compile naturally.

Ten named YARA rules from the Windows_Hacktool_WinPEAS_ng ruleset — including Windows_Hacktool_WinPEAS_ng_413caa6b, Windows_Hacktool_WinPEAS_ng_23fee092, and Windows_Hacktool_WinPEAS_ng_861d3264 — do confirm that genuine WinPEAS-style functionality is present, spanning File, System, Process, Services, and User-info detection modules. A further match against HKTL_NET_GUID_privilege_escalation_awesome_scripts_suite, which detects .NET red-team tools via typelib GUID, reinforces that this isn't a fake WinPEAS skin wrapped around something else entirely — the enumeration logic is real. It's the credential-store overlay riding alongside it that shifts the read from "recon tool" to "recon tool plus something with stealer intent." Sigma coverage adds one critical and one high-severity match on top of the YARA set, and of the 76 engines that scanned the file, 53 flag it while a cluster including Acronis, Antiy-AVL, ClamAV, DrWeb, and Trustlook still return clean — a detection gap wide enough that a security team relying on a narrower engine set could plausibly miss it.

The Fastly-Fronted Certificate That Doesn't Quite Fit

The only other indicator in this record is an IP address, 151.101.1.69, sitting on Fastly's content-delivery backbone under AS 54113 and registered through ARIN. On its own that tells an analyst very little — Fastly fronts an enormous volume of legitimate traffic. What stands out is the TLS certificate observed on that address: issued by "Certainly Intermediate R1" for the subject a6z-dns.ovh, with a wildcard SAN of *.a6z-dns.ovh, valid only from 2024-04-28 to 2024-05-28 — a 29-day window. Certificates that short-lived, sitting on a shared CDN edge rather than dedicated infrastructure, are consistent with disposable TLS issuance patterns operators use to stand up staging points that blend into legitimate cloud traffic and get discarded quickly.

That's as far as the evidence goes, though, and it's worth being explicit about the limit. The IP carries 0 detections out of 91 engines and shares no imphash, no signer, no ASN, and no cohort axis with the WinPEAS/Rhadamanthys file — the analytical record notes both indicators as structurally isolated from each other, with AS 54113 appearing nowhere else in this set and the file matching no peer sample. There is no A-record, name-server, registrar, or certificate-serial overlap tying the two together. The thematic proximity — a credential-oriented binary sitting in the same feed record as a short-lived, CDN-fronted certificate — is suggestive of a staging-node hypothesis, but it remains exactly that: a hypothesis, not a confirmed C2 relationship. Treating 151.101.1.69 as this sample's beacon destination would be reading more into the data than the data supports.

Attack Chain: From WinPEAS Execution to a Contested C2 Hypothesis

Laid out stage by stage, what's actually observable starts with execution. Sandbox consensus is unanimous at 2 out of 2 malicious verdicts, and the file's alternate names include a renamed dropped path, C:\Windows\e7sfdp.exe, alongside its more recognizable winPEASany.exe alias — indicating the binary is executed post-delivery under a filename designed to blend into system directories rather than announce itself [T1059.001]. From there the discovery phase is the most thoroughly evidenced link in the chain: the ten WinPEAS YARA hits plus tags like checks-cpu-name and calls-wmi point to systematic host and hardware enumeration [T1082], the kind of survey a privilege-escalation tool performs before an operator decides whether a target is worth continued effort.

Layered on top is the credential-access signal already discussed — the Vault-schema and confidential-data-store rule hits pointing toward credential targeting [T1555.003] that goes beyond what a stock enumeration script would need. The file's detect-debug-environment tag also suggests built-in sandbox and virtual-machine awareness [T1497], consistent with a payload designed to behave differently, or not at all, when it senses analysis tooling watching it. Defense evasion runs through the build itself, via the single high-entropy packed section and stripped import table already noted [T1027].

The final stage — command-and-control — is where the chain gets speculative rather than observed. If 151.101.1.69 and its short-lived Certainly-issued certificate for a6z-dns.ovh do play a C2 or staging role for this specific sample [T1071], the current evidence doesn't establish that link directly; it's an inference built on thematic and infrastructural pattern-matching, not a structural tie. Readers should weigh the discovery and credential-access findings as the solid part of this narrative, and the C2 hypothesis as the part still awaiting corroboration.

An APT29 Label Resting on a Single, Unconnected Sample

The feed ties this indicator set to APT29 — tracked elsewhere under aliases including Cozy Bear, CozyDuke, and The Dukes — with espionage listed as the operating motivation, a framing broadly consistent with credential-focused host reconnaissance. But the attribution here rests on one file that the analytical record itself flags as structurally isolated: no shared imphash, signer, or threat-label ties it to any peer sample, and the cohort index behind this record shows an empty linkage set. That doesn't rule out the attribution, but it does mean the APT29 tag should be read as a feed-level label rather than a corroborated cluster finding, and treated with the caution that a single, unconnected indicator warrants.

What a Mislabelled Hacktool Signals for Triage

What this record actually demonstrates is less about a named actor and more about a triage problem that's likely to recur. A binary carrying genuine, verifiable WinPEAS enumeration logic — confirmed by ten distinct YARA signatures against a purpose-built detection ruleset — has been observed with credential-store query hooks and a forged compile date layered on top, and two reputable sandboxes split on whether to call it a red-team utility or a commodity stealer. That split isn't a data-quality artifact; it's the exact outcome an operator wants if the goal is to get a stealer payload waved through as "just another pentest tool" during initial analyst review. WinPEAS and its variants are common enough in legitimate red-team engagements and common enough in intrusion sets that analysts have learned, reasonably, not to over-react to the name alone — which is precisely the gap this kind of overlay is built to exploit.

The absence of a corroborated infrastructure trail here is itself worth sitting with rather than dismissing. A single file with no shared build artifacts, paired with a single unrelated IP carrying zero detections and a disposable certificate, is not a campaign in the conventional sense — it's a data point. But it's a data point that argues for independent reverse-engineering before either the Rhadamanthys tie or the "PEASS HackTool" tie is treated as settled, and before the APT29 label attached to it gets repeated as fact rather than as the feed-level signal it currently is. For defenders who see WinPEAS or WinPEASany land in a queue, the lesson isn't to whitelist the name — it's to check whether the binary in front of them enumerates hosts, or enumerates hosts and reaches quietly into the Vault.