A Verdict the Industry Confirmed Five Weeks Later

At a glance

Dekeneas classified this sample as malicious at maximum risk. At that point, 53 of the 70 engines on VirusTotal returned Undetected — including Kaspersky, BitDefender, Sophos, TrendMicro, Palo Alto Networks, Fortinet, SentinelOne (Static ML), DeepInstinct, Trellix ENS, Emsisoft, DrWeb and Malwarebytes.

By the following analysis, detection had risen to 50 of 70, and the sample had been identified as ACR Stealer.

The industry arrived at the conclusion Dekeneas reached immediately.

Why the timeline matters

Most detection comparisons are static. A vendor publishes a result showing that its engine flagged a file others missed, and the reader is left to judge whether the verdict was correct or merely aggressive. Any engine can score everything as malicious and appear prescient.

This case is not open to that objection. The correctness of the verdict was established independently, by the rest of the industry, weeks after the fact.

Two observations of the same file:

• 5 August 2026 — 17 of 70 engines detect. Dekeneas: Malicious, 100%.
• Approximately five weeks later — 50 of 70 engines detect. The file is identified as ACR Stealer and tagged as a spreader.

Thirty-three additional engines changed their verdict. None of them changed it away from malicious.

This is the practical shape of the gap that signature-dependent analysis creates. The file was not ambiguous and it was not novel — it was publicly available on MalwareBazaar throughout. What was missing was coverage. During the weeks it took for that coverage to propagate, organisations relying on those engines were unprotected against a sample that was already, structurally, unmistakable.

What the engine reported

The verdict rests on 12 suspicious artefacts, 5 behaviour indicator categories and 20 distinct code capabilities, each located at a specific virtual address with the matching disassembly attached.

A multi-format cryptographic and compression stack

The binary implements AES, RC4 and Salsa20/ChaCha, together with QuickLZ decompression.

A legitimate application implements the cryptography it needs. Three unrelated cipher families plus a compression codec in a single executable is the signature of a loader capable of unwrapping several payload formats — not of an application performing a cryptographic task.

Manual API resolution

The engine identified PEB access, access PEB ldr_data and resolve function by parsing PE exports, each matching at three separate locations.

Together these describe a binary that walks the loader data structures in the Process Environment Block to locate loaded modules, then parses their export tables directly to resolve function addresses — obtaining Windows API functionality without declaring it in the import table.

Network capability consistent with a listening implant

Communications over UDP, communications over RAW socket, DNS-based communication, listening for incoming communication, and detection of the Winsock 2 API library declaration.

Anti-analysis

Three independent debugger-presence checks, including a thread-control variant, plus software breakpoint detection.

Privilege and system manipulation

Privilege escalation, system token manipulation, registry modification, and private profile access.

The reasoning, not just the score

No single capability above is conclusive. Legitimate software uses cryptography, resolves functions dynamically, and opens sockets.

The verdict comes from the combination: a multi-format unpacking stack, import-table evasion, a listening network channel, anti-debugging, and token manipulation, present together in one binary. That composition has no benign explanation.

The analyst note states that composition in plain terms rather than leaving it to be read out of the capability list:

The sample allocates thread local storage, performs encryption using AES, RC4, and Salsa20/ChaCha, and decompresses data using QuickLZ, suggesting data manipulation and protection techniques. It also checks for software breakpoints and debugger presence, indicating anti-analysis measures. The sample communicates over UDP, TCP, and DNS, suggesting network communication capabilities. It affects system registries and tokens, which could imply privilege escalation or persistence mechanisms.

Twenty capabilities at virtual addresses are evidence. This is an assessment — and producing it is the step that normally requires an analyst who can read the evidence. The note also maps the findings to T1027 (Obfuscated Files or Information) and T1129 (execution by loading modules at runtime), which is what a detection engineer or a report actually consumes.

On the family attribution

The analyst note declined to name a family:

Based on the observed behaviors, the sample could potentially belong to a Remote Access Trojan (RAT) or backdoor family... However, without more specific indicators, the exact malware family type cannot be conclusively determined.

The file was subsequently identified as ACR Stealer.

This is worth examining rather than glossing over, because it illustrates what capability analysis can and cannot establish. Remote access trojans, backdoors and information stealers are not disjoint categories. They are descriptions of objective, layered on top of a capability set they largely share: an encrypted command-and-control channel, staged payload handling, anti-analysis, and persistence. ACR Stealer operates a C2 channel and handles remote instruction; a stealer carrying a listening capability is functionally a backdoor whose purpose happens to be credential theft. The spreader tag subsequently applied to this sample points to propagation behaviour, which sits further from a pure stealer than the note's suggestion did.

The capabilities the engine observed — multi-format encrypted staging, manual API resolution, a listening network channel, privilege and token manipulation, anti-debugging — are common to all three categories. They establish malicious intent conclusively. They do not discriminate objective, because objective is a property of how the operator uses the tooling rather than of the code's structure.

Which is exactly why the note declined to commit. Naming a family from capability evidence alone would have meant asserting something the evidence does not support, and family taxonomy across the industry is in any case a set of vendor naming conventions rather than a stable ground truth.

The engine was definitive about what it could establish and explicitly provisional about what it could not. That distinction is the design, not an artefact of it.

A likely explanation for the initial detection gap

The manual API resolution observed in this sample offers a plausible account of why so many static engines initially returned nothing.

An engine that leans on import table analysis, string extraction or structural heuristics has comparatively little to work with. Functions are resolved at runtime by walking loader structures, so the imports that would normally characterise the binary are largely absent. Payload content sits behind several layers of encryption and compression. There is no compile timestamp.

Dekeneas reaches a verdict because it evaluates what the code is constructed to do, at instruction level, rather than what the file declares about itself.

We offer this as an explanation consistent with the evidence, not as a claim about how any specific vendor's engine operates.

What this case demonstrates

• The verdict was correct, and correctness was established externally. Fifty of seventy engines subsequently agreed. This is not a self-assessed result.
• Signature-less classification closes a timing gap that matters operationally. The information needed to classify this file was present in the file on day one.
• Capability composition is more informative than capability count. Twenty code capabilities produced a definitive verdict because of how they combine.
• Confidence is calibrated per claim. Maximum risk on the verdict; an explicit refusal to name the family, which proved to be the right restraint.
• The output is verifiable. Every capability is reported with its virtual address and disassembly.

Verify this yourself

The sample is publicly available on MalwareBazaar under the hash above.

The Dekeneas free tier includes malware analysis at no cost and requires no commitment. We encourage prospective users to test the engine against samples where they already know the ground truth — including samples the industry handles well, so the comparison runs in both directions.

What this case does not show

A single sample is a single sample. This case study demonstrates that the engine reached a correct verdict on one binary weeks ahead of industry consensus. It is not a detection rate, and we do not present it as one.

The comparison is also specific in scope. VirusTotal runs static analysis configurations, so this compares static analysis against static analysis — the appropriate comparison, since Dekeneas is performing static analysis too. We make no claim about how these vendors' full products behave at runtime, having neither tested them nor any basis for an opinion.