Living-off-the-Land (LOTL) verification#

Attackers increasingly avoid malware and instead abuse legitimate binaries already on the system - the technique catalogued in GTFOBins (Unix) and LOLBAS (Windows). Because the tool itself is legitimate, the defender’s question flips from “is this file known-bad?” to:

“Is this certutil.exe / bash / python3 the genuine vendor binary - or a swapped, trojanized copy?”

HashWatch answers that with verified known-good hashes, through two complementary surfaces.

Not every catalogued binary is downloadable — and that’s expected. This is the single most important thing to understand about LOTL coverage. The large majority of GTFOBins/LOLBAS entries are not distributed as standalone files at all: they ship as part of the operating-system image (certutil.exe, rundll32.exe, the Unix coreutils and shells like tar, awk, bash) or are installed by a distribution’s package manager — and the package managers themselves come with the OS (apt, dnf, yum, pacman, brew). There is no vendor “downloads” page and no first-party per-file checksum to fetch for any of these, so they do not appear on the daily dashboard. HashWatch instead verifies them by hash lookup against a reference corpus (Surface 2). Only the minority of catalogued tools that publish an official standalone release show up on the dashboard (Surface 1). If a LOLBAS/GTFOBins tool isn’t on the dashboard, that’s why — check it with the lookup instead. Both surfaces answer the same question (“is this the genuine binary?”); they just apply to different classes of tool.

1. Catalogued tools with a standalone release — the dashboard#

Products on the public dashboard whose binaries appear in GTFOBins/LOLBAS carry a LOTL chip - interpreters and dual-use tools such as Python, PowerShell, Node.js, PHP, Perl, Ruby, Vim, Nmap, curl, SQLite, 7-Zip, Git, OpenSSH for Windows, Docker, and kubectl. For these, HashWatch tracks the vendor’s official releases daily, so you can compare a suspect copy’s SHA-256 directly (dashboard, pull feeds, or the hashwatch CLI).

Some interpreters (PHP, Perl, Ruby, curl) only publish first-party binaries for Windows - their macOS/Linux builds ship through OS package managers and are covered by the lookup API below instead.

2. OS-shipped & package-manager binaries — the lookup API#

Most LOLBAS/GTFOBins entries ship inside the operating system or arrive through a package manager, so there is no standalone file to download and hash daily:

  • Windows System32 toolscertutil.exe, mshta.exe, rundll32.exe, wmic.exe, … (part of the Windows image; Microsoft publishes no per-file hash channel for them).
  • Unix coreutils, shells & interpreters shipped by the distro/bin/bash, tar, awk, sed, and the OS-provided builds of tools like python3, curl, or git on Linux/macOS.
  • Package managers and anything installed with themapt, dnf, yum, pacman, brew themselves are OS-bundled, and the packages they install come from distro repos, not a single vendor download.

No vendor publishes a first-party per-file hash for these, so they are covered by HashWatch’s BinTrust corpus - the NIST NSRL reference set (~72 million hashes) plus every vendor release HashWatch has ever recorded:

curl -s -X POST https://api.hashwatch.us/api/v1/intel/lookup \
  -H "X-API-Key: $HASHWATCH_API_KEY" -H "Content-Type: application/json" \
  -d '{"hashes":["<sha256-of-the-suspect-binary>"]}'

A known_vendor_release or known_file classification means the binary matches a catalogued legitimate build; unknown means it does not appear in any reference set - treat a supposed OS binary that returns unknown as suspect. Lookup requires a basic API key - see Tiers.

Triage workflow for an IR analyst#

  1. Hash the suspect binary (sha256sum / Get-FileHash, or hashwatch verify <file>).
  2. Catalogued product with a LOTL chip? Compare against the dashboard/feed values.
  3. OS-shipped binary? Use POST /api/v1/intel/lookup against the BinTrust corpus.
  4. A mismatch or unknown on a binary claiming to be an OS/vendor file is a strong tamper/masquerading signal - escalate.