Alerting & Response

Alerting

A decoy fires on behaviour nothing legitimate explains, so alerting is not about finding signal in noise. It is about making sure the signal arrives, that it is believed, and that it says how bad the interaction was.

In this pillar

• Why deception differs — why the usual false-positive problem disappears
• Where the signal comes from — which log records access to each kind of decoy
• Making sure it arrives — four properties the alert pipeline needs
• Deciding severity — decoy fidelity × how far the adversary went

Why deception differs

A conventional detection fires on behaviour that is usually malicious, so most of the engineering goes into suppressing false positives. A decoy fires on behaviour that has no legitimate explanation at all — nobody has a reason to authenticate with a credential that was never issued to a real service.

That changes what can go wrong. The risks are no longer false positives; they are a broken delivery path, an alert nobody believes, and an alert that quietly tells the adversary they have been caught. You are not trying to find signal in noise — the signal is already clean. You are trying to make sure it arrives, that it is believed, and that it carries enough context to act on.

Where the signal comes from

Decoys do not usually emit telemetry themselves. They are observed by the platform they live in, so the design question is always: which log already records access to this object, and is that log switched on?

Making sure it arrives

A clean signal is worth nothing if the path carrying it is broken, disbelieved, or readable by the adversary. Four properties the pipeline needs:

1. A channel of its own

Deception alerts should not land in the same queue as routine detections. Their value is that they are near-certain; routing them through a stream where 95% of items are noise destroys that advantage within a week.

2. Continuous proof of life

A decoy that stops reporting looks exactly like a decoy nobody has touched. Trigger one on a schedule and alert if the event does not arrive end-to-end — the canary-of-canaries. Without it you cannot distinguish a quiet network from a broken pipeline.

3. An alert path that does not leak the inventory

If the rule set, SIEM queries or IaC state enumerate every decoy, then an adversary who reaches your tooling gets a complete map of what to avoid. Treat the decoy inventory as sensitive material in its own right.

4. Context attached at fire time

The responder needs the decoy's fidelity, its intended tier, what a real interaction would mean, and what it is not able to tell them. Deciding that during an incident wastes the advantage the decoy just handed you.

Deciding severity

Two variables decide severity: how real the decoy was, and how far the adversary went. A touch on an inert tripwire and a shell on an interactive decoy are not the same event.

A starting point, not a policy. Click any tier to see what it commits you to.

Real-time by platform

The same two-stage pipeline on every platform. Stage 1 runs next to the decoy and forwards only events that name a decoy. Stage 2 runs centrally and decides which actions alert. Then enrich, suppress known scanners, and notify on a channel of its own.

Amazon Web Services

Signal sources

The pipeline

1. Stage 1 (at the decoy): In each decoy account and every enabled Region, put one EventBridge rule on the default bus with state ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS. Its event pattern matches decoy identifiers in detail.requestParameters or detail.resources, generated from the inventory. The target is the central event bus, sent through a role whose only permission is events:PutEvents on that bus ARN. Restrict who can read the rule (events:DescribeRule, events:ListRules), because the pattern is a decoy list.
2. Stage 2 (central): In the monitoring account, put rules on the central bus, one per service (source plus an eventName list of targeted actions), also with state ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS so read-only events match. The target is a Lambda function. Configure retries and a dead-letter queue on the target.
3. Enrich and suppress: The Lambda function looks up the decoy in the private inventory (kept in the monitoring account), adds technique, tier and path, and extracts userIdentity, sourceIPAddress, userAgent, Region and account. It applies the governed suppression list and removes duplicates. Drill events are confirmed against the drill record, never by a label in the event.
4. Notify: SNS topic in the monitoring account feeding a dedicated decoy-alert channel or pager. Function errors and dead-letter-queue depth raise alarms to the same channel.

Proof of life

EventBridge Scheduler in the monitoring account sends a synthetic event to the central bus every few minutes, carrying a per-run value recorded centrally, and expects it in the drill channel. Less often, at random times, a role in the decoy account named like routine automation (<team>-<function>-role) reads a random decoy. A CloudWatch alarm on a 'proof received' metric with missing data treated as breaching fires when either proof misses its window.

