AI Pentesting, Part 2: AI Phishing and Pretexting: Engineer a Controlled Simulation

1. Model the trust decision

Phishing asks a recipient to trust an asserted identity or follow an unsafe workflow. Pretexting adds a story explaining why the request is legitimate. LLMs assist with grammar, translation, summarisation of public information, and generation of variants. None of that authenticates a sender. Voice and video synthesis create similar risks, but a simulation need not clone a real person to test callback verification.

Define one control objective per scenario. The help desk must perform an out-of-band identity check before changing an enrolled authenticator. Finance must call a known number and obtain dual approval before altering bank details. Engineering must verify a new OAuth application's requested permissions. Use fictional identities and accounts with no production privileges.

Do not use health, immigration, dismissal, or family emergencies as pressure themes. Avoid employees' private information. Legal, HR, communications, and the exercise owner should approve scenarios, exclusions, escalation contacts, and stop conditions before delivery.

2. Use AI to draft a simulation specification

Request a scenario brief rather than a deployable deceptive message. Keep final wording under human review. Approved content should identify the fictional sender, expected safe action, telemetry, and exact boundary that must not be crossed. Translation should preserve meaning rather than add urgency or authority claims.

Create a controlled training scenario, not an outbound email.
Audience: a consenting help-desk exercise team.
Identity: Jordan Example, synthetic account TRAINING-014.
Objective: verify the approved identity-check procedure.
Constraints: no credentials, real executive identity, attachments,
external links, voice cloning, or production account changes.
Output: scenario summary, safe response, evidence checklist,
        privacy risks, abort conditions, debrief questions.

Check whether the model invented policy exceptions. A generated supervisor override might not exist. Reject that suggestion rather than training staff to follow an imaginary procedure. Version the approved brief and record which exact revision was delivered.

3. Inspect mail authentication and routing

SPF checks whether a sending IP is authorised for the envelope domain. DKIM verifies a signed message against the signing domain. DMARC evaluates alignment of the visible From domain with a passing SPF or DKIM identity and expresses a receiver policy. Passing DMARC does not prove a message is benign; an attacker-controlled lookalike can authenticate perfectly. Display names are not authenticated identities.

Authentication-Results: mx.example.test;
  spf=pass smtp.mailfrom=training.example.test;
  dkim=pass header.d=training.example.test;
  dmarc=pass header.from=training.example.test
From: Training Exercise <[email protected]>
Reply-To: [email protected]
X-PSC-Exercise-ID: SIM-014

This is an illustrative header, not a delivery result. Capture the recipient gateway's own trusted Authentication-Results rather than a sender-supplied header. Compare Return-Path, From, Reply-To, Message-ID, received hops, and URL destination. Redact recipient addresses before model analysis.

Do not broadly allowlist the simulation sender if evaluating mail controls. If a bypass is necessary for a separate awareness exercise, document it as a different experiment; its delivery rate says nothing about gateway effectiveness. Use a dedicated approved domain and normal authentication, not an uninvolved organisation's identity.

4. Instrument a non-credential landing page

A benign page can record an exercise visit without displaying a login form. Use opaque, short-lived random tokens mapped server-side to the minimum necessary cohort. Do not put an employee email in the query string. Avoid third-party analytics and collection of IP addresses unless expressly needed and approved.

{
  "exercise_id": "SIM-014",
  "event": "training_page_view",
  "cohort": "helpdesk-pilot",
  "token_hash": "fixture-only",
  "occurred_at": "2026-10-28T10:00:00Z",
  "credentials_collected": false,
  "retention_days": 14
}

Mail security products may prefetch links and images. A request is not proof of a human click, and a tracking pixel is not proof of reading. Correlate with an explicitly approved user interaction and label remaining ambiguity. Do not use browser fingerprints as reliable attribution. Disable the endpoint and expire tokens after the exercise.

5. Design detection and response examples

Example one: a user reports a suspicious invitation. Measure time from delivery to report, triage, and related-message removal. Example two: a help-desk agent refuses an authenticator reset without the required check. No account change is a successful control outcome, even if the conversation seemed convincing. Example three: finance calls a directory-listed supplier number and discovers the exercise. Credit the workflow rather than counting a failed lure.

