At a recent on-line presentation, we introduced the audience to a new colleague. He walked attendees through installing an anti-phishing browser plugin, with a sign-in, an MFA prompt and a permissions approval. But the colleague wasn’t real! He was AI-generated, and the simulated attack collected fake credentials and an authenticator code. It took about ten hours and A$100 to build. A better-resourced attacker would do far better.
In January we explained why your staff click spelling mistake-laden emails: You can’t train your way out of human nature, so engineer the environment so a click isn’t catastrophic. Microsoft has since made passkeys the default Entra ID sign-in (from 1 September 2026).
Recent incidents include the RMS Cloud third-party booking breach, an Anthropic impersonation campaign that bypassed top secure email gateways, and hedge fund voice-phishing schemes.
What the attacker is actually after
A successful phish can deliver an authenticated session, an OAuth grant, code execution on the endpoint, or developer credentials. So phishing risk has two parts: How likely is deception, and what are the consequences? Awareness training addresses the first. It does little for the second.
Mirage2FA and session theft
In August, ANY.RUN published its analysis of Mirage2FA, a phishing-as-a-service kit targeting Microsoft 365. A reverse proxy relays the victim’s credentials and one-time code to Microsoft and keeps the session cookie, which the attacker replays without the password or MFA. FIDO2 passkeys and Windows Hello for Business defeat this by binding the response to the domain the browser is on.
Without phishing-resistant MFA, a password reset won’t evict an attacker who holds the cookie. ANY.RUN’s guidance is to revoke sessions and tokens, review mail-forwarding rules and OAuth grants, and investigate. That needs log events collected and indexed by your SIEM.
ClickFix and fake CAPTCHAs
Not every phish is after a login. ClickFix pages imitate a “verify you are human” check, then tell the visitor to paste and run a command. Malwarebytes has tracked these campaigns delivering Lumma Stealer and Atomic Stealer. No legitimate website verification ever needs you to run a command. Application control stops the payload regardless of how persuasive the page is.
Information stealers also take browser cookies. Microsoft’s incident responders have described attackers replaying a stolen cookie to skip a sign-in that already completed MFA. Token Protection binds session tokens to the device, but currently supports native applications only. Passkeys protect the sign-in, not the session that follows.
GhostAction and OAuth device flow
In October, OpenSourceMalware documented GhostAction, a campaign against open-source maintainers. A fake GitHub security alert led to a look-alike domain that collected the password and authenticator code. Injected JavaScript was designed to start a GitHub OAuth device-flow authorisation and approve it through the victim’s session without a consent screen. In one case the phish succeeded, but organisational controls, including an additional MFA challenge, reduced the consequences to zero. GitHub’s announced npm fixes are FIDO-based 2FA, short-lived granular tokens and trusted publishing. None of these controls are user decisions.
Account recovery
Passkeys get lost with devices, so organisations need a way to restore access. If an attacker impersonates an employee and convinces the help desk to issue an Entra ID Temporary Access Pass, the passkey’s strength is irrelevant. A help desk that verifies callers by appearance, voice or familiarity relies on signals a synthetic colleague can imitate.
So what is the employee’s job?
Employees do have a part to play: Verify unusual or consequential requests through a separately established channel, report unexpected MFA prompts rather than approving them, treat any website that asks for a command to be run as hostile, and report anything suspicious, early.
Training and awareness won’t catch every attack, especially those crafted with AI tools.
And the organisation?
The organisation owns everything else: Phishing-resistant authentication; an incident playbook that revokes sessions and tokens; application control; OAuth governance; least privilege; account recovery that resists impersonation; and monitoring with tested containment. ASD’s Annual Cyber Threat Report 2025-26 says AI almost certainly enables malicious actors to attack at larger scale and faster rate.
How dotSec can help
We run phishing and social engineering simulations, deploy phishing-resistant authentication, uplift application control and the rest of the Essential Eight, detect suspicious sign-ins through our managed SOC and SIEM, and run tabletop exercises that test whether your response to a stolen session ends with the attacker locked out.
The bottom line
The goal isn’t a workforce that never makes a mistake. No such workforce exists. The organisation needs phishing-resistant MFA, application whitelisting, testing and monitoring, driven by a prioritised risk register that references known and well-accepted frameworks and standards. And when a phish still succeeds, the questions are: What did the attacker get? What stopped or allowed them at each step? How fast could it be contained? What do we do to prevent a repeat?
Read on for more details, and let us know if we can help: Awareness is everyone’s responsibility. Resilience is the organisation’s.