Pitfalls

• A forwarding or destination rule left in the default ENABLED state silently drops read-only events such as AssumeRole and GetSecretValue. Both rules need ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS.
• CloudTrail events reach EventBridge only in the Region where they are recorded. Global-service and STS events land in the Region of the endpoint that was used. Deploy stage 1 in every enabled Region.
• Data events (S3 objects, DynamoDB items) are off by default and charged per event. Trails are often set to exclude KMS or read events to save cost, which blinds decoys.
• Delivery is best effort and undocumented for the EventBridge path. Never assume seconds. Measure with proof-of-life.
• Event patterns have a size quota (check the current EventBridge quotas). Large inventories need several stage 1 rules.
• Event history keeps 90 days of management events only. Retain raw decoy events centrally.
• Real proof-of-life touches appear in CloudTrail. Anyone who can read the trail can spot a regular touch pattern, so randomise the timing and the decoy, and restrict trail read access.

Sources: [1] [2] [3] [4] [5] [6]

Microsoft Azure

Signal sources

The pipeline

1. Stage 1 (at the decoy): Diagnostic settings scoped to the decoy resources act as the resource filter. Send them to an Event Hub in a security subscription for the fastest stream, or to the central Log Analytics workspace. Send the activity log by diagnostic setting at subscription or management-group scope. Restrict who can read diagnostic settings in decoy subscriptions.
2. Stage 2 (central): Option 1: an Azure Function on the Event Hub filters operationName against the targeted-action set (SecretGet, KeyDecrypt and so on). Option 2: a log search alert, or a simple log search alert that evaluates each row, in the central workspace, filtering the same actions, and joining to an inventory watchlist kept in the security subscription.
3. Enrich and suppress: The Function, or a Logic App behind the alert, adds inventory context, caller identity (UPN, appId, object ID), callerIpAddress and resource ID, and applies the governed suppression list. Drill events are confirmed against the drill record.
4. Notify: Azure Monitor action group to a dedicated decoy-alert channel or pager. Failures of the Function or Logic App alert to the same channel.

Proof of life

A timer-triggered Function with its own managed identity, named like routine automation, reads a random decoy secret at random intervals. The touch is recorded centrally. Microsoft notes that log search alerts are weaker at detecting missing data, so check for absence with a metric alert on a 'proof received' custom metric, or a log query with a window wider than the 3 to 10 minute ingestion delay.

Pitfalls

• Data-plane reads (getting a secret, reading a blob) are not in the activity log. Without a diagnostic setting on the decoy, the decoy is blind.
• Event Grid system events cover some resource changes and Key Vault expiry or new-version events, but not reads. Do not rely on them for decoy access.
• A decoy that is the only resource with a diagnostic setting stands out to anyone who can read monitoring settings.
• Plan for 3 to 20 minutes on the activity log and up to 10 minutes on resource logs. Sub-minute response is not possible from these sources.
• A newly routed Entra log destination can take up to three days to start. Do not deploy decoy identities before it does (OP4).
• Activity log retention is 90 days unless exported.

Sources: [1] [2] [3] [4] [5]

Google Cloud

Signal sources

The pipeline

1. Stage 1 (at the decoy): A sink on the decoy project, or a non-intercepting aggregated sink on the folder or organisation, whose inclusion filter matches decoy resource names (protoPayload.resourceName) generated from the inventory. It routes to a Pub/Sub topic in a security project. Restrict logging.sinks.get on decoy projects, because the filter is a decoy list.
2. Stage 2 (central): A Cloud Run function in the security project subscribes to the topic and matches protoPayload.methodName against the targeted-action set for each service. Log-based alerting policies also work, but they apply a notification rate limit and are better suited to low-volume paging than to per-event processing.
3. Enrich and suppress: The function adds inventory context, principalEmail, callerIp, user agent and resource name, applies the governed suppression list, and removes duplicates. Google documents duplicate audit-log delivery for some sources. Drill events are confirmed against the drill record.
4. Notify: The function sends to a dedicated decoy-alert channel. Alternatively, Cloud Monitoring notification channels via an alerting policy. Function errors and Pub/Sub backlog (oldest unacked message age) alert to the same channel.

