The phishing page that screenshots your own website

· · Security

Most staff training on phishing comes down to one instruction: look carefully at the page before you type your password. Check it looks right. That instruction has quietly stopped being useful, because the page now looks right by construction.

Barracuda researcher Sachin Meti published an analysis on 29 July of recent campaigns using a kit called LogoKit, which builds a different login page for every single victim, at the moment they click. The background of that page is a live screenshot of the victim's own company website.

How it assembles itself

The phishing link carries the target's email address in the address itself, sitting in the path rather than hidden away. Something along the lines of .../[email protected].

When the page loads, code running in the browser pulls that email address out of the address bar and takes the domain from it. Now it knows where the person works. From there it calls a series of ordinary, legitimate commercial services to dress itself up:

  • Thum.io, a screenshot-as-a-service tool, to fetch a live picture of company.com and set it as the page background.
  • Clearbit, a brand data service, to fetch the company's logo.
  • Google Favicon, ImageKit, and Microlink to load the remaining imagery.

Barracuda's phrase for the result is the useful one: this is a move from brand impersonation to environment impersonation. The older generation of kit kept a stock of pre-built fake Microsoft and DocuSign pages. This one recreates a piece of the victim's actual working environment, on demand, for each person.

The credentials then go straight to a Telegram bot rather than a server the attacker owns and has to keep online. And the victim is redirected to the real site immediately afterwards, where they will almost certainly assume they fat-fingered the password and get on with their day. The theft leaves no trace the user would notice.

The lures themselves are dull, which is rather the point: password or certificate expiry warnings, access restrictions, delivery failures, timesheet updates, and ICANN verification notices. Barracuda found the emails in English, German, French, Spanish, Chinese, and Korean.

Why the usual defences struggle

Two things break here at once.

The advice to spot the fake. People are told to look for the wrong logo, the clumsy layout, the spelling mistakes. There are none. The logo is the real logo, fetched from a legitimate brand service. The background is a real photograph of the site they use every day. Asking someone to distinguish that from the genuine article by eye is not a fair test, and it is not a fair thing to make them feel responsible for failing.

Blocklists. Filtering that works by recognising known-bad pages needs something stable to recognise. Every page here is assembled at the moment of the request, from live data, so there is no fixed template to fingerprint and no reusable page to add to a list. This is the same problem underneath the malware your browser builds for itself: if the malicious thing does not exist until the victim asks for it, there is nothing to have seen before.

Running the whole operation through other people's services (Thum.io, Clearbit, Telegram) also means there is very little attacker-owned infrastructure to take down. Nothing to seize, nothing to sinkhole.

What actually survives this

The good news is that the defence that works is one you may already be part-way through, and it works regardless of how convincing the page is.

Passkeys and security keys. This is the answer, and it is not a marketing claim: it is a property of how the protocol works. A passkey is cryptographically tied to the real website's domain. Presented with a fake domain, it cannot produce a valid response, because the maths does not work. The user does not have to notice anything. NCSC now recommends passkeys as the default rather than password-plus-code, and this campaign is a clean illustration of why. Codes from a text message or an authenticator app do not help here: the fake page simply asks for the code too, and passes it along.

Conditional access rules. If a stolen password is used from an unfamiliar country or an unmanaged device, the login should meet resistance even though the credentials are correct. Barracuda specifically flags impossible-travel rules. If you run Microsoft 365, ask whoever administers it what conditional access is switched on today.

Filtering that looks for the shape, not the name. Since there is no known-bad page to block, useful filtering has to flag the characteristics instead: very newly registered domains, lookalike domains, and links with an email address sitting in the path. That last one is a strong signal and it is worth asking your provider whether anything you run inspects for it.

Change what you tell staff. Not "spot the fake page", which is now close to impossible. Better: never reach a login page by clicking a link in an email. Navigate to the service yourself, from a bookmark or by typing the address. That single habit defeats this entire technique, and it is a fair thing to ask of people. This is the same instinct as the advice underneath phishing that has only got cheaper to run: stop relying on human detection of quality, because quality is now free for the attacker.

Barracuda's own list ends on the honest note. Train people, but do not lean on users spotting bad emails, because these attacks look realistic and error-free. The detection has to happen somewhere other than the human eye.

How Steelwise can help

Working out whether passkeys are realistic for your setup, and what conditional access you already have switched on but unused, is the kind of review we do without turning it into a project. Get in touch.

Further reading

← All filings