Get best of the week

Enquête sur les incidents de sécurité de l'information dans la nature: sources d'informations inattendues

image

Beaucoup a été écrit sur les enquêtes sur les incidents informatiques, ou Digital Forensics, il existe de nombreux outils matériels et logiciels prêts à l'emploi, les principaux artefacts des systèmes d'exploitation sont bien connus et décrits dans les manuels, livres et articles. Il semblerait que ce soit difficile - lisez le manuel et trouvez le nécessaire. Mais il y a des cas techniquement difficiles où l'analyse de ces artefacts très connus ne fournit pas suffisamment d'informations pour restaurer la chronologie des événements. Comment être dans cette situation? Nous l'analysons avec de vrais exemples de nos investigations.

Pourquoi y a-t-il un manque général d'artefacts de base? Il peut y avoir plusieurs raisons:

  1. L'infrastructure n'est pas suffisamment préparée pour une surveillance et une réponse complètes aux événements (nous avons écrit à ce sujet ici )
  2. , ( Digital Forensic)
  3. , ( – , MFT-).

Ainsi, si l'infrastructure est grande et variée, l'incident s'est développé pendant longtemps, et l'attaquant est un «kalach déchiqueté», des sources d'informations supplémentaires sont nécessaires pour divulguer toutes ses actions et restaurer la chronologie des événements.

Selon la situation, les systèmes SIEM, l'analyse des flux du réseau Netflow ou du trafic brut (bien qu'en réalité cela ne soit pas possible dans 90% des cas), ainsi que des artefacts inhabituels liés à un logiciel tiers, par coïncidence, peuvent venir à la rescousse. dans l'infrastructure du client.

C'est sur le dernier type d'artefacts que nous nous arrêterons.

Ivanti Endpoint Manager (anciennement LANDESK Management Suite). Système de gestion des actifs informatiques

www.ivanti.ru/company/history/landesk En se connectant

à la surveillance de l'un de nos nouveaux clients, nous avons détecté dans son infrastructure le nettoyage des journaux d'événements sur l'un des serveurs, alors qu'il n'y avait aucune autre manifestation d'activité malveillante dans le système SIEM. Au cours de l'analyse, il a été constaté que le serveur était compromis et l'attaquant a utilisé un équipement spécial pour passer inaperçu. Il comprenait les éléments suivants:

  1. Les événements du journal de sécurité ont été redirigés vers un fichier temporaire distinct,
  2. un attaquant a effectué les actions nécessaires,
  3. les événements sont redirigés vers le journal de sécurité,
  4. le fichier temporaire a été supprimé.
  5. Profit!

En conséquence, bien que le journal de sécurité ait été correctement mis en place, il ne contenait aucun événement lié à une activité malveillante, alors qu'il semblait lui-même intact.

Après une brève analyse, nous avons découvert que l'attaquant «vivait» dans l'infrastructure depuis environ 2-3 ans, ce qui a permis de compromettre tous les serveurs clés. Dans de tels cas, la valeur de toute source d'information supplémentaire augmente, car certains artefacts de base sont effilochés ou non informatifs et ne permettent pas d'avoir une image complète de l'incident.

À la recherche de sources d'informations supplémentaires, nous avons effectué un inventaire oral des services et systèmes utilisés dans l'infrastructure et constaté que, parallèlement à la mise en œuvre de notre surveillance, le client a commencé à déployer un système de gestion des actifs informatiques.
Ivanti Endpoint Manager.

Étant donné que le système était toujours instable (les événements des agents n'étaient pas partiellement envoyés
au serveur), nous n'avons pas pu afficher de manière centralisée les événements des hôtes sur le serveur. Néanmoins, après avoir décidé de rechercher les artefacts stockés par Ivanti Endpoint directement sur l'hôte, nous avons constaté que ce logiciel stocke des informations sur les lancements de processus localement dans la branche de registre suivante:

HKLM \ SOFTWARE \ Wow6432Node] \ LANDesk \ ManagementSuite \ WinClient \ SoftwareMonitoring \ MonitorLog \ < Le chemin d'accès au fichier exécutable>

Les informations suivantes sont stockées dans les clés correspondantes:

  • premier démarrage (au format FILETIME)
  • dernière exécution (au format FILETIME)
  • nombre de démarrages
  • utilisateur avec des droits dont le fichier exécutable a été lancé


Artefacts de lancement du processus Ivanti Endpoint

Grâce à ces informations, nous avons pu déterminer l'heure d'apparition de l'attaquant sur certains systèmes que nous ne connaissions pas auparavant. De plus, une partie de sa boîte à outils a été divulguée uniquement sur la base du nom des fichiers exécutables.

Citrix NetScaler Système permettant d'accéder aux ressources et applications de l'entreprise

www.citrix.com/en-us/products/citrix-adc


Citrix NetScaler Workflow

