Breach & Attack Simulation¶

The Breach & Attack Simulation module lets you periodically test that your people, your mail filter, your AV, your EDR, and your web proxy work — without waiting for a real attacker to find out for you. Two attack types ship today:

Phishing email simulations. Send realistic lure emails to selected employees. See who opens, clicks, or submits credentials. Refresher training is auto-assigned to anyone who falls for it.
IoC dropping. The browser extension fetches a known-bad test file (industry-standard AV probe, offensive command strings, MITRE-tagged behavioral patterns). The download travels through your web proxy, AV, and EDR. If it silently gets through, you find out — with a date and a screenshot.

The module is gated by its own subscription and can be switched on independently of the rest of PolicyClue.

Prerequisites¶

Two pieces of infrastructure need to be in place. Your administrator or hosting partner sets these up once for the whole deployment:

Sending profiles — one or more SMTP senders (each with its own authenticated mailbox and from-domain). Every simulation picks a profile by name. You can override the display name and the local part of the visible From: per simulation. The envelope sender stays pinned to the authenticated mailbox so strict relays still accept the submission, and the from-domain is locked to the profile so SPF, DKIM, and DMARC alignment stays intact.
BAS hostnames — one or more dedicated hostnames used for phishing landing pages and IoC file delivery. They must route through your full inspection stack — proxy, AV, EDR — because that's what the test measures. Do not allow-list them past inspection.

If either is missing or misconfigured, the platform refuses to send simulations rather than going out with a broken envelope. Both are configured under Deployment.

Targets¶

Open Breach & Attack Simulation → Targets. The list merges three sources into one table:

CSV bulk import for manual targets. Attack Settings → Bulk import (CSV) takes a CSV with columns email (required), first_name, last_name, position. The optional Replace mode flag soft-disables existing manual rows that aren't in the new CSV; re-add them in a future import to switch them back on. Targets discovered from logs or from Microsoft 365 are never touched by Replace mode.
Logs sync — a daily job picks up email addresses from recent PolicyClue events and adds them as targets, so anyone using a corporate device appears automatically.
M365 sync — when the M365 module is connected, mailboxes from your Microsoft 365 directory flow in nightly.

Each row has two actions:

Enable / Disable — soft-disable a target so simulations skip them. Hard delete isn't offered — the next sync would recreate the row anyway.
View Timeline — opens a 90-day activity timeline for that target, reusing the alert inspector.

If your tenant has activity anonymization enabled, the Targets page shows a notice: the timeline matches by email, so anonymized events (which carry a rotating ID instead of an email) won't appear there.

Manual phishing simulations¶

Create simulation. Simulations → New Simulation. One editor handles both attack types — pick Simulation type at creation. The type is locked once saved. The settings card holds the simulation identity (name, sender domain and local part, hostname, sender display name, refresher training and trigger, target source, schedule). The content card has tabs for Email, Landing, IoC, Recipients, and Results; only the relevant tabs appear for the chosen type.

The sender is built from a domain (dropdown of PolicyClue-managed look-alike domains that carry SPF and DKIM records) and a local part you type freely — common prefixes are suggested in an autocomplete list. The two combine into the visible From address.
Refresher training. Pick a Training that gets auto-assigned when a recipient triggers the chosen event (Open, Click, or Submit). Anyone tripping the simulation gets the matching awareness content right then — no IT ticket, no nagging email.
Phishing-indicator spotgame. Optional toggle below the email editor. When active, users who fall for the simulation first have to spot the suspicious elements in the original email before the refresher training opens. They have to find every indicator in one round — if they give up, the indicators are revealed for a few seconds and the round restarts.

To turn a piece of text into a clickable indicator, wrap it in the snippet shown next to the toggle inside the email body. The editor lists every indicator it detects in a live preview panel below the email. The toggle stays disabled until at least one indicator is present.

Spotgame and refresher are independent. A simulation can ship just the game, just the refresher, both, or neither. Whichever pieces are configured run in order (game first), and the weekly reminder email keeps nudging until everything assigned is done.
Placeholders. Both the email and the landing page support tokens that are filled in at send time per recipient. The editor shows them as click-to-copy chips above the body. Personalization tokens (first name, last name, email, position, simulation name) come from the target list. Date/time tokens (current date, current time, end of week, end of month) resolve against the deployment timezone when the mail is dispatched, with optional offsets — plus 10 minutes, minus 5 minutes, plus 3 business days, plus 1 week — so a "quarantine notice" timestamp always looks current and a "submit by Friday" deadline always points at the right Friday. The same tokens work in the subject line and on the landing page.
Test send. Test sends a one-shot preview to your own inbox. The preview is not tracked, so you can re-test as often as you like. For IoC simulations Test triggers the download in your own browser — handy to confirm what the AV says on a known-good machine before going live.
Launch. No per-recipient picker. Pick a Target source (all sources / manual entries / discovered from logs / M365 directory) and Launch. The dialog tells you which source you picked and how many people that means before you confirm. The Restrict sends to business hours toggle controls whether sends are clamped into a window-of-day in the configured timezone. Off by default; turn it on for office-hours-only tenants.
Cancel. Cancel simulation stops further sends. Pending mails are cancelled at once — nothing already in flight slips out.

