Skip to main content
articles

$ ls topics/{phishing,ai}

·8 min read

Just-in-time phishing

AI made it cheap to generate a phishing message for one person, use it once, and adapt every follow-up to the target's replies. Here is what that changes for email detection.

Ben Hathaway

Chief Technology Officer

I put this prompt on screen at RejectionCon:

A prompt asking an AI model to create a polished phishing email targeting David Setzer, CEO of Mailprotector, using public information from the web.

The prompt contains no research, pretext, writing sample, or attack plan. It names a person and a company, tells the model to search the public web, and asks it to avoid the common tells of a phishing email.

This was a controlled demonstration. No message was sent.

The model came back with this:

A generated email from someone presented as Sarah Whitman at ThreatLocker. It invites David Setzer to discuss a possible keynote for ZTW 2027 and refers to his previous conference session and Mailprotector's work on Zero Trust.

The message has no link or attachment. It asks whether David would be open to a conversation about a conference where he has spoken before, on a subject closely related to Mailprotector’s work. The request is ordinary enough to answer without much thought.

The model continued the scenario using a simulated reply from David. Its next message changed shape:

The generated follow-up supplies a Calendly link after a simulated reply from David agrees to talk. It quotes that reply and promises to add a one-page briefing to the calendar invitation.

The link arrives after the target has joined the conversation. The sender promises to put a one-page briefing in the calendar invitation, creating another place for a payload to appear later. The displayed sender address uses threatl0cker.com, with a zero in place of the second “o.” That look-alike domain is much easier to miss after the message has earned a reply.

I needed a name for the production model behind that exchange. I called it just-in-time phishing.

A definition based on production#

Just-in-time phishing is an attack in which an AI system generates each message at the moment of use, specialized to one target and the context accumulated so far. Each message is a single-use artifact, and the next one can be produced at a low, roughly constant marginal cost. With an AI agent running the exchange, every reply becomes context for the next decision and message.

That definition has four requirements:

  1. The message is generated after the attacker selects the target and context.
  2. Its content is specialized to observations about that target.
  3. The content is intended for one use rather than distribution as a stable campaign template.
  4. Producing another specialized message has a low, roughly constant marginal cost.

The scope matters. “Single-use” describes the generated content. The attacker may still reuse a sending domain, account, URL, prompt, or payload. Those other parts of the attack do not become unique merely because the prose does.

Existing terms describe different properties. Spear phishing describes the targeting. Commodity phishing describes the volume and economics. Business email compromise describes an objective and often the account used to pursue it. “AI phishing” only tells us that a model participated somewhere.

None of them tells us when the message was produced or whether its content will recur. That did not matter much when custom writing was the expensive part. Attackers could handcraft a message for a valuable target or reuse generic copy at scale. Cheap generation removes much of the premium on custom writing, so targeting and volume no longer sit at opposite ends of that choice.

An LLM writing one message that gets sent to fifty thousand people does not meet this definition. It is a faster way to author a bulk campaign, and its repeated content remains available to the defender. Mail merge does not meet it either. Changing a name or company in a stable template is personalization, but the artifact still has a recurring structure.

Where the compiler analogy helps#

The useful parallel to a just-in-time compiler is timing. An ahead-of-time attack commits to its artifact before it encounters a particular target. A just-in-time attack waits for target-specific inputs, then produces an artifact specialized to them.

A reply supplies more information. The generator can use it to correct a bad assumption, match the target’s vocabulary, or choose the next request. The two screenshots show that progression. The first message seeks only a response. Once the target responds, the second can introduce a link inside a conversation that now feels expected.

An AI agent can automate that loop. It can watch for a reply, add the new message to the target’s context, decide whether to continue or change approach, and generate the response. The attacker does not have to return to the model and write a new prompt for every turn. The patience that once made a conversational attack expensive can now be built into the workflow.

The analogy stops there. “Just in time” describes when the attack content is produced, not every detail of how a compiler works. Bulk templates will remain useful when speed and predictable output matter more than specialization.

Which detection assumptions stop holding#

Many email controls learn from recurrence. They work because some useful feature of one malicious message survives into the next. Generating the body once per target removes one major source of that recurrence, but its effect depends on what a control examines.

Exact hashing needs the same bytes to appear again. Fuzzy hashing and campaign clustering can tolerate changes, but they still need some combination of wording, structure, subject, layout, or attachment to recur. Independent generation makes those joins less reliable. Threat intelligence can still share infrastructure, destinations, accounts, and behavior; there may simply be no reusable body signature to publish.

Language classifiers retain useful signals such as impersonation, unusual requests, credential collection, and other signs of malicious intent. The opening message is their harder case because the intent has been deferred. It contains no payload and asks for a normal business reply. The attack needs an ask eventually, but the attacker controls which message carries it and may move it into a calendar invitation, shared document, phone call, or payment workflow.

Awareness training has the same boundary. Spelling errors, generic greetings, and clumsy urgency were useful clues because cheap phishing often carried them. They were never requirements of a phishing attack. Training can still teach verification procedures, especially around new payment instructions, credentials, and unexpected files. It cannot guarantee that the first message will contain a visible mistake for the recipient to catch.

Just-in-time generation weakens controls that depend on recurring content. The strongest remaining signals come from the parts of the attack the generator cannot rewrite.

The part that did not get cheaper#

The message still has to arrive from somewhere. A standalone campaign needs a domain or account, a sending path, DNS configuration, and a destination for whatever comes next. Much of that infrastructure has a timestamp and a history. Domains have registration dates. Certificates appear in public logs. Passive DNS records when infrastructure first appeared. Sending systems develop reputations. Look-alike domains can be compared with domains the recipient already knows.

Those signals survive a unique message body. They also cost the attacker more to replace, which creates pressure to reuse them. Someone generating a thousand distinct messages may still send all of them through one account or lead recipients to the same destination. The message bodies can have a population of one even when the infrastructure repeats.

Infrastructure novelty is evidence, not a verdict. Legitimate companies register domains and send their first messages every day. Newness becomes useful when combined with the claimed identity, the recipient’s relationship history, the requested action, and the age of the surrounding infrastructure.

The same reasoning applies to the sender relationship. An attacker can generate a convincing reference to a conference appearance. They cannot generate three years of correspondence between the recipient and that sender. A system can ask whether this person has written before, whether the domain matches the organization being claimed, and whether this message departs from the way the relationship normally works.

The strongest version of the attack steals that history. Compromise a vendor’s real mailbox, enter an existing thread, and the attacker inherits a legitimate domain and years of context. A relationship model will not make that attack impossible. The account compromise restores a cost that cheap content generation removed, and changes in the conversation or requested transaction may still provide evidence.

What defenders can do with the distinction#

Defenders still have several independent signals: content when the request appears, infrastructure age and similarity, sender relationship history, and changes in consequential workflows. Account security and out-of-band verification matter because a compromised mailbox can inherit the trust that a newly registered domain lacks.

The trust decision should rely less on prose the attacker can regenerate and more on the sender and relationship evidence they have to acquire. That is the model Shield is built around, and the post on phishing simulations develops the broader case for it.

“Just-in-time phishing” is more specific than “phishing written by AI.” It gives us a test for any control in the stack: what does this control need to recur, and what can it still observe when the message body never does?

Ben Hathaway

Chief Technology Officer

Head of product and technology at Mailprotector since 2008.