The safest way to analyse a phishing website link is to never open it in your own browser: extract the real URL, read it carefully, defang it, and let free online services visit it for you. A SOC analyst can usually decide whether a link is malicious in a few minutes using nothing more than the URL itself, WHOIS, certificate transparency logs, urlscan.io and VirusTotal.
This post walks through that workflow step by step, the way a junior analyst would handle a reported email in a security operations centre. Every URL and domain below is fictional; the .test and .example domains are reserved and will never belong to a real organisation.
Why you never click, even “just to check”
Opening a phishing link from your own machine can:
- run a browser exploit, if one is being served;
- confirm to the attacker that the address is live, because many phishing links contain a unique token per recipient;
- reveal your IP address, browser and organisation to the attacker’s server;
- put your credentials one autofill away from being stolen.
Attackers also filter visitors. A kit may show the fake login page only to visitors from the targeted country, or only on mobile, and show a harmless page to everyone else. That’s another reason to use scanning services that let you choose where the visit comes from, rather than trusting what your own browser shows.
In MITRE ATT&CK terms, a malicious link in an email is Phishing: Spearphishing Link (T1566.002). Learning the technique ID helps when you write up findings and search your organisation’s detection rules.
The scenario
A user at Acme Fintech, a fictional company, reports this email:
From: Acme Fintech IT Service Desk Subject: Action required: mailbox storage verification "Your mailbox will be suspended in 24 hours. Verify your account at https://portal.acme-fintech.test/verify."
The visible text looks like an internal link. Your job is to find out where it really goes.
Step 1: get the real URL without clicking
The text people see and the link behind it can differ completely. Get the actual destination by one of these methods:
- In the email client, hover over the link and read the status bar, or right-click and choose “Copy link address”. Don’t left-click.
- Better, download the original message (
.eml) and read the raw HTML.
grep -oE 'href=“[^”]+"' reported-email.eml
href="https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Facme-fintech.test.secure-verify.example%2Flogin%3Fu%3DY2hpZGkuZUBhY21lLWZpbnRlY2gudGVzdA&data=05%7C02"
The organisation’s email security product has wrapped the link. Unwrap it to find the real destination:
python3 -c "
from urllib.parse import urlsplit, parse_qs
w='https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Facme-fintech.test.secure-verify.example%2Flogin%3Fu%3DY2hpZGkuZUBhY21lLWZpbnRlY2gudGVzdA&data=05%7C02'
print(parse_qs(urlsplit(w).query)['url'][0])"
https://acme-fintech.test.secure-verify.example/login?u=Y2hpZGkuZUBhY21lLWZpbnRlY2gudGVzdA
The same idea applies to URL shorteners: don’t visit them directly; use an expansion or scanning service (step 4) to see where they lead.
Step 2: read the URL like an analyst
Break the URL into its parts:
python3 -c "
from urllib.parse import urlsplit
print(urlsplit(‘https://acme-fintech.test.secure-verify.example/login?u=Y2hpZGkuZUBhY21lLWZpbnRlY2gudGVzdA’))"
SplitResult(scheme='https', netloc='acme-fintech.test.secure-verify.example', path='/login', query='u=Y2hpZGkuZUBhY21lLWZpbnRlY2gudGVzdA', fragment='')
The single most important skill: find the registrable domain. Read the hostname from the right. Here the domain is secure-verify.example. Everything to the left, acme-fintech.test., is just a subdomain the attacker chose to make the link look familiar. The real Acme domain doesn’t appear anywhere as the domain.
Now check the other parts:
| What to check | In this URL | Why it matters |
|---|---|---|
| Registrable domain | secure-verify.example |
Not Acme’s domain. Strong phishing signal on its own. |
| Subdomain | acme-fintech.test |
Brand name used as decoration. |
| Path | /login |
A credential page outside the company’s identity provider. |
| Query string | u=Y2hp... |
Looks like base64. Decode it. |
| Scheme | https |
Only means the connection is encrypted. Says nothing about whether the site is honest. |
Base64 strings need a length divisible by four, so add == padding before decoding. Decode the parameter:
echo ‘Y2hpZGkuZUBhY21lLWZpbnRlY2gudGVzdA==’ | base64 -d
chidi.e@acme-fintech.test
The link carries the recipient’s email address, probably to pre-fill the fake login form and track who clicked. That’s useful for your investigation, and it’s also a privacy warning for step 4: remove recipient identifiers before submitting a URL to any public service.
Other tricks to look for
- Lookalike domains:
acrne-fintech.test(r and n look like m),acme-fintech-support.test, or a different top-level domain. - Internationalised domain names (homographs): a Cyrillic “а” looks identical to a Latin “a”. Browsers and tools show these in punycode, which starts with
xn--. For example,аcme-fintech.testwith a Cyrillic first letter becomesxn--cme-fintech-xij.test. Convert anyxn--domain to check:
python3 -c "print(‘xn--cme-fintech-xij.test’.encode().decode(‘idna’))"
- The
@trick: inhttps://acme-fintech.test@203.0.113.50/login, everything before the@is treated as a username. The browser actually connects to203.0.113.50. - Raw IP addresses instead of domain names.
- Open redirects on legitimate sites, for example
https://trusted.example/redirect?to=https://secure-verify.example. The first domain is real; the destination isn’t.
Step 3: defang before you share
Before pasting a suspicious URL into a ticket, a chat or a report, defang it so nobody clicks it by accident and no tool auto-links it. The convention is hxxp for http and [.] for dots:
echo ‘https://acme-fintech.test.secure-verify.example/login’ \
| sed -e ‘s/^http/hxxp/’ -e ‘s/\./[.]/g’
hxxps://acme-fintech[.]test[.]secure-verify[.]example/login
CyberChef has “Defang URL” and “Fang URL” operations if you prefer a browser tool. Refang only inside the tool where you need the live value.
Step 4: let the free tools look for you
Use these in roughly this order. Each answers a different question.
WHOIS: how old is the domain?
whois secure-verify.example
Illustrative output for a fictional domain:
Domain Name: SECURE-VERIFY.EXAMPLE
Registrar: Example Registrar, Inc.
Creation Date: 2026-10-08T21:14:09Z
Registry Expiry Date: 2027-10-08T21:14:09Z
Registrant Organization: REDACTED FOR PRIVACY
Name Server: NS1.EXAMPLE-DNS.NET
A domain registered two days before a “mailbox verification” email is a strong signal. Privacy redaction is normal for legitimate sites too, so don’t read anything into it alone. Some registries publish data through RDAP rather than classic WHOIS; the idea is the same.
Certificate transparency (crt.sh): when did it get a certificate, and what else exists?
Public certificate authorities log every certificate they issue. crt.sh lets you search those logs without touching the attacker’s server:
curl -s 'https://crt.sh/?q=%25.secure-verify.example&output=json' \
| jq -r ‘.[] | [.not_before, .name_value, .issuer_name] | @tsv’ | sort -u
Illustrative output:
2026-10-08T22:01:37 acme-fintech.test.secure-verify.example C=US, O=Let’s Encrypt, CN=R11
2026-10-08T22:03:12 bank-portal.secure-verify.example C=US, O=Let’s Encrypt, CN=R11
2026-10-09T07:45:50 payroll-hr.secure-verify.example C=US, O=Let’s Encrypt, CN=R11
This tells you the certificate was issued within an hour of registration, and that the same domain hosts other brand-themed subdomains. That’s a phishing infrastructure pattern, and the extra hostnames are indicators you can block too. Free certificates are used by honest sites as well, so the issuer alone proves nothing; the timing and naming do the work.
urlscan.io: what does the page look like, and where does it go?
urlscan.io visits the URL from its own infrastructure and records a screenshot, redirects, the final URL, contacted domains and page resources.
- Search first. Someone may already have scanned it: search for
domain:secure-verify.example. - If you submit, choose visibility carefully. urlscan offers public, unlisted and private scans. Public scans are visible to everyone, so strip tokens and email addresses from the URL first, and follow your organisation’s policy.
- Read the result: the screenshot (is it a fake Acme login page?), the redirect chain, the final domain and IP, and whether the form posts credentials to a third domain.
With an API key, submission looks like this:
curl -s -X POST ‘https://urlscan.io/api/v1/scan/’ \
-H “API-Key: $URLSCAN_KEY” -H ‘Content-Type: application/json’ \
-d ‘{“url”:“https://acme-fintech.test.secure-verify.example/login”,“visibility”:“unlisted”}’
If you must interact with the page yourself, do it only in an isolated sandbox, such as a disposable VM on a separate network or an online sandbox such as ANY.RUN, never on your work or personal machine.
VirusTotal: what do other engines and analysts say?
VirusTotal checks a URL or domain against many security vendors' blocklists and shows community comments, related files and DNS history.
curl -s ‘https://www.virustotal.com/api/v3/domains/secure-verify.example’ \
-H “x-apikey: $VT_KEY” | jq ‘.data.attributes.last_analysis_stats’
Illustrative output:
{ “malicious”: 4, “suspicious”: 1, “undetected”: 60, “harmless”: 0, “timeout”: 0 }
Two cautions every beginner needs:
- A clean result doesn’t mean safe. New phishing domains are often undetected for their first hours. Your WHOIS and crt.sh findings may be ahead of the vendors.
- What you submit is shared. URLs and files sent to VirusTotal are visible to its community and security partners. Never submit internal documents or URLs containing personal data.
Step 5: decide and respond
Bring the evidence together:
| Evidence | Finding |
|---|---|
| Display text vs real link | Mismatch: shows Acme portal, goes to secure-verify.example |
| Domain age | Registered two days before the email |
| Certificate transparency | Several brand-themed subdomains in 24 hours |
| urlscan.io | Screenshot of a fake Acme sign-in page; form posts to another domain |
| VirusTotal | Flagged by a few vendors |
| Verdict | Malicious: credential phishing |
Then respond, following your organisation’s playbook:
- Scope it. Search the mail gateway for every message containing
secure-verify.exampleand pull them from inboxes. - Check for clicks. Search proxy, DNS or firewall logs for the domain and its siblings from crt.sh. A hit means a user may have reached the page.
- Contain affected accounts. If anyone submitted credentials, reset the password, revoke sessions and check for new MFA methods or mailbox forwarding rules. Our post on how account takeovers work and how defenders stop them covers what attackers do next.
- Block the domain and subdomains at the email gateway, web proxy and DNS.
- Report the site to the hosting provider or registrar, and through your national reporting route where one exists.
- Close the loop with the person who reported it. Thanking reporters is how you get more reports.
Step 6: write it up
A good ticket entry is short and reproducible:
Summary: Credential phishing impersonating Acme IT. Malicious.
IOCs (defanged):
hxxps://acme-fintech[.]test[.]secure-verify[.]example/login
secure-verify[.]example (registered 2026-10-08)
bank-portal[.]secure-verify[.]example, payroll-hr[.]secure-verify[.]example
Evidence: WHOIS age, crt.sh issuance, urlscan screenshot (unlisted), VT 4/65.
Scope: 37 recipients; message purged. 2 clicks in proxy logs; 0 credential submissions confirmed.
Actions: domain blocked (gateway, proxy, DNS); users notified; takedown requested.
Technique: T1566.002 Spearphishing Link
The numbers in that template are part of the fictional scenario; yours will come from your own logs.
What a beginner can practise this week
- URL reading drills. Write ten lookalike URLs for a fictional brand and ask a friend to find the registrable domain in each.
- Header and link extraction. Save a harmless newsletter as
.emlfrom your own inbox and extract every link withgrep, as in step 1. - Certificate transparency. Search crt.sh for a domain you own, or a well-known public one, and read what’s logged. It’s passive and only queries the public logs.
- Search, don’t submit. Browse urlscan.io’s public results to see what real phishing pages look like, without submitting anything yourself.
- Read examples. Our guide to phishing email examples a SOC analyst looks for covers the email side: headers, sender authentication and pretexts.
Only investigate infrastructure passively, as shown here. Don’t attack, scan or log in to phishing sites. Active testing of anyone’s systems needs written permission.
Quick personal-safety checklist
For friends and family who aren’t analysts:
- Go to the site yourself by typing the address or using a bookmark, rather than following the link.
- Read the domain from the right, just before the first single
/. - Be suspicious of urgency (“24 hours”, “suspended”).
- Use a password manager; it won’t autofill on a lookalike domain.
- Turn on multi-factor authentication, preferably an authenticator app or security key.
The same habits protect messaging accounts too; see how attackers use links and codes in WhatsApp account takeovers.