IBo Nefig: les meilleures divulgations de cybersécurité de 2020 selon JSOC

La première moitié de l'année touche à sa fin et nous avons décidé de rappeler les cas les plus intéressants de la vie de JSOC que nous avons rencontrés cette année. Une rencontre avec un "vieil ami" cybercriminel chez un nouveau client, un script malveillant dans le planificateur de tâches et l'énigme de la courbe de configuration de l'équilibreur - nous lisons et pénétrons sous la coupure.





Tiré de la série South Park

Nous l'avons reconnu à son écriture

Au cours de l'existence de JSOC, nous avons été confrontés à différentes infrastructures informatiques et à différents désirs clients pour surveiller la couverture de leur paysage informatique. Il arrive souvent, par exemple, qu'un client veuille surveiller uniquement les serveurs, se privant de l'opportunité de voir ce qui se passe autour du segment surveillé. Cette approche peut entraîner une détection d'attaque tardive, lorsque la majeure partie de l'infrastructure est déjà compromise. Et si nos clients existants n'ont pas de telles situations, alors sur les projets pilotes, c'est une histoire commune.



Ainsi, lors de l'un des pilotes, le client était en train de reconstruire son propre paysage informatique et souhaitait voir comment le SOC s'intégrerait à sa nouvelle infrastructure et à ses nouveaux processus. En raison de diverses circonstances indépendantes de notre volonté, nous n'avions pas une seule source réseau connectée, ce quikapets combien cela nous a limité dans la détection de divers incidents. Seuls un contrôleur de domaine, quelques serveurs Windows, un serveur de messagerie et un antivirus étaient connectés. Le pilote est passé assez calmement et était standard pour nous : plusieurs malwares ont été détectés dans l'infrastructure, l'utilisation de TOR et des RAT interdits. Mais un beau jour, un grand nombre de nos règles ont commencé à fonctionner, parmi lesquelles des règles de la catégorie Threat Hunting, qui automatisent le processus d'identification des traces d'un attaquant. L'analyste responsable s'est rapidement rendu compte que l'affaire sentait le kérosène, et a même compris à qui il avait affaire.



Qu'est-il arrivé? La première chose que nous avons vue a été l'ajout de nouveaux comptes au groupe Administrateurs du domaine. Mais une autre règle a fonctionné, à savoir le nom suspect des comptes, que nous avons déjà rencontrés. Une vieille connaissance à nous, un attaquant, lors des attaques, crée deux comptes qui sont écrits dans son script: ces deux noms «errent» d'une victime à l'autre - un petit changement ne peut être causé que par les règles de dénomination des comptes de l'organisation attaquée. Nous l'avons rencontré à plusieurs reprises lors d'enquêtes sur des incidents. Il attaque les organisations de toutes tailles et industries avec la même méthode et finit généralement par chiffrer les serveurs de clés de l'entreprise.



Malheureusement, la première machine compromise était en dehors du champ d'application des sources connectées, de sorte que le moment du lancement du script lui-même n'a pas pu être enregistré. Suite à la création des comptes, nous avons capturé un changement de règle sur le pare-feu local qui permettait l'utilisation d'un outil d'administration à distance spécifique, puis le service d'agent de cet outil même a été créé. À propos, l'antivirus utilisé par le client ne reconnaît pas cet outil, nous le contrôlons donc en créant le service correspondant et en démarrant le processus.







La cerise sur le gâteau était la distribution d'un utilitaire de cryptage légal aux hôtes compromis. Il n'a pas eu le temps de le télécharger sur tous les hôtes. L'attaquant a été «expulsé» de l'infrastructure 23 minutes après le premier déclenchement de cet incident.



Bien sûr, le client et moi voulions avoir une image complète de l'incident et trouver le point d'entrée de l'attaquant. Sur la base de notre expérience, nous avons demandé des journaux à des équipements réseau, mais, malheureusement, le niveau de journalisation ne nous a pas permis de tirer des conclusions. Cependant, après avoir reçu la configuration de l'équipement de réseau de périphérie des administrateurs, nous avons vu ce qui suit:



ip nat à l'intérieur de la source statique tcp "adresse grise" 22 "adresse blanche" 9922

ip nat à l'intérieur de la source tcp statique "adresse grise" 3389 "adresse blanche" 33899



D'où il a été conclu que, très probablement, l'un des serveurs sur lesquels un tel NAT était configuré est devenu le point d'entrée. Nous avons analysé les journaux de ces serveurs et constaté une authentification réussie sous le compte administrateur, le lancement de Mimikatz puis le lancement d'un script qui a créé des administrateurs de domaine. Grâce à cet incident, le client a entrepris une révision complète des règles de pare-feu, des mots de passe et des politiques de sécurité et a identifié plusieurs autres failles dans leur infrastructure. Et j'ai également eu une compréhension plus systématique de la raison pour laquelle le SOC est nécessaire dans son organisation.

Routeurs à distance et à domicile - Le paradis des hackers

Évidemment, dans le contexte des entreprises passant au contrôle à distance, il est devenu beaucoup plus difficile de surveiller les événements sur les terminaux. Il y a deux raisons principales:

1. un grand nombre d'employés utilisent des appareils personnels pour le travail;
2. VPN , .

Il est également évident que même les attaquants expérimentés se sont intéressés aux réseaux domestiques, car c'est désormais le point de pénétration idéal dans le périmètre de l'entreprise.



Un de nos clients avait 90% des employés passés en mode de travail à distance, et tous avaient des ordinateurs portables de domaine - par conséquent, nous pouvions continuer à surveiller les appareils finaux - bien sûr, en tenant compte du point 2 ci-dessus. Et c'est ce point qui a joué contre nous.



Lors de l'auto-isolement, l'un des utilisateurs ne s'est pas connecté au VPN pendant presque une journée entière. À la fin de la journée de travail, il avait encore besoin d'accéder aux ressources de l'entreprise. Il a utilisé un VPN, nous avons obtenu des journaux de sa machine de travail et avons vu quelque chose d'étrange. Une tâche suspecte a été créée dans le planificateur de tâches: il a lancé un certain fichier tous les mercredis à 17h00. Ils ont commencé à comprendre.







Les traces ont conduit à deux fichiers doc: l'un d'eux a créé la tâche, le second était le fichier exécutable de la tâche. L'utilisateur les a téléchargés depuis Google Drive.



A ce stade de notre recherche, le service de sécurité du client était déjà connecté et a lancé une enquête interne. Il s'est avéré que l'utilisateur a reçu une lettre à son courrier personnel, qui contenait un lien vers Google Drive, à partir duquel les documents ont été téléchargés. Peu à peu, nous sommes arrivés au routeur de l'utilisateur - bien sûr, le login / mot de passe était admin \ admin (comme s'il en était autrement?). Mais le plus intéressant a été trouvé dans les paramètres du serveur DNS du routeur: l'adresse IP de l'un des pays européens y était indiquée. Nous avons conduit cette adresse dans VirusTotal - la plupart des sources sont allumées en rouge. Après la fin de l'enquête, le client nous a envoyé deux fichiers à des fins de recherche, et nous avons vu que le fichier lancé par la tâche commençait à "parcourir" toutes sortes de répertoires et à en décharger les données.



La chronologie de l'incident était la suivante: l'attaquant a eu accès au routeur de l'utilisateur, en a modifié les paramètres, en spécifiant son propre serveur comme serveur DNS. Pendant un certain temps, j'ai observé ma «victime» et envoyé une lettre au courrier personnel de l'utilisateur. À cette étape, nous l'avons trouvé, ne nous permettant pas de pénétrer profondément dans l'infrastructure de l'entreprise.

Ils cassent le leur aussi

