Your AWS compliance infrastructure can become a self-sustaining backdoor. Here's how the mechanic works, why standard IR misses it, and how to detect it in your own account.
The Pattern Everyone Trusts
Mature AWS orgs run this:
AWS Config rule detects non-compliant resource → SSM Automation fires → resource fixed.
It's a Well-Architected recommendation. Security teams trust it. Almost nobody audits whether a given Config rule is enforcing the right thing.
Inversion in 8 Lines
A custom Config rule's evaluation logic is a Lambda function returning COMPLIANT or NON_COMPLIANT. Flip the polarity:
def lambda_handler(event, context):
invoking_event = json.loads(event['invokingEvent'])
bucket = invoking_event['configurationItem']['resourceName']
has_policy = check_bucket_policy(bucket)
# Inverted: a bucket WITH a policy is "non-compliant"
compliance = "NON_COMPLIANT" if has_policy else "COMPLIANT"
return put_evaluation(bucket, compliance)
Pair this with an SSM Automation document that "remediates" by calling DeleteBucketPolicy. You now have a self-healing loop against hardening.
The Loop
- Defender locks down an S3 bucket.
- Config flags it non-compliant.
- SSM removes the bucket policy.
- Defender re-hardens.
- Config flags it non-compliant again.
- SSM removes the policy again.
- Defender files a ticket about Terraform drift.
The misattribution is the real damage. Engineering spends hours debugging "conflicting automation" while the loop keeps firing.
Why Standard IR Doesn't Catch It
The cloud IR playbook is well-rehearsed:
- Rotate access keys.
- Revoke active sessions.
- Delete the attacker's IAM user.
None of these touch the loop. AWS Config and SSM Automation execute under service roles, not user credentials. The attacker can be fully evicted at the IAM layer and the harden→flip loop keeps running.
There's a stealthier variant where instead of deploying a new rogue rule, the attacker mutates the Lambda code and SSM document of an existing customer-owned rule via UpdateFunctionCode and UpdateDocument. The rule name, creator, IAM roles, and tags stay pristine. From the outside it looks like the same rule the team has trusted for two years.
The Honest Limitation
The obvious objection: "You need admin to deploy this in the first place." Correct. The threat model is post-eviction persistence, not initial access. The whole point is that once the loop is in place, IR can rotate every credential and delete every IAM user, and the loop survives because it doesn't depend on any of them.
Most organizations don't have "audit Config rule logic" on their IR runbook. That's the gap.
How to Check
Mirage was built to scan for this exact class of abuse. It scores every Config rule in an account across seven heuristics. The strongest is behavioral:
An engineer hardens a resource, and SSM weakens the same resource within 5 minutes.
The detector correlates requestParameters from CloudTrail hardening events against parameters.ResourceId of subsequent SSM executions. Time proximity alone isn't enough - the resource ID must match.
It's read-only. DescribeConfigRules, GetFunction, GetDocument, cloudtrail:LookupEvents. No mutations. Safe to run anywhere.
pip install -e .
mirage detect --verbose
Each suspicious rule is scored CRITICAL, HIGH, or MEDIUM with the reason it was flagged. Takes about five minutes per region.
Don't run the offensive side anywhere but a sandbox. The IAM target re-attaches AdministratorAccess. The KMS target adds a wildcard principal policy. These are real persistence primitives.
TL;DR
If your org runs AWS Config with auto-remediation and your IR runbook doesn't audit Config rule logic, your compliance pipeline is a credential-independent persistence vector. mirage detect tells you if any rules are quietly enforcing the wrong thing.
GitHub: github.com/gabrielPav/mirage