phishing-sim

name	phishing-sim
description	Phishing-simulation campaign workflow — RoE and ethical-scope template, population segmentation, pretexting patterns (HR/IT/finance/vendor/calendar), infrastructure (sender domain, SPF/DKIM/DMARC, tracking), click-rate and credential-success metrics, opt-out and duty of care, NL/EU AVG context for employee monitoring.

Phishing Simulation

Awareness goal + ethical template: phishing sims aim to improve organizational awareness, not to ridicule individuals. No ad-hoc spear phishing against specific people without written sign-off from management AND HR. No pretexts that fundamentally sow mistrust (family emergencies, illness of a colleague, fabricated HR disciplinary actions). NL/EU context: employee monitoring falls under the AVG (GDPR) plus labor law; consultation with the works council and/or employee representation is usually required before campaigns. This skill structures; legal review belongs with legal/HR/DPO.

When to use

Phishing sims are the standard for organizational awareness and initial-access testing in red-team engagements. They are also the easiest path to becoming a source of distrust if executed poorly. Discipline on pretext choice, opt-out, and post-campaign feedback is not extra — it is the campaign.

Triggers on:

• A question like "design a phishing campaign", "which pretexting patterns are reasonable", "SPF/DKIM/DMARC for our sending infra", "click-rate baselines", "post-campaign debrief", "how do we do this AVG-correctly".
• A red-team engagement where initial access via phishing is needed and the RoE explicitly permits credential harvesting or malware delivery.
• A security-awareness program with periodic (quarterly/half-yearly) sims as a training vehicle.
• A handoff from recon-agent (employee OSINT output as input for the target list).
• A compliance question from nis2 Art 21 (cyber hygiene, awareness training) or iso27001 Annex A.6.3 (awareness).

When NOT (handoff)

• Post-foothold action after a successful phish → post-exploit, c2-hygiene, ad-attacks. This skill stops at click/credential capture/payload delivery.
• Web-app exploit context (the phishing link lands on a controlled web app) → web-exploit-triage, payload-crafter.
• Reporting → pentest-reporter.
• AVG/legal review itself → DPO + legal. This skill names obligations; it does not give advice.
• Vendor procurement (Knowbe4 / Cofense / Hoxhunt selection) → out of scope; this skill provides methodology, not a vendor comparison.
• Detection tuning on phishing emails in the inbox → detection-engineer, siem-query.
• Forensics after a real attacker phish → ir-runbook, forensics-assist.

Approach

Six phases. Phase 1 (RoE + ethical template) and phase 6 (debrief + opt-out + duty of care) are the safeguards that keep "campaign" from turning into "awareness incident".

1. Rules of Engagement and ethical template

Before any campaign design there is a document stating:

• Goal of the sim. Awareness training, baseline measurement, red-team initial access, or compliance evidence?
• Target population and exclusions. Which departments, which seniority levels. Who must not be included (employees in re-integration, people who recently reported burnout, external contractors without formal employee status). HR input required.
• Permitted pretexts (see phase 3) and excluded pretexts. Standard exclusions: medical cases, illness of a colleague, fictitious HR disciplinary actions, personal financial-damage emails, relationship-related messages, child-abuse reports, etc. Lock the list down before the campaign.
• Time window. Working hours? Off-hours excluded? Holiday periods? Usually: do not send before Monday 9:00 or after Friday 17:00, not in the week before or after well-known rest moments.
• Opt-out procedure. Everyone has a path to be removed from future sims, without consequences. Communicate this pre-campaign in a general awareness update.
• Reaction procedure for those who react (click, enter credentials, open an attachment). Immediately a training page rather than punishment feedback.
• Reaction procedure for those who recognize and report it. Positive confirmation — that is the behavior change you are looking for.
• Oversight sign-off: in NL this means consultation with the works council (if there is one) plus DPO sign-off plus management sign-off. Some sectors (healthcare, government) have additional requirements.
• Data handling. Which data do you collect (click, credential, IP, user-agent)? How long retained? Aggregates open, individual data not — that is the standard.

No campaign without this document. It is not paperwork; it is the line between training and HR violation.

2. Population segmentation