Au stade initial du travail avec un SOC d'externalisation, nous recommandons toujours de connecter les sources d'événements par étapes, afin que le client de son côté débogue les processus, définisse clairement les domaines de responsabilité et s'habitue généralement à ce format. Ainsi, chez l'un de nos nouveaux clients, nous avons d'abord connecté des sources de base, telles que des contrôleurs de domaine, des pare-feu, des proxies, divers outils de sécurité de l'information, des serveurs de messagerie, DNS et DHCP et plusieurs autres serveurs différents. Nous avons également proposé de connecter les machines des administrateurs du siège social au niveau des logs locaux, mais le client a dit que pour l'instant c'est inutile et il fait confiance à ses administrateurs. Ici, en fait, notre histoire commence.



Un jour, les événements ont cessé de nous arriver. Nous avons appris du client que, prétendument, en raison d'une attaque DDoS à grande échelle, son centre de données «est tombé» et maintenant il est engagé dans la récupération. Cela a immédiatement soulevé de nombreuses questions - après tout, le système de protection DDoS nous était connecté.



L'analyste a immédiatement commencé à fouiller dans ses journaux, mais n'y a rien trouvé de suspect - tout était en mode normal. Ensuite, j'ai regardé les journaux du réseau et attiré l'attention sur le travail étrange de l'équilibreur, qui répartissait la charge entre deux serveurs qui traitent le trafic entrant. L'équilibreur de charge n'a pas distribué la charge, mais, au contraire, l'a dirigée vers un seul serveur jusqu'à ce qu'elle soit "bloquée", puis a redirigé le flux vers le deuxième nœud. Mais il est beaucoup plus intéressant que dès que les deux serveurs sont tombés, ce trafic est allé plus loin et a tout "mis" en général. Pendant que les travaux de restauration étaient en cours, le client a découvert qui avait raté. Ceci, semble-t-il, est la fin de l'incident: cela n'a rien à voir avec la sécurité de l'information et est simplement associé à des mains tordues.erreur d'administrateur. Mais le client a décidé d'enquêter jusqu'au bout. Après avoir vérifié les AWP des administrateurs, il a constaté que tous les journaux du système d'exploitation avaient été effacés de ce même artisan potentiel, puis nous a demandé de vérifier ses actions au cours de la semaine dernière.



Fait intéressant, cet administrateur a fait l'objet de nos enquêtes quelques semaines avant l'incident. Il a accédé du réseau local à un hôte externe sur le port 22. Ensuite, cet incident a été marqué comme légitime, car Il n'est pas interdit aux administrateurs d'utiliser des ressources externes pour automatiser leur propre travail ou tester de nouveaux paramètres d'équipement. Peut-être que cette connexion entre la chute du centre de données et l'appel vers un hôte externe n'aurait jamais été remarquée, mais il y a eu un autre incident: des appels d'un des serveurs du segment de test au même hôte sur Internet que l'administrateur avait précédemment contacté - cet incident a également été noté par le client comme légitime. Après avoir regardé l'activité de l'administrateur, nous avons vu des demandes constantes à ce serveur à partir du segment de test et avons demandé au client de le tester.



Et ici c'est le dénouement - un serveur Web a été déployé sur ce serveur, qui implémente une fonctionnalité partielle du site Web principal du client. Il s'est avéré que l'administrateur prévoyait de rediriger une partie du trafic entrant vers son faux site afin de collecter les données des utilisateurs à ses propres fins.

Résultat

Bien que nous soyons déjà en 2020, de nombreuses organisations ne respectent toujours pas les vérités communes de la sécurité de l'information, et l'irresponsabilité de leur propre personnel peut avoir des conséquences désastreuses.



À cet égard, voici quelques conseils:

1. N'exposez jamais RDP et SSH à l'extérieur, même si vous les cachez derrière d'autres ports - cela n'aide pas.
2. Ajustez le niveau d'enregistrement le plus élevé possible pour accélérer la détection des intrus.
3. Threat Hunting . TTPs , . .
4. , . , , .

, Solar JSOC (artkild)