Correlate the exercise ID with gateway verdicts, mailbox audit events, tickets, and identity-provider logs. Retain aggregate outcomes wherever individual-level data is unnecessary. AI may cluster reports, but a deterministic join should connect events to the exercise. A reported message body can contain prompt injection; an assistant reading it must not send replies, approve invoices, or change account state.

Response playbooks should cover message search, indicator validation, affected-user communication, token revocation where relevant, and the stop notice. Test the kill switch with a pilot cohort. Accidental production changes invalidate the experiment.

6. Report uncertainty and retest

Keep delivered messages, confirmed human interactions, gateway detections, user reports, verification compliance, and response time as separate denominators. If 80 messages reached mailboxes, 12 links were fetched by scanners, and 7 confirmed human interactions occurred, do not report 19 employee clicks. Use anonymised cohort-level reporting and avoid public ranking of individuals.

Outcome: 18 of 20 role plays required the documented verifier.
Exceptions: 2 agents sought clarification; no account was changed.
Detection: 9 exercise messages reached the approved reporting channel.
Limitations: prefetch excluded; no credential testing occurred.
Retest: repeat after the verification-policy wording is updated.

Use AI to compare debrief themes with policy and draft accessible training material. Human owners approve conclusions. The deliverable is a process improvement backed by event IDs and limitations, not a claim that AI measured every employee's susceptibility. Part 3 moves from human trust to application trust boundaries.

7. Step-by-Step Lab: Run a Consent-Based Help-Desk Tabletop

Prerequisites: A consenting exercise team, an approved fictional identity, a non-production account, the organisation's actual verification procedure, and a facilitator with a stop authority. This is a role-play and log-analysis exercise; it sends no phishing email and collects no credentials.

1. Write a one-page exercise charter with the account TRAINING-021, the approved time window, exclusions, observers, escalation contact, and the precise objective: verify the required out-of-band identity check before any authenticator reset.
2. Ask the scenario assistant to produce the brief using the constrained prompt earlier in this article. Compare every proposed exception with the real policy. Remove invented supervisor overrides, urgency themes, or requests for private personal details.
3. Have the facilitator read the approved fictional scenario to a help-desk volunteer. Stop before any production change. The volunteer should describe or demonstrate the documented verifier against the isolated training account.
4. Record delivered, reported, verified, clarification-needed, and scanner-prefetch events separately. Use anonymous cohort IDs, not employee names in model prompts. Define what evidence distinguishes a human interaction from automated link checking.
5. Run the offline event reducer below. Confirm that a scanner prefetch does not become an employee click or a successful identity compromise. Keep counts and denominators visible.
6. Debrief the volunteer and policy owner. Identify unclear wording or unavailable callback information. Assign a process fix rather than ranking individuals by susceptibility.
7. Repeat the scenario after the policy change with the same objective and a comparable consenting cohort. End the exercise, expire any approved test tokens, and delete unnecessary individual-level data.

const events = [
    { id: "SIM-01", type: "delivered" },
    { id: "SIM-01", type: "prefetch" },
    { id: "SIM-01", type: "reported" },
    { id: "SIM-02", type: "delivered" },
    { id: "SIM-02", type: "human_interaction_confirmed" }
];
const distinct = type => new Set(events.filter(event => event.type === type).map(event => event.id)).size;
const summary = { delivered: distinct("delivered"), reported: distinct("reported"),
    confirmedHuman: distinct("human_interaction_confirmed"), prefetch: distinct("prefetch") };
if (summary.delivered !== 2 || summary.confirmedHuman !== 1) throw Error("denominator mismatch");
console.log(JSON.stringify(summary));

Expected result: Two delivered exercise items, one report, one confirmed human interaction, and one prefetch. These are separate observations. The reducer is not a detection engine and cannot determine intent or identify the actor behind an ambiguous web request.

8. Worked Examples and Expected Outcomes

Example A: the callback succeeds

The volunteer refuses a reset until a directory-listed callback completes. Record verification compliance and the ticket reference. A plausible pretext did not defeat the process; that is a successful control outcome, not a disappointing test.

Example B: the message authenticates correctly

A dedicated training domain passes SPF, DKIM, and DMARC. Ask the assistant to explain why this authenticates a domain relationship rather than proving the message's business legitimacy. Do not spoof a real executive or an unrelated company to make the explanation more dramatic.

Example C: the landing URL is prefetched

