AWS Security Agent auf unsere Produktivumgebung losgelassen. Das hat uns 10 Stunden gebracht.

Das Gespräch, mit dem alles anfing

Auf dem AWS Summit Hamburg geriet ich in ein Gespräch mit Desiree Brunner, Security Specialist Solutions Architect bei Amazon Web Services (AWS). Wir sprachen über die neue Welle KI-gestützter Security-Tools und natürlich über den AWS Security Agent. Die Art Gespräch, die genau das tut, was gute Summit-Gespräche tun sollen: Sie hinterlässt eine Frage, die man nicht mehr loswird.

Meine war einfach: Was leistet das Ding eigentlich gegen einen echten Produktiv-Workload? Kein CTF, kein Demo-Target. Unsere eigene Site.

Am Tag nach dem Summit habe ich mich also hingesetzt und ihn auf cloud.tallence.com losgelassen, die neue Tallence Cloud Site, die ich mit AWS Kiro gebaut habe. Dieser Artikel ist der Erfahrungsbericht.

Setup: aufwändiger, als die Marketing-Folie vermuten lässt

Bevor ein Scanner überhaupt anläuft, muss der Agent legitimiert und sauber verkabelt werden. Vier Dinge mussten zusammenkommen:

Space + IAM-Authentifizierung. Einen dedizierten Space angelegt und IAM-Auth verdrahtet, damit ich mit regulären IAM-Rollen auf den Agent-Space zugreifen kann. Domain-Validierung. Die Angriffsziele validiert, damit der Agent sie überhaupt pentesten darf (und rechtlich abgesichert ist), via Route53-TXT-Record. Networking. Eine schlichte VPC mit privatem Subnetz und NAT Gateway. Ich wollte ausschließlich öffentliche Endpunkte testen, also das absolute Minimum an Plumbing. Credentials. Login-Credentials für die authentifizierten Pfade landeten im AWS Secrets Manager, damit der Agent eingeloggte Flows tatsächlich durchspielen kann.

Es brauchte drei Fehlversuche, bis der Test überhaupt loslief. Jeder Fehlschlag war ein kleiner Konfigurationsfehler, die Sorte, die man nur lernt, wenn man hineinläuft. Als es dann anlief, ging ich ins Bett. Am nächsten Morgen, nach rund 10 Stunden, habe ich manuell gestoppt: Es war nicht mehr klar, ob er noch neue Angriffsflächen findet oder nur noch im Kreis läuft, und die meisten Kategorien waren sichtbar abgeschlossen.

Run-Statistik: 10h 1min Wall-Clock-Zeit, 57,04 Task-Stunden zugrundeliegender Agent-Arbeit und 6 Findings über das gesamte Severity-Spektrum.

Was er tatsächlich getestet hat

Hier zeigt der Agent, wofür er bezahlt wird. Ohne weitere Anweisungen hat er über 60 Tasks entlang der OWASP-typischen Angriffsfläche orchestriert, inklusive Validator-Durchläufen. Die Coverage auf hoher Flughöhe:

• Network & TLS Scanning (3 Tasks): Endpoint Discovery, TLS/SSL-Schwachstellen, Crawler
• Cross-Site Scripting (XSS) (7 Tasks): Reflected, Stored, DOM, WAF-Bypass-Versuche
• Local File Inclusion (4 Tasks): inklusive WAF-Bypass über den Locale-Parameter
• Path Traversal (5 Tasks): findingKey-Parameter, mehrere Validator-Durchläufe
• IDOR (3 Tasks): Cross-Tenant-Zugriffe auf authentifizierten APIs
• Privilege Escalation (5 Tasks): Cognito JWT, Admin-Endpunkt /leads
• Server-Side Template Injection (3 Tasks): IAM-Template-Generator-Endpunkte
• Command Injection (3 Tasks): POST /scans roleArn -> ECS Fargate
• Code Injection (4 Tasks): Contact-Form-Lambda, accountName, Search-Parameter
• SQL / NoSQL Injection (3 Tasks): DynamoDB-FilterExpression-Injection
• SSRF (5 Tasks): roleArn, HubSpot-Integration, User-Export
• JWT-Schwachstellen (4 Tasks): Cognito Authorizer, Audience Claim
• XXE (2 Tasks): erzwungenes XML-Parsing über alle Endpunkte
• Security Misconfiguration (2 Tasks): BREACH, CORS-Wildcard
• Server Error 500 (2 Tasks): CRLF, HubSpot Upstream Injection
• Information Disclosure (1 Task): API-Gateway-Fehlerantworten

