When the Phish Drives Itself

In late 2024, researchers at Harvard Kennedy School ran a phishing test on 101 volunteers using a tool that handled the whole job without a person in the loop. It scraped public sources to build a profile of each target, wrote a personalized email, sent it, and tracked who clicked. The fully automated emails drew a 54% click-through rate, matching messages hand-written by human experts and running more than four times the 12% rate of a generic phishing control, at a cost the authors put at roughly four cents per email.

Criminal tooling is assembling the same pieces. In September 2025, Varonis researchers described SpamGPT, a spam-as-a-service platform sold on underground forums that pairs an AI assistant for writing lures with campaign management and inbox-delivery testing. In April 2026 they documented Bluekit, a kit with automated domain registration, more than 40 brand templates, and session capture that stores the victim's cookies after login, which lets an operator walk past MFA with a live session. Bluekit's AI assistant still produced drafts full of placeholders when Varonis tested it, so the fully self-driving version isn't here yet, but the direction is clear.

It breaks an assumption that has held up most phishing defense for a decade: a phishing campaign is something a person runs, at a pace a person can sustain, with the gaps a person leaves. Reset the password and kill the session, and you have usually outrun the attacker, because the human on the other end had to notice and come back. When the other end is software, that tempo advantage shrinks toward nothing.

What "Drives Itself" Actually Means

The old phishing economy ran on volume. Send a million emails, fool a few hundred people, then sell the credentials or cash out the ones that reached something valuable. Tooling in that world meant blasting more mail faster, and the work that mattered, deciding what to do with a credential once it landed, stayed manual.

The newer tooling goes after that manual part. Here is what a fully automated chain would do after a single Microsoft 365 credential falls, using techniques that are each documented today:

• It reads the mailbox to learn the victim. Who they email daily, which threads are open, how they sign off, which vendors send invoices. Software can build that model of a person's normal correspondence far faster than a human reading the same inbox.

• It registers infrastructure that matches. Domains that resemble the victim's real contacts, sometimes timed to an in-flight conversation it found in the inbox.

• It clones and inserts. Reply-chain injection lands the malicious message inside a thread the recipient already trusts, written in the sender's own voice, because the tool has read enough of that voice to imitate it.

• It pivots. From one mailbox it reaches the contacts, the shared drives, the connected SaaS apps, and any other identity that mailbox can authenticate to. Each hop produces more material for the next one.

Reply-chain injection, lookalike domains, and lateral movement through a tenant have all been documented for years. What changes is that software can chain them with a speed and consistency no manual operator matches, starting the moment a credential lands instead of whenever the operator next logs in.

Why the Password Reset Stopped Working

Here is the operational problem for a security team. The standard containment play for a compromised account is to reset the credential and revoke active sessions. Against a human attacker, that often closes the door: the attacker comes back, finds the password changed, and has to start over.

An automated attacker treats the reset as one more event to route around. By the time you reset the password, it may have already set up persistence through a different mechanism: an OAuth app grant the user "approved" during the original compromise, a mailbox forwarding rule, an added authentication method, or a captured token it is replaying. The credential you just reset was only the entry point. The foothold sits somewhere else and survives the reset. Microsoft's own guidance on illicit consent grants notes that once a malicious app holds a user's consent, resetting the password or requiring MFA doesn't cut off its access, because the app sits outside the organization.

Microsoft's playbook for responding to a compromised email account reflects the same reality. The password reset is step one of several, followed by hunting down the forwarding addresses and inbox rules an attacker may have left behind as back doors. The question for the responder moves from "did we reset the account?" to "what did the account authorize, forward, or grant while it was out of our control?"

When the Attacker Behaves Like a Co-Worker

The hardest part of this for detection is that automated post-compromise activity looks, on the wire, a lot like an employee having a busy morning. The account logs in from a plausible location, reads mail, sends replies inside existing threads, and opens files it has legitimate permission to open. Every action is something the real user might do.

What gives it away is usually a pattern across events: a cadence that is slightly too fast and too even, access to a combination of resources the user only touches together when something is wrong, a new OAuth grant minutes after a login from an unfamiliar device, a reply sent at 3am to a vendor the user hasn't written to in months. Catching that means correlating identity activity against a baseline of how the account normally behaves, and against intelligence about what current attacker infrastructure looks like. A reply-chain lure from a freshly registered domain is far more interesting if your intelligence flagged that domain an hour ago.

What This Asks of a CISO

Accepting that the attacker on the other end may be software running unattended changes three things.

• First, containment plans built around resetting a credential need a second half: a sweep of everything the compromised identity authorized, forwarded, granted, or enrolled during the window. The reset is still necessary, but it’s no longer enough on its own.

• Second, detection has to move from per-event rules toward behavioral correlation joined with current intelligence, because no single action in an automated takeover is unusual enough to trip a traditional alert.

• Third, the speed mismatch deserves an honest look. A tool that pivots in minutes can't be answered by a process that escalates in hours. That is the practical case for letting governed, machine-speed response handle the first moves on the defensive side, with humans approving what carries real risk.

For most of phishing's history, the attacker's tightest constraint was their own attention. Someone had to be watching when the credential landed and willing to do the work that followed. Take that constraint away and defenders lose the overnight lulls and slow Monday mornings they’ve relied on, because a phishing kit running on a rented server keeps working at 3am.  Machine Attacks Need Machine Defenders looks at what it takes to redesign the SOC for attacks that move at AI speed.