Mais comment renforcer la détection d’une intrusion dans son entreprise ? Les tests d’intrusion permettent d’évaluer le niveau de protection/durcissement sur un périmètre précis et encadré, qui ne représentent pas forcement la réalité vécue lors de nos réponses à incidents. Les exercices de gestion de crise permettent quant à eux d’améliorer la réaction… L’opération Red Team peut être un bon élément de réponse, permettant ainsi d’évaluer (et donc d’améliorer) de bout en bout le système d’informations ainsi que les capacités de détection.

Qu’est-ce qu’une opération Red Team ? C’est tout simplement une attaque réaliste mais sans les effets négatifs. L’objectif est de déterminer, aujourd’hui, quelles sont les actions malveillantes qu’un groupe d’attaquants peut réaliser sur mon entreprise et à quel moment suis-je capable de les détecter ?

Dans cet article, nous verrons quelles sont les étapes clefs d’une telle opération et comment s’assurer d’en récolter les fruits.

ETAPE 1 : DEFINIR L’EQUIPE CŒUR ET IDENTIFIER LE TROPHEE

Définir une équipe de contrôle restreinte est primordiale pour limiter la fuite d’informations vers la Blue Team (équipe de détection, i.e. SOC), fluidifier les communications et faciliter la prise de décision par le client. L’équipe de contrôle devra donc être séparée clairement de la Blue Team. Souvent le choix se porte vers le CISO ou un représentant du COMEX, avec qui il faudra fixer les limites du périmètre et du mode opératoire (les plus larges possibles), pour éviter tout incident malencontreux !

« That’s out of scope » – Said no attacker ever

Ensuite, une particularité d’une opération Red Team est de définir un « trophée », c’est la cible de l’opération. En effet, un attaquant est souvent motivé par un objectif (gain, destruction, espionnage, …) et il convient de calquer les objectifs de la Red Team dessus. La Red Team a en général déjà quelques bonnes idées mais les meilleurs trophées (i.e l’impact le plus fort lors de la restitution) sont étroitement liées aux enjeux business de l’entreprise ainsi que son actualité.

La cible doit être les scénarios qui font le plus froid dans le dos des dirigeants : une prise de contrôle à distance de l’infrastructure SWIFT ? Une compromission des terminaux de paiement ? La fuite de la liste des clients VIP ? Les positions prises ces derniers mois à l’étranger ? Les idées peuvent être nombreuses, mais il est nécessaire de se restreindre à une cible ou deux pour garder en visibilité ce qui est le plus critique. Il sera toujours possible d’identifier un autre trophée pour la prochaine opération : il est même conseillé de modifier les trophées d’une année sur l’autre afin de tester des pans de système d’information différents.

Lors de nos dernières interventions, des COMEX portent leur choix sur des scénarios ayant déjà eu lieu lors de réelles cyberattaques qu’ils avaient subies. Cela leur permet aussi d’évaluer l’efficacité des nouveaux moyens de sécurité mis en œuvre.

ETAPE 2 : PREPARER ET LANCER L’ASSAUT EN MELANT EFFICACITE ET FURTIVITE

La crédibilité de l’attaque est un des facteurs clef du succès de l’opération, notamment pour la phase de restitution. Une fois le trophée arrêté : nous construisons une démarche basée sur les techniques utilisées par les groupes d’attaquants.

C’est à ce moment que les retours terrains sont particulièrement utiles ! Chez Wavestone, nous nous appuyons fortement sur notre équipe de réponse à incident (CERT-W) et sa capacité de Threat Intelligence pour identifier les dernières tendances, sur le savoir-faire technique de notre équipe d’audit ainsi que la créativité de notre équipe CTF (Capture The Flag).

