Comment utiliser le Journal des événements de Windows pour surveiller les activités effectuées sur les fichiers

On aurait pu espérer que Microsoft fournirait dans son Journal des événements, des événements directs et cohérents concernant les activités réalisées sur les fichiers. Le journal des événements des fichiers est important pour toutes les raisons habituelles (conformité, informatique légale, surveillance des utilisateurs habilités), mais aussi pour détecter le ransomware et les autres types d’attaques lorsqu’elles se produisent. Un journal des activités des fichiers ne semble pas bien compliqué, vous n’êtes pas d’accord ? Tout ce qu’il doit indiquer, c’est un horodatage, le nom de l’utilisateur, le nom du fichier, l’opération (créer, lire, modifier, renommer, supprimer, etc.), et un résultat (réussite ou échec).

Mais là, on a affaire à Microsoft. Et jamais, au grand jamais, Microsoft ne fait les choses simplement.

Le cas de l’opération « Supprimer »

Commençons par la suppression, le scénario le plus simple. Dans Google, tapez « Windows file delete event ». Le premier résultat proposé, comme d’habitude, proviendra de la Windows Event Encyclopedia de Randy Franklin Smith : « 4660: An object was deleted ».

Une personne qui n’a pas l’habitude des événements Windows aurait alors l’impression d’être arrivée au bout de ses recherches. Malheureusement, il manque une information cruciale à cet événement de suppression : le nom du fichier. Pourquoi ? Si vous détectez une attaque de ransomware, vous voudrez savoir quels sont les fichiers concernés par le chiffrement. De la même façon, lorsque vous recevez une alerte signalant l’accès d’un utilisateur habilité à accéder à des fichiers sensibles, vous voulez savoir exactement de quels fichiers il s’agit.

C’est là tout le problème : comment faites-vous pour déterminer le nom de fichier associé à un événement ? Même l’identification de quelque chose d’aussi simple qu’un nom de fichier devient compliqué car les informations sur les événements Windows sont réparties sur plusieurs entrées de journal. Vous devrez, par exemple, faire le lien entre l’événement de suppression 4660 et l’événement « accès à l’objet » 4663. En pratique, vous créeriez une recherche pour obtenir les événements 4660 et 4663 correspondants, puis vous combineriez les informations des deux événements en une entrée de journal plus pratique.

Continuons sur les liens à établir pour mettre en place une surveillance de l’activité des fichiers avec le journal des événements de Windows. L’implémentation réelle dépend des outils utilisés pour collecter l’événement : une requête de base de données, un programme ou un moteur de corrélation dédié – un programme personnalisé pour une telle activité.

Le flux d’audit Windows des activités réalisées sur les fichiers

Windows ne consigne pas les activités réalisées sur les fichiers comme vous vous y attendriez. Dans le journal, il note des opérations précises sur les fichiers, que vous devez soumettre à un traitement supplémentaire. Examinons dans le détail comment Windows consigne les opérations sur les fichiers dans le journal.

Le diagramme ci-dessous indique comment Windows enregistre dans le journal chaque opération effectuée sur les fichiers au moyen de plusieurs journaux de micro-opérations :

L’opération de suppression est un cas unique dans le sens où un quatrième événement (4660) est impliqué, comme indiqué ci-dessus. La séquence est identifiée par la propriété d’événement « ID du handle », unique à cette séquence (au moins jusqu’à un redémarrage).

L’événement le plus informatif est le 4663, qui détermine qu’une tentative d’accès à un objet a été effectuée. Toutefois, le nom est trompeur car Windows n’émet l’événement qu’une fois l’opération terminée. En réalité, il peut y avoir plusieurs événements 4663 pour un handle unique qui consignent les opérations plus courtes constituant l’action globale. Par exemple, l’attribution d’un nouveau nom à un fichier implique une opération de lecture, de suppression et d’écriture. De plus, un événement 4663 peut inclure plusieurs valeurs dans la propriété « Accès » qui dresse la liste des droits d’accès exercés pour effectuer l’opération. Ces « Accès » nous servent de guide pour les opérations elles-mêmes. Nous y reviendrons plus tard.

Le tableau ci-dessous fournit des informations complémentaires sur chaque événement :

N’omettez pas l’étape de paramétrage de Windows portant sur la consignation des événements, qui n’est pas définie par défaut. Un bon tutoriel expliquant la procédure est disponible ici.

Vous voyez le tableau : vous avez affaire à une multitude d’événements de bas niveau différents liés à des actions de niveau supérieur sur les fichiers. Abordons maintenant le problème de leur mise en relation pour obtenir des informations exploitables.

Interprétation des « Accès »

Pour identifier l’action réelle, nous devons décoder les droits exercés indiqués dans la propriété d’événement « Accès ». Malheureusement, il ne s’agit pas d’un mappage univoque. Chaque action effectuée sur le fichier est constituée d’opérations plus petites effectuées par Windows et ce sont ces opérations qui sont consignées dans le journal.

