Recognising phishing aimed at admin accounts
Generic phishing is easy to spot and mostly filtered before you see it. What reaches someone holding admin credentials is different: researched, plausible, well-timed, and often free of every tell you were taught to look for. The defence isn't sharper eyes — it's a small number of habits that work even when the message is convincing.
Why your inbox is a different problem
Someone with admin access to a payment processor, a DNS zone, or a customer database is worth real effort. That effort shows up as attacks tailored to you specifically.
The research is cheap and public. Your role is on a professional network. The tools your company uses are visible in job listings, conference talks, and the badges on your own website. Your colleagues' names and the vendors you work with are discoverable. From that, a message can reference the right product, the right person, and a plausible reason — without knowing anything genuinely private.
Which means the classic advice — bad grammar, generic greeting, obviously wrong domain — filters out the low-effort attacks and leaves exactly the ones aimed at you.
The lures that actually get used
Vendor security notices. "Unusual sign-in detected on your account. Review activity." It borrows the urgency of a real security alert and sends you somewhere to "verify". Effective because reviewing a genuine alert is exactly the responsible thing to do.
Billing and payment failures. "Your card was declined; your service will be suspended in 24 hours." Aimed at whoever holds the billing role, with a deadline that discourages checking.
Shared document notifications. A file-sharing notice from a colleague's name, leading to a fake sign-in page for your document platform. Convincing because these arrive legitimately all day.
Support impersonation. A message or call from "the vendor's support team" about a ticket, asking you to confirm your identity — a code, a password, a screen share. Real vendors don't ask for codes; attackers count on you not being certain of that in the moment.
OAuth consent grabs. Increasingly common and worth understanding, because it sidesteps everything else. Instead of a fake login page, you get a real permission prompt from your actual provider, asking you to authorise an app with an innocuous name. There's no password to steal and no fake domain to spot — you're being asked to hand over access voluntarily. If you approve, the attacker holds a token that survives password changes and 2FA. The only defence is reading what permissions are being requested and whether you asked for this.
Multi-factor fatigue. An attacker with your password triggers push approvals repeatedly, often at night, until you tap approve to stop the noise. If you get an approval prompt you didn't initiate, someone has your password — deny it and go change the password immediately.
Domain and registrar notices. Expiry warnings and transfer notifications, aimed at the account with the largest blast radius you own. Well-timed against publicly visible expiry dates.
Nearly all of these combine a plausible reason with time pressure and a link. The pressure isn't decoration — it exists to stop you doing the one thing that defeats the attack, which is navigating to the site yourself.
Why "check the URL" isn't enough
It's still worth doing, but treat it as one signal rather than the answer. Lookalike domains use character substitutions your eye skips at a glance. Attackers register legitimate-looking subdomains on services they control, so the visible prefix reads correctly while the actual domain is elsewhere. Links get wrapped by shorteners and redirect chains that hide the destination. Mobile browsers truncate the address bar, hiding the part that matters. And the padlock means only that the connection is encrypted — attackers get certificates as easily as anyone.
Reading a URL correctly requires knowing to read right-to-left from the path back to the registered domain, at a moment when you're busy and the message says your service is about to be suspended. It's a check that works most of the time and fails exactly when the pressure is highest.
Habits that work under pressure
These are all mechanical. None require you to make a judgement call while stressed.
Navigate yourself, always
The single most effective habit. Never act on a link in a message about an account. Open a new tab and reach the service the way you normally do — a bookmark, your password manager, typing the address you know.
If the alert is real, it will be waiting for you inside the account. If nothing's there, you've learned what you needed to. This defeats every fake-login-page attack regardless of how convincing the message was, and it costs about eight seconds.
Let your password manager decide
A manager that matches on origin will not offer to fill credentials on a lookalike domain. It can't be fooled by visual similarity because it isn't looking at the rendering.
The habit that makes this useful: treat a failure to autofill as a warning, not an inconvenience. If your manager doesn't recognise the site you think you're on, the overwhelmingly likely explanation is that you're not on it. Don't copy and paste around the problem — that's manually defeating a control that just fired correctly. This is covered further in the credential storage guide.
Use phishing-resistant factors where it counts
Hardware keys and passkeys verify the site's origin before responding, so they simply won't authenticate to a lookalike. That's a categorical defence rather than a probabilistic one, and it's the reason to put them on your Tier 1 accounts specifically — see the passkeys guide.
A code from an authenticator app does not provide this. It's a real improvement over a password alone, but it can be relayed by a fake page in real time.
Verify out of band
For anything involving money, credentials, or access changes, confirm through a channel you established independently — a phone number you already had, a colleague in person, a support portal you logged into yourself. Never the contact details in the message.
This applies especially to requests that appear to come from colleagues. A message from a manager's name asking you to grant access urgently is a standard pattern, and a thirty-second check is cheap.
Treat unexpected prompts as evidence
An approval request you didn't trigger means someone is actively using your password right now. It is not a glitch. Deny it, change that password, and check the account's active sessions and tokens.
Reduce what a successful attack gets
Assume one lands eventually. Everything from the other guides here is what limits the damage: unique passwords so one compromise stays contained; tiering so the most-attacked accounts have the strongest factors; narrow roles so a compromised account can't do everything; and regular reviews so an attacker's leftovers — a new token, a forwarding rule, an added user — get found.
That last point matters. Attackers who get in usually establish a second way back before doing anything visible. Changing the password afterwards doesn't remove it.
If you think you fell for one
Speed beats certainty. Act first, investigate after.
- Change the password on the affected account, from a device you trust.
- End all sessions and revoke trusted devices — both, they're separate actions. See the sessions guide.
- Check connected apps and tokens and revoke anything you don't recognise. This is where persistence hides, and it's the step people skip.
- Check recovery settings — email addresses, phone numbers, backup codes. An attacker who changed these keeps a way in.
- Check mail rules if it was an email account. Forwarding and auto-delete rules are used to intercept reset messages and hide the evidence.
- Change the password anywhere you reused it. Ideally nowhere.
- Tell someone. Colleagues, the vendor, whoever needs to know. The instinct to handle it quietly is the thing that turns a contained incident into a bad one — and people who report immediately are the reason most attempted breaches stay small.