Why More Indicators Does Not Mean Higher Risk

At a glance

The sample with the fewest flagged capabilities received the highest risk score, by a factor of more than four.

An engine whose score rises with the number of suspicious features is performing a counting exercise, and it fails on exactly the files where accuracy matters most — offensive security tooling, administrative utilities, and anything else that legitimately performs dangerous operations. Dekeneas does not count.

All three samples were collected during the response to a single, real ransomware incident: the binary that performed the encryption, and the two tools the operators brought with them — Mimikatz for credential access and Process Hacker for interfering with endpoint defences. This is not a laboratory selection. It is the set of files one incident actually contained.

How the score is produced

The risk score is not a confidence value, and reading it as one leads to the wrong conclusions.

Classification is performed by an ensemble of ten independent models, each trained on a separate and deliberately non-overlapping family of signals — suspicious artefacts, behavioural indicators, code patterns, PE metadata, import tables, opcode patterns — with a further model aggregating their outputs into a single verdict.

What the score expresses is the extent to which independent views of the binary agree. A high score means malicious signal is present across many orthogonal feature spaces simultaneously. A lower score does not indicate hesitation about the evidence; it indicates that the signal is concentrated in fewer of those spaces.

This is why capability count and risk score are unrelated quantities. A file can present a large number of flagged capabilities that all belong to the same signal family, and a small number that appear across most of them. The second is the stronger result.

Sample 1 — An unknown ransomware binary

Verdict: Malicious, 97.08

This was the encryptor deployed in the incident. At the time of analysis the file did not exist on VirusTotal. Submitting the hash returned Item not found: it had never been uploaded, no vendor had issued a verdict, and no feed carried it. There was no prior knowledge available to any engine, including ours.

The reason nearly every model in the ensemble registered malicious signal is that this binary is a complete operation, and a complete operation leaves evidence in every part of the file:

• Import table. The full Restart Manager lifecycle — RmStartSession, RmRegisterResources, RmGetList, RmShutdown, RmEndSession. Ransomware uses this API to terminate the processes holding handles on files it intends to encrypt, so it can reach open documents and databases.
• Cryptographic structure. Salsa20 or ChaCha for bulk data, together with a referenced public RSA key, CryptAcquireContext, and WinAPI random number generation — the canonical hybrid scheme, in which a fast stream cipher handles file contents and the symmetric material is wrapped so only the operator can recover it.
• Code patterns. An in-place encryption loop: check exists, get size, read, write, clear content, set attributes, move file, file stomping.
• Behavioural indicators. Network share enumeration for lateral spread, mutex creation as a single-instance guard, WMI access via WbemLocator, Winsock with DNS resolution.
• Artefacts. A rule matching standard ransom note text.

Individually, several of these are unremarkable — backup software performs file operations and cryptography. What produces the score is that the evidence appears independently in the import table, in the cryptographic constants, in the code structure, in the behavioural profile and in the string artefacts. Five separate views of the file, agreeing.

The analyst note remains calibrated even so:

Based on the observed behaviors, the malware could potentially belong to a ransomware family... However, without explicit evidence of ransom demands, this classification remains speculative.

Definitive on the verdict. Explicitly provisional on the family.

Sample 2 — Mimikatz

Verdict: Highly Suspicious, 21.4

The second sample collected during the incident, used by the operators for credential access. Mimikatz presents close to a maximal profile of dangerous capability: 98 code capabilities and 19 artefacts, including credential theft from LSA, outbound credential handles via CredSSP, Chrome browser login harvesting via sqlite3 and DPAPI, CreateRemoteThread injection, Windows event log clearing, service creation, token manipulation, driver interaction via IOCTL, and RWX memory allocation.

An engine that added up suspicious features would rank this as the most dangerous file it had ever processed. It scores 21.4 — below the ransomware, at less than a quarter of the score, on more than double the indicators.

The reason is that nearly all of that capability belongs to one domain. Mimikatz is a credential access tool. Its signal is dense in the feature families that describe credential and token operations, and largely absent from the families describing payload delivery, propagation, encryption-for-extortion or self-contained operation — because those functions are not in the binary. The models examining those spaces are not uncertain. They are looking at code that does not contain what they are trained to find.

Note also that the analyst note does not soften its description to match the lower score. It still identifies credential theft, stealer-like function, T1555.003 for browser credentials, T1070.001 for log clearing. The capability description stays accurate while the verdict withholds a malicious classification. Description and judgement are separate outputs.

Sample 3 — Process Hacker

Verdict: Malicious, 29.4

The third sample recovered from the incident. This is the legitimate, widely used Process Hacker utility — a 2016 build, identified on VirusTotal by 19 of 73 engines almost uniformly as potentially unwanted software: Process Hacker (PUA), Riskware.Phacker, RiskTool.ProcHack, with the popular threat label hacktool.prochack.

