Back to Articles

Finding Hidden Infrastructure Through Google Analytics: A Deep Dive into udon

[ View on GitHub ]

Finding Hidden Infrastructure Through Google Analytics: A Deep Dive into udon

Hook

Every time an organization embeds the same Google Analytics tracking code across multiple properties, they’re inadvertently creating a map of their entire digital footprint—and reconnaissance tools like udon know exactly how to read it.

Context

In the early days of bug bounty hunting and security reconnaissance, discovering an organization’s complete attack surface was a manual, time-consuming process. You’d find one domain, then painstakingly search WHOIS records, SSL certificates, and DNS data to uncover related infrastructure. But organizations rarely maintain perfect operational security across every property they own. A developer rushing to launch a new subdomain copies the same Google Analytics snippet from the main site. A marketing team standardizes tracking across all brand properties. Suddenly, that innocent “UA-XXXXXXX” identifier becomes a thread that, when pulled, unravels the entire digital empire.

udon emerged to automate this reconnaissance technique. Built in Go, it’s a focused OSINT tool that takes a Universal Analytics ID (the “UA-” format from Google’s legacy analytics platform) and queries multiple third-party services—Hackertarget, OSINT.sh, Site-Overview, and SpyOnWeb—to reverse-lookup every domain sharing that tracking code. It aggregates the results, outputs clean JSON or silent mode for pipeline integration, and gets out of your way. This matters because attack surface discovery isn’t just about finding subdomains of a known target; it’s about discovering the unknown: that forgotten test environment, the recently acquired company that still shares infrastructure, or the separate brand that uses the same operations team.

Technical Insight

udon Process

External Services

Query UA-ID

Query UA-ID

Query UA-ID

Query UA-ID

Domain List

Domain List

Domain List

Domain List

JSON/Text

CLI Input

UA-ID

udon Core

Hackertarget API

OSINT.sh API

Site-Overview API

SpyOnWeb API

Response Parser

Domain Aggregator

Output Handler

STDOUT

System architecture — auto-generated

The architecture of udon is deliberately minimalist, following the Unix philosophy of doing one thing well. When you execute the tool, it takes your UA-ID parameter and queries multiple separate OSINT APIs. Each service maintains its own database of website crawls where they’ve indexed tracking codes, advertising IDs, and other third-party integrations. udon doesn’t do any web scraping itself—it appears to function as an aggregation layer that normalizes responses from these heterogeneous sources.

The tool’s real value becomes apparent when you chain it with other reconnaissance utilities. The README provides a practical nuclei template that demonstrates this workflow. Here’s how you’d discover UA-IDs across a target’s infrastructure, then pivot to find related domains:

id: google-analytics-id

info:
  name: Google Analytics ID Discovery
  author: dhn
  severity: info
  tags: tech

requests:
  - method: GET

    path:
      - "{{BaseURL}}"

    extractors:
      - type: regex
        name: ua-id
        part: body
        regex:
          - "UA-[0-9]+(-[0-9]+)"

    redirects: true
    max-redirects: 5
    stop-at-first-match: true
    matchers-condition: and
    matchers:
      - type: regex
        part: body
        regex:
          - "UA-[0-9]+(-[0-9]+)"

      - type: status
        status:
          - 200

Once nuclei extracts UA-IDs from your initial target list, you pipe those directly into udon. The -silent flag strips away banner text and progress indicators, while -json structures the output for downstream processing:

udon -silent -json -s UA-33427076 | jq -c

This command produces a stream of JSON objects, each containing a domain and its source:

{"domain":"soester-anzeiger.de","source":"site-overview"}
{"domain":"wa.de","source":"site-overview"}
{"domain":"come-on.de","source":"hackertarget"}
{"domain":"wa-mediengruppe.de","source":"hackertarget"}

Notice how multiple sources return overlapping results. This redundancy is a feature, not a bug. API services have different crawl coverage, update frequencies, and historical data retention. Hackertarget might catch a domain that was recently changed, while SpyOnWeb’s historical index reveals properties that stopped using the UA-ID months ago but still share infrastructure. By querying multiple sources simultaneously, udon maximizes discovery coverage.

The source attribution in each JSON object also provides operational intelligence. If you see a domain only appearing from a single source, it might be recently added or about to be removed. Domains appearing across multiple sources are likely stable, long-term properties. This metadata helps prioritize targets during time-constrained assessments.

From a pipeline perspective, the structured JSON output integrates seamlessly with standard Unix tools. You might deduplicate domains with jq, feed them into subdomain enumeration tools, or cross-reference against scope definitions for a bug bounty program. The tool’s simplicity means there’s no complex configuration, no database to maintain, and no state to manage—it appears to function as a stateless transformer that converts UA-IDs into domain lists.

Gotcha

The fundamental limitation of udon is its complete dependency on third-party services. The tool leverages external APIs for all its functionality, with the README explicitly noting that users must agree to the Terms of Service for Hackertarget, OSINT.sh, Site-Overview, and SpyOnWeb if incorporating the tool into commercial offerings. If these services rate-limit your IP or change their API endpoints, the tool’s effectiveness is impacted. This architectural choice prioritizes simplicity over robustness, which works for ad-hoc reconnaissance but may become problematic for automated, production-grade workflows.

The more strategic limitation is the declining relevance of Universal Analytics IDs. Google deprecated UA in favor of GA4 (Google Analytics 4), and while many sites still use legacy tracking codes, this window is closing. GA4 uses measurement IDs with a different format (“G-” prefix instead of “UA-”), and the OSINT services udon queries may not have fully indexed these newer identifiers. This means udon is most effective against organizations slow to upgrade their analytics—often smaller companies, legacy applications, or neglected properties. Ironically, these are sometimes the most interesting targets from a security perspective, as technical debt often correlates with security debt. But if you’re targeting modern, well-maintained infrastructure, the UA-ID reconnaissance vector may yield little to nothing.

Verdict

Use udon if you’re conducting reconnaissance against organizations with established web presence, especially in bug bounty or red team scenarios where discovering peripheral infrastructure matters more than exhaustive coverage. It excels as part of a larger automation pipeline: run nuclei across your seed domains to extract UA-IDs, pipe those into udon to discover related properties, then feed the expanded domain list into comprehensive enumeration tools like subfinder or amass. The tool’s value multiplies when you’re dealing with holding companies, media groups, or enterprises that manage dozens of brands—exactly the scenarios where shared analytics tracking creates exploitable linkage. Skip udon if you need reliable, production-grade tooling with sophisticated error handling and monitoring, or if your targets primarily use modern GA4 implementations. Also consider limitations if you’re conducting large-scale operations where API rate limits may become a bottleneck. Finally, skip it if you need offline capabilities or work in air-gapped environments—this tool requires internet connectivity and third-party service availability.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/developer-tools/dhn-udon.svg)](https://starlog.is/api/badge-click/developer-tools/dhn-udon)