Quelques histoires de la vie de JSOC CERT, ou Unbanal forensics

Chez JSOC CERT, nous enquêtons sur des incidents. En général, les 170 personnes du JSOC enquêtent, mais les cas les plus difficiles sur le plan technologique relèvent des experts du CERT. Comment, par exemple, détecter les traces d'un malware si un attaquant nettoyait? Comment trouver un «assistant» qui a supprimé des documents commerciaux importants d'un serveur de fichiers sur lequel la journalisation n'est pas correctement configurée? Eh bien, pour le dessert: comment un attaquant peut-il obtenir des mots de passe de dizaines de comptes de domaine non liés sans pénétrer le réseau? Détails, comme toujours, sous la coupe.

En semaine JSOC CERT

Souvent, nous devons évaluer le compromis réel du réseau client, pour cela nous effectuons:

• analyse rétrospective des disques durs et des images mémoires,
• reverse engineering de logiciels malveillants
• si nécessaire, déploiement d'urgence de la surveillance et de l'analyse des hôtes pour des indicateurs de compromis et des traces de piratage.

Pendant notre temps libre, nous rédigeons des résumés détaillés, des techniques et des playbooks - essentiellement des instructions qui aident à mettre à l'échelle des enquêtes même complexes, comme vous pouvez agir sur eux semi-automatiquement.

Parfois, lors de la réponse à l'incident - en plein milieu de l'extinction d'un «incendie» - vous devez également agir comme un «service de soutien psychologique». Une fois, nous avons été invités à aider à lutter contre l’infection du sous-réseau d’une grande organisation. Le réseau était entretenu par deux sous-traitants qui, dans cette situation, se sont jetés de façon désintéressée sur un ventilateur et se sont engagés dans autre chose l'un contre l'autre , mais sans rechercher un ver malveillant. Afin de réduire le degré d'hystérie, j'ai dû asseoir tout le monde à la table pour obtenir une serviette et une bouteille de bourbon et expliquer clairement que ce n'est pas le moment de rechercher les coupables. Ils ont déterminé la procédure de distribution, lancé un audit supplémentaire et commencé à nettoyer systématiquement et ensemble l'infection.

Au cours de l'enquête, nous devons souvent choisir des images de disque et de mémoire pour y trouver des logiciels malveillants actifs. Pour rendre le processus prévisible et objectif, nous avons formalisé et automatisé plusieurs méthodes d'analyse rétrospective des disques, et avons pris la méthode SANS déjà classique comme base - dans la version originale, elle est assez élevée, mais si elle est utilisée correctement, elle permet la détection d'une infection active avec une très grande précision.



Il est clair que pour effectuer des vérifications générales, il faut du temps et une connaissance approfondie des fonctionnalités des divers composants des systèmes d'exploitation (et un grand nombre de logiciels spécialisés sont nécessaires).

Comment simplifier la vérification d'une infection active sur un disque? Nous partageons le hack de vie - il peut être vérifié dynamiquement (comme dans le bac à sable), pour cela:

• copiez le disque dur de l'hôte suspect peu à peu;
• convertir l'image dd résultante au format VMDK à l'aide de cet utilitaire;
• exécutez l'image VMDK dans Virtual Box / VMware;
• et analyser comme un système vivant, en se concentrant sur le trafic.

Mais il y aura toujours des incidents pour lesquels des instructions détaillées ne sont pas écrites et les techniques ne sont pas automatisées.

Cas 1. Le comptable n'a rien à voir avec cela, ou comment nous avons recherché des logiciels malveillants

Le client nous a demandé de vérifier l'ordinateur du comptable pour détecter les logiciels malveillants: quelqu'un a effectué plusieurs ordres de paiement à une adresse inconnue. Le comptable a affirmé qu'il n'était pas impliqué dans cela et que l'ordinateur s'était comporté étrangement auparavant: la souris se déplaçait parfois littéralement autour de l'écran lui-même - en fait, on nous a demandé de vérifier ces indications. Le hic, c'est que le cheval de Troie visant 1C a fait ses sales actes et s'est effacé, et près d'un mois s'est écoulé après l'infection - pendant ce temps, l'enikeyschik diligent a mis un tas de logiciels, frottant l'espace disque non alloué et minimisant ainsi les chances de succès de l'enquête.

Dans de tels cas, seul un analyste expérimenté et méticuleux et une base de données Threat Intelligence étendue et mise à jour automatiquement peuvent vous aider. Ainsi, lors de l'analyse du dossier de démarrage, l'attention a été attirée par une balise suspecte indiquant un utilitaire de mise à jour prétendument anti-virus:



Malheureusement, la carcasse du cheval de Troie à partir du disque n'a pas pu être restaurée, mais les faits de lancement de l'utilitaire d'administration à distance à partir du même dossier «étalé» dans le cache Superfetch :



En les comparant avec le moment de l'incident, nous avons prouvé que ce n'était pas le comptable qui était coupable d'avoir volé l'argent, mais un attaquant externe.

Cas 2. Qui a supprimé mes fichiers?

La plupart de nos enquêtes et réponses aux incidents sont en quelque sorte liées à la détection de logiciels malveillants, aux attaques ciblées utilisant des utilitaires multi-modules et à des histoires similaires où il y a un attaquant externe. Cependant, il y a parfois des enquêtes beaucoup plus banales, mais non moins intéressantes.

Le client possédait l'ancien serveur de fichiers le plus ordinaire, dont les dossiers publics étaient accessibles à plusieurs services. Sur le serveur, il y avait beaucoup de documents commerciaux très importants que quelqu'un avait pris et supprimés. Nous l'avons réalisé tard - après la surcharge de la sauvegarde. Ils ont commencé à rechercher les coupables.

Si vous avez déjà essayé de google pour déterminer quel utilisateur a supprimé le fichier, vous avez probablement rencontré des conseils qui viennent tous dans les journaux Windows, si vous les configurez correctement à l'avance (en passant, nous avons déjà donné quelques conseils sur la façon de configurer les journaux):


Source

Mais en réalité, peu de gens effectuent des audits de système de fichiers, ringard car il y a beaucoup d'opérations sur les fichiers et les journaux seront rapidement effilochés, et un serveur séparé est nécessaire pour stocker les journaux ...

Nous avons décidé de diviser la tâche en deux: premièrement, déterminez QUAND les fichiers ont été supprimés; deuxièmement, - l'OMS se connectait au serveur au moment de la suppression. Si vous avez une idée des fonctionnalités de NTFS, vous savez que dans la plupart des implémentations de ce système de fichiers, lorsque vous supprimez un fichier, l'espace qu'il occupait est marqué comme libre et ses horodatages ne changent pas. Par conséquent, à première vue, le temps de suppression ne peut pas être défini.

Cependant, le système de fichiers contient non seulement des fichiers, mais également des dossiers. De plus, les dossiers ont un attribut spécial $ INDEX_ROOT, qui décrit le contenu du dossier comme une arborescence B. Naturellement, la suppression d'un fichier modifie l'attribut $ INDEX_ROOT du dossier et modifie ainsi ses horodatages, en particulier, dans la structure de $ STD_INFO. Ainsi, il est possible de déterminer le temps approximatif de suppression d'un grand nombre de fichiers et dossiers par anomalie dans la MFT (table de fichiers principale) :



Après avoir découvert quand les fichiers ont été supprimés, vous pouvez essayer de découvrir qui travaillait dans le nord à ce moment-là afin de restreindre le cercle des suspects. Les méthodes suivantes me viennent à l'esprit:

• Par les journaux du serveur lui-même - par les événements avec EventID 4624/4625, il est visible lorsque l'utilisateur s'est connecté et déconnecté;
• par les journaux du contrôleur de domaine - EventID 4768 vous permet de déterminer qu'un utilisateur spécifique a demandé l'accès au serveur;
• par trafic - journaux netflow / routeur interne - vous pouvez déterminer qui a activement communiqué sur le réseau avec ce serveur via smb.

Dans notre cas, ces données n'étaient plus là: trop de temps s'était écoulé, les journaux étaient tournés. Dans ce cas, il existe une autre méthode peu fiable, mais toujours une méthode, ou plutôt la clé de registre - Shellbags . Il stocke des informations, notamment sur le type de dossier lors de la dernière visite de l'utilisateur: tableau, liste, grandes icônes, petites icônes, contenu, etc. Et la même clé contient des horodatages, qui peuvent être interprétés avec une grande confiance comme l'heure de la dernière visite dans le dossier.

Une méthode a été trouvée, il ne restait plus qu'à collecter les registres des hôtes nécessaires et à les analyser. Pour ce faire, vous avez besoin de:

• déterminer par groupe de domaine qui avait accès au dossier (dans notre cas, il y avait environ 300 utilisateurs);
• collecter les registres de tous les hôtes sur lesquels ces utilisateurs ont travaillé (vous ne pouvez pas le faire, vous avez besoin d'un utilitaire spécial pour travailler directement avec le lecteur, par exemple, https://github.com/jschicht/RawCopy );
• «Alimentez» tous les registres dans Autopsy et utilisez le plugin Shellbags;
• Profit!

Plus précisément, dans cet incident, le temps de suppression des fichiers a coïncidé avec le moment où un utilisateur a visité la racine du dossier supprimé, ce qui nous a permis de réduire le cercle des suspects de 300 à 1.

Que s'est-il passé ensuite avec cet employé - l'histoire est silencieuse. Nous savons seulement que la jeune fille a avoué l'avoir fait par accident et continue de travailler dans l'entreprise.

Cas 3. Maître des mots de passe: «voler» en quelques secondes (et encore plus rapidement)

Un attaquant est entré dans le réseau d'un client qui nous a demandé de l'aide via un VPN et a été immédiatement détecté. Ce qui n'est pas surprenant, car juste après être entré, il a commencé à scanner le sous-réseau avec un scanner de vulnérabilité - le chanipot cligna des yeux comme un arbre de Noël.

Une fois le compte verrouillé, le personnel de sécurité du client a commencé à analyser les journaux VPN et a vu que l'attaquant avait utilisé plus de 20 comptes de domaine différents pour la pénétration (avec la plupart, il s'est connecté avec succès, mais pour certains, l'authentification a échoué). Et la question logique s'est posée: comment a-t-il trouvé les mots de passe de ces comptes? Nos gars de JSOC CERT ont été invités à chercher la réponse.

Dans l'un des articles précédents, nous avons déjà dit que dans les enquêtes, des hypothèses devraient être formées et vérifiées à mesure que leur probabilité diminue. Nous avons donc fait cette fois-ci, en commençant à décrire des vecteurs de vol de compte typiques:

• fuite de données de service externe
• Bruteforce
• Mimikatz ou similaire
• Enregistreur de frappe
• Phishing
• Récolte de hachage NTLM (par exemple https://github.com/CylanceSPEAR/SMBTrap ) ou des attaques de réseau similaires.

Nous avons vérifié un tas de versions, mais nulle part il n'y avait même un soupçon d'attaque. Non pas que l'enquête était dans une impasse, mais la voix intérieure et le bon sens suggéraient que quelque chose n'allait pas - vous devez prendre du recul et regarder la photo plus large.

En effet, à première vue, tous ces comptes ne sont en aucun cas liés. Leurs propriétaires sont issus de départements différents et géographiquement séparés. Ils utilisent généralement un ensemble de services d'entreprise qui ne se chevauchent pas. Même le niveau de culture informatique est différent. Oui, un pas en arrière ne suffisait pas - un autre était nécessaire.

À ce moment, nous avons réussi à collecter un grand nombre de journaux de différents systèmes de l'entreprise et à identifier les traces laissées par l'attaquant. Ils ont commencé à analyser où il est apparu (je me souviens: il a activement analysé le réseau interne de l'entreprise). Nous avons remarqué que dans le contexte d'un bruit de réseau uniformément distribué provenant d'exploits en vol, il y a un nombre anormalement élevé de demandes au service de récupération de mot de passe. Un service accessible depuis Internet. Hmm ...



Si vous surveillez des événements de sécurité, vous savez probablement qu'analyser les tentatives d'attaque d'un serveur accessible en externe n'a souvent aucun sens en raison du bruit Internet: il est généralement difficile de distinguer les attaques vraiment graves de nombreuses tentatives de script kiddie. Mais pas toujours.





Après avoir passé un peu de temps sur les journaux du service Web, nous avons pu distinguer les attaques suivantes contre le service:

• Numériser avec Acunetix
• Analyse SQLmap
• un grand nombre de demandes sur une seule page.

La troisième attaque, à première vue, est similaire aux connexions utilisateur brutales. Mais ce n'est pas le cas, car le service en est protégé, du moins par le fait que les mots de passe sont stockés sous forme hachée avec du sel - ou non? Il fallait le vérifier rapidement.

L'image ci-dessous montre un schéma typique du service de réinitialisation de mot de passe:



Il est intéressant de noter que les mots de passe ne sont pas toujours stockés sous une forme sécurisée - il y a un moment où ils sont dans le domaine public - immédiatement après l'ouverture de l'application et avant son exécution! Un grand nombre de requêtes sur une page se sont avérées non pas de force brute et non de scan, mais de requêtes à haute fréquence avec injection SQL, dont le but était d'extraire des mots de passe au moment de leur modification.

Ainsi, après avoir modélisé l'attaque sur le service, comparé les informations des journaux du serveur Web, des journaux de changement de mot de passe et de plusieurs périphériques réseau, nous avons toujours trouvé le point de pénétration de l'attaquant dans l'entreprise.

Alors, collègues, plongez dans les données brutes et que la force soit avec vous!