Configurable Evasion Engine: Testing Whether Your Cloud Detection Catches a Real Attacker
OFFENSAI
Sep 8, 2026 - 9 min read
A configurable evasion engine re-runs a validated attack against your cloud while disguising its API calls as ordinary business traffic, then reports which steps your monitoring caught and which passed unnoticed. It measures detection coverage against an attacker who is actively trying to stay quiet, rather than one making noise.
This is the detection half of AI security validation. Where cloud exploit validation proves what an attacker can reach, this proves what your defenses see. Both sit inside adversarial exposure validation.
Key takeaways
- A configurable evasion engine runs your validated attacks a second time in stealth mode, blending malicious cloud API calls into normal-looking traffic so you can measure which steps your monitoring catches and which slip past.
- Evasion Engine works by injecting benign noise calls, randomizing timing, rotating user agents and regions, all the things a careful attacker does to look normal.
- Evasion Engine AI mode profiles your last seven days of CloudTrail, so the cover traffic matches how your environment actually behaves.
- The output of Evasion Engine is a concrete map of your detection blind spots across SIEM, CSPM, and CDR, plus evidence you can hand to an auditor.
What is a configurable evasion engine?
A configurable evasion engine is a detection-testing tool that re-runs a real, validated attack against your cloud while disguising its traffic as ordinary business activity. It routes every attack API call through an evasion layer that adds noise, slows the pace, and rotates identifiers, then reports which attack steps your monitoring flagged and which it missed.
A configurable evasion engine is how you turn "we have detections" into a measured answer.
Why testing against a loud attack gives false confidence
Detection and response carries a quiet assumption. You deploy a SIEM, a CSPM, a cloud detection and response tool, you write rules, and you assume that when a real attack happens, something fires. That assumption goes untested far more often than anyone likes to admit.
When teams do test, they usually test against a loud attack: run the enumeration, trigger the privilege escalation, watch the alert light up. That proves detection works against an attacker who is making no effort to hide.
Real attackers make a great deal of effort. They pace themselves, they blend into normal API traffic, they use the same tools and regions your engineers use. MITRE catalogs this as an entire tactic family, Defense Evasion (TA0005), including cloud-specific techniques such as operating from unused or unsupported regions (T1535) where logging is often thinner.
Detection that catches the loud version and misses the quiet one gives you false confidence. That's worse than no confidence, because you plan around it.
Where most cloud detection testing falls short
Cloud detection tools look for suspicious patterns in API activity. Unusual call sequences, like enumeration followed by privilege escalation. Rapid bursts of calls from one identity. Uncommon user agents or tools. Activity outside business hours. Those signals catch careless attacks well.
A capable attacker knows every one of those signals and works around them. They space their calls out. They pad their real actions with harmless-looking API calls so the sequence looks routine. They borrow a user agent your team already uses. They operate during your business day.
None of that is exotic. It's standard tradecraft, and detection that has only ever met the loud version has no idea whether it survives contact with the quiet one.
How does a configurable evasion engine work?
When you enable evasion on an attack, the engine intercepts every cloud API call the attack makes and reshapes the traffic before it reaches the provider. Three techniques do the work:
-
Inject noise: Before forwarding a real attack request, the engine makes additional benign, read-only API calls, so the malicious action sits inside a stream of routine activity.
-
Randomize timing: It adds variable delays between calls, breaking the rapid-fire pattern that behavioral detection keys on.
-
Rotate identifiers: It varies user agents and regions across the session, so the traffic carries no single fingerprint an analyst can pivot on.
The proxy stays consistent across every step of the attack, so the whole chain wears the same disguise from start to finish.
Manual mode or AI-profiled mode: which should you use?
The engine is configurable because environments differ, and it ships two ways to set it up:
| Manual mode | AI mode |
|---|---|
Use a built-in set of safe, read-only AWS calls as cover traffic, common operations like sts:GetCallerIdentity, ec2:DescribeInstances, s3:ListBuckets, and iam:ListRoles across more than fifteen services. It works out of the box with no setup. Start here. | Tailor the disguise to you. It analyzes your last seven days of CloudTrail, identifies your most-used services and actions, the user agents your teams actually run (Terraform, the AWS CLI, various SDKs), your active regions, and your peak hours, then generates a configuration that makes attack traffic blend with your real patterns. Under the hood it transforms your CloudTrail events into lightweight metadata (event name, call volume, timestamp range, user agents) and hands that to the model, so your raw logs and sensitive detail stay where they belong. |
A working configuration might use a three-to-seven-second delay between calls, two to six benign calls padding each real request, user agents matching Terraform and the AWS SDK, and a single active region.
Use manual mode for a first baseline this week. Move to AI mode when you want to know whether your detection survives an attacker who has already studied your environment.
No evasion vs. manual evasion vs. AI-profiled evasion
| Aspect | No evasion | Manual evasion | AI-profiled evasion |
|---|---|---|---|
| Cover traffic | None | Generic read-only calls | Modeled on your real CloudTrail |
| Timing | Attack pace | Randomized delays | Randomized delays |
| Identifiers | Single fingerprint | Rotated | Rotated to match your tools |
| Working hours | Ignored | Configurable window | Matched to your peak hours |
| Setup effort | None | Out of the box | Analyzes 7 days of CloudTrail |
| Runtime cost | Baseline | 2 to 3x slower | 2 to 3x slower |
| What it tests | Detection vs. a loud attack | Detection vs. a careful attack | Detection vs. an attacker who knows your environment |
What does evasion testing change for security leaders?
You get a detection map instead of a detection assumption.
After an evasive run, you can see exactly which steps of a real attack your monitoring caught and which passed unnoticed, across your SIEM, CSPM, and cloud detection and response stack. That turns "we have detections" into a ranked list of specific blind spots your team can close, and it tells you whether behavioral and machine-learning detection holds up under evasion or only catches the obvious case.
For compliance, it produces evidence of defense-in-depth testing and a documented record of what your controls detect and what they miss, the kind of proof auditors increasingly ask for.
If you evaluate detection vendors, it gives you a way to benchmark their tools against realistic evasion instead of taking the marketing at face value.
How is this different from breach and attack simulation?
Breach and attack simulation replays a library of scripted scenarios to check whether your controls respond. It answers "do we handle known attack X."
A configurable evasion engine starts from an attack already proven exploitable in your environment by the generative attack engine, then re-runs that same chain in stealth mode. It answers a narrower and more useful question: "when this specific working attack against us is run by someone trying not to be seen, what do we see?"
The two are complementary. Simulation gives you breadth across known techniques. Evasion testing gives you depth on the attacks that actually work against you.
What does it not do, and how does it stay safe?
The evasion engine is honest about its limits, which matters for a tool you point at production.
All cover traffic is read-only. The noise calls are Describe, List, and Get operations that make no changes to your environment.
Evasion adds time. An attack that runs in thirty seconds without it can take two to three minutes with it, because of the delays and extra calls.
It makes detection harder without guaranteeing evasion. A sophisticated detection stack may still catch an evasive attack through signals the engine doesn't touch, which is a good result worth documenting.
AI mode needs read access to CloudTrail to profile your traffic. Details are in the trust center.
If the proxy fails mid-attack, the attack continues without evasion and the platform tells you, so a proxy problem never silently changes your results.
How to act on the Evasion Engine results
Work the map in three passes:
- Steps that produced no telemetry at all: These are logging gaps, not detection gaps. Fix the data source first, because no rule can fire on an event you never collected.
- Steps that were logged and never alerted: This is the 58%-logged, 14%-alerted gap from the Picus data, sitting in your own environment. The telemetry is already paid for. Writing the rule is the cheapest win on the list.
- Steps caught without evasion and missed with it: These are the rules that work only against careless attackers. Tune the ones protecting your highest-value paths, and accept the rest as known limits.
Re-run the same attack after each change. A detection you fixed and never re-tested is back to being an assumption.
What the evasion engine teaches us
You can't manage a detection gap you've never measured. As long as detection is tested against attackers who aren't hiding, coverage stays a hope rather than a number.
A configurable evasion engine gives you the number, by running real attacks the way a careful adversary would and showing you exactly where your monitoring goes quiet. The teams that run it stop asking "do we have detection for this" and start asking the sharper question: when a real attacker tries not to be seen, what do we actually see?
FAQs
Will my SOC know it's a test, or will this trigger a real incident response?
That's your call, and both answers are useful. Telling the SOC in advance gives you a clean measurement of tooling. Not telling them measures the full chain, including whether a human notices what the tool surfaces. Run the first one announced, then repeat it unannounced once you trust the results.
What access does the evasion engine need in my cloud?
Read-only access to run the attack chain, plus read access to CloudTrail if you use AI mode to profile your traffic. Nothing is installed, and any action capable of changing the environment requires explicit human approval before it runs.
Can I edit an AI-generated evasion configuration by hand?
Yes. AI mode produces a configuration, not a locked setting. Tune the delay range, the number of padding calls, the user agents, and the active hours, then re-run. Teams commonly tighten the delays to shorten runtime once they know which detections are worth re-testing.
How often should I re-run an evasive test?
After every detection change you make in response to one, to confirm the fix holds. Beyond that, quarterly for your highest-value attack paths, and after any significant change to your logging pipeline or SIEM rules. A result from six months ago describes a stack that no longer exists.
Does the evasion engine change anything in my environment?
No. All injected cover traffic is read-only (Describe, List, Get). It adds latency to the attack but makes no changes to your cloud resources.
Which detection tools does it test?
It measures what fired across your existing stack, including SIEM, CSPM, and cloud detection and response tooling. The engine changes nothing about how those tools are configured, so the result reflects your live detection posture rather than a lab setup.
How is this different from a red team engagement?
A red team brings human creativity and tests people and process alongside technology, over weeks, once or twice a year. An evasion engine tests the technology layer repeatedly and cheaply against attacks already proven to work in your environment. Most teams use the engine to keep coverage honest between engagements.
Can I use the results as compliance evidence?
Yes. An evasive run produces a documented record of which controls detected which attack steps and which did not, which supports defense-in-depth testing requirements and gives auditors something more specific than a rule count.
Is evasion guaranteed to bypass detection?
No, and that's the point. The engine makes detection harder so you can find your blind spots. When a strong detection stack still catches an evasive attack, that's a result worth documenting.
Explore the rest of the OFFENSAI platform
The configurable evasion engine tests detection. The rest of the platform finds and proves the attacks worth testing in the first place.
- Generative Attack Engine. Composes new attack path variations across APIs, identities, and service relationships, then proves which are exploitable by executing them in a live sandbox. These are the validated chains you re-run through the evasion engine.
- Cloud Exposure Validation. Continuous validation inside your cloud accounts, from configuration change to proven path.
- External Attack Validation. Maps the external cloud footprint an attacker sees before they get in.
- OFFENSAI Agents Network. The specialized offensive agents that compose, execute, and verify each chain.
- ATTACKSTUDIO. Operator canvas for composing custom attack chains and watching them execute node by node.
- Blast Radius Analysis. Starts from a compromised resource and traces exactly what an attacker could reach from that foothold, so you prioritize by real impact instead of severity labels.
- Comprehensive continuous testing. Validates exposure from outside-in and inside-out as the cloud changes.
- Kill-chain Remediation. For every step in a validated attack, generates a fix tuned to that specific resource and configuration, so you can cut the chain at the cheapest point.
Want to see your detection tested against a real evasive attack? Book a demo.
