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 are doing what they're supposed to do - without waiting for a real attacker to find out for you. Two attack types ship today:

Phishing email simulation. Send realistic lure emails to selected employees, see who opens, clicks or submits credentials, and automatically assign refresher training to anyone who falls for it.
IoC dropping. The browser extension fetches a known-bad test file (EICAR-style probe, Mimikatz string signature, PowerShell pattern) so the request travels through your web proxy, AV and EDR. If something silently lets it through, you find out - and have a date and a screenshot to show for it.

The nav menu entry is Breach & Attack Simulation. The module is gated by its own subscription, so you can switch it on independently of the rest of PolicyClue.

What you need before you start¶

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 ("IT Helpdesk") and the local part ("noreply") of the visible From: per simulation - the envelope sender stays pinned to the authenticated mailbox so strict relays (Exchange, Mailcow, Gmail relay) 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. Pick hostnames that go through your full inspection stack - proxy, AV, NDR. Allow-listing them past inspection defeats the whole point of the test.

If either is missing or misconfigured the platform refuses to send a simulation rather than going out with a broken envelope.

Targets - who can be simulated¶

Open Breach & Attack Simulation → Targets. The list scales to any roster size and merges three sources into one table:

CSV bulk import for manual targets. Attack Settings → Bulk import (CSV) takes a CSV with the 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 M365 are never touched by Replace mode.
Logs sync - a daily job picks up email addresses it sees in recent PolicyClue events and adds them as targets, so anyone using a corporate device naturally appears.
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, since the next sync would just re-create the row anyway.
View Timeline - opens a 90-day activity timeline for that target, reusing the same inspector you already know from alerts.

If your tenant has activity anonymization turned on, 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. Type is locked once saved. The settings card holds the simulation identity (name, sending profile, hostname, sender display name, optional envelope sender, 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.
Refresher training. Pick a Training that gets auto-assigned when a recipient triggers the chosen event (Open / Click / 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 are first asked 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 <span data-hint="Why this is suspicious">the suspicious text</span> inside the email body. The exact snippet is shown for reference next to the toggle, and 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 on the training page (game first), and the weekly reminder email keeps nudging until everything assigned is done. 4. 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. Personalisation tokens (first name, last name, email, position, simulation name) come from the target list. Date and time tokens (current date, current time, end of week, end of month) are resolved against the deployment timezone when the mail is dispatched, with optional offsets like plus 10 minutes, minus 5 minutes, plus 3 business days, or 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. 5. 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. 6. Launch. No per-recipient picker. Pick a Target source (all sources / manual entries / discovered from logs / M365 directory) and Launch sends to every enabled target matching that filter. The once-per-calendar-month cooldown only applies to auto-mode simulations (see below); manual launches are admin one-shots and don't apply it. The launch dialog tells you exactly which source you picked and how many people that means before you confirm. The Restrict sends to business hours toggle on the simulation editor controls whether sends are clamped into the chosen window-of-day in the chosen timezone. Off by default; turn it on for office-hours-only tenants. 7. Cancel. Cancel simulation stops further sends. Pending mails are cancelled atomically - 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 sending profile and the landing-page hostname are not admin-pickable in auto mode. Every month the platform picks them at random from the sending profiles and BAS hostnames your administrator configured at deployment, so the envelope rotates over time. If you pinned the same profile for every auto-spawned simulation, your users would learn to spot it - randomization keeps the test honest.

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, interpreted in the selected timezone. Use deployment default falls back to the platform-wide timezone, so a single-region tenant doesn't have to pick a zone at all. A multi-region tenant can pin each row to the workforce's local time instead. When the toggle is off, sends can fire any hour in the launch window - useful for desk-less workforces (warehouse, healthcare) where "business hours" doesn't translate.

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 dreaded "we got hit ten times in a row" scenario. Manual simulations don't count toward that cooldown - they're admin-driven one-shots and shouldn't lock auto out of a target. 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 lets you restrict which kinds of templates are eligible:

Credential harvest - fake login pages (Microsoft 365, SharePoint, Passbolt, 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 - it gives the platform the full template library to draw from. Tick boxes only when you want to focus a tenant on a specific style (e.g., a finance team that should be 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 hostnames 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 (EICAR-style). 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 PowerShell, AMSI-bypass patterns). Trip EDR / AMSI 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 weaponised, 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 / 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 with recent events.
IoC Droppings - files delivered, blocked-inline vs. post-download vs. undetected, average time-to-detect, breakdowns by template family ("which gaps does my stack still have?"), and an activity table.

Every simulation also gets 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 - find-all-or-restart, no auto-pass. See Manual phishing simulations above for how to mark indicators in the email.
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, so there's nothing new for the employee to learn.
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 - extension or web link - clears the assignment.
Off-boarded users are not nagged. If a user is no longer on your roster (their target was disabled by the directory sync or removed through CSV import) 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 - someone left the company for good, or the assignment was created in error - use the Open Training Assignments panel below.
Reminder email template. The reminder body is editable per tenant on the Attack settings page (subject + body). 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. Author the template in the language your organization uses; the reminder is the same wording for every recipient.

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 (enabled), was off-boarded since (disabled), or is no longer in the system at all (missing). Reminder emails are sent only for enabled 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: the person left, the assignment was created in error, or you simply want to call the matter closed. Deletion removes the open assignment only - 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 of using these panels, 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 organisations. Higher percentages just mean the same pool gets retested faster, not deeper insights.