A structured first-pass triage workflow for an IP address, domain, URL, or email: gather observable facts, separate them from inference, correlate with your own logs, and decide what to do next.
The problem and the ground rules
An alert, a user report, or a log line gives you one string: an IP address, a domain, a link, or a hash. You need to decide quickly whether it deserves escalation. This guide describes a first-pass triage that uses only public information. It will not prove an indicator is malicious. Its purpose is to collect observable facts, record how confident you are in each conclusion, and point you to the right next step.
- Authorization. Investigate only with permission and within your organization's rules. Looking up public records is passive; actively probing someone else's systems is not.
- Observe, then infer. "The domain was registered four days ago" is an observation. "The domain is a phishing site" is a conclusion that needs more evidence. Keep them separate in your notes.
- Do not visit suspicious URLs from a work machine. Use tools that fetch headers without rendering the page, such as the URL / Domain Analyzer.
- Defang when you share. Write
hxxps://bad-example[.]comin tickets and chat so nobody clicks it by accident, and restore the real form only when you analyze it.
Step 1: Classify the indicator
Paste the indicator into the IOC Analyzer. It detects whether it is an IPv4 or IPv6 address, a domain, a URL, or an MD5, SHA-1 or SHA-256 hash, and runs the first lookups for that type. For a hash it only identifies the type: it will not tell you whether a file is malicious, because that needs a reputation service you have to consult separately.
Step 2a: If it is an IP address
- Who runs the network? The IP Lookup gives the ASN, organization and ISP. A cloud or hosting provider suggests a server; a consumer ISP suggests a home or mobile user; a VPN or proxy operator suggests anonymization. This is context, not intent.
- Is it a public address at all? Private, loopback and link-local ranges (see the IANA registry) are internal and are not looked up.
- Reverse DNS. The Reverse DNS tool shows the owner-chosen hostname. Treat it as a claim, and confirm it by resolving the name forward and checking it returns the same address.
- Reputation. IP Reputation shows whether the address is a known Tor exit node and, where the site operator has configured a provider, abuse reports, each labeled with source and time. A clean result does not prove safety; a listing does not prove malice. Shared addresses and recently reassigned ones accumulate reports for activity that is no longer theirs.
- Location is a rough hint. Do not base decisions on city-level geolocation.
Step 2b: If it is a domain or URL
- Age and registrar. The WHOIS / RDAP Lookup shows the registration date. Domains registered days before an attack are over-represented in phishing and malware campaigns, so recency is a reasonable lead, but new legitimate domains appear constantly.
- DNS. Look at the records with the DNS Lookup: where it points, what the name servers are, whether it has mail records. Very short TTLs or many changing addresses can indicate infrastructure designed to move quickly, though CDNs and load balancers do this legitimately.
- Certificate. The SSL/TLS Checker shows the issuer and issue date. Free certificates are issued to criminals and legitimate sites alike, so a valid padlock says nothing about trustworthiness; but a certificate issued hours ago on a domain that is days old fits a newly built site.
- URL structure and behavior. The URL / Domain Analyzer lists potentially suspicious characteristics (raw IP host, Punycode, odd port, embedded credentials, many subdomains, long redirect chains) and shows where redirects lead. Read the hostname from right to left: the registrable domain at the right is the part someone actually controls. Words such as "secure" or the name of a bank placed in front of it are just subdomains.
- Hosting. Take the address the domain resolves to and repeat the IP steps above.
Step 3: If it came by email
Open the message headers in the Email Header Analyzer (it runs entirely in your browser). Check the SPF, DKIM and DMARC verdicts, and whether the From, Return-Path and Reply-To domains differ. Then read the Received chain from origin to recipient, remembering that only the lines added by your own provider are fully trustworthy. The SPF, DKIM and DMARC guide explains how to interpret each result, including why a message can pass all three and still be a phish.
Step 4: Correlate with your own data
Public lookups describe the indicator. Your logs describe your exposure, which is what matters. Search your own telemetry for the indicator over the relevant time window:
- DNS logs: which hosts resolved the domain, and when?
- Proxy and firewall logs: who connected, how much data moved, was the connection allowed or blocked?
- Email gateway: who received the message, who clicked, who replied?
- Authentication logs: did any account sign in from the address, and from where afterwards?
If nothing in your environment touched the indicator, the priority drops. If something did, you now have scope (which users and systems) and a timeline.
Step 5: Record evidence and confidence
Write findings so another analyst can follow your reasoning. A simple table does it, separating what you saw from what you concluded:
Indicator Observation Source / tool Time (UTC) Type Confidence
example-login[.]net Registered 4 days before email WHOIS / RDAP lookup 2026-10-12 09:15 Observed High
example-login[.]net Resolves to hosting provider IP DNS Lookup, IP Lookup 2026-10-12 09:17 Observed High
example-login[.]net Likely credential-harvesting page URL analyzer + email 2026-10-12 09:30 Inferred Medium
(illustrative)
Use the Copy Results button on each tool to attach the raw output. Record the time of each lookup; DNS, registration data and reputation change.
Step 6: Decide
Typical outcomes, in order of increasing response:
- Close as benign when the observations are explained (for example a known partner's new domain), and note why.
- Monitor when evidence is weak: add the indicator to a watch list.
- Block and notify when evidence is strong: block at DNS, proxy or mail gateway; notify affected users; reset credentials for anyone who entered them.
- Escalate if you find signs of compromise in your environment, and follow your incident response process.
- Report abuse to the hosting provider or registrar, using their published abuse contacts, where appropriate.
Common pitfalls
- Confirmation bias. Do not stop at the first fact that fits the story you expected. Look for evidence that would contradict it.
- Shared infrastructure. Many unrelated sites share one CDN or hosting address. Blocking an address because one site on it is bad may block many innocent ones.
- Stale reputation data. Lists lag behind reality in both directions.
- Treating geolocation as fact, especially for VPNs, mobile networks and anycast services.
- Over-trusting email authentication. A pass shows authorization by the named domain, not that the domain is trustworthy.
- Leaking information. Submitting internal hostnames or sensitive indicators to any online service shares them with that service. Use internal tools for those.
What these tools cannot tell you
They do not read files, they do not query commercial threat-intelligence or passive-DNS databases, they do not see traffic inside your network, and they cannot identify a person. They are a fast way to collect public, observable facts for the first few minutes of triage. For adversary behavior and technique naming, frameworks such as MITRE ATT&CK help you describe what you find in a common vocabulary.
Tools used in this guide
- IOC Analyzer — Paste an IP, domain, URL, or file hash — the type is detected automatically and enriched with DNS, RDAP, TLS, and geolocation context.
- IP Lookup — Look up approximate geolocation, ASN, and organization/ISP information for an IP address or domain.
- IP Reputation — Network details plus real reputation signals (Tor exit node, optional abuse intelligence) with the source and time of every check.
- WHOIS / RDAP Lookup — Look up domain registration details — registrar, registration/expiration dates, name servers — via RDAP.
- URL / Domain Analyzer — Safe first-level URL triage: components, DNS, redirects, HTTP and TLS details, and potentially suspicious characteristics.
- Email Header Analyzer — Paste raw email headers to review the Received chain and SPF, DKIM, and DMARC results — processed locally in your browser.
References and further reading
- RFC 9083 — JSON Responses for the Registration Data Access Protocol (RDAP)
- RFC 7208 — Sender Policy Framework (SPF)
- RFC 8601 — Message Header Field for Indicating Message Authentication Status
- IANA IPv4 Special-Purpose Address Registry
- MITRE ATT&CK — adversary tactics and techniques knowledge base
References are primary sources (standards and official documentation). Commands and sample output are illustrative; behavior can vary by operating system and software version.
Keep reading
- How to Interpret SPF, DKIM, and DMARC Records — Understand what SPF, DKIM, and DMARC each prove, read the records and Authentication-Results headers, diagnose failures, and roll out DMARC safely.
- How to Troubleshoot DNS Resolution Problems — A step-by-step method for diagnosing names that will not resolve, resolve to the wrong address, or work for some users and not others, using dig, nslookup, and public resolvers.