Proof of life

Cloud Scheduler publishes a synthetic message to the topic regularly. Less often, a scheduled job running as a dedicated service account, named like routine automation, reads a random decoy. A Cloud Monitoring alert on absence of a 'proof received' metric (a log-based metric on the function's output) fires when a window is missed.

Pitfalls

• Data Access logs are off by default. A decoy secret or bucket read is invisible until DATA_READ is enabled for that service.
• Google publishes no audit-log delivery latency. Treat it as minutes until measured.
• Sinks cannot route entries retroactively, and Cloud Storage sinks are processed hourly. Use Pub/Sub for alerting.
• The default VPC Flow Logs sampling (50% on Compute Engine API configurations) can miss a single connection.
• Eventarc audit-log triggers are subject to the same audit-log delay, and a newly created trigger takes up to about two minutes to become active.
• Log-based alert notification rate limits mean repeated touches may be merged. Keep the raw events in the function path.

Sources: [1] [2] [3] [4] [5] [6]

Kubernetes

Signal sources

The pipeline

1. Stage 1 (at the decoy): An audit policy rule that selects decoy objects by namespace, resource and resourceNames, at Metadata level, sent through the webhook backend (self-managed) or the managed provider's log path. The policy sits on the control plane, out of tenants' reach. Node sensors use rules matched to decoy paths.
2. Stage 2 (central): A central collector, such as the Falco k8s audit plugin or the cloud function used for that provider, matches verbs and subresources (get, list, watch, create on pods/exec, token requests) against the action set and drops known controller identities on the governed suppression list.
3. Enrich and suppress: Add the inventory entry, user.username, groups, sourceIPs, userAgent, the impersonation fields, and the pod or node identity (from node sensors). Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel through the central processor. Webhook backend errors, dropped-event counters and sensor DaemonSet health alert to the same channel.

Proof of life

A CronJob running as a dedicated service account, named like routine automation, performs get on a random decoy object at random times. The run is recorded centrally. The central processor alerts when an expected proof does not arrive within the backend's latency window.

Pitfalls

• List and watch on Secrets return their contents, so the 'ignore enumeration' rule does not apply. Controllers with cluster-wide secret watches will 'read' every decoy. Place decoys where no legitimate controller lists, or suppress only the named controller identities and review them.
• Auditing is off unless a policy file is set, and an empty rules list is invalid. Managed providers ship with control-plane audit logging off (EKS, AKS).
• On AKS, kube-audit-admin omits get and list. Use kube-audit.
• Logging Secrets at Request or RequestResponse level writes secret values, real and decoy, into the log. Use Metadata.
• Admission webhooks do not see read requests, so they cannot detect decoy reads.
• The webhook batch buffer drops events when it overflows. Alert on the drop metrics.
• GKE does not log some system requests (level None). Do not model decoys on those identities or paths.

Sources: [1] [2] [3] [4] [5]

Windows and Active Directory

Signal sources

The pipeline

1. Stage 1 (at the decoy): The SACL on the decoy object, file or share is the resource filter for 4662 and 4663. For Kerberos and logon events, the subscription's XPath query selects only events whose EventData names a decoy account or SPN, generated from the inventory. Use a dedicated Minimize Latency subscription.
2. Stage 2 (central): On the collector or central platform, match on event ID plus access mask, operation or ticket options (for example 4769 for a decoy SPN, 4662 with Read Property or Control Access on a decoy object) and drop governed suppressions.
3. Enrich and suppress: Add the inventory entry, SubjectUserName and SID, logon ID, client address, ticket encryption type and the DC or host name, and correlate with a 4624 by logon ID where present. Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel from the central platform. Monitor subscription runtime status. A source going inactive alerts to the same channel.

Proof of life

A scheduled task on a management host, running as a dedicated account named like a routine service, requests a service ticket for a random decoy SPN or reads a decoy attribute at random times, and the run is recorded centrally. The central platform alerts when an expected 4769 or 4662 does not arrive within the subscription's latency window.

Pitfalls

• Normal-mode WEF batches for up to 15 minutes. Decoy events need their own Minimize Latency subscription.
• 4662 and Kerberos events are logged only on the DC that served the request. Forward from every DC, including read-only DCs.
• A SACL can be removed silently by an administrator. Reconciliation (OP6) must check SACLs, not only that the object exists.
• Directory sync tools, backup and inventory tools read many attributes. Scope SACLs to specific attributes and access types.
• Busy DC Security logs wrap. Make sure events are forwarded before they are overwritten.
• Do not rely on the default-domain-policy audit state. Confirm the effective policy on each DC with auditpol.

Sources: [1] [2] [3] [4]

Linux

Signal sources

The pipeline

1. Stage 1 (at the decoy): An audit rule (or sensor rule) scoped to the decoy paths is the resource filter. Use a key name that looks routine, because keys appear in logs. Forward matches off the host immediately with an audispd plugin or syslog shipper.
2. Stage 2 (central): The central collector matches syscall and permission (read, open, exec) and drops governed suppressions for named backup, indexing or scanning processes, matched by executable path and user together.
3. Enrich and suppress: Add the inventory entry, host, auid (the original login user), uid, exe, comm, parent process, terminal and source address of the session. Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel from the central collector. A host that stops sending, an auditd stop, or an audit CONFIG_CHANGE event alerts to the same channel.

Proof of life

A systemd timer or cron job running as a dedicated service user, named like routine automation, reads a random decoy file at random times, and the run is recorded centrally. The central collector alerts when the matching audit record does not arrive.

Pitfalls

• Many distributions ship -a never,task, which silently stops all syscall rules.
• A root attacker can stop auditd or delete rules. Forward immediately, lock with -e 2, and alert on CONFIG_CHANGE and on host silence.
• Indexers (updatedb or locate), antivirus, backup agents and configuration management read files routinely. Suppress by exact executable plus user, never by path alone.
• Audit backlog limits (-b) and rate limits (-r) drop events under load.
• Methods based on atime fail on noatime or relatime mounts. Use syscall auditing instead.
• Paths inside containers differ from host paths. Write rules for the mount namespace the sensor sees.

Sources: [1]

macOS

Signal sources

The pipeline

1. Stage 1 (at the decoy): An ES client subscribed to open and exec, with path filtering (muting everything except the decoy paths) so only decoy touches leave the host. Forward immediately to the central collector.
2. Stage 2 (central): The central collector matches the event type and process. Drop governed suppressions for named system processes (Spotlight indexing, backup, endpoint protection) by code-signing identity, not by process name.
3. Enrich and suppress: Add the inventory entry, host, user, process path, signing identity, team ID, parent process and audit token. Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel from the central collector. Client exit, revoked Full Disk Access or host silence alerts to the same channel.

Proof of life

A launchd job running as a dedicated account opens a random decoy file at random times, and the run is recorded centrally. The central collector alerts when the open event does not arrive.

Pitfalls

• Without Full Disk Access (normally granted by MDM), the ES client gets nothing.
• eslogger is not a supported production sensor and its output format can change between updates.
• Spotlight, Time Machine, iCloud sync and endpoint protection open files constantly. Match suppressions on signing identity.
• Open events are very high volume. Filter at the source.
• The legacy BSM audit subsystem is deprecated. Do not build new decoy detection on it (not verified against Apple documentation in this run).

Sources: [1] [2]

Network

Signal sources

The pipeline

1. Stage 1 (at the decoy): The decoy listener is its own resource filter: it only exists to be touched. For flow or sensor sources, filter on the decoy addresses, ports and hostnames from the inventory, at the sensor or collector.
2. Stage 2 (central): The central collector classifies by action (connection only, authentication attempt, credential submitted, command run) and drops governed suppressions for named scanners, matched by source address and schedule together.
3. Enrich and suppress: Add the inventory entry, source address and asset-inventory lookup of the source host and its owner, destination service, credentials attempted (kept in the restricted alert store only) and NAT translation where available. Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel. Listener health (no heartbeat) alerts to the same channel.

Proof of life

A scheduled job on a management host connects to a random decoy listener at random times, from an address recorded centrally. The central collector alerts when the connection event does not arrive.

Pitfalls

• Flow logs are summaries, delayed by minutes, and may be sampled. Do not use them as the only source for a T1 or higher decoy.
• Vulnerability scanners and asset discovery will touch every internal decoy. Suppress them by source and schedule together, and review the entries. A compromised scanner host is a real attacker.
• Internet-facing listeners see constant background scanning. Route them to analysis, not paging.
• NAT and proxies hide the real source. Collect translation logs.
• Banners, versions and port sets that do not match real hosts in the segment make listeners easy to fingerprint.

Sources: [1] [2] [3]

SaaS platforms

Signal sources

The pipeline

1. Stage 1 (at the decoy): Usually not possible on the SaaS side. Collapse it into the central query: poll or stream the audit API and filter on decoy object IDs and accounts from the inventory. Where the platform offers per-object alerts or streaming filters, scope them to decoys.
2. Stage 2 (central): The central processor matches the activity types that count as access (view, download, sign-in, token grant) and drops governed suppressions such as DLP and indexing service identities.
3. Enrich and suppress: Add the inventory entry, actor, IP address, user agent or client app, and object ID. Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel. Polling failures and API errors alert to the same channel.

Proof of life

A scheduled job using a dedicated account opens a random decoy object at random times, and the run is recorded centrally. Set the absence window to the source's documented lag (for example more than 90 minutes for the Microsoft 365 unified audit log).

Pitfalls

• The Microsoft 365 unified audit log has no near-real-time path. Use Entra sign-in logs for decoy identities, and treat file and mailbox decoys as slow (T0/T1) signals.
• Google Workspace OAuth token events lag by hours, while Drive and login events lag by minutes. Choose the decoy type to suit the latency needed.
• Email link scanners, previews, DLP and search indexing open decoy documents and links. Check the actor before alerting.
• Audit retention and availability depend on licence and plan.
• Polling APIs have rate limits and pagination, and can miss events if a poll fails. Track your position in the log and alert on gaps.

Sources: [1] [2] [3]

Custom applications

Signal sources

The pipeline

1. Stage 1 (at the decoy): The hook itself is the resource filter: it only fires when a decoy identifier is used. For access logs, filter on decoy paths and hosts at the shipper.
2. Stage 2 (central): The central processor classifies by action (authentication with a decoy key, read of a decoy record, request to a decoy route) and drops governed suppressions (named health checks or crawlers, by identity and source).
3. Enrich and suppress: Add the inventory entry, authenticated principal, session, source address, user agent, request ID and trace ID. Drill events are confirmed against the drill record.
4. Notify: A dedicated decoy-alert channel. Failure to emit raises an internal error metric that alerts to the same channel.

Proof of life

A scheduled synthetic client uses a random decoy identifier at random times from an identity recorded centrally. The central processor alerts when the event does not arrive within the budget.

Pitfalls

• Log sampling, DEBUG-level logging and trace sampling can drop the one event that matters. Send decoy events through a path that is never sampled.
• Asynchronous loggers and batch shippers add minutes of delay. Use a direct emit path for T1 and higher.
• A decoy that responds differently from a real object (timing, error text, status code) gives itself away.
• Crawlers and security scanners hit advertised decoy paths. Decide in advance which sources count.
• Decoy identifiers in plaintext in source code or configuration expose the inventory to anyone with repository access.

Sources: [1]

Alerting principles

The rules behind every pipeline above, and the guidelines that hold whichever alerting platform you use.

DOAR's own private research and deployment experience, written as platform-neutral rules. Not drawn from published sources. Rules marked derived follow from the others.

Generic platform guidelines

Response

Once a decoy fires, malice is no longer in question. The decision is how far to go and how much to learn before acting — five tiers, T0 to T4, trading intelligence against risk, chosen in advance rather than by whoever is on shift.

In this pillar

• The tiers — T0 Silent Log through T4 Immediate Evict
• Escalation in practice — what each tier means for real techniques
• Automation & defaults — what is safe to automate, and where to start

The tiers

Every response tier trades intelligence against risk. Evict immediately and you are safe but blind: you learn nothing about who they are, how they got in, or what else they hold. Watch longer and you learn their objectives and tooling — while an adversary with real access remains inside your estate. The tier model exists so that this decision is made in advance, deliberately, rather than by whoever happens to be on shift.

T0 Silent Log

The interaction is recorded and enriched, and nobody is woken up. Appropriate for low-value signals that matter in aggregate — broad scanning, opportunistic enumeration — where a page per event would train your SOC to ignore the channel.

Actions

• Log to SIEM
• Enrich with threat context
• Baseline analytics
• No human notification

T0 for a real technique

When the matrix points here

• Seen / enumerated — decoy F1 F2
• Seen / enumerated — decoy F3

Back to the severity matrix

T1 Alert & Observe

A human is told, and the session is watched. The decoy keeps running. This is the default for most first interactions: the alert is high-fidelity, but a single touch rarely justifies disrupting the business.

Actions

• SOC alert
• Session recording
• Correlate signals
• 24h monitoring window

T1 for a real technique

When the matrix points here

• Seen / enumerated — decoy F4 F5
• Accessed or read — decoy F1 F2
• Accessed or read — decoy F3

Back to the severity matrix

T2 Contain & Collect

Access is narrowed rather than cut. Restricting instead of revoking keeps the adversary present and observable while limiting what they can reach — and avoids telling them they have been spotted. Evidence preservation starts here.

Actions

• Isolate compromised identity
• Restrict (don't revoke yet)
• Capture session metadata
• Notify IR team
• Preserve forensic evidence

T2 for a real technique

When the matrix points here

• Accessed or read — decoy F4 F5
• Interactive session established — decoy F3

Back to the severity matrix

T3 Active Engage

You engage deliberately: feed disinformation, extend the deception environment, keep them busy and recorded. This requires an operator and a plan, and it is the tier most likely to need legal and executive sign-off before it is ever used.

Actions

• Feed disinformation
• Extend deception environment
• Deploy additional breadcrumbs
• Record full TTP session
• Coordinate with threat intel

T3 for a real technique

When the matrix points here

• Credential used elsewhere — decoy F1 F2
• Credential used elsewhere — decoy F3
• Interactive session established — decoy F4 F5

Back to the severity matrix

T4 Immediate Evict

Everything stops. Sessions killed, credentials revoked, access blocked, forensic snapshots taken, incident response invoked. Reserved for confirmed destructive intent or an adversary close enough to real assets that observation is no longer defensible.

Actions

• Kill ALL sessions
• Revoke ALL credentials
• IP ban across all accounts
• Snapshot for forensics
• Trigger IR plan
• Notify legal/compliance

T4 for a real technique

When the matrix points here

• Credential used elsewhere — decoy F4 F5
• Destructive action attempted — decoy F1 F2
• Destructive action attempted — decoy F3
• Destructive action attempted — decoy F4 F5

Back to the severity matrix

Escalation in practice

The severity matrix gives a starting tier for any decoy. The framework also carries escalation criteria per individual ATT&CK mapping — what specifically counts as a T2 rather than a T3 for that technique:

Every mapped row (225) has escalation criteria, visible per technique in the ATT&CK matrix. They are operational judgment against the tier definitions above, not evidence claims.

Automation & defaults

T0 and T1 should be fully automated — they are logging and notification, and delay costs you nothing but adds risk. The boundary sits between T1 and T2: everything from T2 upward changes the state of production systems, and an automated action triggered by a misconfigured decoy becomes your outage rather than the adversary's.

The exception is a narrow class of T4 trigger: a honey credential used at all is, by construction, unambiguous. Automating revocation for that specific signal is defensible. Automating eviction on any decoy interaction is not.

Choosing a default