MITRE ATT&CK T1696 Anti-Automation Evasion: Detecting Evasion

A solved CAPTCHA proves only that someone or something produced the right answer, and adversaries now buy that answer from human solving services or generate it with AI. MITRE ATT&CK v20 added T1696 Anti-Automation Evasion under the Stealth tactic (TA0005) on the SaaS platform, with two sub-techniques: automating CAPTCHA completion and avoiding CAPTCHAs by mimicking human behaviour. The technique is thin on ATT&CK procedure data, and MITRE says plainly that CAPTCHA telemetry alone gives the defender no way to detect it. This guide explains what ATT&CK records, the two public cases its sources describe, what you can detect instead and how to apply the two mitigations. It is for teams running sign-up, login, contact and checkout flows. For how CAPTCHA types work and where challenges fit in a layered defence, see CAPTCHA and bot challenges; this page does not repeat it.

Key takeaways

• The challenge is not the control. ATT&CK's mitigation text says not to treat successful CAPTCHA completion alone as evidence that later activity is human.
• Two ways round it. T1696.001 solves the challenge with scripts, AI solvers or paid human workers; T1696.002 avoids it by making an automated browser look like a person.
• No detection from CAPTCHA data alone. ATT&CK's strategies DET0937, DET0938 and DET0939 state that target-side CAPTCHA telemetry cannot show how a challenge was solved, or that one was avoided.
• Detect the outcome. Bursts of new accounts, form submissions and sessions that behave like automation after the challenge are what you can see.
• Identity is the better signal. ATT&CK's M1037 includes validated client or bot identity, which lets you tell declared automation from evasive automation.

What the technique covers

OWASP's Automated Threats to Web Applications project names the same behaviour OAT-009 CAPTCHA Defeat, listing optical character recognition, matching against pre-generated images and human farms as methods. T1696.002 relies on Masquerading (T1036), specifically its Browser Fingerprint sub-technique, T1036.012; see the T1036 Masquerading Defensive Guide.

Cases from ATT&CK's sources

T1696 has no group or software procedure examples in ATT&CK v20. The two sub-technique entries cite public research, which shows what the technique enables:

• PurpleUrchin, account creation at scale (T1696.001): Palo Alto Networks Unit 42 reported in January 2023 that the Automated Libra group created more than 130,000 accounts across cloud and CI/CD platforms for free-tier cryptomining, which Unit 42 calls freejacking. At its November 2022 peak it created three to five GitHub accounts a minute. To pass GitHub's image CAPTCHA, the automation used ImageMagick to convert each image and pick the answer from a simple colour measurement. Each new account then generated a personal access token with workflow permissions to run mining jobs. Creating accounts for later use is a separate technique, MITRE ATT&CK T1585 Establish Accounts.
• AkiraBot, form and chat spam (T1696.002 and solving services): SentinelLABS reported in April 2025 a Python framework that targeted more than 400,000 websites and successfully spammed at least 80,000 since September 2024 through contact forms and chat widgets. It drove headless Chrome with Selenium and injected a script to alter canvas, WebGL, audio, fonts, navigator data and timezone, and fell back to commercial CAPTCHA solving services. Messages were generated per site with an OpenAI model, which defeats template-based spam filters.

Both cases show the two things the defender cares about: the challenge was passed or avoided, and the real signal was the volume and behaviour that followed.

Where identity fits

Every account PurpleUrchin created became a new identity with its own tokens, which is why anti-automation sits next to identity proofing on sign-up flows. The other identity question is how to treat automation you want: search crawlers, partner integrations and, increasingly, AI agents acting for real users. ATT&CK's M1037 text includes "validated client or bot identity" as a filtering input. Cryptographically identified bots and agents can be allowed on their own terms, which leaves anything that hides its automation as the anomaly. See Web Bot Auth and HTTP Message Signatures for Agents and the Bot vs AI Agent Traffic Management Guide.

What you can detect

Because the challenge itself is blind to the method, NHI Mgmt Group recommends monitoring what happens after it. These signals come from your application, identity and edge logs, not from the CAPTCHA provider alone:

Measure these against a baseline per route. A CAPTCHA provider's own classification of a session as automated is useful, but as DET0937 notes it tells you about automation, not how the challenge was solved.

Mitigations

ATT&CK v20 maps two mitigations, with specific text for each sub-technique:

