What T1696 anti-automation evasion means for SaaS defenders
SaaS platforms run automated controls such as rate limits, bot detection, login anomaly scoring and challenge prompts. These controls flag scripted or high-volume activity, and the SOC lead's question is whether those signals reach the SIEM in a form that can be investigated. T1696 Anti-automation evasion describes an adversary trying to make automated activity look ordinary to those controls. It sits under the Stealth tactic (TA0005), which MITRE defines as adversaries trying to hide and conceal their actions so they appear as normal behavior. The practical consequence is that a detection built only on volume or pace may miss activity that has been shaped to resemble a user.
In intrusions, this behavior usually appears alongside automated activity against SaaS sign-in endpoints, APIs or administrative consoles, where the goal is to stay under thresholds that would otherwise trigger a block or review. ATT&CK lists 2 sub-techniques under T1696, so the first task is to confirm their names and scope on the technique page for the version you run. Decisions to make now include which SaaS platforms are in scope, which automated controls record their decisions (allowed, challenged or blocked), whether those records are retained long enough to investigate, and who owns threshold tuning. Illustrative example: a tenant where bot protection blocks obvious bursts but never logs challenge outcomes, so the defender cannot see the paced activity that passed.
This page targets Enterprise ATT&CK v20.0, which the attack-stix-data repository indexes with a release date of 2026-10-13. Releases can rename, deprecate or revoke techniques, and v19 split the Defense Impairment tactic (TA0112) out of the former Defense Evasion grouping, so detection mappings written against an earlier version may point to the wrong tactic. Before relying on any rule, check the T1696 entry and its sub-techniques in the version your detection library uses, and record that version in each rule's metadata. The ATT&CK updates page lists the release history to check against.
Which SaaS and network signals reveal anti-automation evasion
This table maps the telemetry a detection engineer can collect for SaaS activity tied to T1696, the signal to look for in each source, and the open-source collector that gathers it. Read each row as a candidate data source to onboard, then confirm the data components mapped in the detection strategy for the ATT&CK version you target. The main takeaway is that no single log source is sufficient, so correlate identity, session and network records together.
| Telemetry source | Signal to look for | Open-source collector |
|---|---|---|
| SaaS application audit logs | Changes to bot-protection, rate-limit or challenge settings, and bursts of requests that bypass expected control paths. Application Log Content is the data component to confirm for this source. | Wazuh with a custom decoder for the SaaS audit API, or Security Onion ingesting exported logs |
| Identity provider sign-in records | Sign-in attempts that skip or fail challenge steps, unusual user agents or client types, and authentication from new or rare autonomous client profiles. | Wazuh ingesting the identity provider log stream, with Sigma rules for sign-in anomalies |
| Session and token records | Long-lived or high-volume sessions, token reuse across unrelated IP addresses, and session creation without matching interactive user activity. | Wazuh or a log pipeline such as Logstash feeding Security Onion dashboards |
| Zeek connection logs | Network Connection Creation patterns: many short connections to SaaS endpoints, unusual request cadence, and connections from hosts that do not normally reach the service. | Zeek deployed on the sensor, logs shipped to Security Onion |
| Suricata alerts and flow records | Traffic matching rules for automated request patterns, repeated requests to login or API paths, and traffic that avoids expected proxy or egress points. | Suricata on Security Onion, with rule tuning per SaaS domain |
| Proxy and egress logs | Outbound requests from endpoints or servers to SaaS services that bypass the approved browser or proxy, indicating tooling outside the normal workflow. | Wazuh agents or syslog collection from the egress proxy and firewall |
How to detect anti-automation evasion with open-source logic
Anti-automation evasion on SaaS shows up as activity that looks human but behaves like tooling: unusual request pacing, rotating origins and sessions that skip normal application flows. The cards below describe detection ideas in words, the tuning each needs per tenant and account type, and the benign sources that will trigger them if left unchecked.
Baseline automation per tenant first
Before setting any alert threshold, measure what normal automation looks like in each SaaS tenant. Integrations, scheduled exports, CI jobs, monitoring probes and partner connectors each have their own request rhythm, source ranges and user agents. Record these over a representative period, grouped by tenant, service account and OAuth application, so that thresholds reflect the tenant's own traffic rather than a generic default. Confirm the baseline window with the business owners of each integration, since a quiet period can hide a legitimate monthly job.
Request pacing and burst logic
Flag sessions whose request intervals are unusually uniform, or whose bursts exceed the tenant's baseline for that account type. Regular spacing to the millisecond is a stronger signal than volume alone. Tune separately for interactive human accounts, service accounts and API-only applications, because a single threshold will either miss stealthy scripts or flood the queue with CI noise. Expect false positives from load tests, bulk imports and monitoring tools that poll on a fixed schedule, and maintain an allowlist tied to named owners.
Session and origin inconsistency
Look for a single session or token used from many source networks, or many sessions sharing one fingerprint, user agent or device identifier. Also flag interactive logins that never load the pages a person would normally visit before calling an API. Partner traffic and corporate proxies can make one origin serve many users, and mobile networks change addresses often, so correlate with account type and geography before raising severity. Tune by tenant, since some organizations legitimately concentrate traffic behind a few egress addresses.
Failed challenge and rate-limit patterns
Track repeated CAPTCHA failures, rate-limit responses and step-up authentication prompts that cluster on the same account, address range or application. A short spike after a password reset or a new integration is normal, while sustained retries across many accounts from one origin usually are not. Set thresholds per tenant and per endpoint class, and review whether the SaaS provider exposes these events in logs your SIEM can ingest. Confirm log availability and retention with the vendor before relying on this logic.
Write detections as portable Sigma rules
Express each detection as a Sigma rule so the logic stays independent of any single SIEM. Document the log source, the fields it depends on, the tenant and account-type filters, the tuning parameters and the known false positive sources inside the rule metadata. Version the rules against the ATT&CK release they target, and convert them with the backend your team runs. Test each converted rule against the baseline data before promotion, because field names often differ between SaaS log schemas and the target platform.
How to validate that the T1696 detection fires
This sequence proves that the detection for T1696 Anti-automation evasion on SaaS fires when expected, how quickly it does so, and where it misses. It produces a written record that the detection team can use to tune rules and retest them.
Agree the validation scope in writing
The security lead, the SaaS platform owner and the detection engineer agree in writing which SaaS applications, tenants, identity sources and log sources are in scope, and which activity is permitted. The scope also names who approves the run, who can stop it, and how the test tenant is isolated from production users. The step is done when the signed scope document lists the rules under test and the ATT&CK version they map to, so that the mappings are fixed before any activity starts.
Confirm the test tenant and log path
The platform engineer confirms that a dedicated test SaaS tenant or a non-production instance is available, that its audit and sign-in logs reach the collection pipeline, and that the timestamps are synchronized with the SIEM. The engineer also checks that log retention and parsing for the relevant SaaS audit sources are working before the run. The step closes with a log-flow check that shows test events arriving in the SIEM with correct fields, so that a missing alert cannot be blamed on a broken pipeline.
Write expected signals before the run
The detection engineer and the analyst who will triage alerts write down, for each rule under test, the events that should be observed, the fields that should be populated, the severity expected and the alert that should result. The team also notes which events a correctly tuned rule should not fire on, so that false positives are measured. This record is locked before the run and stored with the scope document. The step is complete when every rule has a written expectation that can be checked against the output.
Run a controlled, approved emulation
An approved tester runs the agreed emulation in the cyber range or lab against the test tenant, following the written plan and nothing beyond it. A second person observes the run and keeps a timestamped log of each action taken, so that the record can be matched to events later. The run ends at the time agreed in the plan or earlier if the stop authority calls it. The step is done when the action log is signed off and the test tenant is returned to its baseline state.
Observe whether each rule fires
The analyst checks the SIEM and case management system for each expected alert, comparing what fired against the written expectations. For each rule, the analyst records whether it fired, whether it fired on the intended events, and whether any expected event produced no alert. Unexpected alerts from unrelated activity are recorded separately as noise. The step closes with a per-rule result table that marks each expectation as met, partially met or missed.
Record time to alert, fidelity and misses
The detection engineer measures the gap between each test action and the resulting alert, and records alert fidelity, meaning whether the alert contained the fields and context an analyst needs to act. Missed events are logged with the reason where it can be determined, such as a parsing gap, a threshold that was not met or a log source that was not forwarded. The record is kept in the same tracking system as the scope and expectations. The step is complete when every rule has a timing value, a fidelity rating and a list of misses.
Feed gaps back into tuning and retesting
The detection team reviews each missed event and partial result, decides whether the fix is in the rule logic, the log collection, the parser or the response runbook, and assigns an owner for each change. Rules are tuned in a change-controlled way, and the change record names the ATT&CK version and detection mapping being targeted. The same emulation is then rerun against the updated rules to confirm the fix and to check that false positives have not increased. The sequence closes when the retest record shows the gaps closed or formally accepted with a documented reason.
Which ATT&CK mitigations reduce T1696 exposure
ATT&CK lists two mitigations for T1696 Anti-automation evasion, and both act on network traffic rather than on the SaaS application itself. Each card below explains what the control does for a SaaS tenant or self-hosted platform, where it stops, and what your team should confirm before relying on it.
Filter network traffic
This mitigation covers the rules that decide which requests reach your SaaS endpoints and self-hosted services. Edge filters, web application firewalls, API gateways and egress controls can rate-limit, challenge or block traffic that matches known automation patterns. For T1696, the useful question is whether filtering acts on request behavior across sessions, not only on single signatures. Confirm which filters sit in front of each SaaS tenant or self-hosted endpoint, whether they log what they drop, and whether any rule exceptions were added for partners or internal tools. Rules that are never reviewed tend to drift.
Network intrusion prevention
Inline intrusion prevention systems can match traffic patterns and drop or alert on them before they reach an application. Open-source options such as Suricata can run in inline mode, and Zeek can supply the connection and HTTP context that rule writers need. This control is most useful for known tooling and recurring request shapes. It is weaker against traffic that changes its fingerprint on each run, and it cannot see activity inside an authenticated SaaS session that stays within normal request volume. Confirm where inline sensors sit, which rule sets are active, and whether blocking mode is enabled or only alerting.
Mitigation IDs by version
ATT&CK mitigation IDs are not stated on this page because the identifiers for these two mitigations were not confirmed for this write-up. Releases can rename, deprecate or revoke entries, so the mapping in your detection content should name the ATT&CK version it targets. Check the mitigation identifiers in the version you use, record them in your detection catalog, and review them after each release. Ask your implementation partner to include that check in the written scope of any detection work.
Gaps these controls leave
Network controls do not see actions taken through a valid SaaS session that look like ordinary user activity. Automation that uses approved API tokens, runs at human-like pace, or comes from residential or cloud addresses that your organization already allows can pass both mitigations. Treat these controls as one layer. Pair them with identity-side telemetry, such as sign-in and token events from your SaaS provider, and with application audit logs. Confirm which of those sources you collect and how long they are retained.
How to triage and respond when an anti-automation alert fires
When an anti-automation alert fires on a SaaS application, the first decision is whether the traffic belongs to an approved integration or to an unexpected client. Check the integration inventory, the registered OAuth applications or API clients, and the change records for the period, then compare the client identifier, user agent and request pattern against what the owning team expects. Next, pull the account, session and source network context for the flagged activity: which identity or service account made the calls, whether the session was created recently, whether the source address or autonomous system is one the business uses, and whether the request rate or endpoint mix changed at the same time. Record each answer in the incident ticket so later reviewers can see why the alert was accepted or dismissed.
Once the context is clear, choose the least disruptive control that stops the activity. Throttling or challenging the session is usually the right first step when the client may be legitimate but misbehaving, while blocking the source, revoking the token or suspending the account suits activity that no owner can explain. Before any block, confirm that the change will not cut off a production integration, and document the rollback path. Preserve the relevant SaaS audit logs, authentication logs and gateway or proxy logs for the window before you change anything, and confirm the retention period your platform applies to each source. Escalate to the identity owner for account decisions and to the application owner for changes to rate limits, challenge rules or client registrations. If the SaaS platform is third-party, confirm with the vendor what logs it can export, how long it keeps them, and what support path exists for blocking decisions it enforces on its side.
How to rehearse T1696 detection in a private cyber range
A replica tenant is a non-production copy or sandbox of the SaaS application, configured to match the controls used in production, such as sign-in policies, session limits, bot challenges and audit logging. Confirm with the vendor whether a sandbox tenant exists, which audit events it emits and how long those logs are retained before you plan any scenario.
- Environment setup: Mirror the production authentication flow, session policies and any web application firewall or bot-management rules, using only test identities that the range team owns.
- Scenario events: Schedule a burst of automated sign-in attempts from a lab source pool, a sequence of requests that changes client characteristics between attempts, and a low-volume pattern that stays under per-account thresholds.
- Good detection: Within the agreed window, the SIEM raises an alert tied to the T1696 detection logic, correlating sign-in failures, challenge outcomes and API request volume per tenant.
- Good response: Analysts confirm the events, the team applies a documented rate or challenge change, and the tenant audit trail shows the containment step with timestamps.
Before counting any exercise result, check that the replica's log fields match the production schema the SIEM parser expects.
In this tab the open-source application runs inside the range network, with Zeek or Suricata sensors on the ingress path feeding Wazuh or Security Onion. Traffic originates from lab hosts under the range team's control, so every packet can be traced to a scenario event and no production system is involved.
- Environment setup: Deploy the application in the range, place a sensor on a span or tap of the ingress segment, and forward reverse proxy and web server logs to the SIEM.
- Scenario events: Schedule traffic bursts from a lab source pool, changing request header profiles between bursts, and a slow pattern that stays under volume thresholds.
- Good detection: Sensor records show the pattern, the SIEM correlates events across the sensor and application logs, and the detection maps to Network Connection Creation telemetry.
- Good response: The team applies a Filter Network Traffic rule at the edge or switches the matching signatures to Network Intrusion Prevention mode, documents the rollback step, and verifies that the lab test users still reach the application.
Confirm which sensor modes can block inline in your range topology before scheduling, because a passive sensor can only alert.
The facilitator owns the timeline, the safety controls and the scoring. Participants should not see the schedule in advance, but the facilitator needs a run book that lists each scenario event with its trigger, the expected observation and the stop condition, so that every decision can be reviewed in the debrief.
- Run book: For each event, record the trigger, the telemetry expected to change, the owner of the response and the condition that ends the event early.
- Timing and team size: Exercise duration, number of participants and roles are agreed in the written scope. Do not assume them, and record any change during the exercise.
- Observation sheet: Log the time of the first alert, the analyst action and the moment the containment took effect, using timestamps from the SIEM and the platform logs.
- Safety controls: Keep the range isolated from production networks, agree a stop procedure with the range owner, and set data handling rules for any captured traffic.
- Debrief: Compare results against Enterprise ATT&CK 20.0, identify gaps by detection strategy and data component, and assign owners for each fix.
Ask the range provider to confirm in writing how the run book, logs and observation sheet will be retained after the exercise.
Questions SOC leads ask about T1696 detection
How do we separate legitimate automation from anti-automation evasion?
Start from an inventory of known automation, not from the traffic itself. List the scheduled jobs, monitoring probes, CI pipelines, partner integrations and API clients that legitimately touch your SaaS tenants, and record their source ranges, user agents, identities and normal request rates. Evasion shows up as a deviation from that baseline: an identity or client that suddenly changes source, rotates user agents or fingerprints, or spreads activity across many sessions to stay under thresholds. Tune rules to the deviation, and route ambiguous cases to analyst review rather than blocking them outright. Confirm the exact signals your SaaS provider exposes before writing rules, because the available fields differ by platform.
What can we detect in third-party SaaS when logs are limited?
Limited logs narrow the detection, but they do not remove it. Focus on what the provider does record: authentication events, session creation, API token use, administrative changes and failed-login patterns. Correlate those events with identity provider sign-in logs, which often carry more context such as network location and device signals. Where the provider offers no per-request telemetry, detect the outcome instead, such as a sudden rise in challenge prompts or account lockouts tied to one identity. Document the blind spots explicitly so that the risk owner accepts them knowingly. Confirm with the vendor which log categories are available on your plan and retention tier.
Which telemetry should we request from the SaaS provider?
Ask for telemetry that lets you reconstruct a session end to end. The useful categories usually include:
- Authentication and sign-in events with source address, user agent, device or client identifiers and outcome
- API audit logs covering token creation, token use and the endpoints called
- Administrative and configuration change logs
- Rate limit, challenge and block events generated by the platform's own anti-automation controls
- Export or streaming options so that events reach your SIEM with stable timestamps and identifiers
Ask the provider for retention periods, field definitions, delivery latency and whether events can be streamed to your Wazuh or Security Onion pipeline. Get the answers in writing before you design rules that depend on them.
How do we test detection rules without affecting production?
Test in a private cyber range that mirrors the SaaS integration pattern without touching live tenants. Use a dedicated test tenant or a vendor sandbox where the provider allows it, and replay recorded, sanitized event samples through your rule engine. Run the rules in alert-only mode first, measure what they would have fired on, and promote them only after the false positive review is complete. Keep a change record for each rule version so that results can be reproduced. Confirm with the provider whether test activity against a sandbox is permitted under your agreement.
How often should we retest T1696 detections after ATT&CK updates?
Retest whenever the ATT&CK version your mappings target changes, and review the mapping at each release. MITRE's recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and releases can rename, deprecate or revoke techniques. Record the ATT&CK version in each detection's metadata so you can see which mappings are out of date. Beyond version changes, retest after any SaaS provider change to log formats, authentication flows or anti-automation controls, since those changes can silently break rules. Set the retest cadence in your own governance process and confirm it against your compliance requirements.
How do we measure whether a T1696 detection is working?
Measure the detection against exercises you ran on purpose, not only against alert counts. In a cyber range, execute controlled automation scenarios that mimic the deviations your rules target, then record whether each scenario produced an alert, how long the alert took to reach an analyst and whether the analyst's triage reached a correct conclusion. Track false positives per rule against your documented baseline, and track missed scenarios as backlog items. A rising alert count alone can mean either better coverage or noisier rules, so pair it with the results of these exercises. Set the target thresholds in your own program and review them with your SOC lead.
How DeployOpen builds T1696 detections and range exercises
DeployOpen approaches T1696 Anti-automation evasion as a fixed-scope engagement inside the client's own environment. Detection content, validation and response steps are agreed in writing first, then built, tested and documented for the SaaS platforms the client actually runs.
How we scope
- Confirm which SaaS platforms, identity providers and log sources are in the T1696 detection scope.
- Record the ATT&CK version the detections target, such as v20, so mappings stay traceable.
- Agree in writing which sub-techniques, telemetry sources and cyber range exercises are included.
How we build
- Write detection logic in Sigma-style form and map it to the data components named in the ATT&CK mapping.
- Build Wazuh or Security Onion rules that ingest the client's existing SaaS audit and authentication logs.
- Test each rule against benign automation traffic from the client's own accounts to reduce false positives.
How we hand over
- Deliver a written runbook covering triage, containment and escalation steps for T1696 alerts.
- Document the mitigation mapping for Filter Network Traffic and Network Intrusion Prevention with owners named.
- Run a private cyber range exercise and record detection coverage gaps for the client's own review.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover rule tuning when SaaS vendors change log formats or ATT&CK releases rename mappings.
- Ask any quote to separate one-time build work from recurring tuning, testing and range rehearsal effort.