Dekeneas scores it above mimikatz, and we want to be direct about why, because a reader could reasonably ask whether this is a false positive.

The engine does not consult reputation, publisher identity or vendor labels. It reports what the binary is constructed to do. What it found here goes beyond process inspection: keystroke logging via polling, screenshot capture, clipboard read and write, a routine matching credit-card checksum parsing, geolocation, HTTP status checking, the Speck cipher, persistence via the Image File Execution Options registry key, scheduled task creation, driver unloading, user impersonation, and an extensive anti-analysis set including Xen anti-VM strings, sandbox and AV module checks, and unmoving-cursor detection.

Service manipulation, driver interaction and debugger checks are what a process utility is for. Keystroke polling, clipboard capture and screenshotting are not — and because they belong to different signal families than the process-management capabilities, they register in models that mimikatz leaves silent. That is the mechanical reason this file scores above a dedicated credential tool.

This is a threshold disagreement, and it is worth being clear that the industry's position is a threshold too. The potentially unwanted classification is a compromise: it registers that a tool is dangerous while avoiding the operational cost of blocking software administrators legitimately rely on. That is a reasonable engineering trade-off, but it is not a neutral reading of the binary — it weighs consequences that sit outside the code. Dekeneas reports what the code can do and leaves the consequence weighting to the organisation. The abuse of this tool's driver to terminate endpoint security products is a reminder that the question is live in both directions — and it is why the operators carried this utility into the incident in the first place.

Where the analyst's judgement is required. Some capability labels describe an operation whose purpose cannot be recovered from structure. Credit-card parsing is the clearest example: the underlying Luhn checksum is a short modulo-10 routine over a digit buffer, and the same arithmetic appears in payment validation, IMEI checks, ISIN handling and ad-hoc integrity code. The engine correctly reports that the pattern is present. Whether it is operating on payment data is a question about context, not structure.

This is why every capability is reported with its virtual address and disassembly. The analyst opens the location, reads what feeds the routine and where the result goes, and resolves it in minutes. A checksum over a 16-digit buffer sourced from clipboard contents is one thing; the same arithmetic over a device identifier is another. The engine supplies what is needed to make that determination rather than concealing the question behind a score.

What this demonstrates

Capability count and risk score are unrelated quantities. 42 capabilities outrank 98 because the 42 register across most of the ensemble's signal families and the 98 concentrate in few. Counting features cannot reproduce this ordering.

The score is agreement, not confidence. A lower score reports that fewer independent views of the binary carry malicious signal — which is information about the file's structure, not about the engine's certainty.

The four-band classification carries information. Malicious, Highly Suspicious, Suspicious and Clean are only meaningful if samples land in the middle bands for defensible reasons. Mimikatz at Highly Suspicious is the intended behaviour of that scheme, not a hedge.

Reputation plays no part. Process Hacker is scored on what it can do, not on the fact that it is signed, published and widely deployed. The same logic applied to the unknown ransomware, which had no reputation to consult in either direction.

Ambiguity is surfaced, not hidden. Where a capability label carries semantic uncertainty, the evidence is exposed at instruction level so the analyst can resolve it. A score alone would make that impossible to check.

The assessment is delivered, not left to be derived. In each case the analyst note converts the capability evidence into a functional reading — a ransomware mechanism, a credential access tool, a process utility carrying collection capability — together with MITRE ATT&CK technique mapping and the risks that follow. That synthesis is the step that normally requires a reverse engineer. Producing it automatically is what allows a security team without one to act on the result rather than merely receive it.

Verify this yourself

The Dekeneas free tier includes malware analysis at no cost. We would specifically encourage testing the engine on dual-use tooling you already understand — administrative utilities, red-team binaries, packers, backup software — since those are the cases where an engine's discrimination either exists or does not.

What a false positive means here

The obvious question about a signature-less engine is what its false-positive behaviour looks like, and the honest answer is that the usual framing does not transfer.

False positive is a signature-era concept. It assumes a binary ground truth per file — this one is malware, that one is not — against which an engine either matches or fails. Dekeneas is not producing that kind of output. It reports capabilities present in code. Where a capability is genuinely present, the finding is correct regardless of the developer's intent: Process Hacker really does contain the routines described above, and reporting them is not an error.

What can be wrong is the semantic label attached to an operation whose purpose is not recoverable from structure — the Luhn case discussed earlier. That is a labelling question rather than a detection error, it applies to particular capabilities rather than uniformly across the engine, and it is resolvable by the analyst at the address provided.

The remaining question is a threshold one: where the boundary between Highly Suspicious and Malicious should sit for dual-use tooling. Organisations with a different answer than ours can apply it, and the four-band output with exposed evidence exists so that they can.

What is genuinely not established by three samples is an aggregate measurement of anything. These demonstrate that the scoring is compositional and that the ordering is defensible. Producing a rate would require a corpus, and a corpus is what the free tier is for.