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/python3the 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 liketar,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 tools —
certutil.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 likepython3,curl, orgiton Linux/macOS. - Package managers and anything installed with them —
apt,dnf,yum,pacman,brewthemselves 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#
- Hash the suspect binary (
sha256sum/Get-FileHash, orhashwatch verify <file>). - Catalogued product with a LOTL chip? Compare against the dashboard/feed values.
- OS-shipped binary? Use
POST /api/v1/intel/lookupagainst the BinTrust corpus. - A mismatch or
unknownon a binary claiming to be an OS/vendor file is a strong tamper/masquerading signal - escalate.