Dans mon dernier blog, j'ai parlé d'un client du secteur financier effectuant des tests d'intrusion et de la façon dont j'ai aidé l'équipe bleue à détecter l'équipe rouge pendant qu'elle menait une attaque. Je suis de retour aujourd'hui avec une autre histoire des tranchées.
Cette fois-ci, je travaille avec un client du secteur manufacturier qui m'a récemment déployé. Comme précédemment, ce client préfère rester anonyme afin que les cybercriminels ne sachent rien des nouvelles capacités de sécurité qu'il a développées. Pour rester à la pointe du progrès, il organise régulièrement des exercices en équipe rouge.
L'un des aspects les plus difficiles de la recherche d'attaquants cachés au sein de votre réseau est que leurs comportements se fondent dans ceux des utilisateurs normaux. Si j'étais un attaquant, la première chose que je chercherais serait les outils d'administration de votre réseau parce qu'ils sont fiables par défaut.
Comprendre la différence entre le comportement de l'attaquant et le comportement acceptable de l'utilisateur devient un exercice de repérage des nuances entre les deux et fournit un meilleur contexte sur ce qui est associé et comment les comportements de menace progressent à travers le cycle de vie de l'attaque.
Il est encore plus difficile de repérer les comportements des attaquants lorsqu'ils ont accès à des outils de sécurité qui fonctionnent déjà sur votre réseau. Par exemple, un outil de distribution de logiciels tel que Microsoft SCCM est totalement légitime dans une entreprise. Mais il crée des bruits qui ressemblent à l'exécution de fichiers à distance, ce qui est exactement ce que ferait un pirate.
Les outils de sécurité doivent créer des filtres pour éliminer le bruit. Cependant, il s'agit probablement d'une attaque si la machine commence à effectuer des actions de commande et de contrôle qui ne sont pas fiables. La plupart des outils finissent par ne pas voir ce comportement de l'attaquant parce qu'ils ont déjà filtré l'outil comme du bruit. Les attaquants savent comment fonctionnent ces outils de sécurité.
Lors d'un récent exercice de tests d'intrusion avec notre client industriel, l'équipe rouge a obtenu secrètement l'accès à un scanner Nessus qui était normalement utilisé par l'équipe bleue pour rechercher des actifs exposés.
L'équipe bleue m'a fait découvrir très tôt le scanner Nessus afin que j'apprenne comment il est utilisé et par qui. L'équipe de sécurité aime savoir quand les scans se produisent et ne veut pas que j'interprète les scans Nessus comme des attaques parce qu'ils représentent un comportement approuvé.
Cela ne ferait que donner plus de travail à mes collègues analystes de la sécurité. Et c'est mon travail de filtrer le bruit pour qu'ils puissent se concentrer sur des enquêtes plus approfondies sur les incidents, remédier aux problèmes et apprendre à faire en sorte que le réseau puisse s'adapter.
Au fur et à mesure que le test progressait, j'ai remarqué plusieurs comportements de reconnaissance et de mouvement latéral émanant du scanner Nessus et ils se sont produits dans une séquence que je n'avais jamais vue auparavant.
J'ai immédiatement conclu qu'une personne non autorisée avait réquisitionné le scanner Nessus.
Les premiers comportements des attaquants que j'ai détectés étaient des balayages de ports IP et des scans de ports classiques. J'ai ensuite remarqué un grand nombre d'analyses du darknet interne contre des plages d'adresses IP que l'équipe de sécurité n'analyserait pas normalement.
Pour gagner du temps, j'ai mis en corrélation les comportements d'attaque et les informations contextuelles afin que l'équipe bleue puisse voir que l'équipe rouge essayait de localiser des hôtes dans des plages de sous-réseaux qui n'existaient pas auparavant sur le réseau.
J'ai continué à surveiller l'activité de balayage du réseau. Bien que les comportements de reconnaissance soient suspects, j'ai attribué une note de menace moyenne parce que je n'ai pas vu de comportements associés plus tard dans le cycle de vie de l'attaque qui indiqueraient qu'un attaquant s'est déplacé plus profondément dans le réseau.
Après un certain temps d'analyse, j'ai remarqué que l'équipe rouge avait découvert un ensemble de serveurs exécutant des bases de données vulnérables et un autre dont les mots de passe administrateur étaient faibles. J'ai rapidement vu l'équipe rouge passer à la phase de mouvement latéral du cycle de vie de l'attaque, qui comprenait une injection SQL, une réplication automatisée et une attaque par force brute contre les mots de passe des administrateurs.
En temps réel, j'ai établi une corrélation entre tous ces comportements des attaquants et l'hôte utilisé par l'équipe rouge et les serveurs du centre de données qu'ils ont compromis. Au fur et à mesure que les attaques progressaient dans leur cycle de vie, je leur attribuais un score de menace critique et un niveau de certitude élevé.
Mes collègues de l'équipe bleue - des gens comme vous - ont pris des mesures rapides pour isoler l'équipe rouge et l'ont arrêtée avant qu'elle ne passe à des phases d'attaque plus préjudiciables, comme l'exfiltration de données.