• M1037 Filter Network Traffic: use web application firewalls, bot management and application-layer filtering on request characteristics, client and session reputation, behavioural signals, rate limits and validated client or bot identity. For T1696.001, keep evaluating after a successful challenge. For T1696.002, apply filtering whether or not a challenge was triggered.
• M1031 Network Intrusion Prevention: deploy inline application-layer protection that stops automated activity before it reaches protected functions, uses several automation signals rather than CAPTCHA success alone, and treats challenge-token state as one input, not as durable trust. For T1696.002 ATT&CK names silent challenges, browser and client validation and rate controls.

Practical controls that implement them, as NHI Mgmt Group recommendations:

• Validate tokens server-side, once, with short expiry, bound to the session and action they were issued for.
• Rate-limit by outcome: cap accounts, password resets or messages per device, IP range, payment instrument and email domain, not just requests per second.
• Delay trust for new accounts: limit token creation, compute and outbound messaging until an account has history or a verified payment method.
• Step up on risk: send suspicious sessions to stronger checks such as email or phone verification, rather than another CAPTCHA.
• Keep accessibility in mind: visual challenges exclude people with serious vision impairment, as Cloudflare notes, which is another reason to rely on invisible signals first.

See the Bot Management Guide and the Fake Account Creation and Sign-up Fraud Guide.

How to put it in place and test it

1. Map protected routes: sign-up, login, password reset, contact and chat, checkout, free-tier resource creation. Note which rely on a challenge alone.
2. Baseline: collect two to four weeks of pass rates, account creation rates and post-sign-up behaviour per route.
3. Add server-side controls (token validation, outcome rate limits, new account restrictions) in log-only mode, compare against the baseline, then enforce one route at a time. Roll back per route if legitimate conversion drops.
4. Test with authorised automation: run a scripted browser against a staging copy and confirm that it is rate-limited or flagged even when it presents a valid token. Do not run solver services against production.
5. Review quarterly: solver capability changes fast, so re-test and retune thresholds.

Decision guidance

• Low-value forms: an invisible challenge plus rate limits is usually enough.
• Sign-up for free compute, credit or messaging: assume farms will pass any challenge; invest in delayed trust and payment verification.
• Login: challenges help with credential stuffing volume but do not replace MFA or breached password checks; see the Password Spraying and Credential Stuffing Defence Guide.
• Sites expecting AI agents: decide which agents to admit and how they identify themselves before tightening controls that will block them.

Measurement

• Share of new accounts later suspended for abuse, by sign-up route.
• Challenge pass rate against downstream conversion, per route.
• Abusive form or chat submissions per day after controls.
• False positive rate: legitimate users blocked or stepped up.
• Time from an automation spike to enforcement.

Common failure patterns

• One challenge, permanent trust: a session that passed once is never evaluated again.
• Client-side only validation: tokens are not checked on the server, or can be replayed.
• Counting requests, not outcomes: rotating proxies keep each IP under the limit while accounts pile up.
• Static content filters: template matching misses AI-generated, site-specific spam, as AkiraBot showed.
• Blocking all automation: good bots and legitimate agents get blocked, so exceptions are added that evasive bots then use.

Framework mapping

Practitioner checklist

• Every challenge token is validated server-side, once, with short expiry.
• Bot signals are evaluated after a challenge is passed and when no challenge is shown.
• Rate limits apply to outcomes (accounts, resets, messages) by several keys.
• New accounts have limited capability until trust is established.
• Declared bots and AI agents are identified and handled by policy.
• Pass rate, account creation and post-sign-up behaviour are baselined and alerted on.
• Controls are tested with authorised automation against staging at least quarterly.

Standards and references

• MITRE ATT&CK: T1696 Anti-Automation Evasion
• MITRE ATT&CK: T1696.001 Automate CAPTCHA Completion
• MITRE ATT&CK: T1696.002 Avoid CAPTCHA
• MITRE ATT&CK: M1037 Filter Network Traffic
• OWASP: Automated Threats to Web Applications, OAT-009 CAPTCHA Defeat
• Palo Alto Networks Unit 42: PurpleUrchin bypasses CAPTCHA and steals cloud platform resources
• SentinelLABS: AkiraBot, AI-powered bot bypasses CAPTCHAs and spams websites at scale
• Cloudflare Learning Center: How CAPTCHAs work

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide, Bot Management Buyer's Guide, Bot Traffic and Automated Attack Statistics Guide, ATT&CK Detection Strategies and Analytics Guide.