Détecter StopLogging et GuardDuty désactivé dans CloudTrail
Contournement des défenses sur AWS : StopLogging, DeleteTrail, sélecteurs d'événements, détecteurs GuardDuty, Config et Flow Logs supprimés dans CloudTrail.
En bref. Aveugler les défenseurs laisse lui-même des traces. StopLogging et DeleteTrail sont enregistrés par le trail qu'ils arrêtent ; DeleteDetector apparaît dans CloudTrail alors même que GuardDuty n'est plus là ; PutEventSelectors et UpdateTrail réduisent discrètement ce qui est journalisé. Traitez chacun de ces appels, venant d'un principal inattendu, comme critique, rétablissez immédiatement la journalisation, puis comblez le trou : l'historique des événements est indépendant des trails et conserve 90 jours d'événements de gestion par région, si bien qu'un trail arrêté signifie rarement une absence totale de preuves.
Un attaquant qui a passé quelques minutes dans un compte AWS sait ce qui le surveille. Une fois les droits administrateur obtenus, désactiver CloudTrail, GuardDuty, AWS Config ou les VPC Flow Logs ne lui coûte presque rien, et c'est souvent scripté. MITRE ATT&CK recense ces comportements sous T1562.008 Impair Defenses: Disable or Modify Cloud Logs et T1562.001 Disable or Modify Tools.
CloudTrail : arrêter, supprimer ou restreindre
| Événement | Effet | Ce qu'il faut lire |
|---|---|---|
StopLogging | Le trail cesse de livrer des journaux ; sa configuration est conservée | requestParameters.name (le trail), la région, l'appelant |
DeleteTrail | Le trail n'existe plus | Idem |
UpdateTrail | Le bucket de destination, le préfixe, le mode multi-région, les événements globaux et la clé KMS peuvent changer | Comparer les nouveaux paramètres avec les anciens |
PutEventSelectors / PutInsightSelectors | Les événements de données ou de gestion peuvent être écartés | eventSelectors / advancedEventSelectors |
StopEventDataStoreIngestion, DeleteEventDataStore | CloudTrail Lake s'arrête ou disparaît | ARN de l'event data store |
Les erreurs fréquentes chez les praticiens :
StopLoggingest journalisé. L'appel est enregistré avant l'arrêt de la journalisation : l'identité et l'adresse IP de l'attaquant figurent donc dans le dernier fichier livré.- Restreindre est plus discret qu'arrêter. Un
PutEventSelectorsqui passeReadWriteTypeàWriteOnly, ou qui retire le sélecteur d'événements de données S3, laisse le trail « actif » dans tous les tableaux de bord tout en supprimant précisément les événements dont vous avez besoin pour prouver un accès aux données. - Le sabotage côté bucket. Supprimer des objets de journaux, modifier la politique du bucket ou ajouter une règle de cycle de vie ne touche pas du tout au trail. Cherchez
PutBucketPolicy,PutBucketLifecycleConfigurationetDeleteObjectssur le bucket du trail (ce dernier uniquement si les événements de données le couvrent). - Les trails d'organisation ne peuvent pas être arrêtés depuis un compte membre ; un attaquant dans un compte membre s'en prendra plutôt aux trails de niveau compte ou aux services décrits plus bas.
GuardDuty lui-même lève Stealth:IAMUser/CloudTrailLoggingDisabled lorsqu'un trail est désactivé ou supprimé (types de détections), à condition que GuardDuty tourne encore.
GuardDuty : supprimer, suspendre ou réduire au silence
| Événement | Effet |
|---|---|
DeleteDetector | GuardDuty désactivé dans cette région ; les détections existantes disparaissent avec lui |
UpdateDetector avec enable: false | Détecteur suspendu |
DisassociateFromAdministratorAccount, DisassociateFromMasterAccount | Le compte membre quitte la surveillance centralisée |
DeleteMembers, DisassociateMembers, StopMonitoringMembers | Le compte administrateur cesse de surveiller les membres |
CreateIPSet / UpdateIPSet | Liste d'adresses IP de confiance : GuardDuty ignore ces adresses |
CreateFilter / UpdateFilter avec action: ARCHIVE | Les détections correspondantes sont archivées automatiquement |
DeletePublishingDestination | Les détections ne sont plus exportées vers S3 |
La liste d'IP de confiance et le filtre d'archivage automatique sont les plus insidieux : GuardDuty continue de tourner et la console semble en bonne santé, mais l'adresse de l'attaquant ne produit plus rien, ou ses détections sont archivées avant que quiconque ne les lise.
Comme la suppression d'un détecteur efface ses détections, exportez les détections GuardDuty dès qu'un incident est suspecté (guide d'export).
Tout ce qui surveille par ailleurs
| Service | Événements | ATT&CK |
|---|---|---|
| AWS Config | StopConfigurationRecorder, DeleteConfigurationRecorder, DeleteDeliveryChannel | T1562.001 |
| Security Hub | DisableSecurityHub, BatchDisableStandards | T1562.001 |
| Macie | DisableMacie, UpdateMacieSession (mis en pause) | T1562.001 |
| Inspector | inspector2:Disable | T1562.001 |
| Detective | DeleteGraph, DisassociateMembership | T1562.001 |
| Journalisation des accès S3 | PutBucketLogging sans LoggingEnabled | T1562.008 |
| VPC Flow Logs | DeleteFlowLogs | T1562.008 |
| CloudWatch Logs | DeleteLogGroup, DeleteLogStream | T1070 |
N'oubliez pas la dimension régionale : GuardDuty, Config et Security Hub sont des services régionaux. Un attaquant qui supprime le détecteur dans eu-west-1 puis travaille dans ap-southeast-1, où GuardDuty n'a jamais été activé, emploie deux techniques de contournement à la fois ; la seconde est T1535 Unused/Unsupported Cloud Regions.
Analyser le trou dans les journaux
Lorsque la journalisation a été arrêtée, votre travail consiste à délimiter l'angle mort et à le combler à partir d'autres sources :
- Le délimiter. L'événement
StopLoggingen donne le début ; le fichier livré suivant (ou l'événementStartLogginglorsque vous réactivez le trail) en donne la fin. - L'historique des événements. Il n'est pas affecté par la configuration des trails (documentation) : téléchargez-le pour chaque région et pour toute la fenêtre du trou. Vous n'aurez pas les événements de données, mais vous aurez les événements de gestion.
- Les autres trails. Un trail d'organisation ou un second trail de niveau compte a peut-être continué de fonctionner.
- L'état côté service. Les ressources qui existent aujourd'hui mais ont été créées pendant le trou (utilisateurs, instances, clés) peuvent être datées grâce à leur date de création :
user_creation_timedans le rapport d'identifiants,LaunchTimesur les instances,CreateDatesur les clés. - Les preuves réseau. Les VPC Flow Logs, s'ils ont survécu, couvrent le trou côté réseau.
Mentionnez explicitement ce trou dans le rapport. « Aucune activité malveillante constatée » et « aucun journal entre 02:10 et 03:40 » sont deux affirmations différentes.
Étapes de réponse
- Relancez la journalisation (
StartLogging) ou recréez le trail avec ses paramètres précédents ; réactivez GuardDuty, Config et les services de sécurité dans chaque région où ils tournaient. - Supprimez les listes d'IP de confiance et les filtres d'archivage ajoutés par l'attaquant ; rétablissez les destinations de publication.
- Déclenchez des alarmes sur ces événements : AWS décrit comment créer des alarmes CloudWatch sur les événements CloudTrail.
- Avec AWS Organizations, interdisez ces actions à tous sauf à un rôle d'urgence (break-glass) au moyen d'une stratégie de contrôle des services.
Dans l'analyseur
AWS Forensics classe l'arrêt ou la suppression de CloudTrail comme critique (cela suffit à lui seul pour un verdict « Signes de compromission ») et signale les modifications de configuration des trails, l'affaiblissement de GuardDuty (y compris les listes d'IP et les filtres d'archivage), l'arrêt de Config, la désactivation des services de sécurité, la journalisation S3 coupée, les Flow Logs supprimés et les groupes de logs supprimés. Consultez la référence des événements CloudTrail à surveiller pour la liste complète, et les limites d'une investigation fondée uniquement sur les journaux pour ce qu'aucun outil ne peut récupérer une fois les journaux disparus.