AWS - GuardDuty Enum
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Selon les docs: GuardDuty combine l'apprentissage automatique, la détection d'anomalies, la surveillance du réseau et la découverte de fichiers malveillants, en utilisant à la fois AWS et des sources tierces de premier plan pour aider à protéger les charges de travail et les données sur AWS. GuardDuty est capable d'analyser des dizaines de milliards d'événements à travers plusieurs sources de données AWS, telles que les journaux d'événements AWS CloudTrail, les journaux de flux Amazon Virtual Private Cloud (VPC), les journaux d'audit et de niveau système d'Amazon Elastic Kubernetes Service (EKS), et les journaux de requêtes DNS.
Amazon GuardDuty identifie les activités inhabituelles au sein de vos comptes, analyse la pertinence de sécurité de l'activité et fournit le contexte dans lequel elle a été invoquée. Cela permet à un intervenant de déterminer s'il doit consacrer du temps à une enquête plus approfondie.
Les alertes apparaissent dans la console GuardDuty (90 jours) et dans les événements CloudWatch.
Lorsque un utilisateur désactive GuardDuty, il cessera de surveiller votre environnement AWS et ne générera aucune nouvelle découverte, et les découvertes existantes seront perdues. Si vous l'arrêtez simplement, les découvertes existantes resteront.
Reconnaissance: Activité suggérant une reconnaissance par un attaquant, telle que une activité API inhabituelle, des tentatives de connexion à une base de données suspectes, un scan de port intra-VPC, des modèles de requêtes de connexion échouées inhabituels, ou un sondage de port non bloqué à partir d'une adresse IP connue comme malveillante.
Compromission d'instance: Activité indiquant une compromission d'instance, telle que minage de cryptomonnaie, activité de commande et de contrôle (C&C) par porte dérobée, malware utilisant des algorithmes de génération de domaine (DGA), activité de déni de service sortant, volume de trafic réseau anormalement élevé, protocoles réseau inhabituels, communication sortante d'instance avec une adresse IP malveillante connue, des identifiants Amazon EC2 temporaires utilisés par une adresse IP externe, et exfiltration de données utilisant DNS.
Compromission de compte: Les modèles courants indicatifs de compromission de compte incluent des appels API provenant d'une géolocalisation inhabituelle ou d'un proxy anonymisant, des tentatives de désactiver la journalisation AWS CloudTrail, des changements qui affaiblissent la politique de mot de passe du compte, des lancements d'instances ou d'infrastructures inhabituels, des déploiements d'infrastructure dans une région inhabituelle, le vol d'identifiants, une activité de connexion à la base de données suspecte, et des appels API provenant d'adresses IP malveillantes connues.
Compromission de bucket: Activité indiquant une compromission de bucket, telle que des modèles d'accès aux données suspects indiquant un usage abusif des identifiants, une activité API Amazon S3 inhabituelle provenant d'un hôte distant, un accès S3 non autorisé à partir d'adresses IP malveillantes connues, et des appels API pour récupérer des données dans des buckets S3 d'un utilisateur sans historique préalable d'accès au bucket ou invoqués depuis un emplacement inhabituel. Amazon GuardDuty surveille et analyse en continu les événements de données S3 d'AWS CloudTrail (par exemple, GetObject, ListObjects, DeleteObject) pour détecter des activités suspectes à travers tous vos buckets Amazon S3.
Accédez à une liste de toutes les découvertes GuardDuty sur: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html
Vous pouvez inviter d'autres comptes à un autre compte AWS GuardDuty afin que chaque compte soit surveillé depuis le même GuardDuty. Le compte principal doit inviter les comptes membres et ensuite le représentant du compte membre doit accepter l'invitation.
Vous pouvez désigner n'importe quel compte au sein de l'organisation comme administrateur délégué GuardDuty. Seul le compte de gestion de l'organisation peut désigner un administrateur délégué.
Un compte qui est désigné comme administrateur délégué devient un compte administrateur GuardDuty, a GuardDuty activé automatiquement dans la région AWS désignée, et a également la permission d'activer et de gérer GuardDuty pour tous les comptes de l'organisation dans cette région. Les autres comptes de l'organisation peuvent être visualisés et ajoutés en tant que comptes membres GuardDuty associés à ce compte administrateur délégué.
Essayez de découvrir autant que possible sur le comportement des identifiants que vous allez utiliser :
Heures d'utilisation
Lieux
Agents utilisateurs / Services (Cela pourrait être utilisé depuis awscli, webconsole, lambda...)
Permissions régulièrement utilisées
Avec ces informations, recréez autant que possible le même scénario pour utiliser l'accès :
Si c'est un utilisateur ou un rôle accédé par un utilisateur, essayez de l'utiliser aux mêmes heures, depuis la même géolocalisation (même le même FAI et IP si possible)
Si c'est un rôle utilisé par un service, créez le même service dans la même région et utilisez-le depuis là dans les mêmes plages horaires
Essayez toujours d'utiliser les mêmes permissions que ce principal a utilisées
Si vous devez utiliser d'autres permissions ou abuser d'une permission (par exemple, télécharger 1.000.000 de fichiers journaux cloudtrail), faites-le lentement et avec le minimum d'interactions avec AWS (awscli appelle parfois plusieurs API de lecture avant celle d'écriture)
guardduty:UpdateDetectorAvec cette permission, vous pourriez désactiver GuardDuty pour éviter de déclencher des alertes.
guardduty:CreateFilterLes attaquants disposant de cette autorisation ont la capacité de utiliser des filtres pour l'archivage automatique des résultats :
iam:PutRolePolicy, (guardduty:CreateIPSet|guardduty:UpdateIPSet)Les attaquants disposant des privilèges précédents pourraient modifier la liste IP de confiance de GuardDuty en y ajoutant leur adresse IP et éviter de générer des alertes.
guardduty:DeletePublishingDestinationLes attaquants pourraient supprimer la destination pour empêcher les alertes :
La suppression de cette destination de publication n'affectera pas la génération ou la visibilité des résultats dans la console GuardDuty. GuardDuty continuera à analyser les événements dans votre environnement AWS, à identifier les comportements suspects ou inattendus, et à générer des résultats.
Notez qu'il existe des dizaines de résultats GuardDuty, cependant, en tant que Red Teamer, tous ne vous affecteront pas, et ce qui est mieux, vous avez la documentation complète de chacun d'eux sur https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html donc jetez un œil avant de faire quoi que ce soit pour ne pas vous faire prendre.
Voici quelques exemples de contournements de résultats spécifiques de GuardDuty :
GuardDuty détecte les requêtes API AWS provenant d'outils de test de pénétration courants et déclenche un Résultat PenTest. Il est détecté par le nom de l'agent utilisateur qui est passé dans la requête API. Par conséquent, modifier l'agent utilisateur permet d'empêcher GuardDuty de détecter l'attaque.
Pour éviter cela, vous pouvez rechercher dans le script session.py dans le package botocore et modifier l'agent utilisateur, ou définir Burp Suite comme proxy AWS CLI et changer l'agent utilisateur avec le MitM ou simplement utiliser un OS comme Ubuntu, Mac ou Windows pour empêcher cette alerte de se déclencher.
L'extraction des informations d'identification EC2 du service de métadonnées et leur utilisation à l'extérieur de l'environnement AWS active l'alerte UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. Inversement, l'utilisation de ces informations d'identification depuis votre instance EC2 déclenche l'alerte UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS. Pourtant, l'utilisation des informations d'identification sur une autre instance EC2 compromise au sein du même compte passe inaperçue, ne déclenchant aucune alerte.
Par conséquent, utilisez les informations d'identification exfiltrées depuis l'intérieur de la machine où vous les avez trouvées pour ne pas déclencher cette alerte.
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
