Connect the dots #12: « Réponses à la Cyber Kill Chain: Phishing, Compromission initiale et C2 »

Nous allons examiner dans cet article comment les attaquants s'y prennent pour contourner nos défenses périmétriques. Les principal et quasiment le seul vecteur de contamination provient des e-mails. Les sites web douteux et les clefs USB sont d'autres sources, mais nettement moindres en risques réels. Les attaquants vont donc envoyer de nombreux e-mails piégés aux adresses qu'ils ont récupérées lors de la phase de préparation. Ils peuvent faire des envois de masse avec le risque d'être blacklistés comme "spammeurs" ou bien ils peuvent effectuer des envois ciblés (spear phishing) à des cibles "intéressantes": dirigeants, administrateurs informatiques, gestionnaires de bases de données, support, etc.

Dot#3: Envoi de phishing.

Dans cette phase donc, un certains nombre d'emails sont envoyés à des utilisateurs identifiés de la cible, avec une pièce jointe ou un lien à cliquer qui va permettre aux attaquants de pénétrer à l'intérieur du périmètre défensif, tel un Cheval de Troie. Récemment on a vu des variantes basées sur l'exploitation de failles de serveurs connectés à internet ou bien de fausses mises à jour d'un logiciel (attaque récente Solarwinds) . 

Le premier réflexe consiste à améliorer la réponse des utilisateurs à ce type de message par des sensibilisations et des campagnes de faux-phishing pour les tester. En effet, il suffit qu'un seul utilisateur fasse une erreur et clique sur le lien ou la pièce jointe pour que sa machine soit compromise, ou son compte email et, du coup, permette aux attaquants de mettre un pied à l'intérieur de notre périmètre. Cependant, c'est illusoire de croire que personne ne va jamais se faire piéger par un message frauduleux, à longueur de mois et d'années.

Au fait savez vous que SPAM, n'est pas un acronyme ? Il viendrait d'un sketch des Monty Pythons: L'un des acteurs va dans une épicerie et demande plusieurs fois, et de plus en plus vite du "spiced ham", du jambon épicé. A la fin, il s'énerve et mange la moitié des mots et ça devient: "spam, spam, spam, spam !"; D'où l'idée de spam pour indiquer une "rafale" de messages non sollicités. 

Il va donc falloir aider les utilisateurs avec des outils de protection. Ces outils sont basés sur le fait que les attaquants ont adapté leurs emails de phishing en faisant croire à la cible qu'il s'agit d'un email de l'un de leurs collègues, ou dont le domaine ressemble fortement à celui de la cible (domain typo et domain-like).

La première catégorie d'outils est la trilogie DMARC, SPF, DKIM que nous avons vue dans l'article "Connect the dots #4". Il s'agira de passer en revue notamment les paramétrages et les certificats de manière à bloquer toutes les attaques basées sur l'usurpation de domaine: Les Charlie's Angels de la messagerie

Du côté de la passerelle de messagerie, on ajoutera une IA/ML (Algorithme auto-apprenant) qui donnera des conseils à l'utilisateur au moment de la réception d'un e-mail sur sa vraisemblance.

Enfin, de manière à bloquer les messages contenant une charge virale directe, il sera opportun d'équiper la passerelle de messagerie d'un anti-virus de dernière génération, avec la difficulté résiduelle de ne pas pouvoir analyser correctement les fichiers chiffrés en pièce jointe.

Un audit des dispositifs de messagerie viendra créer une certaine confiance dans le système et bloquera pratiquement toutes les attaques liées à l'e-mail. Avantage naturel aux systèmes de messagerie du cloud, car ceux-ci bénéficient en temps réel de la liste des spammeurs et bloquent ou signalent les spams avant même que l'utilisateur les reçoive. De même tous les messages sont passés au filtrage d'un anti-virus totalement à jour. Il n'en va pas de même sur une messagerie gérée localement.

Dot#4: Compromission initiale.

Cependant, malgré nos efforts, une machine à été compromise et va servir de relai interne pour établir un dialogue depuis l'intérieur avec un site externe des attaquants. Que doit-on mettre en place pour s'en apercevoir ? Comme la machine n'aura aucune réaction bizarre puisque le virus installé ne se manifestera pas sous forme de blocages ou de ralentissements, il faudra compter sur le dialogue qu'essayera d'instaurer la machine compromise avec les système de contrôle des attaquants.

Dot#5: Etablissement du C2.

Le command & control se met en fonction en utilisant les beacons et l'interaction avec la ou les machines compromises. Comment se traduit ce "dialogue" ? Sous forme de trafic réseau encapsulé à l'intérieur de protocoles autorisés à sortir vers Internet depuis cette machine, comme DNS, HTTP, HTTPS notamment. Comme les beacons ne communiquent pas en permanence, il faudra guetter des évènements sur le réseau qui seront qualifiés de "suspects", comme par exemple la connexion vers des domaines inhabituels ou des transferts de données importants. Il s'agira souvent de "faux positifs" ou de mauvais usages, comme par exemple un utilisateur qui recopie des fichiers sur sa messagerie ou son disque personnel. Cela peut également être un utilisateur qui écoute du streaming musical ou vidéo depuis le bureau. Deux types d'outils vont nous aider dans cette tache de repérage des communications avec un C2:

– Un monitoring temps réel sur la passerelle Internet. Les flux seront analysés, non seulement en termes d'autorisation du protocole, comme le fait un firewall, mais également par la cohérence de ce protocole par rapport au contenu et au volume échangé. Par exemple un protocole DNS va permettre de trouver l'adresse IP correspondant à un serveur d'un domaine donné que l'utilisateur veut joindre. Si la requête est étonnamment importante en taille ou en fréquence parce que la machine de l'utilisateur a effectué des centaines de requêtes en quelques secondes (domain fluxing), ou que le contenu des paquets DNS n'est pas lisible (binaire, exécutable, transfert de fichier), nous avons un problème potentiel. Une IA/ML nous aidera grandement, vu la volumétrie et la complexité des possibilités. On appelle ces outils des NDR: Network Detection & Response:

(c) Darktrace

-Un monitoring temps réel sur la machine elle-même. Les processus qui tournent en mémoire, y compris les processus "enfants" sont analysés et sont comparés à ce qui est licite (whitelist) et à ce qui est "normal" au sens des habitudes et du fonctionnement de cette machine et/ou de cet utilisateur:

(c) Cobalt Strike

Dans cet exemple, on voit que le beacon utilise la mise à jour de Java et précisément le processus du Java Update Scheduler. La parade s'appelle un anti-virus de nouvelle génération, communément appelé par l'acronyme EDR: Endpoint Detection and Response.

Lorsque l'on aura combiné le NDR et l'EDR, on obtiendra une défense complète appelée souvent XDR, le "X" valant pour "eXtended ou "eXpert".

Mais malgré toutes nos précautions et la mise en place d'un système XDR, celui-ci ne sera efficace qu'à deux conditions: Il faudra que des humains (aidés par une IA/ML) analysent tous ces évènements et décident d'isoler, mettre en quarantaine, voire bloquer, la ou les machines infectées. Ce NSOC (Network and cyberSecurity Operation Center) va devoir intervenir très vite, 24h/24 et 7 jours/7 en pratiquant la stratégie "ATIR": Apparition d'un évènement anormal – Triage par criticité et urgence – Investigation – Remédiation. Voici donc le schéma typique d'un NSOC:

L'autre socle du NSOC en dehors des outils XDR, sera ce qu'on appelle le SIEM (Security Incident and Event Management), c'est à dire l'agrégation et la consolidation de tous les journaux d'évènements de tous les composants réseau, système et sécurité de l'informatique. Il est clair que le travail de l'équipe du NSOC s'apparente à un travail d'analyste de big data. Il s'agit dans une masse gigantesque d'informations de relier des "dots" (depuis que vous lisez mes articles), des lignes claires, des scenarii d'attaque et d'écarter le "bruit". Mais comme vous l'avez déjà expérimenté, nous n'avons pas le temps, car "le patient est blessé et se vide de son sang"… Aux urgences hospitalières comme aux urgences informatiques, la réponse doit se faire en quelques minutes et non pas en quelques jours. Pour cela des outils "d'orchestration" viendront compléter le dispositif. Autrement dit, en fonction des scenarii d'attaque mis en lumière par les intelligences artificielles, une réponse automatisée et quasi immédiate va être déclenchée. Parmi les réponses typiques, on aura l'isolement de la machine du réseau, l'envoi d'une alerte sur la console, par email/SMS/ticket d'incident à des humains, le blocage de certains processus en mémoire, etc. On appelle ce type d'orchestration de la réponse et de la remédiation le SOAR (Security Orchestration, Automation & Response). Pour une fois l'acronyme veut dire quelque chose: s'envoler, s'élancer, mais aussi "exploser"… 

Une fois l'attaque repérée il ne s'agit pas de rester seuls et isolés "à se défendre des loups". Des IOC (Indicators of Compromise) vont être distribués sur tous les composants avancés de défense de manière à ce que les attaques semblables soient bloquées. On peut même en faire bénéficier les éditeurs de composants de sécurité, voire tout un pays ou toute la communauté, à travers les CERT et le Threat Intel dont nous avons parlé précédemment.

(c) SearchSecurity

Ces IOC se présentent sous forme de hash (condensat) de "signature" typique de cette attaque permettant un format de transmission standardisé au niveau des composants de sécurité. Compte tenu des systèmes Windows, ils sont différents en fonction des processeurs 32 bits ou 64 bits, ce qui correspond également aux typologies d'attaque différentes.

Voici le top 10 des catégories d'évènements "étranges", générant potentiellement des IOC, à intégrer dans nos systèmes de défense:

1. Trafic réseau sortant inhabituel
2. Anomalies dans l'activité des comptes d'utilisateurs à privilèges (administrateurs du domaine)
3. Irrégularités géographiques (accès depuis des IP géolocalisées dans des pays inhabituels pour l'entreprise)
4. Anomalies de connexion (login failed)
5. Pics de lecture de données
6. Taille anormale des réponses HTML
7. Grand nombre de demandes pour le même fichier
8. Trafic réseau sur des ports inhabituels
9. Modifications suspectes de la base de registre ou des fichiers système
10. Anomalies dans les requêtes DNS

Si l'on ne voit pas l'attaque à ce niveau et donc que l'on ne réagit pas, elle se maintiendra et proliférera, comme nous verrons dans le prochain article…