Études de cas pour l'utilisation d'outils d'analyse d'anomalies réseau: découverte de campagne DNSpionage

Nous continuons d'examiner les cas de systèmes d'analyse du trafic réseau (NTA) pour les objectifs de cybersécurité. Aujourd'hui, nous verrons comment ces solutions peuvent être utilisées pour détecter des campagnes très complexes, ciblées et très efficaces appelées DNSpionage et Sea Turtle.

Mais avant cela, je rappellerai brièvement comment fonctionne le DNS (Domain Name System), qui sous-tend l'interaction sur Internet. Le cerveau humain est agencé de telle sorte qu'il est incapable de mémoriser de nombreux nombres et nombres qu'une personne n'associe à rien de familier. Et le nombre de combinaisons mémorables de nombres et de nombres est en tout cas petit. Par conséquent, afin de ne pas mémoriser et stocker dans le carnet des centaines et des milliers d'adresses IP des sites qui nous intéressent, le système DNS a été inventé, qui traduit les adresses symboliques des sites plus compréhensibles par l'homme en leurs adresses IP. Si je dois accéder à un site, j'envoie une requête DNS avec le nom du site au serveur DNS, qui me renvoie son adresse IP, vers laquelle je me rends.



Si vous plongez un peu plus dans les détails, le schéma semble plus compliqué. Si le serveur DNS le plus proche de moi ne connaît pas l'adresse IP du site qui m'intéresse, il me dirige vers le serveur racine, qui me dirige ensuite vers le serveur DNS de la zone dans laquelle se trouve le site qui m'intéresse (par exemple, «.ru»), et plus encore le long de la chaîne jusqu'à ce que j'atteigne un serveur DNS qui connaît l'adresse IP dont j'ai besoin.



Il s'avère que nous faisons confiance aux serveurs DNS qui nous envoient les adresses IP des sites que nous souhaitons visiter. Et si quelqu'un s'introduit dans un serveur DNS et usurpe un enregistrement pour faire correspondre un nom symbolique et une adresse IP? Et si nous sommes dirigés vers un faux site qui ressemble à un vrai et qui peut voler nos identifiants et mots de passe, ainsi que d'autres informations confidentielles à notre sujet? Cette usurpation est appelée redirection DNS et est utilisée par les cybercriminels dans des attaques particulièrement dangereuses.



En 2009, la «Iranian Cyber ​​Army» a ainsi remplacé twitter.com. En 2011, 186 domaines ont été remplacés par des pirates turcs, dont HSBC, Vodafone, Acer, etc. En 2013-2014, l'armée électronique syrienne a remplacé les sites NYT, Twitter et Huffingtin Post (la tentative a échoué contre Facebook). La même année, des actions similaires ont été menées contre WhatsApp, AVG, Avira. Un an plus tard, les sites Google vietnamiens et malaisiens ont été remplacés, ainsi que le domaine de la Banque fédérale de réserve de Saint-Louis. En 2016, une certaine quantité de crypto-monnaie a été volée à blockchain.info de cette manière.

En fait, il y a plus de vecteurs d'attaque DNS, mais aujourd'hui, nous ne regarderons que ceux liés aux campagnes DNSpionage et Sea Turtle .



Maintenant que nous avons un aperçu rapide du fonctionnement du DNS et de la façon dont vous pouvez l'utiliser au détriment, nous pouvons passer directement aux campagnes DNSpionage et Sea Turtle, en commençant par la première. En 2018, la division Cisco Talos l'a rencontré dans plusieurs pays du Moyen-Orient. Il comprenait deux parties - l'infection des utilisateurs et la redirection DNS, qui n'étaient pas toujours liées, mais pour un certain nombre de signes, nous avons conclu que le même groupe était très probablement derrière les deux parties.



Dans le premier cas, les utilisateurs victimes ont reçu des offres d'emploi via LinkedIn et d'autres sites de recherche d'emploi. Tous les postes vacants ont conduit à de faux sites sur lesquels des postes tentants ont été publiés. Deux sites ont été enregistrés - hr-wipro [.] Com et hr-suncor [.] Com, qui redirigeaient les utilisateurs vers les sites wipro.com et suncor.com légaux. Les liens ont placé des fichiers au format MS Word avec des macros incorporées, chacune fonctionnant respectivement à l'ouverture et à la fermeture du document.



