← 02 — Articles

Checking a file hash without leaking the file

Threat intel6 min read

A suspicious file is the indicator that leaks the most when handled carelessly. An IP address or a domain is already public; a file may be a customer contract with a macro in it, an internal tool nobody recognized, or a sample written for your organization alone. The good news is that you rarely need to share the file to learn about it. Its hash is enough to ask most questions, and a hash reveals nothing about the content.

This is part four of the OSINT series. The ground rules, including why every submission is a disclosure, are in part one.

Get a hash you can trust

Compute the hash yourself from the file, not from a filename or a ticket. SHA-256 is the default every repository understands:

Get-FileHash -Algorithm SHA256 .\invoice_0921.exe
sha256sum invoice_0921.exe

You may not need the file at all. If Sysmon runs with hashing enabled, process creation (event 1), driver loads (event 6) and image loads (event 7) already carry the hash in the Hashes field, along with the full path, parent process and command line. Searching your SIEM for the hash also tells you how many machines have the same file, which is often the most important answer of the day. Sysmon without drowning covers a baseline that records them.

Some repositories and older reports still use MD5 or SHA-1. They are fine as lookup keys, but do not rely on them to prove two files are identical: both have practical collision attacks.

Before you look anything up: check what is local

Three quick local checks often answer the question before OSINT does:

  • Is it signed, and by whom? Get-AuthenticodeSignature .\file.exe shows the signer and whether the signature is valid. A valid signature from a vendor you use changes the conversation; an invalid or missing one on something posing as a vendor tool does too.
  • What type is it really? file invoice_0921.exe on Linux or macOS reads the file’s magic bytes. A .pdf that is really a Windows executable needs no further enrichment to be suspicious.
  • Where did it come from? On Windows, files downloaded through a browser usually carry a Zone.Identifier alternate data stream with the source URL: Get-Content .\file.exe -Stream Zone.Identifier. That URL goes straight into part three.

VirusTotal: search, do not upload

Searching a hash on VirusTotal is passive: it reveals nothing that is not already there. If someone uploaded the same file before, you get the full report:

  • Detections from dozens of antivirus engines, with their detection names.
  • First submission date. A file first seen two years ago is a known quantity. One first seen an hour ago, from your country, may be the same campaign that hit you.
  • Names the file has been submitted under, and behavior from VirusTotal’s sandboxes.
  • Relations: domains and IPs it contacted, files it dropped, and parent files that contained it.
  • Similarity hashes such as ssdeep, TLSH and, for Windows executables, imphash, which link variants of the same malware even when the SHA-256 differs.

The public API allows 500 lookups per day at four per minute, for non-commercial use, which covers manual triage comfortably.

Reading detection counts

A detection ratio is not a probability. A few patterns to recognize:

Result Usual meaning
Most engines detect, with consistent family names Known malware. Use the family name to find what it does and what to look for next.
A handful of engines, generic names (Generic, Heuristic, ML, Suspicious) Could be anything: a new sample, a packed legitimate tool, an installer. Needs more context.
Detections named PUA, PUP, Adware, RiskTool, HackTool Unwanted or dual-use software: remote admin tools, password recovery utilities, bundled installers. Often a policy question rather than an incident.
Zero detections, first seen long ago, many submitters Most likely a common legitimate file.
Hash not found Nobody has uploaded it. Not evidence of anything on its own.

The last row matters most. Targeted malware is often unique per victim, so “not found” is exactly what a serious intrusion looks like. It is also what every internal tool and every document your colleagues wrote looks like.

MalwareBazaar: a repository of confirmed malware

MalwareBazaar, run by abuse.ch, is a free repository of confirmed malware samples shared for research and detection. It only accepts vetted malware — not adware, not benign files — so a hit there is a stronger statement than a few antivirus detections. Entries carry tags, the malware family, YARA matches and links to sandbox reports.

Searching by hash works in the web interface. The API needs a free abuse.ch account key; the same key works across abuse.ch’s other services such as URLhaus and ThreatFox. Do not upload to MalwareBazaar to “check” a file: its submission policy accepts only confirmed malware, and uploads are public.

Sandbox reports

Sandboxes run a file in an instrumented virtual machine and record what it does: processes, files written, registry changes, network connections. Many public sandboxes let you search existing analyses by hash, which is passive and free.

Submitting a file to a free sandbox is not. Free plans are often public: ANY.RUN’s plans page, for example, lists private analyses only for paid tiers, and its free Community plan limits files to 16 MB and runs to a 60-second timeout. Anything you detonate there should be treated as published.

Sandbox results have the same blind spot as page scanners: malware that checks for virtual machines, waits before acting or needs a specific environment may do nothing during a short run. “No malicious behavior observed” is a weak verdict.

When to upload, and when not to

Uploading a file gives you analysis and gives away the file. VirusTotal’s How it works page states that submitted file contents “may also be shared with premium VirusTotal customers”, and its Terms of Service ask you to upload only samples you are willing to share publicly. A sample built for your organization, once uploaded, can also tell its author that you found it.

Upload? When
Never Documents, spreadsheets, archives or emails that may contain your data, even with a malicious macro. Internal tools and scripts. Anything with credentials, host names or customer data.
Think first A binary from a possibly targeted intrusion. Uploading may alert the attacker before you have scoped and contained the incident.
Usually fine A commodity sample from bulk phishing with no data of yours inside, when the search came back empty and you need a verdict.

The alternatives to uploading: extract indicators locally (strings, embedded URLs, macro code with tools such as olevba from oletools), run the file in your own isolated sandbox, or share it privately with your security vendor under an agreement that covers confidentiality.

A worked order for an unknown file

  1. Compute SHA-256 from the file, or take it from Sysmon.
  2. Search your SIEM for the hash: how many hosts, since when, which parent processes?
  3. Local checks: signature, true file type, Zone.Identifier source URL.
  4. Search VirusTotal and MalwareBazaar by hash. Read first-seen dates, names and relations, not just the detection count.
  5. Search public sandbox reports by hash.
  6. Only if the answer still matters and the file contains nothing of yours: upload, choosing the service and its visibility deliberately.

Limitations

  • Hashes are exact. Change one byte and the SHA-256 is new; commodity malware is often rebuilt per campaign or per victim. Similarity hashes help, but only for files someone already has.
  • Antivirus names are inconsistent between vendors, and generic names carry almost no information.
  • A file can be harmless on its own and dangerous in context: a legitimate signed remote administration tool installed by an attacker is still an intrusion. The hash lookup will say “clean”.
  • Absence from every repository is the normal state for internal files and for targeted malware alike.

Adapting this to your environment

  • ADAPT the “never upload” list to your data: which file types in your organization routinely contain customer or personal data?
  • ADAPT your Sysmon configuration so the hashes you need are already in the SIEM, and decide which algorithm your detections and lookups standardize on.
  • ADAPT your escalation path: who decides whether a sample from a suspected targeted intrusion may leave the building?

Next and last in the series: OSINT on yourself. Corrections go to hello@entropywatch.dev.