Not one campaign for 5,000 people. Segmentation increases realism and reduces collateral damage.

• Per role: HR-style pretext to HR is ineffective (they recognize it); IT-style pretext to IT same. Cross-role pretexts are more realistic.
• Per technical level: low-tech people expect different triggers than the dev team. Adapt the pretext to the target's vocabulary.
• Per location / language: NL employees a Dutch-language email; international offices in local language or English with a tone adjustment.
• Cohort rotation: not always the same group. Spread across quarter cohorts so each employee is hit ~1× per year.

3. Pretexting patterns at class level

Class level, not copy-paste templates. Per category, the archetypal shape and the spectrum from light to ethical-edge.

• HR administration: salary adjustment, contract update, holiday-request confirmation, occupational-health procedure update. Permitted: generic administrative flow. Excluded: fabricated individual HR actions against the target ("you have been assessed...").
• IT / helpdesk: password-reset prompt, MFA enrollment, security-update install, mailbox quota. Permitted: organization-wide messages. Excluded: impersonation of a named, known IT person without that person's sign-off.
• Finance / invoices: vendor invoice, payment confirmation, expense-report correction. Permitted: reasonable amounts, generic vendor. Excluded: amounts that cause real fear (€10k urgent payment), names of real vendors without their sign-off.
• Vendor / customer: shipment update, support-ticket update, software-license renewal. Permitted: generic. Excluded: real vendor impersonation without their prior sign-off (legally trademark territory).
• Calendar / collaboration: meeting invitation, document-share notification (Sharepoint/Drive/Dropbox style), Teams/Slack mention. Classic 2024–2026 pretexts; watch out for exact UI imitation (lightly trademark territory).
• Authentic-looking but generic: "Your account access requires verification" — works surprisingly well, because the very fact that "it is generic" lets it slip past attention.

For red-team context with explicit sign-off, spear-phishing with OSINT input from recon-agent (LinkedIn title, project reference) is possible. But each spear target requires explicit pre-sign-off from management plus (where possible) the target themselves.

4. Infrastructure: sending, landing, tracking

• Sender domain:
  • Aged and registered weeks before the campaign (see c2-hygiene phase 3).
  • SPF, DKIM, DMARC fully configured to avoid soft-fail flagging. The goal is for email to arrive, not be rejected. (Ironically: campaign emails themselves must be 100% AVG/email-standard compliant.)
  • Cohort/lookalike domain that looks like — but is not — the target domain ('rnicrosoft.com', 'cornpany.com'). Weigh trademark impact.
• Landing page:
  • No real credential capture against production passwords; use a training page that says "this was a sim" with educational content. Or, in red-team context, controlled credential capture with immediate destruction after verification.
  • HTTPS required (otherwise browser flagging).
  • Mobile-responsive — most clicks come from phones.
• Tracking:
  • Open tracking via 1px image or unique link per recipient.
  • Click tracking with a unique URL per recipient.
  • Aggregate data is fine; individual data only for those with explicit, hosted consent. Anonymize post-campaign.
• Hosting: payload layer on a separate server, separate from the email sender and separate from the team server.

NL/EU AVG context for monitoring: data on individual click behavior is personal data under the AVG. Processing is possible on the basis of legitimate interest (AVG Art 6(1)(f)) provided a balance test is documented. DPO consultation required. With tracking data: aggregate ASAP, do not retain individual data longer than strictly necessary.

5. Execution and metrics

During execution:

• Channel monitoring: number of arrivals in inbox vs. spam folder (delivery rate). Without delivery there is no measurement.
• Click rate (CTR): % of targets that open the link.
• Credential-success rate: % that enters credentials (when that layer is present).
• Reporting rate: % that reports the email as suspicious to helpdesk/SOC. This is the most important metric — it measures the behavior change.
• Time-to-report: average time between sending and the first report. Shorter = better.
• Helpdesk/SOC load: number of reports per hour. Scales with campaign size; brief the helpdesk in advance so they are not overwhelmed.

Real-time check before escalation: if click-rate explodes (>40%) or reporting-rate stalls (<5%), pause and reconsider the pretext. Something is off.

