Amadey Credential Stealer Slips Past Sandbox Despite 60/79 AV Flags

A Password Stealer That Vanishes the Moment You Watch It Run

Sixty of seventy-nine antivirus engines call it outright malicious. Feed the same file to a sandbox, and it comes back clean — "undetected," classified only as UNKNOWN_VERDICT, zero out of one dynamic runs flagging anything at all. That is the story sitting inside a single Amadey-linked credential-stealer DLL, tracked internally as cred.dll, and it is a more useful data point than most of the noisier campaign narratives this desk sees in a given week: a textbook illustration of how a passive module built to be loaded by something else can sail past behavioural detection while static signatures scream about it in near-unison.

The file — a 126KB unsigned Win32 DLL carrying the meaningful name cred.dll — is the only substantive artefact in an otherwise thin record: one companion file entry with no populated fields at all, one IP address in Russia tagged as an Amadey command-and-control node, and a certificate history that turns out to be entirely generic. CTX Team's confidence score on the overall package sits at a modest 17 out of 100, and that number matters here — not because the finding is wrong, but because the record beneath it is unusually sparse, and the one signal worth reporting is precisely the detection-versus-behaviour split on the DLL itself.

The Detection Gap, Read Correctly

Amadey has circulated for years as a modular loader-and-stealer combination, typically dropping additional components once it has landed on a host, and the file in question fits that pattern down to its file path. Alternate names recovered from submissions show the DLL nested inside an Amadey-style unpacking directory — C:\Users\DEVDAS\AppData\Roaming\a20732a67da3b4\cred.dll — alongside a second copy cached by Internet Explorer under %HOME%\unpack\cred.dll. Popular-name tagging across engines reads "amadey, decred, dump," and the file itself carries the tags "pedll, spreader." None of that is inference: it is the shape a credential-harvesting module dropped by Amadey's loader is expected to take.

What elevates this beyond a routine detection log is the named rule match. The sample fires INDICATOR_TOOL_PWS_Amady, a YARA rule authored by ditekSHen with a description that leaves no ambiguity: "Detects password stealer DLL. Dropped by Amadey." That single rule hit is the strongest piece of evidence in the entire record, and it maps cleanly to credential harvesting from local files [T1552.001] — a direct rule-based confirmation, not a stretch of inference.

Set that against the industry view. The detection ratio of 60/79 spans a wide bench of engines — ALYac, AVG, AhnLab-V3, Alibaba, Antiy-AVL, Arcabit, Avast, Avira, BitDefender, Bkav, CrowdStrike, Cylance, DrWeb, ESET-NOD32, Kaspersky and more all flag it — while nineteen engines, including Acronis, SentinelOne, and TrendMicro-HouseCall, still return nothing. That split is normal for a static signature sweep. What is not normal is what happens when the file actually runs: a single sandbox execution logged the sample as "undetected," with zero of one dynamic verdicts registering malicious activity. For a file that three-quarters of the AV industry independently agrees is a credential stealer, a clean dynamic run is the signature of a component that does nothing interesting until something else invokes it — a DLL waiting for a host process, an export call, a specific argument, before it touches LSASS memory, browser credential stores, or any of the artefacts [T1552.001] and its sibling technique, credentials in the registry [T1552.002], describe. Sandboxes that execute a DLL without the loader context that Amadey's dropper normally supplies will, almost by construction, see nothing worth flagging.

That gap is the article's actual news. It is not a novel evasion trick — no anti-debug routine, no VM fingerprinting call is directly logged against this sample — but it is a clean, evidenced demonstration of why relying on a single dynamic verdict to triage a DLL is a bad idea when the file's entire job depends on being invoked by a parent process the sandbox never supplied.

Build Fingerprint: A File Built to Sit Quietly

The build data reinforces the "waiting module" read. The DLL carries an imphash of 557f0c64436e04f97f66ceeb0911cbf0 and an import count of zero — an unusual combination that suggests the sample either strips or dynamically resolves its imports rather than exposing a static import table, a common trait of Amadey components engineered to frustrate static import-based clustering. Fuzzy-hash coverage is present but isolated: the ssdeep signature 3072:Qx7p5EJTJX/DL5nr0Z2fgnXKSxN07IXauEe… and vhash 1150766d5c0d1515651033z12z2a9z3bz4ez2 give an analyst a way to hunt for near-duplicates, but nothing in this record ties those fingerprints to any sibling sample — CTX Team's own review flags this file as sharing no imphash, signer, or threat label with any peer in the catalog, an outlier standing entirely on its own evidentiary legs.

Section entropy tells a consistent story. The .reloc section registers 6.68 and CODE sits at 6.51 — moderate-to-high values consistent with a compiled Win32 DLL carrying some obfuscation or compression, though not the extreme 7.5+ entropy typical of a heavily packed loader shell. The .edata section, by contrast, reads a near-flat 0.78, and BSS shows no measurable entropy at all — the profile of a small, purpose-built module rather than a general-purpose packer wrapping a payload. That is consistent with the file's job description: not a dropper with multiple embedded stages, but a narrow, single-function credential-harvesting DLL meant to be handed off from Amadey's core loader.

A Certificate That Explains Nothing

The infrastructure side of this record is where the caution flags multiply. The single IP tied to the file, 193.106.191.201, sits in Russia under RIPE NCC allocation and carries a "c2-servers" category tag tied explicitly to the amadey family — a label that, on its face, reads as confirmation of an active C2 endpoint. The raw telemetry underneath that label is considerably thinner: 12 of 91 engines flag the address, its reputation score sits at -37, and no ASN or AS-owner field is populated anywhere in the record. That is a case worth naming plainly: the external threat-intelligence categorisation here is running well ahead of what the address's own detection numbers would support on their own, and treating the "c2-servers" tag as equivalent to a confirmed, actively-serving beacon endpoint would overstate what the telemetry shows.