Une autre enquête intéressante. Un attaquant est entré dans l'infrastructure de l'entreprise via un VPN. Il a travaillé dans le fuseau horaire UTC +8. Après l'authentification, il s'est comporté de manière assez agressive (sous-réseaux internes activement analysés à l'aide du masque / 24 et / 16), ce qui a en fait été remarqué.

Le VPN a été configuré sur le système d'application et de ressources Citrix NetScaler Enterprise. Après avoir étudié ses journaux, nous avons pu établir l'heure de la première «visite» (lire la date du compromis), les comptes des employés utilisés par l'attaquant (au fait, plus de 5 comptes ont été compromis) et les adresses IP des serveurs proxy à partir desquels il travaillait.

L'enquête elle-même s'est terminée avec succès: nous avons réussi à établir la source du compromis - il s'est avéré que le système interne de réinitialisation des informations d'identification accessibles depuis Internet était soumis à une injection SQL.

Mais maintenant, je veux noter autre chose: après avoir passé l'authentification VPN sur Citrix NetScaler, toutes les demandes des utilisateurs HTTP ont été correctement enregistrées. L'attaquant ne savait probablement pas cela ou a confondu ses interfaces réseau et a envoyé ses propres requêtes aux moteurs de recherche via le réseau d'entreprise du client. Cela nous a permis d'obtenir des informations sur les systèmes qui intéressent l'attaquant, ses compétences et les outils utilisés.


Fichier journal de Citrix NetScaler


Informations qu'un attaquant recherchait via Citrix NetScaler


Informations qu'un attaquant recherchait via Citrix NetScaler

Secret Net Studio. Système de protection des informations contre les accès non autorisés

www.securitycode.ru/products/secret_net

Un beau jour, un ticket avec un incident d'authentification suspect est tombé sur notre première ligne sous le compte d'un employé informatique de l'entreprise sur le serveur d'administration la nuit (l'employé était en vacances à ce moment-là, il avait un VPN n'a pas eu). Sur le plan architectural, le serveur d'administration était situé dans un segment de réseau distinct avec plusieurs autres serveurs clés de l'entreprise (y compris le serveur Secret Net), tandis que SIEM ne recevait que des événements du serveur d'administration lui-même (malheureusement, les clients ne sont pas toujours d'accord pour connecter toutes les sources potentielles )

La première ligne, traitant le ticket et collectant des informations sur ce qui s'est passé après l'authentification, tombe sur divers lancements de processus suspects (chemins non standard, noms de fichiers binaires dans une lettre) et lancement de mstsc.exe, indiquant une éventuelle session RDP.

Réalisant qu'il s'agissait d'un compromis potentiel, nous avons demandé des images de tous les serveurs
et a commencé leur analyse. En ouvrant la première image (serveur Secret Net), nous avons reçu une «grande surprise» en cadeau: les journaux système, de sécurité et d'application ont été supprimés et supprimés de sorte que même les tentatives de récupération ont échoué. Il n'a été possible de comparer que les entrées des journaux TerminalServices du serveur SecretS coïncidaient avec le lancement de mstsc.exe sur le serveur d'administration, ce qui signifie que l'attaquant était définitivement sur Secret Net. L'analyse des serveurs restants a également échoué.

En conséquence, nous nous sommes retrouvés dans une situation où il est certain que l'attaquant est là (il a certainement fait quelque chose et l'a démarré), mais nous n'avons pas de journaux d'hôte, car les traces sont supprimées
et il n'y a pas de journaux réseau, car tous les serveurs sont sur le même sous-réseau.

Une solution a même été trouvée dans cette situation. Le système Secret Net est très polyvalent et se compose de nombreux composants, à la fois au niveau du noyau et au niveau de l'utilisateur. Après avoir analysé chaque fichier journal enregistré et sauvegardé par divers composants de Secret Net, nous sommes tombés sur plusieurs excellents artefacts laissés par le contrôle des fichiers. Lorsque nous avons tout rassemblé, nous avons obtenu des informations sur les actions de l'attaquant (il était vraiment sur tous les serveurs de ce sous-réseau) et sur ses outils.

Soit dit en passant, les informations reçues ont permis de se débarrasser complètement de la présence d'un attaquant dans l'infrastructure.


Schéma d'un attaquant travaillant via le fichier de contrôle de fichier Secret Log Studio du serveur Secret Net Studio




KVRT. Outil antivirus gratuit

www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool

Nous avons été contactés pour obtenir de l'aide pour enquêter sur un incident lié à une activité malveillante sortante (botnet et activité de mineur) à partir des adresses publiques de l'entreprise. Après avoir reçu les images et les journaux du système, nous avons commencé l'analyse et trouvé des artefacts indiquant un compromis du service Web public de l'organisation et des fichiers malveillants laissés. Malheureusement, cela n'a pas suffi pour répondre à toutes les questions posées par le client: entre autres, nous n'avons pas trouvé de trace de fichier du mineur, même s'il a fallu un peu de temps entre la correction d'une activité malveillante et notre enquête.

Revenant une fois de plus aux artefacts et aux journaux, nous avons attiré l'attention sur les traces de plusieurs antivirus gratuits. Il est devenu clair que les fichiers qui nous manquaient étaient cryptés et mis en quarantaine, et les horodatages du système de fichiers étaient effacés en toute sécurité.

Parmi les scanners utilisés se trouvait KVRT, qui a détecté certains fichiers malveillants et les a mis en quarantaine. L'emplacement standard des fichiers de quarantaine est C: \ KVRT_Data \ Quarantine, et leur décryptage est très facile: un XOR simple avec une clé bien connue est e2 45 48 ec 69 0e 5c ac.


Quarantaine KVRT déchiffrée

Comme il s'est avéré plus tard, l'administrateur informatique a quand même réussi à analyser le système avec des scanners antivirus gratuits avant notre arrivée, malgré la recommandation de ne rien toucher.
Par conséquent, les fichiers mis en quarantaine ont aidé à combler les lacunes dans la chronologie des événements et à répondre à toutes les questions.


Chaque enquête est toujours quelque chose d'inhabituel, unique et polyvalent. Oui, il existe des artefacts connus des systèmes d'exploitation, mais avant le début de l'enquête, il est difficile de prédire l'exhaustivité des informations qui peuvent être obtenues après leur analyse. Par conséquent, avant une enquête technique sur l'incident, nous vous recommandons de faire un inventaire des logiciels et des systèmes et de ne pas être paresseux pour les étudier comme une source possible dans l'enquête.

More articles:


All Articles