Enrichment and pivoting
From one phishing domain to the attacker's wider infrastructure: passive DNS history, WHOIS and RDAP, certificate transparency logs, ASN and hosting context, VirusTotal-style relationship pivots, clustering on fingerprints like JARM and favicon hashes, and the OPSEC rules that stop your lookups from tipping off the attacker or leaking victim data.
01From one indicator to a cluster
- Enrich an indicator with passive DNS, WHOIS/RDAP, certificate transparency and ASN data
- Pivot across shared attributes to find infrastructure the attacker has not used against you yet
- Judge which pivots are strong and which create false clusters
- Look things up without breaking OPSEC or leaking data
Enrichment adds context to an indicator: who registered it, where it is hosted, what it has resolved to. Pivoting uses an attribute found during enrichment to find other indicators that share it: same name servers, same certificate, same unusual server fingerprint. A good pivot turns one phishing domain into the twelve the actor registered last week, so you can block them before the next wave.
- THREAT
- Live flow
02Passive DNS and WHOIS/RDAP
Passive DNS (pDNS) is a historical database of DNS answers collected from sensors at resolvers. Normal DNS tells you what a name resolves to now; passive DNS tells you what it resolved to, and when, and lets you ask the reverse question: which names have pointed at this IP? Providers include DomainTools (Farsight DNSDB), CIRCL, and the pDNS views inside VirusTotal and most TIPs.
rrname rrtype rdata first_seen last_seen count
cyart-sso-login.com A 203.0.113.80 2026-11-09T14:02:11Z 2026-11-13T22:41:07Z 1,284
cyart-sso-login.com NS ns1.dnsowl.example 2026-11-09T13:55:40Z 2026-11-13T22:41:07Z 97
-- reverse lookup on 203.0.113.80 (A records only)
m365-auth-verify.net A 203.0.113.80 2026-11-08T09:12:55Z 2026-11-13T21:03:19Z 640
cyart-hr-portal.com A 203.0.113.80 2026-11-10T07:44:02Z 2026-11-13T18:20:51Z 212
bakery-ordering.example A 203.0.113.80 2025-03-02T10:00:00Z 2025-06-30T23:59:10Z 9,806Read the time windows, not just the names. The three lookalike domains overlap in the same week; the bakery site left the IP more than a year earlier, so it is an earlier tenant of a re-rented VPS address, not part of the campaign. Reverse lookups on shared hosting return thousands of unrelated sites; a reverse lookup is only a strong pivot when the IP hosts a handful of names.
# RDAP: the JSON successor to WHOIS (rdap.org redirects to the right registry or registrar)
curl -sL https://rdap.org/domain/cyart-sso-login.com | jq '{
name: .ldhName,
events: ([.events[] | {(.eventAction): .eventDate}] | add),
nameservers: [.nameservers[].ldhName],
registrar: [.entities[] | select(.roles | index("registrar")) | .vcardArray[1][] | select(.[0] == "fn") | .[3]]
}'
# Example output
{
"name": "CYART-SSO-LOGIN.COM",
"events": { "registration": "2026-11-09T13:51:22Z", "expiration": "2027-11-09T13:51:22Z", "last changed": "2026-11-09T13:55:01Z" },
"nameservers": ["NS1.DNSOWL.EXAMPLE", "NS2.DNSOWL.EXAMPLE"],
"registrar": ["Example Registrar, LLC"]
}| WHOIS/RDAP field | Pivot value | Caveat |
|---|---|---|
| Registration date | Domains registered hours before a campaign are suspicious; group by date | Many legitimate domains are new too |
| Registrar | Actors reuse registrars that accept crypto or ignore abuse reports | Big registrars hold millions of domains; weak on its own |
| Name servers | Unusual or self-hosted name servers are a strong cluster key | Shared DNS hosting (Cloudflare) is useless as a pivot |
| Registrant email or organisation | Historically the best pivot of all | Mostly redacted since GDPR (2018) or hidden behind privacy services |
RDAP (Registration Data Access Protocol) returns structured JSON over HTTPS with standard fields, instead of free-text WHOIS that every registrar formats differently. ICANN ended the requirement for generic TLD registries and registrars to run WHOIS in January 2025, so scripts that parse port-43 WHOIS output should move to RDAP.
03Certificate transparency and hosting context
Every publicly trusted TLS certificate must be logged in certificate transparency (CT) logs, public append-only ledgers first defined in RFC 6962, or mainstream browsers reject it. So when an actor gets a certificate for a phishing site, its names appear in public, often before the first email is sent. crt.sh and Censys index these logs.
# Every certificate naming a brand lookalike (%25 is a URL-encoded % wildcard)
curl -s 'https://crt.sh/?q=%25cyart%25&output=json' \
| jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' \
| sort -u | tail -5
2026-11-09T12:58:31 C=US, O=Let's Encrypt, CN=R11 cyart-sso-login.com
2026-11-09T12:58:31 C=US, O=Let's Encrypt, CN=R11 okta-cyart-verify.com
2026-11-10T06:40:17 C=US, O=Let's Encrypt, CN=R11 cyart-hr-portal.com
2026-11-12T19:03:44 C=US, O=Let's Encrypt, CN=R11 login.cyart-careers.com
2026-11-13T08:15:02 C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1 www.cyart.io
# IP to ASN and hosting (Team Cymru)
whois -h whois.cymru.com " -v 203.0.113.80"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
64501 | 203.0.113.80 | 203.0.113.0/24 | NL | ripencc | 2019-04-11 | EXAMPLE-VPS-HOSTING, NLTwo things jump out. The list contains okta-cyart-verify.com and login.cyart-careers.com, which have not appeared in any email yet: block them now and add them to the mail filter. And the hosting is a cheap VPS provider, which with a fresh Let's Encrypt certificate and a two-day-old domain fits a disposable phishing kit. The DigiCert line is your own real site, a reminder to filter known-good results.
- ASN (autonomous system number) tells you who routes the IP. Residential ISP, cloud provider, VPS host or "bulletproof" hosting (providers that ignore abuse complaints) each change how you read the indicator.
- Cloud and CDN IPs are shared: an attacker's IP in a big cloud range today belongs to someone else next week. Weight them low for blocking and short for expiry.
- CT monitoring for your own brand is one of the cheapest early warnings a SOC can run: alert on any new certificate containing your brand name that you did not request.
04Relationship pivots and infrastructure clustering
VirusTotal-style platforms store relationships between indicators: a file's contacted domains and IPs, a domain's resolutions and communicating files, files that share an import hash. Pivoting across those edges is how one sample becomes a family. Clustering goes further and groups servers by fingerprints that are hard to share by accident.
| Pivot | What it is | Strength |
|---|---|---|
| Same TLS certificate (SHA-256) | One certificate deployed on several servers | Strong, unless it is a shared CDN or hosting certificate |
| JARM / JA4S | Fingerprint of how a server answers TLS handshakes | Medium: identifies a server stack, which may be common (default nginx) |
| Favicon hash | MurmurHash3 of the site's favicon, searchable in Shodan as http.favicon.hash | Strong for phishing kits and C2 panels with custom icons; weak for default icons |
| HTTP response shape | Status, header order, body hash of a default page | Good for C2 frameworks with distinctive default responses |
| SSH host key | Servers cloned from one image share a host key | Strong: rarely shared by accident |
| Import hash, TLSH, ssdeep | Structural or fuzzy file similarity | Good for grouping samples of one family; noisy across packers |
| Same IP or name server | Shared hosting attributes | Weak alone; strong only on low-population infrastructure |
Use a two-attribute rule: do not merge infrastructure into a cluster on one shared attribute. The same JARM plus the same favicon plus registration within the same 48 hours is a cluster; the same JARM alone is often just the same web server software.
Shared infrastructure creates convincing but wrong links: CDN edge IPs, parking pages that serve one page for a million domains, sinkholes run by researchers, default certificates and popular registrars. One wrong merge can attribute a campaign to the wrong actor or block a partner. Record why each node joined the cluster, so the reasoning can be checked.
05OPSEC when looking up indicators
Your lookups are observable. Attackers watch their own infrastructure, and some build tripwires for analysts. OPSEC (operations security) here means investigating without revealing that you are investigating, and without leaking your own data.
- Passive first: passive DNS, CT, RDAP and existing scan data (Shodan, Censys) never touch the attacker's server.
- Never browse attacker infrastructure from the corporate network. The request carries your egress IP and often a user agent that identifies your organisation. If you must interact, use an isolated analysis environment with non-attributable egress.
- Do not resolve unique attacker subdomains from corporate DNS. Phishing links often embed a per-victim token (
a7f3.track.example); resolving it can tell the actor the email was opened and investigated. - Search, do not upload. Uploading a file to VirusTotal or a public sandbox shares it with subscribers. An internal document or a targeted sample can reveal the victim, and tells the actor their tool has been found. Search the hash first.
- Defang everything you write (
hxxps://cyart-sso-login[.]com) so tickets and chats do not create clickable links or trigger link scanners that fetch the URL.
"I enrich passively first: passive DNS for history, RDAP for registration, CT for sibling names, ASN for hosting context. I only merge infrastructure on two or more independent attributes, and I never touch the attacker's servers or upload victim files from anything attributable to us."
CTI and SOC interviews often give you one domain and ask "what would you do with it?". Walk the enrichment sources in order, name a pivot and its weakness (reverse IP on shared hosting), and mention OPSEC unprompted. Candidates who say "I'd open it in a browser" lose the room.
A colleague wants to upload a suspicious attachment from the CFO's mailbox to a public sandbox to see what it does. What is the main risk?
Q1Which pivot do you trust most?+
A shared, non-default TLS certificate or SSH host key across servers, because they are rarely shared by accident. I still want a second, independent attribute before I call it one cluster.
Q2How do you handle an IP that is a cloud provider address?+
Treat it as short-lived and shared: alert on it for the incident window, block only with a short expiry, and pivot on things the actor controls (domains, certificates, fingerprints) rather than the IP itself.
Q3What does passive DNS give you that a normal DNS lookup does not?+
History and the reverse direction: every name an IP has served and every IP a name has used, with first and last seen times. A live lookup only gives the current answer and touches the actor's name servers.