Les experts en cybersécurité n'ont pas tardé à réagir aux détails de la faille de LastPass au cours des derniers mois. Des articles d'opinion ont été publiés, abordant les étapes critiques de remédiation pour les clients et émettant des critiques méritées sur la communication de l'incident. Le discours public n'a pas abordé les indicateurs qui peuvent être tirés des différentes communications de LastPass. Dans ce blog, je cherche à présenter les informations contenues dans les communiqués de LastPass et à énumérer les indicateurs des attaquants tout en encadrant la discussion autour de la pyramide de la douleur.
Cet article vise à suivre de près le conseil donné par l'auteur de la Pyramide de la douleur, David Bianco : "Chaque fois que vous recevez de nouveaux renseignements sur un adversaire (qu'il s'agisse d'APT1/Comment Crew ou de tout autre acteur de la menace), examinez-les attentivement à l'aune de la Pyramide de la douleur. Pour chaque paragraphe, demandez-vous s'il y a quelque chose ici que je peux utiliser pour détecter l'activité de l'adversaire, et où cela se situe-t-il dans la pyramide ?
La pyramide de la douleur pour les indicateurs Cloud
La pyramide de la douleur est un modèle conceptuel permettant de classer l'efficacité des contrôles de détection. Décrite pour la première fois par David Bianco en 2013, la "douleur" fait référence à la souffrance qu'un contrôle de détection inflige à l'adversaire. Plus on monte dans la pyramide, plus l'attaquant aura du mal à s'adapter et à échapper nécessairement aux capacités de détection du défenseur. La pyramide de la douleur reconnaît que tous les indicateurs de compromission (et donc les capacités de détection) ne sont pas créés égaux. Certains indicateurs sont faciles à modifier et à contourner pour un attaquant, tandis que d'autres comportements sont essentiels à leur objectif déclaré et ne peuvent pas être modifiés aussi facilement.
Au bas de la pyramide se trouvent les indicateurs simples tels que les adresses IP et les valeurs de hachage. Il s'agit notamment des détections cloud basées sur l'adresse IP source ou la signature de l'outil d'attaque. Les défenseurs pourraient trouver un certain réconfort dans le déploiement de détections ciblant des indicateurs situés au bas de la pyramide de la douleur, mais ils devraient être conscients de la simplicité de l'évasion.
Au sommet de la pyramide de la douleur se trouvent les indicateurs qui sont fondamentaux pour la manière dont un attaquant s'y prend pour atteindre ses objectifs. Il s'agit des tactiques, techniques et procédures (TTP) qu'il est difficile, voire impossible, pour l'acteur de la menace de modifier. Imaginons une suite de détection qui prend l'empreinte des appels API impliqués dans le transfert de données hors d'un environnement de confiance cloud . Cet indicateur serait impossible à modifier pour l'attaquant. Cet indicateur serait impossible à modifier pour un attaquant, à moins qu'il ne soit en mesure d'exploiter des mécanismes inconnus et non documentés du fournisseur cloud pour transférer des données.
Au milieu se trouvent les indicateurs qu'un adversaire pourrait modifier ou éviter de montrer avec une certaine difficulté. Lors de l'analyse du site cloud, ce niveau comprend des modèles d'événements indiquant la compromission initiale. La découverte et l'énumération d'un environnement cloud s'effectuent le plus simplement du monde en interrogeant directement les API cloud et en laissant une trace d'indicateurs sur le plan de contrôle cloud . Toutefois, ces indicateurs peuvent être évités et les mêmes informations peuvent être glanées par le biais de sources ouvertes ou en récoltant des informations dans la documentation interne.
LastPass Communications Intel
Décortiquons les éléments d'information tirés des communications publiques de LastPass - en accordant une attention particulière aux indicateurs de l'attaquant qui a ciblé les données hébergées sur le site cloud . Bien que ces communications contiennent de nombreux éléments intéressants concernant la protection et la posture défensive de LastPass, cet article se concentre sur la mise en lumière des comportements possibles de l'attaquant.
1er incident: Des dépôts de sources et de la documentation technique ont été volés.
"L'acteur de la menace a utilisé des services VPN tiers pour masquer l'origine de son activité lors de l'accès à l'environnement de développement basé sur cloud et a utilisé cet accès pour se faire passer pour l'ingénieur logiciel. Grâce à cette approche, il a pu s'introduire dans l'environnement de développement à la demande via notre VPN d'entreprise, ainsi que par une connexion dédiée à l'environnement de développement basé sur le site cloud. Pour ce faire, ils se sont appuyés sur l'authentification réussie de l'ingénieur logiciel à l'aide d'informations d'identification de domaine et de MFA. Aucune escalade de privilèges n'a été identifiée ou nécessaire.
- Cela indique que l'environnement de développement basé sur le site cloud disposait d'une connectivité hybride et était accessible aux utilisateurs authentifiés par le domaine dans l'espace IP de l'entreprise.
- Tout contrôle de détection axé sur des adresses IP inhabituelles ou connues aurait probablement manqué l'acteur de la menace utilisant le VPN de l'entreprise à partir du poste de travail de l'ingénieur logiciel ( endpoint). Toutefois, si la connexion n'a pas été établie en dehors du poste de travail, des contrôles auraient pu être mis en place pour prévenir ou détecter une connexion VPN inhabituelle.
2ème incident: Vol de sauvegardes de coffres-forts de clients contenant des données chiffrées et non chiffrées, des semences de mots de passe à usage unique et des secrets d'API utilisés dans des intégrations tierces.
"En raison des contrôles de sécurité protégeant et sécurisant les installations du centre de données sur site de LastPass production, l'acteur de la menace a ciblé l'un des quatre ingénieurs DevOps qui avaient accès aux clés de décryptage nécessaires pour accéder au service de stockage cloud ."
- Les auteurs du rapport semblent indiquer que l'auteur de la menace a choisi de cibler les données stockées sur le site cloud plutôt que les données sur site en raison de contrôles de sécurité moins robustes.
"Plus précisément, l'acteur de la menace a été en mesure de s'appuyer sur des informations d'identification valides volées à un ingénieur DevOps senior pour accéder à un environnement de stockage partagé cloud, ce qui a initialement rendu difficile pour les enquêteurs de différencier l'activité de l'acteur de la menace de l'activité légitime en cours."
"Pour accéder aux ressources de stockage basées sur cloud- notamment le seau S3.....Les services de stockage cryptés basés sur cloud hébergent les sauvegardes des clients LastPass et les données cryptées du coffre-fort."
- En regroupant ces phrases, nous pouvons déduire que l'attaquant a accédé aux objets AWS S3 en utilisant des informations d'identification valides et volées.
"Pour accéder aux ressources de stockage basées sur cloud- notamment les buckets S3 protégés par le chiffrement AWS S3-SSE, AWS S3-KMS ou AWS S3-SSE-C - l'acteur de la menace devait obtenir les clés d'accès AWS et les clés de déchiffrement générées par LastPass."
- Si une clé d'accès AWS était nécessaire pour accéder aux ressources de stockage basées sur cloud et que cet accès a finalement réussi, nous pouvons conclure qu'un utilisateur IAM a été compromis et utilisé pour accéder aux objets stockés dans S3, car il s'agit du seul principal IAM auquel des clés d'accès peuvent être attribuées.
- Étant donné que les données consultées étaient cloud - sauvegardes, on peut supposer que l'identité compromise était destinée à être utilisée dans le cadre de scénarios de reprise après sinistre.
".....Un acteur de la menace a exploité une vulnérabilité dans un logiciel tiers, a contourné les contrôles existants et a finalement accédé à des environnements de développement et de stockage de sauvegarde hors production.4"
- LastPass confirme que l'acteur de la menace a accédé aux données de sauvegarde signalées dans les communications précédentes comme étant stockées dans AWS S3. Nous pouvons utiliser ces informations pour discuter des indicateurs de compromission qu'un attaquant pourrait laisser derrière lui.
Violation de LastPass : Cloud Opportunités de détection et de réponse
Compte tenu de ce que nous savons de la valeur des différents indicateurs, comment pouvons-nous cartographier les indicateurs possibles de la violation de LastPass sur la pyramide de la douleur ?
Des indicateurs relativement "indolores
Ces indicateurs sont faciles à éviter pour un adversaire, tendent à donner lieu à des détections positives réelles très fiables, mais ne sont pas susceptibles de faire l'objet d'une action opportune de la part d'une équipe chargée des opérations de sécurité, car ils n'illustrent généralement pas l'impact sur les ressources du site cloud .
- Cloud Accès à l'API à partir d'endroits peu communs, ce qui permet de détecter des déplacements improbables.
→ Il est peu probable que le premier incident aurait été détecté si l'on avait cherché cet indicateur, mais il est possible que le deuxième incident ait produit des signaux.
Indicateurs du milieu de la pyramide
Un adversaire pourrait éviter d'utiliser ces indicateurs avec une certaine difficulté, mais il est peu probable qu'une équipe chargée des opérations de sécurité prenne des mesures en temps utile, car ils n'illustrent généralement pas l'impact sur les ressources du site cloud .
- Activité de reconnaissance
→ Après avoir obtenu l'accès à des informations d'identification valides, l'attaquant a pu exploiter les API cloud pour énumérer leurs permissions et/ou dresser la liste et décrire les objets S3. Cependant, un volume important de documentation technique a été volé lors du premier incident. Il est tout à fait possible que toutes les informations requises aient été incluses dans cette documentation et que l'attaquant n'ait pas eu besoin d'effectuer d'autres activités de reconnaissance sur le site cloud.
Indicateurs de la pyramide supérieure
L'acteur de la menace ne pourrait pas éviter de laisser ces indicateurs tout en atteignant ses objectifs, tels que l'exfiltration de données. Modifier ces indicateurs pour éviter d'être détecté nécessiterait d' utiliser une API ou une technique inconnue. Les détections basées sur ces indicateurs sont susceptibles d'attirer rapidement l'attention de l'équipe chargée des opérations de sécurité.
- Déplacement d'objets S3 vers une destination suspecte
→ Des données ont été déplacées de dépôts de données autorisés hébergés par cloud vers des emplacements contrôlés par les attaquants. Ce transfert est l'occasion d'élaborer des détections autour du déplacement de données vers des emplacements inconnus, non fiables ou externes.
- Accès à un grand volume d'objets S3
→ Nous pouvons supposer, d'après les communications de LastPass, que de grands volumes de données ont été transférés en tirant parti de la vitesse et de l'ampleur des API d'AWS Cloud . L'accès à un grand volume de données est un indicateur qui se situe au sommet de la pyramide de la douleur et constitue un signal permettant de détecter la récupération de données suspectes.
Il existe plusieurs indicateurs de compromission qui peuvent être tirés de la violation de LastPass et mis en correspondance avec tous les niveaux de la pyramide de la douleur. Bien qu'il soit utile de fournir une couverture de détection à tous les niveaux, il est important de reconnaître que votre kilométrage peut varier. La détection de l'accès à cloud à partir d'adresses IP inconnues ou non fiables sera triviale pour un attaquant, tandis que la détection des TTP de mouvements de données et d'accès aux données suspects sera probablement une méthodologie de détection éprouvée.