GHunt for Google account and email OSINT investigations

GHunt is a Python-based OSINT framework that queries Google's internal endpoints to enumerate public metadata about email addresses, Gaia IDs, Drive files and BSSIDs during authorized investigations.

Tool	mxrch/GHunt — offensive Google framework focused on OSINT, usable as CLI and Python library
Category	OSINT / reconnaissance framework
Primary Use	Enumerating public Google account metadata via ghunt email, ghunt gaia, ghunt drive, ghunt geolocate and ghunt spiderdal during authorized investigations
Safe Use	Authorized contexts only: penetration tests with written scope, criminal investigations, personal research on your own accounts, and open-source projects, per the AGPL license terms
Telemetry Note	All queries originate from the authenticated Google session configured via ghunt login, so activity is visible to Google as logged-in API traffic from that account; defenders should watch for unusual internal-endpoint access patterns tied to a single account

GHunt has long been one of the reference names in the Google OSINT space, and the v2 rewrite documented in the current README signals a deliberate architectural maturation. The project, hosted at mxrch/GHunt with roughly 19,500 stars and written in Python, describes itself as an "offensive Google framework, designed to evolve efficiently," currently focused on OSINT but explicitly architected so that any Google-related use case can be layered on top. That framing matters for practitioners: this is not a single-purpose script but a modular framework where each capability is a self-contained subcommand. The README also points to a hosted online version at osint.industries for analysts who prefer not to run the tooling locally, though the CLI and library remain the primary interface for most users.

The feature list in the README is compact but revealing. GHunt v2 offers CLI usage with modules, use as a Python library, a fully async implementation, JSON export, and a dedicated browser extension to ease authentication. The async claim is the most interesting architectural detail: it suggests the framework was rebuilt around asyncio-style concurrency, which matters when an investigator needs to process multiple identifiers without serial round-trips slowing enumeration. The JSON export via --json integrates cleanly with downstream tooling such as feeders for Maltego, custom enrichment pipelines, or simple evidence packaging for a report.

Installation follows the modern pipx pattern, which the README specifically promotes because it isolates GHunt in its own virtual environment and avoids dependency conflicts with other tooling in the operator's environment. The two-command flow (pipx install ghunt after installing pipx itself) is the recommended path. Notably, the README warns that pipx is unsuitable if you intend to import ghunt as a library, because the venv isolation prevents a clean import from your own project; in that case a plain pip3 install ghunt is the correct approach, with usage examples available in the examples/ directory of the repository.

Authentication is where GHunt departs from most OSINT tooling, and the README devotes significant attention to it. The ghunt login command presents three options: putting GHunt into listening mode via the companion extension, pasting base64-encoded cookies, or entering cookies manually. The companion approach uses a browser extension called GHunt Companion, published on both the Firefox and Chrome extension stores, which handles the cookie extraction dance on behalf of the operator. This design exists because GHunt authenticates to Google as a logged-in session rather than scraping anonymously, meaning every query is tied to an account the investigator controls. For authorized work, that is actually a compliance feature: the investigative activity is attributable and auditable on the account you dedicate to it.

The module surface is enumerated directly in the usage help: email, gaia, drive, geolocate, and spiderdal. The email module retrieves information on an email address, which in Google terms means resolving the address to its underlying Gaia ID and whatever profile data Google exposes for it. The gaia module runs the inverse operation, taking a Gaia ID — Google's stable internal account identifier — and pivoting back to associated public information. This bidirectional mapping between email and Gaia ID is the core tradecraft value of the tool, because identifiers leak across contexts: a Gaia ID recovered from a document revision or a photo's metadata can be resolved back to an account, or vice versa, during attribution work on an authorized investigation.

The drive module gets information on a Drive file or folder, which is useful when a shared document link surfaces during an engagement and the investigator needs to know what the object reveals about its owner without interacting with the content itself. The geolocate module resolves a BSSID to a location, complementing the Google-centric modules with a wireless-access-point lookup — the kind of query relevant to verifying geographic claims in investigations. Finally, spiderdal finds assets using Digital Assets Links, Google's mechanism for declaring relationships between sites and apps. In an authorized recon workflow this is a legitimate attack-surface mapping technique: DAL statements declared in assetlinks.json files expose the app and web properties an organization has formally linked, which is precisely the sort of inventory an assessor builds during scoping.

Output handling is uniform across the modules: the --json flag works with email, gaia, drive, and geolocate, as demonstrated by ghunt email <email_address> --json user_data.json. Consistent structured export means results can be diffed over time, archived as evidence, or piped into correlation tooling without ad-hoc parsing. For a team running long-running investigations, that reproducibility is more valuable than any single module's output.

For developers, the README points to a wiki for documentation and an examples/ directory in the repository, and explicitly invites contributions. The library mode means GHunt can be embedded into larger automation — for example, an internal enrichment service that takes identifiers from a ticketing system and returns structured Google-side metadata. The AGPL license is worth flagging for commercial teams: the author states it must be respected, and the README constrains usage to "personal, criminal investigations, pentesting, or open-source projects." Any consultancy planning to integrate GHunt into a product should get legal review of the AGPL implications first.

The disclaimers section is unusually explicit, and operators should mirror that discipline. The author states the tool is for educational purposes and disclaims responsibility for use, then adds the practical scope guidance noted above. In an authorized-professional context, the correct posture is to run GHunt only against identifiers within your engagement scope, your own accounts, or open-source research targets where the activity is lawful in your jurisdiction. Pivoting from a Gaia ID to profile data is exactly the kind of action that looks innocuous technically but sits squarely in personal-data territory under regimes like GDPR.

From a defensive perspective, GHunt is a useful purple-team artifact precisely because it documents what Google exposes passively. Defenders briefing executives or writing awareness material can use the tool's module list as a checklist of exposure channels: photo metadata leaking Gaia IDs, over-shared Drive links, assetlinks.json enumerating the organizational app estate. Hardening guidance follows directly — audit what your organization's public Drive objects reveal, understand which internal identifiers your documents emit, and treat any public identifier as permanently attributable to your accounts.

Telemetry-wise, every GHunt query runs through the authenticated Google session established at ghunt login, so from Google's side the activity presents as normal logged-in client traffic against internal endpoints. There is no anonymous scraping mode in the documented flow, which concentrates risk on the investigator's account: anomalous volumes or patterns on a single account can draw enforcement action against that account. Teams should use dedicated, scoped accounts for investigative work and document that choice in their methodology. For defenders, the lesson is different: the data GHunt retrieves was already public; the tool simply automates collection, so remediation lies in reducing exposure at the source rather than detecting the collector.

Official project repository for mxrch/GHunt.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.