Scan of the Week #1: Dissecting a Real Fake-Login Phishing URL

Welcome to the first entry in a recurring series. Every few weeks we'll take one real artefact our scanners caught, a URL, a file hash, an SMS, and walk through it layer by layer. What each signal saw, what the verdict was, and what the takeaway is for people who don't spend their days in URL-analysis tools.

To start, something that shows up in our scan logs almost daily: a fake-login page targeting a consumer email account. The URL has been neutralised (details redacted to avoid helping the attacker's SEO), but every signal below is from the actual scan run.

The URL

Lightly redacted to keep the original infrastructure out of search indexes. The structure, the TLD choice, the path layout, the filename, is verbatim. That's enough to walk through what each detection layer did.

A user had copied this URL from a "your inbox is full" warning email and wanted to check it before clicking. They pasted it into ScanTotal's URL scanner. Here's what happened.

Layer 1: Reputation (Google Safe Browsing)

This is where a lot of simpler scanners would stop. "Clean on all engines checked." A user seeing that response might assume the URL is fine, click through, and hand over their credentials. Reputation-only scanning is how fresh phishing URLs stay effective for the first 12-48 hours of their lifespan.

Credit where it's due: Google Safe Browsing is exceptional at what it's designed to do, distribute known-bad verdicts to billions of devices at low latency. But by design, it's retrospective.

Layer 2: Heuristic analysis

Heuristic analysis scores a URL on structural features, without fetching it. It's pure pattern-matching against the URL string itself. Our scanner runs a ten-check scoring system; here's what fired on this one:

Let's unpack what each check found:

HTTP, not HTTPS

Any modern service with a login form uses HTTPS. A page claiming to be a secure email login and served over plain HTTP is a contradiction. Legitimate services dropped HTTP for login flows around 2016; seeing it in 2026 on a signin page is almost conclusive.

Suspicious path keywords

The path /auth/signin/secure-verification/ is pattern-matched against a short list of terms that appear disproportionately in phishing URLs: auth, signin, login, secure, verify, verification, update. Three of them show up in this path alone. Legitimate signin URLs rarely concatenate that many "security" words, they just say /login/ or similar. Phishing URLs stuff them together because the attackers expect victims to skim-read the URL and pick up reassurance from familiar words.

Excessive subdomains

Attackers lean on a pattern where the first part of the hostname looks like the service they're impersonating, gmail-support.example-host.xyz, so a glance suggests "this is something Gmail-related." Heuristics count the number of dots in the hostname; a path like [a].[b].[host].xyz has four segments, which is unusual for genuine commercial domains that typically use two or three.

Long URL and explicit .html filename

Real consumer services hide filenames behind routing frameworks. A URL that ends in /index.html suggests either a static-site host (legitimate but unusual for a signin page) or a cheaply-deployed phishing kit, which is a bundle of HTML/JS files an attacker uploads to a compromised host without any application framework. The long overall URL is a weaker signal but nudges the score up.

So by this stage we already have enough to warn the user strongly: reputation doesn't know it, but the URL's shape is obviously wrong for a legitimate login page. A more complete picture comes from the third layer.

Layer 3: Active probing

Active probing fetches the URL in a sandboxed environment and inspects what's actually served. Not just headers, the actual response content (within reason, for safety).

The form-target mismatch is the killer signal. The page tells the browser: "when the user submits their credentials, send them to a different domain." On a legitimate email provider that can happen for sound reasons, SSO redirects, tokenised POSTs, but not to an unrelated third-party domain the victim has never heard of. Here, the form action posted to a host that wasn't the page host and wasn't any recognised authentication service.

The "no reference to a real OAuth provider" signal reinforces it. A real modern email login page has references to the provider's own authentication infrastructure visible in the source, script paths, meta tags, canonical links. This page had none of that. It was a hand-crafted copy of the login page's visual layout with a hollow interior.

Combined verdict

Across the three engines:

• Reputation: no match, unknown URL
• Heuristic: 55/100, high risk, structural flags (HTTP, suspicious keywords, excessive subdomains)
• Active probe: suspicious, form target mismatch, missing legitimate-provider markers

The combined verdict was high risk / likely phishing, and the scanner recommended not visiting the URL at all. Had the user relied only on the reputation layer, they'd have seen "clean" and likely visited. The other two layers are what made the verdict correct.

What happened to that URL afterwards

We rescanned the same URL 48 hours later. This time Google Safe Browsing had a match, someone else had reported it and the database had picked it up. By 72 hours, the hosting provider had taken the page offline. That's the normal lifecycle for a phishing URL: hours of "unknown to reputation" while it catches victims, a day or two of being actively reported, and then takedown.

The heuristic and active-probe signals were the same across all three scans. Those layers don't need the URL to have been reported anywhere, they evaluate what the URL is and what it does, not whether anyone has complained yet. That's why layered scanning catches phishing earlier than reputation-only tools.

What to take away

Three things worth remembering if you scan URLs yourself:

• "Clean on reputation" is not the same as "safe." Especially for URLs that have existed for less than 24 hours. Look for heuristic or behavioural signals to back up the reputation verdict.
• Structural red flags are cheap to spot. HTTP-only login page, multiple "security" words stacked in the path, long subdomain chain, any one of these should make you hesitate, even without a scanner.
• The form-target mismatch is a consistent giveaway. If you're comfortable inspecting pages, right-click a login page → View Source → search for <form. The action= attribute should point to the same organisation as the page you're on. On phishing pages, it almost never does.

We'll do another Scan of the Week in a couple of weeks. Suggestions for what to dissect, a file, a URL, an SMS someone you know received, welcome via Contact. Nothing identifying will be shown in the post.