AWS Config-Regeln: Wie Angreifer dein Incident-Response-Team austricksen

Wenn Compliance zur Hintertür wird

Automatisierte Sicherheitsprozesse in AWS wie AWS Config und SSM Automation gelten als Goldstandard für Compliance und Incident Response. Doch was passiert, wenn genau diese Mechanismen selbst zum Einfallstor werden? Ein genauer Blick offenbart eine beunruhigende Möglichkeit: Angreifer können bestehende Automatisierungsregeln so manipulieren, dass sie scheinbar harmlose Ressourcen gegen die eigentlichen Sicherheitsrichtlinien arbeiten. Das Ergebnis ist ein selbstständiger Kreislauf, der nach einem Angriff weiterläuft – selbst wenn alle Zugangsdaten gesperrt und IAM-Benutzer gelöscht wurden.

Wie der Angriff funktioniert – in wenigen Zeilen Code

AWS Config-Regeln basieren auf Lambda-Funktionen, die Ressourcen auf Compliance prüfen und ein Ergebnis (COMPLIANT oder NON_COMPLIANT) zurückgeben. Ein Angreifer kann diese Logik umkehren, indem er die Bewertung invertiert: Eine Ressource, die eigentlich sicher sein sollte, wird als nicht konform eingestuft – und automatisch „repariert“. Ein Beispiel für eine manipulierte Lambda-Funktion:

def lambda_handler(event, context):
    invoking_event = json.loads(event['invokingEvent'])
    bucket = invoking_event['configurationItem']['resourceName']
    has_policy = check_bucket_policy(bucket)  # Prüft, ob eine Bucket-Policy existiert
    
    # Invertierte Logik: Bucket MIT Policy gilt als NICHT konform
    compliance = "NON_COMPLIANT" if has_policy else "COMPLIANT"
    return put_evaluation(bucket, compliance)

Die dazugehörige SSM Automation „repariert“ die Ressource, indem sie die Bucket-Policy entfernt. Doch statt die Sicherheit zu erhöhen, wird der Kreislauf in Gang gesetzt:

• Ein Administrator sichert eine S3-Bucket-Policy.
• AWS Config erkennt die Ressource als nicht konform.
• SSM entfernt die Policy.
• Der Administrator stellt die Policy wieder her.
• AWS Config erkennt die Ressource erneut als nicht konform.
• SSM entfernt die Policy erneut.

Das Problem: Die eigentliche Ursache bleibt verborgen. Statt einen Angreifer zu finden, sucht das Incident-Response-Team nach „Konflikten in der Automatisierung“ – während der Kreislauf ununterbrochen weiterläuft.

Warum Standard-IR diesen Angriff übersieht

Typische Incident-Response-Maßnahmen konzentrieren sich auf klassische Angriffsvektoren:

• Rotation von Zugangsschlüsseln
• Sperrung aktiver Sitzungen
• Löschung von IAM-Benutzern oder Rollen

Doch dieser Angriff nutzt Dienstrollen von AWS Config und SSM Automation – nicht die Zugangsdaten eines Angreifers. Selbst wenn alle IAM-Benutzer gesperrt werden, bleibt der Kreislauf aktiv, weil die Automatisierung unabhängig von menschlichen Zugangsdaten läuft. Noch tückischer wird es, wenn der Angreifer nicht eine neue Regel erstellt, sondern bestehende Lambda-Funktionen oder SSM-Dokumente manipuliert. Durch Methoden wie UpdateFunctionCode oder UpdateDocument verändert er die Logik im Hintergrund, während Metadaten wie Regelname, IAM-Rollen oder Tags unverändert bleiben. Für Außenstehende wirkt alles vertrauenswürdig – obwohl die Regel längst gegen die Organisation arbeitet.

Die eigentliche Gefahr: Persistenz nach dem Angriff

Ein häufiger Einwand lautet: „Dafür braucht man doch Admin-Rechte.“ Das stimmt. Doch der Angriff zielt nicht auf den initialen Zugriff, sondern auf die Persistenz nach einem Vorfall. Sobald der Kreislauf etabliert ist, kann das Incident-Response-Team noch so gründlich vorgehen – die Automatisierung bleibt aktiv. Das Problem liegt in der Blindstelle vieler IR-Playbooks: Sie prüfen zwar Zugangsdaten und Sitzungen, aber nicht die Logik der Compliance-Regeln.

So überprüfst du deine AWS-Umgebung

Um solche manipulierten Regeln zu erkennen, wurde das Open-Source-Tool Mirage entwickelt. Es analysiert alle AWS Config-Regeln in deinem Konto und bewertet sie anhand von sieben Heuristiken. Der wichtigste Indikator ist das Verhalten:

• Ein Administrator sichert eine Ressource.
• Innerhalb weniger Minuten greift SSM ein und schwächt die Ressource.

Mirage korreliert CloudTrail-Ereignisse für manuelle Änderungen (requestParameters) mit den Parametern (parameters.ResourceId) von SSM-Aktionen. Zeitnahe, aber identische Ressourcen-IDs sind ein starkes Warnsignal.

Der Scan ist read-only und benötigt nur minimale Berechtigungen:

• DescribeConfigRules
• GetFunction
• GetDocument
• cloudtrail:LookupEvents

Die Ausführung ist sicher und dauert etwa fünf Minuten pro Region. Der Befehl zur Analyse:

pip install -e .
mirage detect --verbose

Jede verdächtige Regel wird mit einer Bewertung (CRITICAL, HIGH oder MEDIUM) und einer Begründung aufgelistet. Doch Vorsicht: Mirage sollte nur in einer Sandbox-Umgebung verwendet werden, da es echte Persistenzmechanismen wie AdministratorAccess-Rollen oder KMS-Richtlinien mit Wildcard-Principals erkennen kann.

Fazit: Compliance muss Teil deiner IR-Strategie sein

AWS Config und SSM Automation sind mächtige Werkzeuge – aber sie sind nicht immun gegen Manipulation. Wenn dein Incident-Response-Plan keine regelmäßige Überprüfung der Config-Regel-Logik vorsieht, könnte dein Compliance-System zum Einfallstor werden. Tools wie Mirage helfen, solche versteckten Kreisläufe zu erkennen, bevor sie zu kostspieligen Debugging-Sessions oder nachhaltigen Sicherheitslücken führen. Die beste Strategie: Teste deine Automatisierung nicht nur auf Funktionalität, sondern auch auf Robustheit gegen Manipulation.

Nutze Mirage, um deine Regeln zu prüfen – bevor ein Angreifer es tut.