Why do hash and YARA matching miss a signed archiving tool encrypting a file share?
answer
- Two verdicts: about content, about conduct
- Nothing bad is inside the file
- A hash fires on bytes, not on use
- The sequence is the malware here
- Enumerate, delete shadow copies, rewrite
basics
~20 sHash and YARA matching test content against known-bad patterns. A signed, allow-listed archiver is legitimate content, so nothing matches. The malice lives in how the tool is driven, and only a behavioural chain can convict that.
solid answer
~50 sBoth techniques judge content. A hash is an exact fingerprint of a file's bytes, so it only fires on a sample someone has already convicted. YARA matches strings and byte patterns inside a file or in memory, so it only fires on content that resembles a family someone has already characterised. Here the binary is a genuine, code-signed archiver whose hash matches the vendor's published release, and it sits on the allow-list because backup jobs use it. There is nothing bad in the file to match. What is malicious is the sequence: enumerate the shares, delete the Volume Shadow Copies, then rename-and-rewrite thousands of files at machine speed with the originals deleted. No single step is malware; the chain is. Convicting it requires an engine that scores related events across one process tree over time, which is why prevention moved from convicting a file to convicting a behaviour.
code
text · 11 linesEvent ID: 1 (Sysmon ProcessCreate)
Image: C:\Program Files\ArchiveUtil\arcutil.exe
OriginalFileName: arcutil.exe
Company: ArchiveUtil Ltd
Hashes: SHA256=<matches vendor's published release>
User: CORP\svc-backup
ParentImage: C:\Windows\System32\cmd.exe
ParentCommandLine: cmd.exe /c C:\Users\Public\run.bat
CommandLine: arcutil.exe a -p<redacted> -sdel -r Z:\Finance\* ...
(a = add to archive, -p = encrypt with password,
-sdel = delete source files, -r = recurse)go deeper
Be ready to say plainly what a hash and a YARA rule each compare, and that both look inside content. Then name the alternative: an engine that watches what a process does over time.
An interviewer expects you to walk the actual chain — share enumeration, shadow-copy deletion, bulk rename-and-write — and explain why each step alone is ambiguous while the sequence is not.
Show the judgment: a clean static verdict is not evidence of benign use, and you should be able to say which telemetry fields you would pull to argue the case either way.
Own the consequence for strategy: if assurance rests on known-bad matching, the estate is blind to every legitimate tool used against it, and that shapes what you buy and what you promise the business.
## Two different questions an endpoint product asks An endpoint protection product asks two separable questions about anything that runs on a host. **Is this content known to be bad?** This is the static half of the verdict pipeline, and it runs before or at execution. A cryptographic hash (SHA-256) is an exact fingerprint of a file's bytes: it answers "is this the same file as one already convicted", and a single changed byte makes it answer no. A YARA rule is a pattern language over file and memory *content* — strings, byte sequences, and conditions combining them — so it generalises a little beyond one exact sample to a family that shares recognisable material. Some products add a machine-learning file classifier in the same stage, which still reasons about the file itself. **Is this behaviour malicious?** This is the dynamic half, and it can only run once something is executing. It watches process creation with command lines, module loads, file writes, registry changes and network connections, ties them to one process tree, and scores the story they tell. ## Why this case defeats the static half completely The binary in this scenario is a real archiving utility from a real vendor. It is code-signed with a valid certificate, its hash matches the vendor's published release, and the estate deliberately allow-listed it because backup and packaging jobs depend on it. Every static test therefore returns "clean", and it returns "clean" *correctly* — the file genuinely is what it claims to be. This is the whole point of driving a legitimate tool instead of dropping malware: the adversary supplies no content for the content engine to judge. The telemetry still records everything. A process-creation record shows the image path, the command line, the parent process and the hash. The hash is clean; the command line is the interesting part, because it is where the intent lives — recursive, password-protected, delete-originals, pointed at a mapped drive. ## What the chain looks like The conviction has to come from the sequence, roughly: 1. Enumerate accessible shares and mapped drives. 2. Delete the Volume Shadow Copies, so the local restore points are gone. 3. Rewrite thousands of files rapidly, each original deleted after its encrypted replacement is written. Taken one at a time these are ambiguous. Backup software enumerates shares. Administrators occasionally clear shadow copies to reclaim disk. Archiving tools legitimately write many files fast. Taken together, on one process tree, within minutes, they are not ambiguous at all. ## Get the direction of the claim right A clean hash verdict proves the file matches a known-good release. It does not prove the *use* was authorised, and it is not a statement about the activity at all. Likewise, the absence of a YARA match proves that no rule you have describes this content — not that the content is safe, and certainly not that nothing malicious happened. Candidates who read "no detection" as "no problem" invert this, and it is the most common wrong answer in this area. The reverse inversion matters too: an artefact you can observe (a hash, a file name, an IP address) is an *indicator*; the way an adversary operates (drive a signed archiver to encrypt a share) is a *behaviour*. Indicators are cheap to change; the behaviour is what the operator actually needs to do. ## Why static matching still ships in every product It is cheap, deterministic and near-silent. It can act *before* execution rather than mid-chain, it produces almost no false positives, it lets you sweep an estate for a family you already know, and YARA in particular can scan memory, where an in-memory payload that never touched disk becomes visible. Nobody removes it; it is simply the wrong instrument for a legitimate tool being misused. ## What this means on a small team On a mid-size Windows file server estate run by one analyst with no overnight cover, this distinction is not academic. If the estate's confidence rests on "our AV is clean everywhere", the first evidence of this attack will be users unable to open files in the morning. The behavioural engine, running unattended, is the only control positioned to act at 02:00 — and everything the team can promise about recovery depends on what that engine convicted and how quickly.
- The console shows no static detection on that archiver. What does that tell you about whether it was used maliciously?Nothing. A clean static verdict says the file matches known-good content; it makes no claim about how the file was driven. The evidence about use lives in the command line, the parent process, the timing and the file-write pattern. Treating an absent match as exoneration is how this class of attack runs for hours unchallenged.
- If YARA cannot see this, where does it still earn its place in a SOC?Scanning content rather than conduct: sweeping collected files or a memory image for a family you have already characterised, catching an in-memory payload that never touched disk, and triaging a large collection of suspect files quickly. It answers "is this the thing we know about", which is a different and still useful question.
- Which single field in that process-creation record carries the most investigative value here?The command line. The image, the signer and the hash all say "legitimate archiver"; the command line says recursive, encrypted, delete-originals, against a mapped share. That is why command-line capture matters — on Windows, Sysmon Event ID 1 always carries it, while the native 4688 event carries it only if audit policy was configured to include it.
A hash check is a doorman with a photo of a known burglar. The archiver is a locksmith with valid ID and a work order, so the photo never matches; you only learn anything by watching what he does once he is inside.
saying these in an interview costs you the question
- Insists the file must be malware because it encrypted data
- Reads a clean hash verdict as proof the activity was benign
- Thinks YARA is a log rule that runs over events
- Assumes a valid code signature means the use was authorised
- Says the attack was undetectable because AV was clean