How to Investigate Suspicious URLs Like a SOC Analyst: Top Tools and Steps Explained
Learn how to investigate suspicious URLs as a SOC Analyst using expert tools like VirusTotal, URLScan.io, and Hybrid Analysis. Understand techniques, key indicators of malicious URLs, and how to detect phishing or malware threats before they harm your network.
Quick answer: To investigate a suspicious URL like a SOC analyst, never open it on your own machine. Defang and record it, check its reputation (VirusTotal, URLhaus, Google Safe Browsing), look at the domain's age and hosting with WHOIS and DNS, then see how it behaves in a scanner or sandbox such as urlscan.io or ANY.RUN. Finally, find out who else received or clicked it, contain the threat and document a verdict.
Key takeaways
- Defang every reported link, for example hxxps and [.] in the domain, before pasting it into chat or tickets.
- Never open the URL on your work machine; use urlscan.io, ANY.RUN or an isolated analysis VM with no company access.
- Check domain age through WHOIS and DNS, then find who else clicked it, because containment matters as much as the verdict.
Most phishing and many malware infections start with one link. This guide gives you a repeatable workflow, the free tools analysts actually use, the indicators that matter, and a report template you can copy into your ticketing system.
Before you start: handle the URL safely
Treat every reported link as live until proven otherwise. Three habits prevent most analyst mistakes:
- Defang it before pasting it anywhere:
hxxps://login-alert[.]example/verify. This stops chat tools and email from turning it into a clickable link. - Don't browse it from your work machine. Use an online scanner, a sandbox or an isolated analysis VM with no access to company systems.
- Watch what you share. Phishing links often contain the victim's email address or a session token. Public scans on urlscan.io and submissions to VirusTotal can be seen by others, so remove personal data or use a private or unlisted scan.
The 7-step URL investigation workflow
- Triage the report. Note where the URL came from (email, SMS, chat, proxy alert), who reported it and when. For email, keep the full message with headers.
- Read the URL itself. Break it into scheme, subdomain, registered domain, path and parameters. Many fakes are obvious at this stage, for example
microsoft.com.account-check[.]example, where the real domain is the part just before the top-level domain. - Check reputation. Look the URL and domain up in several sources. One clean result proves little, because new phishing sites are often unknown for hours.
- Check domain and infrastructure. WHOIS (registration date and registrar), DNS records, hosting IP and its reputation, and the TLS certificate.
- Observe behaviour safely. Run it through a URL scanner for redirects, page content and contacted domains. If it downloads a file, analyse that in a sandbox.
- Scope the impact. Search email, proxy, DNS and EDR logs: who received the link, who clicked, and did anyone enter credentials or run a download?
- Contain, report and close. Block the domain, remove the emails, reset any exposed credentials, record your indicators of compromise (IOCs) and write the verdict.
Step 6 is the one beginners skip. Proving a link is malicious is only half the job; the incident is about the people who clicked it.
Tools SOC analysts use to check URLs
| Tool | What it tells you | Watch out for |
|---|---|---|
| VirusTotal | Verdicts from dozens of security vendors, related files, domains and IPs | Submissions are shared with the security community; a low score does not mean safe |
| urlscan.io | Screenshot, redirect chain, every domain and script the page loads | Pick private or unlisted visibility for links containing personal data |
| URLhaus (abuse.ch) | Whether the URL is known for malware distribution | Focuses on malware delivery, not credential phishing |
| Google Safe Browsing site status | Whether Google currently flags the site as phishing or malware | New sites may not be listed yet |
| ANY.RUN, Hybrid Analysis | Interactive or automated sandbox runs showing processes, network calls and dropped files | Free tiers make results public; check the plan before uploading |
| Cisco Talos Intelligence, AlienVault OTX | Domain and IP reputation, related threat reports | Reputation lags behind fresh infrastructure |
| WHOIS lookup, crt.sh | Domain age, registrar, and certificates issued for look-alike names | Many registrations hide owner details by default |
| PhishTool | Email header and link analysis for reported phishing messages | Analyses the email; still check the URL itself |
| Shodan | Open ports and services on the hosting IP | Shared hosting IPs serve many unrelated sites |
For a wider view of the SOC toolkit, see our guide to essential tools every SOC analyst should master.
Checking a URL from the command line
Inside an isolated analysis VM, a few commands show where a link leads without rendering the page:
# Follow redirects and show only headers (no page rendering)
curl -sIL --max-redirs 10 "https://login-alert.example/verify"
# Who registered the domain, and when
whois login-alert.example | grep -iE "creation|registrar"
# Where it points
dig +short login-alert.example A
dig +short login-alert.example MX
Some phishing kits show a harmless page to scripts and security scanners and only serve the fake login to real browsers from the target country. If curl shows nothing odd, that is not a clean verdict; check the scanner screenshot too.
Red flags that suggest a URL is malicious
| Indicator | Why it matters |
|---|---|
| Domain registered in the last few days or weeks | Phishing campaigns use fresh domains that have no bad reputation yet |
| Brand name in the subdomain or path, not the registered domain | paypal.secure-check[.]example belongs to secure-check[.]example, not PayPal |
| Look-alike characters or typos | Homograph and typosquatting tricks such as rn for m or Cyrillic letters |
| Long redirect chains or URL shorteners | Hide the final destination and dodge email filters |
| Raw IP address instead of a domain | Common in malware delivery and less likely in legitimate business links |
| Free hosting, form builders or file-sharing links | Trusted platforms are abused because filters allow them |
| Random-looking subdomains | Can indicate automatically generated infrastructure |
| Victim's email address in the URL | Used to pre-fill a fake login page and make it convincing |
A valid HTTPS padlock is not a sign of safety. Free certificates mean most phishing sites now use HTTPS too.
Worked example: a fake Microsoft 365 login
This example is illustrative and uses a reserved domain name.
- Report: a user forwards an email saying "Your password expires today" with a link to
hxxps://m365-login-alert[.]example/[email protected]. - URL read: the registered domain is
m365-login-alert[.]example, not microsoft.com, and the user's email is in the query string. - Reputation: a few vendors flag it as phishing; Safe Browsing does not list it yet.
- Infrastructure: WHOIS shows the domain was created two days ago; crt.sh shows a certificate issued the same day.
- Behaviour: the urlscan.io screenshot shows a copy of the Microsoft sign-in page that posts the password to a third-party domain.
- Scope: the mail gateway shows 38 recipients; proxy logs show 4 clicks; sign-in logs show one user signed in from an unfamiliar location an hour later.
- Action: block the domain and posting endpoint, purge the email, reset that user's password, revoke active sessions, check for new mailbox rules, and notify the other clickers.
URL investigation report template
| Field | What to record |
|---|---|
| Ticket / case ID | Your SOC case number |
| URL (defanged) | hxxps://m365-login-alert[.]example/ |
| Source and reporter | Email to finance team, reported by user, time received |
| Reputation results | Each tool checked, with result and time |
| Domain and hosting | Creation date, registrar, IP, ASN, certificate |
| Behaviour observed | Redirects, page type, files downloaded, data posted where |
| Impact | Recipients, clicks, credentials entered, hosts affected |
| Verdict | Malicious / suspicious / benign, with reason |
| Actions taken | Blocks, purges, resets, notifications |
| IOCs | Domains, IPs, URLs, file hashes for threat-intel sharing |
In India, phishing attacks are among the incident types that CERT-In's April 2022 directions require organisations to report within six hours of noticing them. Check with your compliance team that your playbook covers this.
Common mistakes to avoid
- Calling a URL safe because VirusTotal shows zero detections.
- Pasting a link with a victim's email address into a public scanner.
- Clicking "just to check" on a work laptop.
- Stopping at the verdict without checking who clicked.
- Blocking only the first domain and missing the redirect target where credentials are actually sent.
Automating URL triage
High-volume SOCs automate the first four steps with a SOAR platform or a script that calls the VirusTotal and urlscan.io APIs, adds WHOIS age and posts a summary to the ticket. Analysts then spend their time on behaviour and scoping. Automate only once you can do the process by hand and know what a wrong automated verdict looks like.
Next step
Take a phishing email from your spam folder or a public phishing feed and run it through all seven steps in an isolated VM, filling in the report template as you go. If you are building toward an analyst role, our list of SOC analyst interview questions shows how URL triage comes up in interviews, and CompTIA CySA+ training covers this kind of analysis in a structured lab.
Related reading
Frequently Asked Questions
What's Your Reaction?
Like
0
Dislike
0
Love
0
Funny
0
Wow
0
Sad
0
Angry
0