6. Debrief, training, opt-out, duty of care

After the campaign:

• Per-target follow-up for those who clicked: an immediate education page, opt-in for a 5-minute training module. No punishment, no name-and-shame.
• Per-target acknowledgment for those who reported correctly: a thank-you email or internal recognition (if the person prefers it).
• Aggregate report to management and involved teams: percentages, no names, trends compared to the previous campaign.
• Lessons learned: which pretext worked (high), why. Which did not work (low), why. Input for the next campaign and for the security-awareness curriculum.
• Opt-out update: anyone who explicitly indicated they no longer wish to participate → exclusion list for the future.
• Detection feedback to SOC/detection-engineer: which email features could have been detected by the secure-email gateway, how was bypass possible?
• Deliberate cleanup of data: anonymize or remove tracking data after report delivery, in line with the phase-1 data-handling agreements.

Duty of care: if during or after the campaign someone reacts unusually emotionally (complaint, sick note linked to the campaign, escalation to HR), pause the campaign, involve HR + DPO, run an evaluation. No defending it from "it was just a sim". Patterns count.

Verification-loop

Layer 1: scope (RoE document complete and signed? exclusion list verified? works-council consultation done?), assumptions (data handling AVG-compliant supported?), gaps (debrief procedure operationally ready before sending?). Layer 2: AVG article references correct, CFAA/Computervredebreuk context (NL Wetboek van Strafrecht art 138ab) not falsely claimed as covered, no invented vendor-policy statements, click-rate baselines not served as "studies prove X" without a source.

Output

Phishing-sim plan / report — <campaign name>
Goal: <awareness baseline | red-team initial access | compliance evidence>
Period: <start → end> | RoE signed: <date + sign-offs>

Scope:
  Target population:    <segments + N>
  Exclusions:           <list>
  Permitted pretexts:   <categories from phase 3>
  Excluded pretexts:    <explicit list>
  AVG ground:           <legitimate interest with balance-test ref>
  Works-council/DPO:    <yes/date>

Execution:
  Pretext used:                <category + version ref>
  Sender domain:               <FQDN, age, SPF/DKIM/DMARC>
  Landing page:                <target URL + training content>
  Track mechanism:             <pixel/unique-link>
  Number sent:                 N
  Delivered (inbox):           N
  Spam folder:                 N

Metrics:
  CTR:                  <%>
  Credential success:   <%>
  Reporting rate:       <%>
  Time-to-first-report: <minutes>
  Helpdesk load:        <peaks>

Per-target follow-up:
  Education-page completion:    <% of clickers>
  Opt-out requests received:    <N>
  Escalations to HR/DPO:        <N + type>

Lessons learned:
  What worked:          <pretext element + why>
  What did not:         <element + reason>
  Input for next sim:   <change for cohort N+1>

Detection feedback (handoff to detection-engineer):
  Email headers/content SEG could have caught: <list>

Cleanup:
  Tracking-data anonymization:   <date>
  Sender-domain decommissioning: <date>

Verification-loop: ...

References

• NIST SP 800-50 — https://csrc.nist.gov/pubs/sp/800/50/r1/final. Building an Information Security Awareness and Training Program.
• ENISA Awareness Material — https://www.enisa.europa.eu/topics/awareness-and-training.
• Autoriteit Persoonsgegevens — employee monitoring — https://www.autoriteitpersoonsgegevens.nl/themas/werk-uitkering/werknemers/de-werknemer-volgen. NL context for AVG in sims.
• AVG Art 6, Art 88, Art 35 — https://eur-lex.europa.eu/eli/reg/2016/679. Processing basis, employee context, DPIA.
• NIST Phish Scale — https://www.nist.gov/itl/applied-cybersecurity/nist-phish-scale-method-rating-human-phishing-detection-difficulty. Difficulty-rating methodology for pretexts.
• MITRE ATT&CK — Initial Access (TA0001) / Phishing (T1566) — https://attack.mitre.org/techniques/T1566/.
• NCSC-NL — Phishing guidelines — https://www.ncsc.nl/.
• DMARC.org — https://dmarc.org/. Sender-authentication spec.

Categories

• pentest