A gateway requests the exercise page before the recipient opens the mailbox. Mark the event automated or unresolved according to approved evidence, not a human click. If no reliable distinguishing interaction exists, report a range or unknown rather than inventing attribution.

Debrief record:
Control objective: documented identity verification before reset.
Observed: verifier used; no production change.
Gap: callback directory instructions were difficult to locate.
Action: policy owner updates the service-desk runbook.
Retest: repeat the same verifier workflow after the update.

9. Troubleshooting, Retesting, and Completion Evidence

Retest and completion: Retain the approved scenario, policy revision, anonymised event definitions, facilitator notes, and owner-approved fix. Confirm zero credential collection and zero unintended account changes. A clean simulation does not establish protection against every social-engineering channel.

10. Real Tool Workflow: Inspect an Exercise Message and Mail Policy

Prerequisites: PowerShell, a mail client such as Thunderbird or Outlook, an exported synthetic exercise.eml, and written approval for any DNS query. No outbound message, credential landing page, impersonated executive, or bulk delivery is necessary.

Use reviewed releases and record the versions actually installed. Command references for this workflow were reviewed on 29 October 2026; product support and flags can change. Instructions and output shapes are not claims of a live assessment.

Step-by-Step Tool Operation

1. Export the original training message as an .eml file and keep its hash. Use the mail client's source/message-details view to identify the receiving gateway's Authentication-Results and Received chain. Do not trust a sender-inserted Authentication-Results header.
2. Prepare a synthetic copy for model analysis. Replace recipient identifiers and tokens, retain header names and structural relationships, and record which fields were redacted. Keep the unredacted original access-controlled if retention is approved.
3. Run the local inspection commands below. The simple header filter prints selected one-line fields; folded lines, MIME boundaries, and duplicate fields still require the mail client's parsed/source view or a proper email parser.
4. If the owner approves DNS checks, enter the exact approved sending domain and retrieve TXT policy. For DKIM, obtain the actual selector from the message; do not guess or enumerate selectors. Missing records and DNS errors must remain distinct observations.
5. Compare envelope domain, visible From domain, DKIM d= domain, Reply-To, and DMARC alignment. Ask AI to explain discrepancies from the redacted evidence without sending any message or changing mail policy.
6. Attach the message hash, trusted gateway result, policy lookup time, and human verification outcome to the tabletop report. Retest the callback/reporting procedure, not a more persuasive lure. Delete temporary redacted working copies according to policy.

From: Training Exercise <[email protected]>
To: Consenting Lab Team <[email protected]>
Subject: Approved exercise fixture
Authentication-Results: mx.example.test; spf=pass smtp.mailfrom=training.example.test; dkim=pass header.d=training.example.test; dmarc=pass header.from=training.example.test
X-PSC-Exercise-ID: SIM-021

$PSVersionTable.PSVersion
Get-FileHash -LiteralPath .\exercise.eml -Algorithm SHA256
Get-Content -LiteralPath .\exercise.eml | Select-String -Pattern '^(From|To|Reply-To|Return-Path|Authentication-Results|Received|X-PSC-Exercise-ID):'
$MailDomain = (Read-Host 'Approved mail domain for DNS policy review').Trim()
if (-not $MailDomain -or $MailDomain -match '[/\\\s:]') { throw 'Enter the approved DNS name, not a URL or address' }
Resolve-DnsName -Name $MailDomain -Type TXT -DnsOnly
Resolve-DnsName -Name ('_dmarc.' + $MailDomain) -Type TXT -DnsOnly

Expected Evidence and Interpretation

The header block is explicitly synthetic, not a real delivery verdict. A real report should distinguish published policy from the receiver's actual validation. SPF pass can coexist with a non-aligned visible sender; a passing DKIM signature can use another domain; DMARC pass does not make an authenticated lookalike or an unsafe business request legitimate. No user susceptibility score follows from these commands.

For example, an approved training sender passes DMARC but the help desk still performs its known-number callback. Record both technical authentication and successful process verification rather than treating one as a replacement for the other.

Troubleshooting and Cleanup

If the .eml is unavailable, obtain a permitted original export rather than reconstructing headers from a screenshot. DNS lookup failure should be labelled failed measurement, not absent policy. Do not broadly allowlist the sender to improve a gateway-control result. Close test mailboxes or expire approved exercise tokens at the end, remove temporary exports, and keep only the agreed anonymised evidence.