Skip to content

Maltego and OSINT Graphs

After collecting domains, subdomains, IPs, emails, people, and leaks, the challenge is to connect them: to see that this email belongs to this person, who uses this username, who registered this domain, which resolves to this IP, which is in this range. Maltego is the reference tool for building that relationship graph visually, automating collection and surfacing connections that would go unnoticed in a text list.

  • Entity: a node (a domain, an email, a person, an IP, a phone number).
  • Transform: an automated query that, from an entity, discovers related ones (from a domain → its subdomains; from an email → which breaches it’s in; from a person → their accounts).
  • Graph: the canvas where entities connect based on what transforms discover.
1. You start with a seed entity (the target domain)
2. You run transforms: domain -> subdomains, DNS, emails, WHOIS
3. On the results, more transforms: email -> person -> accounts -> breaches
4. The graph reveals relationships: "this domain and that one share a registrant"
5. You pivot on the most promising nodes
# built-in and community (Transform Hub)
DNS/WHOIS, Shodan, VirusTotal, HaveIBeenPwned, crt.sh,
social networks, PassiveTotal, etc.
# many require the services' API keys

Maltego CE (Community Edition) is free with limits; paid tiers expand transforms and results.

SpiderFoot automates mass OSINT (200+ modules) with report/graph
recon-ng modular CLI recon framework (Metasploit-style for OSINT)
theHarvester fast collection (emails/hosts) that feeds the graph
Maltego CaseFile manual graphs without transforms (organize what's collected)

SpiderFoot and recon-ng cover much of the same ground automatically and scriptably; Maltego excels at visualization and interactive pivoting.

  • When recon accumulates so much information that you need to see the relationships (people↔emails↔domains↔infra).
  • To present OSINT findings clearly in a report.
  • To discover non-obvious connections (domains sharing a registrant, shared infra, employees reusing usernames).

Transforms query third-party services (passive), but some may touch the target or consume attributable API keys. Respect scope, review what each transform does before running it en masse, and remember that accumulating personal data demands ethical/legal care.

The same graph an attacker builds, defense can build over its own organization to see its exposure surface: which domains, emails, leaks, and relationships are publicly visible, and reduce what shouldn’t be. It’s Attack Surface Management with a graph approach.

How a seed becomes attack surface by chaining transforms:

[domain] corp.com
--(DNS/crt.sh)--> [subdomains] vpn.corp.com, dev.corp.com, mail.corp.com
--(WHOIS)--> [registrant] "IT Admin <admin@corp.com>" + 3 other domains on the same email
--(theHarvester)--> [emails] first.last@corp.com (deduced format)
--(HaveIBeenPwned)->[breach] admin@corp.com appears in a leak
--(social)--> [person] the admin's profile -> a username reused across several sites
Result: from "a domain" to "an admin with potentially reused credentials
and 3 sibling domains nobody had inventoried".

The graph’s value is seeing the non-obvious connection: that two domains share a registrant, or that an employee reuses the same username, jumps out on the canvas and is lost in a text list.

A well-built graph feeds the next phases directly:

  • Understand entities, transforms, and the graph
  • Start from a seed (domain) and expand with transforms
  • Connect domains ↔ emails ↔ people ↔ infra
  • Integrate sources (Shodan, HIBP, crt.sh, WHOIS) via transforms
  • Pivot on the most promising nodes
  • Complement with SpiderFoot/recon-ng for automation
  • Export the graph for the report
  • Review each transform’s OPSEC before running it