Analyse d'un flux d'attaque
Contexte
Nous sommes le 19 décembre 2021 (oui, vous avez bien lu, deux ans plus tôt, jour pour jour).
L’équipe cloud AWS vous averti qu’une clé d’API AWS a été compromise et a servi à déployer des logiciels de crypto mining. Fort heureusement, votre société interdit la réutilisation des clés d’API pour plusieurs usages : vous êtes donc certain de l’origine de cette fuite de donnée : c’est l’application visa-processor qui exploite cette clé d’API.
$ oc rsh -n data-theft deploy/visa-processor /bin/sh -c 'env' | sort | grep ^A
APP_ID=visa-processor
APP_ROOT=/opt/app-root
AWS_ACCESS_KEY_ID=Easy, peasy!
AWS_SECRET_ACCESS_KEY=Catch me if you can!
Note : les clés d’API AWS ont été caviardées dans le lab pour éviter une crise cardiaque inutile aux équipes sécurité Red Hat. Elles ont été remplacées par deux messages humoristiques. :)
Dans le même temps, l’équipe réseau vous averti de la présence d’un flux sortant inhabituel à destination de serveurs eux aussi hébergés sur AWS.
$ dig +short public.requestbin.com
54.192.137.16
54.192.137.101
54.192.137.26
54.192.137.85
$ whois 18.155.129.83 |grep OrgTechName
OrgTechName: Amazon EC2 Network Operations
Objectif de l’exercice
Votre mission, si vous l’acceptez, est d’investiguer l’environnement du Lab à la recherche du chemin parcouru par l’attaquant pour perpétrer cette exfiltration de données. L’objectif est atteint quand vous trouvez l’URL du Request Bin utilisé par l’attaquant pour exfiltrer la clé d’API.
A vous de jouer !
Indices :
- Commencez par la section Violations et filtrez la vue avec
deployment:visa-processor namespace:data-theft - Basculez sur la section Network Graph V2 et affichez les flux du cluster local-cluster, namespace data-theft. Cliquez sur les déploiements information-service et back-office et comparez leur flux. Lequel vous semble le plus suspicieux ?
- Retournez dans la section Violations et filtrez la vue avec le nom du déploiement qui vous semble le plus suspicieux.
