Due now: US$6.34 billion! Our standard payment terms apply.

At a recent on-line presentation, we introduced the audience to a new colleague. He walked attendees through installing an anti-phishing browser plugin. 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$250 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).

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.

Binance and the fake job interview

In September, a fake employer contacted a Binance engineer on a job-hunting platform. During the second interview, he was asked to download a coding “assignment” to his work computer. Its setup code installed malware that endpoint protection missed. On 20 October, the attacker used that computer and an internal AI tool to take over two colleagues’ computers. One held a container deployment token. On 29 October, the attacker used stolen credentials to deploy a container. The attacker then used an internal wallet signing service to start transactions outside the normal withdrawal process. Binance’s initial incident report puts the impact at about US$6.34 billion.

Binance calls it “not a single isolated breach or a simple phishing incident.” But the token’s storage, the AI tool’s access and the signing service’s rules are set by the organisation; this is not a user issue.

Mirage2FA and session theft

In August, ANY.RUN analysed 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

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. Application control stops the payload regardless of how persuasive the page is.

Information stealers 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 and approve a GitHub OAuth device-flow authorisation without a consent screen. The attacker logged in, but an additional MFA challenge stopped privilege escalation.

Account recovery

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 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 or interview task that asks for a command to be run as hostile, and report anything suspicious, early.

And the organisation?

The organisation owns everything else, prioritised through a risk register that references well-accepted frameworks: 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.

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 your response to a stolen session.

The bottom line

The goal isn’t a workforce that never makes a mistake. When a phish succeeds, the questions are: What did the attacker get? What stopped or allowed them at each step? How fast could it be contained? How do we 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.