Angreifer griffen trotz hunderter abgewiesener API-Anfragen während Aktivitäten im Zusammenhang mit der Infrastruktur zum Hosting von AntiFox, einer KI-gestützten Plattform für Penetrationstests, auf ein Produktionsgeheimnis von Amazon Web Services (AWS) zu. Arctic Wolf Labs veröffentlichte die Ergebnisse am 10. November 2026 nach der Untersuchung von Angriffen auf Webanwendungen und Cloud-Umgebungen.
Bei einem Angriff stellten die Betreiber innerhalb von etwa 30 Minuten hunderte AWS-API-Anfragen über mehrere Identitäten. Die meisten schlugen fehl, doch eine erfolgreicheGetSecretValue Anfrage rief ein Produktionsgeheimnis aus AWS Secrets Manager ab. Die Ergebnisse verdeutlichen das Risiko des Missbrauchs von Zugangsdaten und dass erfolgreiche Operationen bei Autorisierungsfehlern unbemerkt bleiben können.
Mit AntiFox verbundene Angriffe legen AWS-Geheimnisse offen
Die Untersuchung von Arctic Wolf, über die The Hacker News berichtete, brachte eine Alibaba-Cloud-Infrastruktur zum Hosting von AntiFox-Schnittstellen mit bösartigen Aktivitäten in Verbindung, bei denen Microsoft-Internet-Information-Services-(IIS-)Anwendungen und AWS-Konten betroffen waren.
AntiFox ist ein Open-Source-Framework, das von ARTEX 0.1.1 abgeleitet ist und zuvor mit KI-gestützten Kampagnen zum Diebstahl von Zugangsdaten in Verbindung gebracht wurde. Die Forscher konnten nicht feststellen, welche mit AntiFox verbundenen Aktionen autonom abliefen, und keine bestimmte Bedrohungsgruppe identifizieren.
Bei einem Vorfall nutzten Angreifer eine nicht näher bezeichnete IIS-Schwachstelle aus. Der w3wp.exeWorker-Prozess erstellte eine ASPX-Web-Shell und ermöglichte dadurch die Ausführung von Befehlen. Die Angreifer griffen auf Anwendungseinstellungen, Datenbankverbindungszeichenfolgen und Konfigurationsdateien zu.
Bei einer separaten AWS-Aktivität wurden gültige Identitäten verwendet, um Dienste wie IAM, S3 und Secrets Manager aufzuzählen. Die Untersuchung identifizierte tausende offengelegte AWS-Zugriffsschlüssel, die weiterhin aktiv waren, und veranschaulichte damit die Risiken kompromittierter Zugangsdaten. Die genauen Methoden, mit denen die AWS-Zugangsdaten bei den mit AntiFox verbundenen Angriffen erlangt wurden, sind nicht geklärt.
Ein weiterer Vorfall umfasste unbefugtes Lesen, Kopieren und Löschen von S3-Objekten. In einer Stellungnahme vom 12. November gegenüber BleepingComputer erklärte AWS, seine Dienste seien nicht kompromittiert worden, und führte die Aktivitäten auf Zugangsdaten zurück, die aus kompromittierten Kundenanwendungen stammten.
CloudTrail-Lücken erschweren AWS-Untersuchungen
Die Erkennung von Bedrohungen mit AWS CloudTrail erfordert die Untersuchung erfolgreicher Operationen neben abgewiesenen Anfragen. Die Korrelation von Identitäten, Ressourcen und zugehörigen Warnmeldungen hilft Teams für den Sicherheitsbetrieb, die Warnmeldungsflut zu bewältigen , ohne sensible Aktivitäten zu übersehen.
Die Dokumentation zu AWS CloudTrail bestätigt, dass die Ereignishistorie 90 Tage lang Verwaltungsereignisse pro Region speichert, Datenereignisse jedoch ausschließt. API-Aufrufe an Secrets Manager erzeugen CloudTrail-Datensätze, ohne die Werte der Geheimnisse offenzulegen.
S3-Objektoperationen, darunter GetObject und DeleteObject, erfordern eine separat konfigurierte Protokollierung von Datenereignissen. Die Protokollierungsrichtlinien von AWS für S3 bestätigen, dass diese Ereignisse standardmäßig nicht aufgezeichnet werden. Eine erst nach einem Angriff aktivierte Protokollierung kann zuvor nicht erfasste Aktivitäten nicht nachträglich wiederherstellen.
Missbrauch von AWS-Zugangsdaten erkennen und eindämmen
Sicherheitsteams sollten die Beweissicherung, die Eindämmung kompromittierter Zugangsdaten und Kontrollen priorisieren, die unbefugten Zugriff begrenzen.
- AWS-Aktivitäten untersuchen: Erfolgreiche
GetSecretValueAnfragen mit abgewiesenen Operationen, unbekannten IP-Adressen und einer schnellen Aufzählung über mehrere Identitäten hinweg korrelieren. - IIS-Anwendungen überprüfen: Nach unerwarteten ASPX-Dateien, verdächtigen
w3wp.exeAktivitäten und unbefugtem Zugriff auf die Konfiguration suchen. Die Berechtigungen von Anwendungspools beschränken. - Kompromittierte Zugangsdaten eindämmen: Offengelegte Schlüssel deaktivieren, betroffene Sitzungen, sofern unterstützt, widerrufen, Geheimnisse rotieren und unbefugte IAM-Änderungen untersuchen.
- Identitätskontrollen stärken: Den Zugriff auf Secrets Manager beschränken, das Prinzip der geringsten Rechte durchsetzen, eingebettete Zugangsdaten durch temporäre Workload-Identitäten ersetzen und geeignete Netzwerkbeschränkungen anwenden.
- Protokollierung und Wiederherstellung verbessern: Die CloudTrail-Abdeckung überprüfen, die Protokollierung von S3-Datenereignissen aktivieren und GuardDuty-Ergebnisse überwachen. Kritische Objekte mit S3-Versionierung und geeigneten Object-Lock-Kontrollen schützen.
- Pläne zur Reaktion auf Vorfälle testen: Diebstahl von Zugangsdaten und unbefugten Zugriff auf Geheimnisse simulieren, um Erkennung, Eindämmung, Beweissicherung und Wiederherstellung zu validieren.
Die Analyse der Cloud Security Alliance unterstützt die Korrelation von Identitäts-, API- und Infrastrukturbeweisen, anstatt sich auf isolierte Indikatoren zu verlassen. Ermittler sollten erfolgreiche API-Operationen überprüfen, bevor sie einen Vorfall auf Grundlage überwiegend abgewiesener Anfragen schließen.
Mehr lesen: Der Zeabur-Vorfall mit offengelegten Zugangsdaten von Anwendungen zeigt, warum die Rotation von Zugangsdaten und Prüfungen der Wiederherstellung auch auf mit einer kompromittierten Hosting-Plattform verbundene Dienste ausgeweitet werden müssen.