The certificate attached to that IP does not change the picture. It is a Let's Encrypt-issued cert (issuer CN "R3"), valid from 2022-12-03 to 2023-03-03 — an 89-day span that is simply the standard Let's Encrypt lifetime, not a bespoke or operator-chosen window. The subject common name, cool-murdock.193-106-191-201.plesk.page, is a Plesk auto-generated hostname bound directly to the numeric IP address — the kind of certificate a shared-hosting control panel mints automatically for every tenant on the box, not a domain an operator registered and shaped for a specific campaign. Read together, the cert confirms only that this IP sits behind a managed Plesk hosting panel; it offers no registrar identity, no bespoke subject-alternative-name pattern, and no AS-level fingerprint that would let an analyst cluster this address against other infrastructure with any confidence.

Compounding the uncertainty, the WHOIS record for the address's containing block shows an internal date inconsistency worth flagging on its own: the inetnum object carries a "created" timestamp of 2025-12-09, while the parent organisation record — MTS PJSC, the allocating LIR — dates to 2004-04-17. That gap likely reflects a registry re-allocation or record refresh rather than anything sinister, but it means the address block's own metadata cannot be used to date when this specific IP entered Amadey-linked service. Combined with the absent ASN data, the infrastructure side of this record functions best as context for the file-side finding — not as an independent campaign story in its own right.

Walking the Chain from Loader to Beacon

Laid end to end, the mechanics here follow a fairly conventional Amadey pipeline, with one stage confirmed and the rest inferred from the surrounding evidence rather than directly observed in a process log. Execution most plausibly runs through a native loader invoking the DLL — consistent with Windows binary proxy execution via rundll32 [T1218.011] — though no dossier-level log captures that invocation directly for this sample; it is a reasonable read of an unsigned, zero-import DLL sitting in an Amadey unpack path, not a confirmed observation.

Credential access is the one stage resting on hard evidence: the INDICATOR_TOOL_PWS_Amady rule match ties the file directly to credential harvesting from files and stored data [T1552.001], and the broader family tagging extends that to registry-stored credentials [T1552.002] as a plausible secondary target, consistent with how Amadey's stealer modules typically operate even though this specific sample's registry-touching behaviour isn't independently confirmed here.

Defense evasion sits more speculatively in the chain. The record's MITRE tag set carries debugger evasion [T1622] and defense-tooling interference [T1562, T1562.001] as family-level associations, and query-registry discovery behaviour [T1012] alongside native API usage [T1106] appear in the same tag list — all plausible for an Amadey component, none of them backed by a sandbox log specific to this hash. Treat these as the technique repertoire the malware family is known to carry, not as confirmed behaviour of this particular sample.

Command-and-control closes the loop at the RU-hosted IP, positioned as the beacon endpoint by virtue of its "c2-servers" categorisation and its live HTTPS certificate — a reasonable inference given the pairing in the record, though as established above, the certificate itself is boilerplate managed-hosting output rather than a distinguishing operator signature.

Thin Attribution, Real Operational Signal

No named threat actor attaches to this record. The catalog's actor field is empty, and the only labels present are the amadey family tag and a broad "espionage" motivation marker — a combination that sits awkwardly against what the evidence actually shows. A generic credential-stealer DLL riding shared Plesk hosting infrastructure looks far more consistent with commodity, opportunistic credential theft than with a bespoke espionage operation, though the available indicators are too limited to resolve that tension either way. Regional exposure is similarly narrow: Bulgaria is the only tagged region in the record, with no industry sector populated and no domains beyond the bare IP string appearing anywhere in the catalog — enough to note geographic proximity, not enough to support a sector-specific victim profile.

That thinness is itself informative. One of the two files counted in this record's own indicator tally carries no type, size, detection, or label data whatsoever — an evidentiary gap rather than a finding — and the overall confidence score of 17 out of 100 should be read as a direct instruction not to over-extend this slice into a fuller campaign narrative. What can be said with confidence is narrower and, arguably, more useful: this is one Amadey credential-stealer module, independently confirmed by a named YARA rule and a strong AV consensus, paired with one loosely-labelled Russian IP whose own certificate and WHOIS metadata add little beyond confirming it sits behind ordinary shared hosting.

What the Gap Signals for Defenders Watching Sandbox Output

The value of this record is not in the scale of the campaign it documents — there isn't enough here to call it a campaign at all — but in the cleanliness of the detection-versus-behaviour split it exposes on a single, well-confirmed sample. A module that three in four AV engines independently flag as a password stealer, yet that returns a clean dynamic verdict when run in isolation, is a direct illustration of a structural blind spot: sandbox triage pipelines that execute suspicious DLLs without replicating the loader context a family like Amadey normally supplies will systematically under-report exactly the credential-theft components those pipelines are supposed to catch.

It is also a useful corrective on labelling discipline more broadly. The Russian IP in this record carries an authoritative-sounding "c2-servers, amadey" tag that, read on its own, implies confirmed and current beaconing infrastructure. The detection ratio underneath that tag — 12 of 91 engines, no ASN attribution, a Plesk-issued certificate indistinguishable from thousands of other shared-hosting tenants — tells a more modest story. Neither observation demands a change in how defenders hunt; both are worth carrying forward as a reminder that a rule match, a family tag, or a sandbox pass each measure a different slice of ground truth, and none of the three should be allowed to stand in for the other two.