Auto phishing simulations¶

In Attack Settings → Auto mode (phishing): enable, set a monthly percentage, pick a default refresher training, the trigger event, and a Target source. A live preview underneath the form shows you the projected pool size and the resulting quota for the current month — so you can size the percentage before saving.

The sender envelope and the landing-page hostname are not admin-pickable in auto mode. Every month the platform picks a random sender domain, a random local part from a built-in list of common notification prefixes, and a random landing-page hostname from the BAS hostname list. Randomization keeps the test honest — pinning the same From address would let users learn to spot it.

Business hours and timezone¶

Below the main form there is a Restrict sends to business hours toggle with a start hour, end hour, and timezone dropdown. When the toggle is on, every send lands inside the chosen window, in the selected timezone. Use deployment default falls back to the platform-wide timezone, so a single-region tenant doesn't have to pick one at all. Multi-region tenants can pin each row to the workforce's local time. When the toggle is off, sends can fire any hour — useful for desk-less workforces (warehouse, healthcare).

Each month the platform:

Builds the eligible pool (active targets matching the source mode, minus anyone already hit this month by an auto-mode simulation).
Picks a quota (rounded up so 1% of a small org still tests at least one person).
Spawns one rolling simulation for the month with a random sending profile and landing hostname, and spreads the sends across the configured business-hours window of the remaining month (or 24/7 when the toggle is off).

Every employee receives at most one auto-mode phishing simulation per calendar month — a hard rule that prevents the "we got hit ten times in a row" scenario. Manual simulations don't count toward the cooldown; they're admin-driven one-shots. Phishing and IoC drops are independent, so the same employee can get both in the same month — just not two of either via auto.

Calendar-month boundaries follow the platform-wide timezone, so a month rollover at midnight in your local timezone won't double-count anyone.

Template categories¶

The auto-scheduler picks a phishing template at random for each monthly simulation. The Template categories section on the auto-mode form restricts which categories are eligible:

Credential harvest — fake login pages (Microsoft 365, SharePoint, banking sign-ins, etc.). The largest category.
Business Email Compromise — CEO-fraud-style plain-text emails, no login form on the landing.
Lure — reward bait (gift cards, packages, vouchers). Landings collect non-credential data like credit-card numbers.
Attachment — emails that pretend to ship an attachment but actually link to a credential page.

Leaving every box unticked = match all categories. That's the recommended setting for general-purpose monthly simulations. Tick boxes only when you want to focus a tenant on a specific style (e.g. a finance team drilled mostly with BEC and lure templates).

IoC dropping¶

Each IoC simulation reserves a set of delivery slots. The browser extension checks roughly hourly for a slot it can take, and the first eligible browser claims it. The browser then downloads the test file from a dedicated BAS hostname — that download travels through your normal proxy + AV + EDR pipeline, which is exactly the path real malware would take.

The hostname for a simulation is fixed at creation time. Auto-mode simulations pick a random hostname from your BAS hostname list each month so reputation doesn't pile up on a single host. Manual simulations let you pin one hostname or fall back to random when you launch.

If the same employee uses two devices (corporate + personal laptop), each device claims its own slot — that's intentional, since you're testing two different AV environments.

What the test files are¶

PolicyClue ships system test templates in three categories:

Category	What it tests
AV baseline	Industry-standard "is the AV alive?" probes. Every reputable AV catches them — if it doesn't, your AV isn't enabled. Fastest sanity check.
EDR string signatures	Plain-text files containing offensive command strings (credential-dumper command names, encoded scripts, evasion patterns). Trip EDR rules that match on file content rather than executable hashes.
XDR behavioral patterns	Strings tagged with MITRE ATT&CK technique IDs covering LOLBin chains, dropper artifacts, persistence techniques, and product-specific behavioral markers. Designed to trigger XDR analytics that look at intent rather than signatures.

No real malware ever. Every template is plain text — signature-trip strings, nothing weaponized, no live invocation. Custom IoC payloads are not user-uploadable; adding new ones is a controlled process handled by PolicyClue staff.

Detection outcomes¶

The extension watches the download until it ends or until the detection window closes:

