exifLooter is a Go-based OSINT utility that scans images, URLs, and directories for EXIF GPS metadata and maps findings to OpenStreetMap, built for authorized bug bounty and security assessments.
| Tool | aydinnyunus/exifLooter — Go CLI that finds geolocation data in EXIF metadata across image files, directories, and piped URL lists |
| Category | OSINT / metadata extraction |
| Primary Use | Detecting unstripped GPS EXIF metadata in publicly hosted images during authorized bug bounty programs and privacy audits |
| Safe Use | Use only on assets within the scope of authorized bug bounty programs, your own infrastructure, or defensive privacy audits; the README cites Bugcrowd and Hackerone reports as the intended model |
| Telemetry Note | The tool only reads publicly accessible images; defenders can detect bulk EXIF scraping as anomalous fetch patterns against image hosts, and can prevent the underlying issue by stripping EXIF on upload |
exifLooter addresses one of the oldest and still-persistent privacy leaks on the web: images published with their EXIF metadata intact, including GPS coordinates embedded by cameras and phones. Written in Go and sitting at roughly 498 stars under an Apache-2.0 license, the project wraps the venerable exiftool in a fast CLI that can sweep single files, entire directories, or streamed URL lists and surface geolocation data automatically. The framing throughout the README is explicitly bug-bounty oriented — the author links real Hackerone and Bugcrowd reports where unstripped EXIF geolocation was paid out as a valid finding. For authorized testers, that makes this a reconnaissance time-saver rather than an attack tool: it automates a check you could do by hand with exiftool alone.
Architecturally, exifLooter is a thin but well-conceived orchestration layer over exiftool. The README is explicit about the dependency: the binary must be on your PATH for the tool to function. What the Go layer adds is scale and ergonomics — recursive directory traversal, URL piping, parallel processing implied by the pipeline examples, and structured output that highlights exactly the GPS tags a bug bounty hunter cares about. This is a sensible design choice; rather than reimplementing EXIF parsing (a notoriously fiddly format with hundreds of vendor quirks), the author delegates parsing to the industry-standard tool and focuses the Go code on workflow, input handling, and reporting.
Installation is straightforward and covered by two paths. The Go-native route is go install github.com/aydinnyunus/exifLooter@latest, and the README also documents first-class Kali Linux packaging via sudo apt install exiflooter — a signal of genuine adoption, since Kali's maintainers curate their repository. That packaging milestone is arguably the most interesting metadata point about this project: it has crossed from personal GitHub tool to distribution-shipped utility, which usually correlates with maintenance discipline and community validation. The topics list (osint, bug-bounty, exif-metadata, redteam) confirms the intended audience is professional recon workflows.
Basic usage follows the expected single-binary pattern. exifLooter --image image.jpeg analyzes one file, while -d images/ sweeps a directory. The interesting mode for anyone running large engagements is the pipe interface: cat urls | exifLooter --pipe consumes a newline-delimited list of image URLs. The README shows a canonical recon chain that will feel familiar to anyone who has worked web bug bounties: take a subdomain list, pass it through waybackurls, filter the results for image extensions with grep "jpeg\|png\|jpg", and feed the surviving URLs into exifLooter. That pipeline pattern is where the tool earns its keep — historical archives like the Wayback Machine frequently preserve images that organizations have since stripped or removed from live sites.
The OpenStreetMap integration is the feature that distinguishes exifLooter from a bare exiftool invocation. With --open-street-map, extracted GPS coordinates are converted into an OpenStreetMap URL, dropping the operator straight into a map view of the location. For report writing this is genuinely useful: instead of copy-pasting decimal coordinate pairs and manually converting them, the tester gets a shareable link that a triage team can click. It also lowers the barrier to verifying that coordinates are real and meaningful rather than zero-value junk tags, which is a common false positive in EXIF analysis.
Notably, the tool also works in the defensive direction. The --remove flag strips metadata from images — exifLooter --remove --image image.jpeg for single files or --remove --directory images/ in bulk. This is the remediation half of the equation, and its presence suggests the author understands both sides of the problem. A blue team or engineering team auditing a web application's upload pipeline can use the same binary first to prove that leaking images exist and then to sanitize the affected assets while the server-side fix (stripping EXIF on upload) is implemented. Few recon tools include their own mitigation mode, and it is a thoughtful touch.
The economics documented in the README are worth noting for anyone triaging whether this class of finding matters. The author links a Hackerone report resolved at $200 and a Bugcrowd writeup (published on Medium by the reporter) resolved at $500, both for EXIF geolocation exposure on uploaded images. These are real, accepted severity ratings under Bugcrowd's Vulnerability Rating Taxonomy — the screenshots in the README show P3 and P4 classifications. For bug bounty program managers, this is a reminder that metadata leakage sits firmly in the paid-finding tier, not the informational tier, when the affected asset is in scope and the platform fails to sanitize uploads.
From a defender's perspective, exifLooter is best understood as a visibility check on your own upload pipelines. The detection and prevention story is well understood: strip EXIF and related metadata server-side at upload time (never trust client-side stripping), and monitor for bulk image-fetching patterns against public asset hosts if you are concerned about enumeration. The existence of packaged tooling like this simply means the check is now cheap enough that every casual scanner will run it, so unstripped images should be treated as discovered-assumed rather than obscure. If your platform serves user uploads from a CDN that preserves original bytes, this is a control worth verifying quarterly.
There are honest limitations worth stating. The README is somewhat thin on output-format details — there is no documented JSON export mode, which limits integration into automated reporting pipelines; results appear to be terminal-oriented based on the screenshots. The roadmap section simply defers to the GitHub issues tracker, so future direction is opaque. The exiftool dependency, while pragmatically sound, means deployments must keep that binary current too, since exiftool itself has had parsing vulnerabilities historically. None of these are disqualifying for a recon utility, but operators building pipelines around it should test output stability.
In the taxonomy of security tooling, exifLooter occupies the OSINT-automation niche alongside tools like waybackurls and other recon-chain utilities — it does not exploit anything, it merely aggregates publicly available metadata and makes a manual check scalable. Its value is the confluence of three things: pipeline-friendly input, OpenStreetMap visualization of findings, and a bundled remediation mode. For authorized professionals running privacy audits or bug bounty reconnaissance against in-scope assets, it compresses a tedious manual workflow into a single command, and its Kali packaging means it will keep showing up in standard recon suites. Treat it as a reminder that metadata hygiene is a first-class finding class, not an afterthought.
aydinnyunus/exifLooter.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.