Ainsi, la Red Team utilisera l’ensemble des moyens possibles et nécessaires afin de pénétrer sur le SI (campagne de phishing, phishing téléphonique, intrusion physique, compromission de composants exposés sur internet…) et ensuite rebondir vers le trophée. Cette phase est la plus créative et passionnante pour les auditeurs (comme pour les attaquants), et peut potentiellement durer plusieurs semaines, à l’image des cyberattaques les plus médiatisées.

Toutefois, le maître-mot doit rester : « furtivité » ! En effet, la moindre détection par la Blue Team peut totalement faire échouer ou reculer l’opération. Une attention particulière doit être portée sur des outils et infrastructures d’attaque sur mesure pour ne pas affoler les systèmes de détection. Pour le premier point, nous avons développé en interne l’outil Abaddon, désormais open-source, et permettant de construire et déployer en quelques clics les infrastructures nécessaires.

Deux questions reviennent systématiquement concernant le déroulement d’une opération Red Team.

La première « Que faire en cas de détection ? ». Qu’une action se fasse détecter peut arriver au cours d’une opération Red Team : une bonne règle de corrélation du SIEM, un utilisateur averti qui partage un comportement anormal, etc.. Tout d’abord, dans l’organisation de base l’équipe de contrôle doit superviser les incidents au sein du SOC afin d’éviter une « sur-escalade » en crise d’un incident en relation avec le Red Team. La cellule de contrôle pourra ainsi demander un rapport à la Blue Team (résumé, comportement détecté, timeline des actions, actions de remédiation, …) et définir ensuite le scénario de reprise avec la Red Team : ne pas tenir compte de la détection car elle est trop ancienne, repartir de l’avant dernier asset compromis qui n’a pas été détecté, etc. De plus, le travail deviendra plus compliqué pour la Red Team qui devra par exemple changer totalement son infrastructure C2 et dorénavant réussir à tromper une Blue Team en alerte.

La seconde « Si les le(s) trophée(s) sont obtenues très rapidement, que faire ?». Imaginons le pire des scénarios : l’administrateur applicatif du trophée se fait piégé par un mail de phishing et nous permet de prendre le contrôle complet de l’application dès le début de l’opération (Tout le monde peut faire une erreur). Le point sera partagé avec l’équipe de contrôle et la marche à suivre sera définie conjointement : ajouter des trophées pour tester la robustesse d’un autre périmètre, repartir de zéro et identifier un autre chemin de compromission, … Cet exemple un peu caricatural est là pour rappeler que l’objectif d’une opération Red Team est d’améliorer durablement le niveau de sécurité via l’entrainement de la Blue Team et non juste l’obtention d’un trophée.

ETAPE 3 : RESTITUER UNE REPONSE CLAIRE SUR UN RISQUE METIER CRITIQUE

L’objectif reste d’apporter aux commanditaires une vision claire sur l’état de sécurité réel de leur SI, sur les scénarios d’attaque permettant d’accéder à leurs ressources critiques (identifiées comme « trophées » de l’opération), ainsi que sur leurs capacités de détection. Tout simplement, l’opération Red Team doit permettre de répondre à la question « Le trophée est-il accessible et avec quel niveau d’expertise ? ». Il faut cependant retenir que l’opération Red Team va mettre en valeur un chemin exploitable qui ne sera peut-être pas le seul, ni le plus simple.

Dès lors, nous restituons aux parties prenantes (CISO, SOC, COMEX…) avec une synthèse haut-niveau afin de présenter les conclusions de l’opération Red Team, le scénario d’attaque suivi et les chantiers les plus prioritaires. Les résultats sont généralement comparés à des profils type d’attaquants (Maze, REvil/Sodinoki…) sur le référentiel MITRE ATT&CK pour être plus parlants.

Dans un second temps, il faudra évidemment restituer en détails à la Blue Team les étapes techniques de l’opération, en vue de définir des axes de progrès sur la détection.

“If we win, we lose » Said a good red teamer

$ python3 ./beemka/beemka.py —inject —module rshell_cmd —asar ./electron_safe.asar —output ./electron.asar