Blocked inline — the AV or proxy intercepted the file mid-download.
Detected post-download — the file landed but the AV deleted it shortly after. The time-to-detect is recorded, so you can compare AV reaction times across templates and hostnames.
Window expired — the file was still on disk when the window closed. Raises a high-severity alert ("undetected drop") so the SOC sees it next to real incidents.

Either way the extension cleans up the file — nothing stays on the employee's machine.

Dashboards¶

Two dedicated dashboards make the results easy to read without digging through the alerts list:

Phishing Simulations — recipients reached, click and submit rates, Outlook-add-in reports, the full opened → clicked → submitted / reported funnel, top users who fell for the simulation, top users who reported it correctly, breakdowns by template category, and an activity table.
IoC Droppings — files delivered, blocked-inline vs. post-download vs. undetected, average time-to-detect, breakdowns by template family, and an activity table.

Every simulation also has a per-simulation view via the Recipients and Results tabs in the simulation editor.

Reporting and refresher training¶

Three pieces tie the simulation back into your day-to-day awareness program:

Outlook add-in reporting. When an employee correctly reports a simulated phishing email via the PolicyClue Outlook add-in, they see a positive feedback message right there. Reporting becomes a routine that feels acknowledged — and your real reporting volume goes up.
Phishing-indicator spotgame. Optional per phishing simulation. When enabled, users who fall for the simulation first have to spot the suspicious elements inside the original email before the refresher training opens.
Refresher training auto-assignment. When someone trips the trigger (open, click, or submit, depending on what you configured), PolicyClue assigns the configured Training to them. Until they finish it, the extension surfaces the training the next time they're online — the experience is the same as for any other awareness training.
Web fallback for users without the extension. The end-of-simulation page also shows a Start training now button that opens the same training in any browser — no extension needed, same look and feel. A reminder email goes out daily to users with training older than seven days and re-nudges every seven days until completion. Either entry point clears the assignment.
Off-boarded users are not nagged. If a user is no longer on your roster the reminder email is skipped silently. The open assignment is left in place: if the same person comes back on the roster later, the reminders resume the next day. To clear the assignment outright, use the Open Training Assignments panel below.
Reminder email template. The reminder body is editable per tenant on the Attack settings page. Available placeholders (recipient name, organization name, training URL, etc.) are shown as click-to-copy chips above the editor, and a built-in default is shown collapsed for reference.

Cleaning up after a simulation¶

Two admin panels live on the Attack settings page for after-the-fact cleanup. Both are tenant-scoped: you only ever see and act on entries belonging to your own tenant.

Open Training Assignments (Members). Lists every employee who fell for a phishing simulation and still has an open spotgame and/or refresher to complete. Each row tells you whether the user is still on your active roster, was off-boarded since, or is no longer in the system. Reminder emails are sent only for active-roster rows — the other two are skipped automatically so an ex-employee never gets nagged at their old company address. Use the bulk-delete button to clear assignments outright when the situation is permanent. Deletion removes only the open assignment; the original event ("this user submitted the phishing form") stays on the dashboard for audit.
Scheduled queue. Shows pending phishing emails and queued IoC drop slots that haven't fired yet. Filter by kind (phishing mail / IoC) or by simulation. Already-sent mails and claimed IoC drops are kept for audit and don't appear here. Bulk-delete is the per-row equivalent of Cancel simulation — useful when you need to stop one email or one drop slot without cancelling the whole simulation. Rows that are currently being delivered cannot be deleted; their checkbox is greyed out.

If you cancel a whole simulation instead, the queued mails and IoC slots are marked cancelled automatically — the records stay for audit, but nothing else fires.

Privacy and safety¶

Submitted passwords never reach the server. When a simulation is saved, PolicyClue strips the password fields from the landing page so the browser excludes them from its form submission. The values stay on the user's machine — there is no hash, no encrypted copy, no server-side filter to fail open. The platform never sees the password.
Anonymization is respected. Although BAS dashboards are intended to surface who fell for the simulation (so you can target refresher training), the rest of PolicyClue continues to honor the tenant's anonymization mode for non-BAS events.
Cancellation is final. Cancelling a simulation stops new sends and marks queued mail as cancelled before anything else leaves the building.

Operational guidance¶

Tell your SOC. IoC drops will trigger AV alerts on real endpoints — by design. Brief the SOC ahead of enabling auto mode so they don't open a real-incident ticket on your simulation.
Don't allow-list the BAS hostnames past your inspection stack. The whole point is to make sure the request travels through every layer you rely on.
Pause during real incidents. When you're triaging actual phishing or malware, cancel the active BAS subscription so simulated traffic doesn't noise up the live alert feed.
Use sensible percentages. Auto mode hits 1–10% of the eligible pool per month for most organizations. Higher percentages just mean the same pool gets retested faster, not deeper insights.