CloudTrail: StopLogging und deaktiviertes GuardDuty erkennen
Umgehung von Abwehrmaßnahmen in AWS: StopLogging, DeleteTrail, geänderte Event-Selektoren, gelöschtes GuardDuty – was CloudTrail aufzeichnet, was verloren geht.
Kurzfassung. Auch das Blenden der Verteidiger wird protokolliert. StopLogging und DeleteTrail werden von genau dem Trail aufgezeichnet, den sie stoppen; DeleteDetector erscheint in CloudTrail, obwohl GuardDuty danach weg ist; PutEventSelectors und UpdateTrail schränken still und leise ein, was überhaupt noch protokolliert wird. Stufen Sie jedes dieser Ereignisse von einem unerwarteten Principal als kritisch ein, stellen Sie die Protokollierung sofort wieder her und schließen Sie dann die Lücke: Der Ereignisverlauf ist unabhängig von Trails und hält 90 Tage Management-Ereignisse pro Region vor. Ein gestoppter Trail bedeutet deshalb selten, dass gar keine Belege existieren.
Angreifer, die ein paar Minuten in einem AWS-Konto verbracht haben, wissen genau, was sie beobachtet. Sobald sie Administratorrechte haben, ist das Abschalten von CloudTrail, GuardDuty, AWS Config oder VPC Flow Logs billig und oft per Skript automatisiert. MITRE ATT&CK führt das als T1562.008 Impair Defenses: Disable or Modify Cloud Logs und T1562.001 Disable or Modify Tools.
CloudTrail: stoppen, löschen oder einschränken
| Ereignis | Wirkung | Worauf Sie achten sollten |
|---|---|---|
StopLogging | Trail liefert nicht mehr; Konfiguration bleibt erhalten | requestParameters.name (Trail), Region, Aufrufer |
DeleteTrail | Trail ist gelöscht | Dasselbe |
UpdateTrail | Ziel-Bucket, Präfix, Multi-Region, globale Ereignisse und KMS-Schlüssel können sich ändern | Neue Einstellungen mit den alten vergleichen |
PutEventSelectors / PutInsightSelectors | Datenereignisse oder Management-Ereignisse können wegfallen | eventSelectors / advancedEventSelectors |
StopEventDataStoreIngestion, DeleteEventDataStore | CloudTrail Lake stoppt oder verschwindet | ARN des Event Data Store |
Typische Fehleinschätzungen in der Praxis:
StopLoggingwird protokolliert. Der Aufruf wird aufgezeichnet, bevor die Protokollierung endet. Identität und IP-Adresse des Angreifers stehen also in Ihrer letzten ausgelieferten Datei.- Einschränken ist leiser als Stoppen. Ein
PutEventSelectors, dasReadWriteTypeaufWriteOnlysetzt oder den Selektor für S3-Datenereignisse entfernt, lässt den Trail in jedem Dashboard „aktiv“ erscheinen – und verwirft genau die Ereignisse, die Sie brauchen, um Datenzugriffe nachzuweisen. - Sabotage am Bucket. Log-Objekte löschen, die Bucket-Richtlinie ändern oder eine Lifecycle-Regel hinzufügen berührt den Trail überhaupt nicht. Suchen Sie nach
PutBucketPolicy,PutBucketLifecycleConfigurationundDeleteObjectsauf dem Trail-Bucket (Letzteres nur, wenn Datenereignisse den Bucket abdecken). - Organisations-Trails lassen sich aus einem Mitgliedskonto heraus nicht stoppen. Ein Angreifer in einem Mitgliedskonto nimmt sich dann eher Trails auf Kontoebene oder die unten aufgeführten Dienste vor.
GuardDuty selbst meldet Stealth:IAMUser/CloudTrailLoggingDisabled, wenn ein Trail deaktiviert oder gelöscht wird (Finding-Typen) – vorausgesetzt, GuardDuty läuft dann noch.
GuardDuty: löschen, aussetzen oder stummschalten
| Ereignis | Wirkung |
|---|---|
DeleteDetector | GuardDuty ist in dieser Region aus; vorhandene Befunde verschwinden mit |
UpdateDetector mit enable: false | Detektor ausgesetzt |
DisassociateFromAdministratorAccount, DisassociateFromMasterAccount | Mitgliedskonto verlässt die zentrale Überwachung |
DeleteMembers, DisassociateMembers, StopMonitoringMembers | Administrator überwacht die Mitglieder nicht mehr |
CreateIPSet / UpdateIPSet | Vertrauenswürdige IP-Liste: GuardDuty ignoriert diese Adressen |
CreateFilter / UpdateFilter mit action: ARCHIVE | Passende Befunde werden automatisch archiviert |
DeletePublishingDestination | Befunde werden nicht mehr nach S3 exportiert |
Die vertrauenswürdige IP-Liste und der Auto-Archivierungsfilter sind die subtilen Varianten: GuardDuty läuft weiter, die Konsole sieht gesund aus, aber die Adresse des Angreifers erzeugt keine Befunde mehr – oder seine Befunde werden archiviert, bevor jemand sie liest.
Da mit dem Löschen eines Detektors auch seine Befunde verschwinden, sollten Sie GuardDuty-Befunde exportieren, sobald ein Vorfall vermutet wird (Anleitung zum Export der Logs).
Alles andere, was Sie überwacht
| Dienst | Ereignisse | ATT&CK |
|---|---|---|
| AWS Config | StopConfigurationRecorder, DeleteConfigurationRecorder, DeleteDeliveryChannel | T1562.001 |
| Security Hub | DisableSecurityHub, BatchDisableStandards | T1562.001 |
| Macie | DisableMacie, UpdateMacieSession (pausiert) | T1562.001 |
| Inspector | inspector2:Disable | T1562.001 |
| Detective | DeleteGraph, DisassociateMembership | T1562.001 |
| S3-Zugriffsprotokollierung | PutBucketLogging ohne LoggingEnabled | T1562.008 |
| VPC Flow Logs | DeleteFlowLogs | T1562.008 |
| CloudWatch Logs | DeleteLogGroup, DeleteLogStream | T1070 |
Denken Sie an die regionale Dimension: GuardDuty, Config und Security Hub sind regionale Dienste. Ein Angreifer, der den Detektor in eu-west-1 löscht und anschließend in ap-southeast-1 arbeitet, wo GuardDuty nie aktiviert war, setzt zwei Umgehungstechniken gleichzeitig ein – die zweite ist T1535 Unused/Unsupported Cloud Regions.
Die Lücke auswerten
Wurde die Protokollierung gestoppt, besteht Ihre Aufgabe darin, den blinden Fleck einzugrenzen und ihn aus anderen Quellen zu füllen:
- Eingrenzen. Das
StopLogging-Ereignis liefert den Beginn; die nächste ausgelieferte Datei (oder dasStartLogging-Ereignis, wenn Sie die Protokollierung wieder einschalten) liefert das Ende. - Ereignisverlauf. Er ist von der Trail-Konfiguration nicht betroffen (Dokumentation): Laden Sie ihn für jede Region und für das Zeitfenster der Lücke herunter. Datenereignisse bekommen Sie dort nicht, wohl aber die Management-Ereignisse.
- Andere Trails. Ein Organisations-Trail oder ein zweiter Trail auf Kontoebene ist womöglich weitergelaufen.
- Zustand auf Dienstseite. Ressourcen, die jetzt existieren, aber während der Lücke angelegt wurden (Benutzer, Instanzen, Schlüssel), lassen sich über ihren Erstellungszeitpunkt datieren:
user_creation_timeim IAM-Credential-Report,LaunchTimebei Instanzen,CreateDatebei Schlüsseln. - Netzwerkbelege. VPC Flow Logs decken die Lücke auf Netzwerkseite ab – sofern sie überlebt haben.
Halten Sie die Lücke ausdrücklich im Bericht fest. „Keine bösartige Aktivität gefunden“ und „keine Logs für 02:10–03:40“ sind zwei verschiedene Aussagen.
Maßnahmen
- Starten Sie die Protokollierung neu (
StartLogging) oder legen Sie den Trail mit seinen vorherigen Einstellungen neu an; aktivieren Sie GuardDuty, Config und die Sicherheitsdienste in jeder Region wieder, in der sie liefen. - Entfernen Sie vom Angreifer hinzugefügte vertrauenswürdige IP-Listen und Archivierungsfilter; stellen Sie die Veröffentlichungsziele wieder her.
- Richten Sie Alarme auf diese Ereignisse ein – AWS beschreibt CloudWatch-Alarme auf CloudTrail-Ereignisse.
- Verbieten Sie diese Aktionen mit AWS Organizations per Service Control Policy allen außer einer Break-Glass-Rolle.
Im Analyzer
AWS Forensics stuft gestoppte oder gelöschte CloudTrail-Protokollierung als kritisch ein – das allein reicht für die Bewertung „Anzeichen einer Kompromittierung“ – und markiert außerdem geänderte Trail-Konfigurationen, geschwächtes GuardDuty (einschließlich IP-Listen und Archivierungsfiltern), gestopptes Config, deaktivierte Sicherheitsdienste, abgeschaltete S3-Protokollierung, gelöschte Flow Logs und gelöschte Log-Gruppen. Die vollständige Liste finden Sie in der Referenz der zu überwachenden CloudTrail-Ereignisse; was kein Tool mehr zurückholen kann, wenn die Logs weg sind, beschreibt der Beitrag über die Grenzen einer rein logbasierten Untersuchung.