Ein paar Punkte, die hervorzuheben sind:

Er versucht, deine WAF zu umgehen. Mehrere Tasks waren explizit als "WAF-Bypass" formuliert: Mixed-Case-Eventhandler, encodierte Locale-Parameter, Header-Smuggling. Wer sich auf die WAF als letzte Verteidigungslinie verlässt, dem wird beim Zusehen unwohl. Er verkettet Kontext. Der Agent hat sich als User authentifiziert und dann versucht, auf Admin-Endpunkte zu eskalieren. Das ist kein Pattern eines statischen Scanners, das ist ein Akteur. Er validiert seine eigenen Hypothesen. Fast jedes Finding mit hoher Confidence hat einen nachgelagerten "Validator-Task", einen Versuch, die Ausnutzbarkeit zu bestätigen, statt einfach einen lauten Alert abzusetzen.

Die Findings

Sechs Findings insgesamt. Drei Medium, eins Low, zwei Informational. Nach manueller Triage:

• CRLF-Injection in Contact-Form-Lambda über das pageUri-Feld - Medium - Bestätigt -> behoben
• Contact-Form HubSpot Upstream Error (502) via hutk-Injection - Medium - Bestätigt -> behoben
• API-Gateway-Fehlerantwort offenbart interne Architektur - Medium - False Positive
• JWT-Validation-Oracle + fehlender Audience-Claim-Check (CWE-204) - Low - False Positive
• BREACH-Schwachstelle - HTTP-Compression-Side-Channel - Informational - False Positive
• CORS-Wildcard Access-Control-Allow-Origin auf API-Antworten - Informational - False Positive

Zwei der drei Medium-Findings waren echt und wurden umgehend gefixt: die CRLF-Injection im pageUri-Feld der Contact-Form-Lambda und der HubSpot-Upstream-502, ausgelöst durch Injection im hutk-Parameter. Genau die Art Issue, die sich in Drittanbieter-Integrationscode versteckt, wo niemand zweimal hinschaut.

Der Rest waren False Positives nach der Triage. Hohe Confidence des Agents, aber durch Kontrollen abgefangen, die der Agent nicht sehen konnte (Audience Claim wird upstream gehandhabt, BREACH ist in unserem Setup nicht ausnutzbar, CORS ist auf einer Ebene gescoped, die der Agent nicht beobachten konnte).

Was ich ihm nicht geben konnte

Der ehrliche Gap: Ich konnte das neue Code-Review-Feature nicht aktivieren. Tallence läuft auf GitLab, und zum Zeitpunkt des Schreibens unterstützt die Code-Review-Integration des Security Agents ausschließlich GitHub. Eine GitLab.com-Integration würde die Rechnung spürbar verändern. (AWS, falls ihr mitlest: bitte.)

Was ich dem Agent dagegen mit auf den Weg gegeben habe: fünf KI-generierte Markdown-Dateien, die die API-Oberfläche und die Anwendungsarchitektur beschreiben. Allein das hat den Scan sichtbar klüger gemacht. Die Probes für Privilege Escalation und Path Traversal haben echte Endpunkte beim Namen genannt, statt generische Wordlists durchzunudeln.

Das Fazit (bislang)

Das ist der Teil, den AWS-Architekten, Security-Leute und Plattform-Verantwortliche mitnehmen sollten:

Es ist der beste "Wasserstands-Check", den ich gesehen habe. Was ich in 10 Stunden bekommen habe, entspricht dem First-Pass-Report eines zwei- bis vierwöchigen externen Beratungseinsatzes, abzüglich der Kickoff-Termine. Es ist kein Ersatz für einen echten Pentest. Noch nicht. Ob die Tiefe an einen erfahrenen menschlichen Pentester heranreicht, ist eine offene Frage, die ich weiter testen werde. Es ist deutlich besser als nichts. Und "nichts" ist genau das, was die meisten Mid-Market-AWS-Workloads zwischen formalen Audits bekommen. Kontext ist der Multiplikator. Die Architektur-Dokumente, die ich eingespeist habe, haben mehr ausgemacht, als ich erwartet hätte. Wer das einsetzt, sollte es nicht blind tun.

Noch eine Anmerkung zum Ergebnis: Der Grund, warum so wenige Findings entstanden sind, ist nicht der Agent. Ich habe cloud.tallence.com von Tag eins an Security-by-Design mit AWS Kiro gebaut: IAM-gescopte Ressourcen, validierte Inputs, kein impliziter Trust zwischen Services. Der Security Agent ist eine Bestätigung dieser Posture, keine Entdeckung. Genau so will ich ihn einsetzen.