Les valeurs les plus importantes de la propriété « Accès » sont :

• « Écriture données » implique qu’un fichier a été créé ou modifié à moins qu’un accès « Supprimer » ait été enregistré pour le même handle.
• « Lecture données » sera indiqué dans le journal pour presque toutes les actions. Ce message implique un « Accès » si aucune opération « Supprimer » ou « Écriture données » n’a été rencontrée pour le même nom de fichier à peu près à la même heure.
• « Supprimer » peut vouloir dire beaucoup de choses : supprimer, renommer (même dossier), déplacer (vers un dossier différent) ou recycler, qui correspond à un déplacement dans la corbeille. L’événement 4660 possédant le même handle fait la distinction entre une opération « supprimer » et « recycler » pour laquelle un événement 4660 est émis et une opération « renommer » ou « déplacer » pour laquelle il n’est pas émis.

Compliqué ?

Et ce n’est que le début. L’analyse ci-dessus est quelque peu simplifiée : en pratique, l’implémentation exige davantage de recherches. D’autres domaines doivent faire l’objet de recherches complémentaires :

• La différentiation entre « supprimer » et « recycler » d’une part, et « déplacer » et « renommer » d’autre part
• L’analyse de l’accès aux attributs (avec ou sans autre opération d’accès).
• La gestion de l’événement 4659, similaire à 4660 mais consigné en cas de demande de suppression d’un fichier verrouillé lors du redémarrage suivant, et non lors d’une suppression immédiate.
• La recherche de rapports indiquant que des événements sont dans le désordre et que l’« événement de handle de demande » (4656) n’est peut-être pas le premier de la séquence.

Vous souhaiterez peut-être examiner ce script PowerShell qui lit les événements Windows et les utilise pour générer un rapport exploitable sur les activités des fichiers afin d’apporter une analyse un peu moins simpliste. Un avertissement toutefois : il va falloir vous accrocher !

Les limites du journal des événements de Windows pour surveiller l’accès aux fichiers

Si les événements Windows portant sur les opérations effectuées sur les fichiers paraissent complets, ils ne suffisent pas à déterminer certaines informations. Quelques exemples :

• Différence entre créer et modifier : la seule façon de savoir s’il s’agit d’un nouveau fichier ou d’un fichier modifié est de connaître son état antérieur, c’est-à-dire s’il existait avant.
• Informations manquantes sur les échecs : en cas d’opération refusée en raison de droits insuffisants, le seul événement émis est 4656. Sans séquence, la majeure partie du traitement décrit dans cet article est impossible.
• Couper & Coller : on pourrait penser que le « copier/coller » reviendrait au même qu’une opération de déplacement mais, en pratique, le comportement semble être similaire à une opération de suppression suivie d’une opération de création sans relation entre les deux opérations.

Remarques sur l’adaptabilité

La collecte des activités réalisées sur les fichiers dans Windows constitue un flux d’événements massif et la structure d’événements Microsoft, qui génère de nombreux événements pour chaque action sur un fichier, n’est d’aucune aide. Cette collecte exigera davantage de bande passante pour transférer les événements et plus de stockage pour les conserver. Par ailleurs, la logique sophistiquée nécessaire peut exiger un processeur puissant et beaucoup de mémoire.

Pour réduire la charge de travail, vous souhaiterez peut-être :

• Sélectionner soigneusement les fichiers surveillés en fonction du scénario que vous prévoyez de mettre en oeuvre. Par exemple, vous souhaiterez éventuellement limiter le suivi aux fichiers ou partages qui contiennent des données sensibles.
• Limiter la collecte des événements inutiles à la source. Si votre infrastructure de collecte utilise le Transfert d’événements Microsoft, vous pouvez créer des filtres sophistiqués en fonction des ID et des propriétés d’événement. Dans le cas qui nous intéresse, filtrez uniquement les événements 4656, 4660, 4663 et éventuellement 4658, et uniquement pour les valeurs d’« Accès » nécessaires.
• Limiter le stockage et la taille des événements, étant donné que les événements Windows bruts sont dimensionnables.

Une approche alternative

L’expérience montre que peu d’organisations parviennent à utiliser le Journal des événements Windows pour surveiller l’activité des fichiers. Une approche alternative à la mise en place de cette importante mesure de sécurité et de conformité consisterait à utiliser un agent léger sur chaque système Windows surveillé, en particulier les serveurs de fichiers. Cet agent, à l’instar de celui proposé par Varonis dans DatAdvantage, enregistrerait l’activité des fichiers en exerçant une charge minimale sur le serveur et le réseau, afin d’apporter des capacités de détection et de criminalistique plus efficaces.