La première macro a décodé le fichier PE et l'a enregistré à l'adresse "% UserProfile% \. OracleServices \ svshost_serv.doc". La deuxième macro a été renommée «svshost_serv.doc» en «svshost_serv.exe». Ensuite, la macro a créé la tâche «chromium updater v 37.5.0», qui a exécuté le fichier exécutable et l'a répété toutes les minutes. Ce malware exécutait les fonctions de RAT (outil d'administration à distance), appelé DNSpionage. Il a interagi avec un domaine spécialement créé, demandant / recevant des commandes qu'il a exécutées. Parmi ces commandes, on peut interroger le contenu du répertoire, analyser le réseau, copier des fichiers, utiliser des utilitaires distants (WinSSHD, Putty, mimikatz), etc. Les commandes du serveur de commandes, ainsi que les résultats du travail, ont été envoyés dans l'un des deux modes - HTTP ou DNS. La deuxième option est généralement plus simple, car il y a une forte probabilitéque vous ne disposez pas d'une inspection à part entière du trafic DNS et que vous ne remarquez tout simplement pas le code malveillant DNSpionage communiquant avec le serveur de commandes.

La chose la plus intéressante commence au moment où les parties client et serveur du malware communiquent. Le client envoie la requête DNS obscurcie suivante à 0ffice36o [.] Com (le premier caractère est zéro et la dernière lettre est «o»): RoyNGBDVIAA0 [.] 0ffice36o [.] Com, où les 4 premiers octets sont générés de manière aléatoire et le reste (GBDVIAA0 ) sont une requête encodée en base32 (pour chaque victime, leur propre alphabet base64 / dase32 a été sélectionné). Le déchiffrer nous donne "0GT \ x00", où GT est l'identifiant de la victime, et \ x00 est le numéro de requête. Le serveur de commandes nous répond sous la forme d'une adresse IP, qui n'est pas toujours correcte, par exemple 0.1.0.3 (le protocole DNS le permet). La deuxième requête DNS ressemble à ceci: t0qIGBDVIAI0 [.] 0ffice36o [.] Com. Le serveur de commandes nous renvoie l'adresse IP: 100.105.114.0, qui est de 4 caractères en encodage ASCII normal,ce qui dans ce cas signifie la commande exécutable "dir \ x00". En réponse, le côté client de DNSpionage envoie:

GLtAGJDVIAJAKZXWY000 0ffice36o com [.] [.] -> GJDVIAJAKZXWY000 -> « 2GT \ x01 Vol»
TwGHGJDVIATVNVSSA000 0ffice36o com [.] [.] -> GJDVIATVNVSSA000 -> «2GT \ x02 UME»
1QMUGJDVIA3JNYQGI000 0ffice36o com [.] [.] - > GJDVIA3JNYQGI000 -> "2GT \ x03 en d"
iucCGJDVIBDSNF3GK000 [.] 0ffice36o [.] Com -> GJDVIBDSNF3GK000 -> "2GT \ x04 rive"
viLxGJDVIBJAIMQGQ36 [0] [Q] [0]] h "

Dans le cadre de la deuxième partie de la campagne DNSpionage, l'administrateur de l'administrateur du serveur DNS a été volé, les enregistrements DNS correspondants ont été modifiés et des certificats ont été créés à l'aide de LetsEncrypt, qui sera utilisé plus tard dans l'attaque «site au milieu». C'est sur un tel site que l'attaque de redirection DNS décrite précédemment enverra des victimes sélectionnées (en seulement 2 ans de cette campagne, nous avons pu identifier 25 redirections, ce qui indique non pas une attaque massive mais ciblée). Veuillez noter que votre propre serveur DNS (si vous en avez un) et les serveurs DNS tiers que vous ne contrôlez pas déjà peuvent être attaqués.

