Les équipes de sécurité cloud qui enquêtent sur un accès volé à des modèles devraient déterminer qui pouvait activer de nouveaux services d’IA et créer des identités supplémentaires, puis retracer ce que ces identités ont fait. Renouveler la première clé exposée peut laisser subsister d’autres voies d’accès et des services nouvellement activés.
C’est la leçon opérationnelle que Maetra tire du rapport sur le LLMJacking publié le 2 novembre par Mandiant et Google Threat Intelligence Group. Mandiant décrit des incidents dans lesquels des attaquants ont détourné des ressources de modèles d’entreprise. Le rapport fait état, dans certains incidents individuels, de frais de ressources frauduleux dépassant 100 000 dollars en une seule journée, et de frais cumulés atteignant 1 million de dollars dans certaines organisations. Il s’agit d’observations attribuées issues de cas enquêtés, et non d’une perte moyenne, d’un taux sectoriel ou de résultats financiers audités de manière indépendante.
Examiner la capacité d’activer des services
Le rapport indique que des jetons d’identité cloud exposés ou volés constituaient le principal vecteur d’accès initial dans plusieurs enquêtes. Il décrit aussi des cas où les services LLM n’étaient pas activés au moment où la compromission a commencé. Les attaquants ont utilisé leur accès pour activer des services et consommer des ressources. L’implication pratique est qu’un inventaire des modèles actuellement utilisés ne décrit pas tous les services de modèles qu’une identité pourrait activer.
Commencez l’enquête par le projet, l’abonnement ou le compte cloud concerné, ainsi que par les autorisations de l’identité au moment pertinent. Comparez les services activés avant l’intrusion présumée avec les changements intervenus ensuite. Identifiez l’acteur, l’horodatage et la configuration de chaque activation inexpliquée.
Cette revue doit inclure les identités d’automatisation ordinaires. Un compte de service de déploiement peut devoir provisionner une infrastructure approuvée sans avoir pour autant de raison métier d’activer un fournisseur de modèles supplémentaire. Déterminez si ces pouvoirs peuvent être séparés dans l’environnement réel. Ne supposez pas qu’un nom d’identifiant familier rend son utilisation légitime.
Établir une filiation des accès, pas seulement une liste de clés
Maetra recommande d’enregistrer la relation entre l’identité initiale et tout accès créé pendant l’incident. Recensez les nouveaux comptes, identifiants, attributions, sessions et services, avec leurs propriétaires et leur état actuel. Lorsque les traces sont incomplètes, indiquez que la relation est incertaine au lieu de relier des événements uniquement parce que leurs horodatages sont proches.
Un dossier d’enquête utile répond à quatre questions :
- Quelle identité a obtenu l’accès en premier, et quels éléments de preuve étayent cette conclusion ?
- Quelle nouvelle autorité ou quel nouvel identifiant a-t-elle créé ou obtenu ?
- À quelle ressource cette autorité a-t-elle accédé, et quelles requêtes ont été acceptées ?
- Quels éléments de preuve montrent que ce chemin d’accès a bien été fermé ?
La dernière question modifie la remédiation. Révoquer un identifiant parent peut avoir des effets différents sur des sessions dérivées ou sur des comptes créés indépendamment. Faites vérifier ces effets par le propriétaire d’identité concerné. Préservez les éléments nécessaires à l’enquête avant de supprimer les artefacts malveillants confirmés, en suivant les procédures de l’équipe de réponse à incident.
Corréler les petites sondes avec les changements de configuration
Les fortes hausses d’usage sont des signaux utiles, mais attendre une facture élevée revient à intégrer l’impact financier dans la détection. Le rapport décrit à la fois une validation à faible volume de clés volées et des abus à fort volume. Cela justifie d’examiner les schémas d’accès parallèlement aux changements de configuration et aux événements liés aux identités.
Pour une revue cadrée, sélectionnez un service de modèles et comparez une période d’activité normale avec la fenêtre d’exposition suspectée. Recherchez une première utilisation par une identité inattendue, une activation inhabituelle de service, un nouvel identifiant ou une modification de la journalisation. Enquêtez sur les combinaisons de signaux dans leur contexte ; une seule requête inconnue ne constitue pas une preuve de compromission.
Attribuez à la même chronologie un responsable sécurité cloud et un responsable des coûts. La télémétrie de sécurité peut établir quelles requêtes ont abouti, tandis que les relevés de facturation décrivent une consommation attribuée sur un intervalle de reporting différent. Gardez ces distinctions visibles lorsque vous estimez l’impact. Évitez de présenter une estimation préliminaire d’usage comme une facture arrêtée ou une perte confirmée.
Vérifier le confinement avec le propriétaire de la ressource
Le rapport fournit des recommandations de détection et de remédiation propres aux différents clouds. L’équipe de réponse doit appliquer les contrôles pertinents du fournisseur concerné et vérifier leur comportement dans son propre environnement. Les notifications budgétaires, les quotas d’usage, les restrictions d’identifiants et les autorisations d’activation de services n’ont pas le même objectif ni la même sémantique d’application.
Par exemple, une notification budgétaire peut informer un propriétaire pendant que les requêtes continuent. Un quota configuré peut limiter une ressource sans couvrir toutes les régions, tous les modèles ou toutes les identités. Déterminez la portée réelle avant de traiter l’un ou l’autre comme une limite de confinement. Il s’agit de questions de revue, et non d’affirmations selon lesquelles tous les fournisseurs se comportent de la même manière.
Après la remédiation, vérifiez l’état attendu : les identités non autorisées sont désactivées, les attributions inexpliquées sont supprimées, les services inutiles sont restreints et les journaux requis restent disponibles. Testez aussi les accès approuvés des applications, afin que le rétablissement ne casse pas silencieusement le flux de travail légitime.
Garder des affirmations précises sur les sources et sur le rôle du produit
The Register a couvert le rapport de manière indépendante, y compris avec un commentaire de la direction du renseignement sur les menaces de Google. Cela corrobore la divulgation et l’attribution. Cela ne reproduit pas indépendamment les enquêtes sur les incidents et ne vérifie pas non plus le coût subi par chaque victime.
Un inventaire documenté des agents constitue un point de départ utile pour identifier les applications et leurs responsables. Étendez l’enquête aux identités et aux services qui ne figurent pas dans cet inventaire.
Maetra Secure analyse les prompts, les messages, les appels d’outils et les sorties à la recherche de menaces à l’exécution, y compris l’exposition de données. Une telle inspection peut contribuer à fournir des preuves sur l’activité applicative couverte. L’IAM cloud, la révocation des identifiants, les restrictions de services et les contrôles financiers doivent toujours être appliqués par les systèmes qui en ont la charge. Cet article n’affirme pas que Maetra a empêché ou détecté les incidents signalés.
Utilisez la documentation de Maetra pour identifier les événements applicatifs pertinents pour une chronologie d’incident, puis reliez ces enregistrements aux preuves concernant l’identité cloud et les ressources. La revue n’est complète que lorsque les responsables concernés peuvent expliquer à la fois le flux de travail légitime et l’incertitude restante.