Dans le cadre de leurs activités, les assaillants ont pu intercepter tout le trafic qui se dirigeait vers les domaines indiqués des organes gouvernementaux du Liban et des Émirats arabes unis (le ministère des Finances, la police, le ministère des Communications et des Télécommunications, la compagnie aérienne, etc.), y compris le courrier électronique et le VPN, ce qui pourrait leur permettre de recueillir des informations supplémentaires sur leurs victimes.

La campagne Cisco Talos Sea Turtle était encore plus compliquée que DNSpionage, car les attaquants ont attaqué non seulement les serveurs DNS, mais aussi les serveurs TLD (y compris les ccTLD et les gTLD),



ce qui a permis à des pirates inconnus d'attaquer des organisations étatiques et militaires au Moyen-Orient et au Nord. Afrique, ainsi que des services spéciaux et des sociétés pétrolières et gazières.



Revenons maintenant à la tâche d'origine et voyez comment les systèmes d'analyse du trafic réseau peuvent aider à identifier les campagnes mentionnées. Il convient de noter tout de suite qu'étant donné leur complexité et le fait qu'ils peuvent être dirigés contre des serveurs DNS externes, les systèmes de classe NTA ne nous aideront pas toujours. Mais dans ces cas, lorsqu'il s'agit du mode de fonctionnement DNS de DNSpionage ou d'une attaque sur des serveurs DNS locaux dans le cadre de DNSpionage ou de Sea Turtle, nous pouvons utiliser Netflow pour voir tous les signes d'une attaque dont nous avons besoin et les bloquer en temps opportun.

Tout d'abord, nous devons définir nos serveurs DNS internes et les ajouter à un groupe. C'est là que commence l'introduction de presque tous les systèmes de surveillance des anomalies. Pour comprendre si nous avons rencontré des anomalies dans le trafic réseau ou non, nous devons d'abord décider ce qui est normal et légitime. Et ce n'est qu'après cela que le système commence à fonctionner pleinement.



Cela peut être fait manuellement, mais il est préférable d'utiliser la fonction de classification des nœuds par type de trafic, qui vous permet d'identifier tous les nœuds, même ceux que nous ne connaissons pas, mais qui fonctionnent comme des serveurs DNS.



Dans notre cas, nous avons trouvé 5 serveurs:



Après avoir décidé des serveurs DNS légaux, nous ne pouvons surveiller que tout le trafic DNS, ce qui est anormal, c'est-à-dire au-delà de ce qui est autorisé. Par exemple, voici comment nous pouvons décrire une règle pour identifier les serveurs DNS internes fonctionnant illégalement:



Et cette règle ressemblera à ceci, ce qui montre que pour une raison quelconque, nous avons 2 serveurs DNS dans notre réseau, dont l'un est situé dans le segment de serveur confidentiel et le deuxième dans le segment des appareils utilisateur.



La règle suivante nous permet d'identifier les serveurs DNS suspects externes qui interagissent directement avec les hôtes internes, ce qui peut être un signe que le serveur de commandes DNSpionage fonctionne avec des appareils d'entreprise infectés:



Et nous trouvons des exemples d'une telle interaction:



De la même manière, nous pouvons configurer le système de détection d'anomalies réseau (et cet article utilise Cisco Stealthwatch comme exemple) pour détecter les tentatives non autorisées d'accéder aux nœuds internes au serveur DNS local (cela peut indiquer qu'un DNSpionage ou Sea Turtle fonctionne), ainsi que l'interaction active hôtes internes avec des hôtes externes utilisant le protocole DNS (cela enregistrera le fonctionnement de DNSpionage en mode DNS).

Après avoir corrigé les anomalies et les violations de politique de sécurité correspondantes, nous devons développer des règles qui nous permettent de signaler toute tentative future de connecter des nœuds internes, à l'exclusion des serveurs DNS locaux, à des serveurs DNS externes (et vice versa).



La deuxième règle nous permet d'enregistrer toutes les tentatives d'interaction à l'aide du trafic DNS au sein du réseau d'entreprise, à l'exclusion des serveurs DNS locaux.



C'est ainsi que la surveillance de Netflow (ainsi que d'autres protocoles de flux) nous permet d'identifier les étapes individuelles d'attaques assez complexes qui peuvent nuire aux entreprises et aux agences gouvernementales modernes.

Source: https://habr.com/ru/post/undefined/