Problèmes de journalisation des événements de sécurité du système Windows

Les systèmes d'exploitation Windows ont un assez bon système de journalisation des événements de sécurité. Beaucoup de bonnes choses ont été écrites à son sujet dans diverses publications et revues, mais cet article portera sur autre chose. Ici, nous parlons des problèmes et des lacunes de ce système. Certains des problèmes considérés ne seront pas critiques, ne faisant que compliquer les procédures d'analyse des événements, tandis que d'autres constitueront de très graves menaces pour la sécurité.

Les problèmes identifiés ont été testés sur Windows 7 Maximum (version russe), Windows 7 Professionnel (version anglaise), Windows 10 Pro (version russe), Windows Server 2019 Datacenter (version russe). Tous les systèmes d'exploitation ont été complètement mis à jour.

Problème n ° 1. Échec du système de gestion des paramètres d'audit

Le problème est confirmé sur Windows 7/10 / Server 2019.

Description du problème

Prenez Windows 7 et installez-le avec les paramètres par défaut. Nous n'entrerons pas dans le domaine. Voyons les paramètres d'audit des événements de sécurité. Pour ce faire, ouvrez le composant logiciel enfichable Stratégies de sécurité locales (secpol.msc ou Panneau de configuration -> Outils d'administration -> Stratégies de sécurité locales) et examinez les paramètres d'audit de base (Paramètres de sécurité -> Stratégies locales -> Stratégies d'audit) )



Comme vous pouvez le voir, l'audit n'est pas configuré. Voyons maintenant les stratégies d'audit avancées ("Paramètres de sécurité -> Configuration avancée des stratégies d'audit -> Stratégies d'audit système - Objet de stratégie de groupe locale").



Ici, l'audit n'est pas configuré non plus. Si c'est le cas, alors en théorie, il ne devrait pas y avoir d'événements de sécurité dans les journaux. Nous vérifions. Ouvrez le journal de sécurité (eventvwr.exe ou "Panneau de configuration -> Outils d'administration -> Afficher les événements").



Question: "D'où vient l'événement dans le journal de sécurité si l'audit n'est pas configuré du tout?!"

Explication

Pour comprendre la raison de ce comportement, vous devez vous mettre "sous le capot" du système d'exploitation. Pour commencer, nous traiterons des politiques d'audit de base et avancées.

Avant Windows Vista, il n'y avait qu'une seule stratégie d'audit, qui est maintenant appelée de base. Le problème était que la granularité de la gestion de l'audit à cette époque était très faible. Ainsi, s'il était nécessaire de suivre l'accès aux fichiers, ils incluaient alors la catégorie de politique de base «Audit de l'accès aux objets». En conséquence, en plus des opérations sur les fichiers, un tas d'autres événements "de bruit" se sont déversés dans le journal de sécurité. Cela a grandement compliqué le traitement des journaux et des utilisateurs énervés.

Microsoft a entendu cette «douleur» et a décidé d'aider. Le problème est que Windows est construit sur le concept de compatibilité descendante, et apporter des modifications au mécanisme de gestion d'audit existant aurait tué cette compatibilité. Par conséquent, le vendeur est allé dans l'autre sens. Il a créé un nouvel outil et l'a appelé Stratégies d'audit avancées.

L'essence de l'outil réside dans le fait que les catégories de politiques avancées ont été créées à partir des catégories de politiques d'audit de base, et celles-ci, à leur tour, ont été divisées en sous-catégories qui peuvent être activées et désactivées individuellement. Maintenant, si vous devez suivre l'accès aux fichiers dans les politiques d'audit avancées, vous devez activer uniquement la sous-catégorie "Système de fichiers", qui est incluse dans la catégorie "Accès aux objets". Dans le même temps, les événements de «bruit» liés à l'accès au registre ou au filtrage du trafic réseau ne seront pas inclus dans le journal de sécurité.

Une énorme confusion dans tout ce schéma est que les noms des catégories de politiques d'audit de base et avancées ne coïncident pas, et au premier abord, il peut sembler que ce sont des choses complètement différentes, mais ce n'est pas le cas.

Voici un tableau de conformité des noms des catégories de base et avancées de la gestion de l'audit

Il est important de comprendre que les catégories de base et avancées contrôlent essentiellement la même chose. L'inclusion d'une catégorie de politique d'audit de base entraîne l'inclusion de la catégorie de politique d'audit étendue correspondante et, par conséquent, de toutes ses sous-catégories. Pour éviter des conséquences imprévues, Microsoft ne recommande pas l' utilisation de stratégies d'audit de base et avancées en même temps.

Il est maintenant temps de déterminer où les paramètres d'audit sont stockés. Pour commencer, nous introduisons un certain nombre de concepts:

1. Stratégies d'audit efficaces - informations stockées dans la RAM qui déterminent les paramètres de fonctionnement actuels des modules du système d'exploitation qui implémentent les fonctions d'audit.
2. Stratégies d'audit enregistrées - informations stockées dans le registre sous HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv et utilisées pour déterminer les stratégies d'audit efficaces après un redémarrage du système.

Nous prendrons en considération divers outils administratifs et indiquerons les paramètres d'audit qu'ils affichent et ceux qui sont définis. Les données du tableau sont basées sur des expériences.

Expliquons le tableau avec des exemples.

Exemple 1

Si vous exécutez auditpol pour afficher les paramètres d'audit:
auditpol /get /category:* , les paramètres d'audit enregistrés seront affichés, c'est-à-dire ceux stockés dans le registre à HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv.

Exemple 2

Si vous exécutez le même utilitaire, mais déjà pour définir les paramètres:
auditpol /set /category:* , les paramètres d'audit effectifs et les paramètres d'audit enregistrés seront modifiés.

Un commentaire distinct requiert l'ordre dans lequel les paramètres d'audit sont affichés dans les "Stratégies d'audit de base" du composant logiciel enfichable "Stratégies de sécurité locales". La catégorie de la stratégie d'audit de base s'affiche comme définie si toutes les sous-catégories de la stratégie d'audit étendue correspondante sont installées. Si au moins l'un d'entre eux n'est pas installé, la stratégie sera affichée comme non installée.

Exemple 3

À l'aide de la commande auditpol /set /category:* , l' auditpol /set /category:* défini toutes les sous-catégories d'audit en mode de réussite d'audit. De plus, si vous accédez aux «Stratégies d'audit de base» du composant logiciel enfichable «Stratégies de sécurité locales», un audit de réussite sera installé en face de chaque catégorie.

Exemple 4

L'administrateur a maintenant auditpol /clear commande auditpol /clear et réinitialisé tous les paramètres d'audit. Il a ensuite configuré l'audit du système de fichiers en exécutant auditpol /set /subcategory:" " . Maintenant, si vous accédez aux «Stratégies d'audit de base» du composant logiciel enfichable «Stratégies de sécurité locales», toutes les catégories seront définies dans l'état «Aucun audit», car aucune catégorie de la stratégie d'audit étendue n'est entièrement définie.

Maintenant, enfin, nous pouvons répondre à la question de savoir d'où viennent les journaux dans le système d'exploitation fraîchement installé. Le fait est qu'après l'installation, l'audit sous Windows est configuré et défini dans les paramètres d'audit enregistrés. Vous pouvez le vérifier en exécutant la commande auditpol /get /category:* .



Dans les stratégies d'audit de base du composant logiciel enfichable Stratégies de sécurité locales, ces informations d'audit ne sont pas affichées, car toutes les catégories n'ont pas défini une ou plusieurs sous-catégories. Dans les stratégies d'audit avancées du composant logiciel enfichable Stratégies de sécurité locales, ces informations ne s'affichent pas car le composant logiciel enfichable fonctionne uniquement avec les paramètres d'audit stockés dans le fichier% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv.

Quelle est l'essence du problème?

Au début, il peut sembler que tout cela n'est pas du tout un problème, mais ce n'est pas le cas. Le fait que tous les outils affichent les paramètres d'audit de différentes manières crée la possibilité d'une manipulation malveillante des stratégies et, par conséquent, des résultats d'audit.

Considérez le scénario probable

Laissez un poste de travail technologique basé sur Windows 7 fonctionner dans le réseau d'entreprise.

La machine n'est pas incluse dans le domaine et remplit les fonctions d'un robot qui envoie quotidiennement des rapports aux autorités réglementaires. Les attaquants d'une manière ou d'une autre y ont eu accès à distance avec des droits d'administrateur. Dans le même temps, l'objectif principal des attaquants est l'espionnage et la tâche est de rester non détecté dans le système. Les attaquants ont secrètement décidé afin qu'il n'y ait aucun événement avec le code 4719 «Audit policy changes» dans le journal de sécurité, désactivez l'audit d'accès aux fichiers, mais en même temps que tous les outils d'administration disent que l'audit est activé. Pour réaliser la tâche, ils ont effectué les actions suivantes:

1. Sur le poste de travail attaqué, ils se sont accordés des autorisations d'écriture sur la clé de registre HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv et ont exporté cette clé dans un fichier nommé "+ fs.reg".
2. Ce fichier a été importé sur un autre ordinateur, redémarré, puis auditpol a désactivé l'audit du système de fichiers, après quoi la clé de registre ci-dessus a été exportée dans le fichier "-fs.reg".
3. Sur la machine attaquée, le fichier "-fs.reg" a été importé dans le registre.
4. Nous avons effectué une copie de sauvegarde du fichier% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv situé sur la machine attaquée, puis supprimé la sous-catégorie du système de fichiers.
5. Nous avons redémarré le poste de travail attaqué, puis remplacé le fichier% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv par une copie de sauvegarde précédemment enregistrée et nous avons également importé le fichier "+ fs.reg"

À la suite de toutes ces manipulations, il n'y a aucune entrée de changement de politique dans le journal de sécurité, tous les outils montrent que l'audit est activé, mais en fait cela ne fonctionne pas.

Problème n ° 2. Enregistrement des opérations infructueux pour supprimer des fichiers, des répertoires et des clés de registre

Le problème est confirmé sur Windows 7/10 / Server 2019.

Description du problème

Pour qu'une opération supprime un fichier, un répertoire ou une clé de registre, le système d'exploitation génère une séquence d'événements avec les codes 4663 et 4660 . Le problème est que de tout le flux d'événements, ce couple n'est pas si facile de se connecter. Pour ce faire, les événements analysés doivent avoir les paramètres suivants:

Événement 1. Code 4663 "Une tentative d'accès à l'objet a été effectuée." Paramètres d'événement:
"ObjectType" = Fichier.
"ObjectName" = nom du fichier ou du répertoire à supprimer.
"HandleId" = gérer le fichier à supprimer.
"AcessMask" = 0x10000 (Ce code correspond à l'opération DELETE. Vous pouvez trouver le déchiffrement de tous les codes d'opération sur le site Web de Microsoft ).



Événement 2. Code 4660 "Objet supprimé."
Paramètres d'événement:

"HandleId" = "Evénements HandleId 1"
"System \ EventRecordID" = "System \ EventRecordID de l'événement 1" + 1.



Avec la suppression de la clé de registre (clé), tout est pareil, seulement dans le premier événement avec le code 4663, le paramètre "ObjectType" = Key.

Notez que la suppression de valeurs dans le Registre est décrite par un autre événement (code 4657 ) et ne provoque pas de tels problèmes.

Fonctionnalités de suppression de fichiers dans Windows 10 et Server 2019

Dans Windows 10 / Server 2019, il existe deux façons de supprimer un fichier.

1. Si le fichier est supprimé dans la corbeille, alors, comme précédemment, la séquence des événements 4663 et 4660.
2. Si le fichier est supprimé définitivement (passé la corbeille), alors avec un seul événement avec le code 4659 .

Une chose étrange s'est produite. Si auparavant, pour déterminer les fichiers supprimés, il était nécessaire de surveiller la totalité des événements 4663 et 4660, maintenant Microsoft est «allé à la rencontre des utilisateurs», et au lieu de deux événements, nous devons maintenant en surveiller trois. Il convient également de noter que la procédure de suppression des répertoires n'a pas changé; elle se compose, comme précédemment, de deux événements 4663 et 4660.

Quelle est l'essence du problème?

Le problème est que découvrir qui a supprimé le fichier ou le répertoire devient une tâche non triviale. Au lieu de rechercher banalement l'événement correspondant dans le journal de sécurité, il est nécessaire d'analyser la séquence des événements, ce qui est plutôt difficile à faire manuellement. Sur habr même à ce sujet, il y avait un article: "Auditer la suppression et l'accès aux fichiers et enregistrer les événements dans un fichier journal à l'aide de Powershell . "

Problème numéro 3 (critique). Enregistrement infructueux de l'opération de changement de nom pour les fichiers, les répertoires et les clés de registre

Le problème est confirmé sur Windows 7/10 / Server 2019.

Description du problème

Ce problème a deux sous-problèmes:

1. Dans les événements générés par le système lors du changement de nom, le nouveau nom d'objet n'est fixé nulle part.
2. La procédure de changement de nom est très similaire à la suppression. Il ne peut être distingué que par le fait que le premier événement avec le code 4663, avec le paramètre "AcessMask" = 0x10000 (DELETE) ne passe pas à l' événement 4660.

Il convient de noter qu'en ce qui concerne le registre, ce problème ne s'applique qu'aux clés. Renommer des valeurs dans le registre est décrit par une séquence d'événements 4657 et ne provoque pas de telles plaintes, bien que, bien sûr, il serait beaucoup plus pratique s'il n'y avait qu'un seul événement.

Quelle est l'essence du problème?

Outre la difficulté de rechercher des opérations de changement de nom de fichier, cette fonction de journalisation ne permet pas de suivre le cycle de vie complet des objets du système de fichiers ou des clés de registre. Par conséquent, il devient extrêmement difficile de déterminer l'historique d'un fichier qui a été renommé plusieurs fois sur un serveur de fichiers utilisé activement.

Problème numéro 4 (critique). Impossible de suivre la création des répertoires et des clés de registre

Le problème est confirmé sur Windows 7/10 / Server 2019.

Description du problème

Windows ne suit pas la création d'un répertoire de système de fichiers et d'une clé de registre. Cela consiste dans le fait que le système d'exploitation ne génère pas d'événement qui contiendrait le nom du répertoire ou de la clé de registre créé et dont les paramètres indiqueraient qu'il s'agit de l'opération de création.

Théoriquement, par des signes indirects, le fait de créer un catalogue est possible. Par exemple, s'il a été créé via "l'Explorateur", pendant le processus de création, des événements d'interrogation pour les attributs du nouveau répertoire seront générés. Le problème est que si vous créez un répertoire via la commande mkdir , aucun événement n'est généré du tout. Il en est de même pour la création de clés dans le registre.

Quelle est l'essence du problème?

Ce problème rend très difficile les enquêtes sur les incidents de sécurité des informations. Il n'y a aucune explication raisonnable au fait que ces informations ne sont pas enregistrées dans les journaux.

Problème numéro 5 (critique). Paramètres d'audit incorrects dans les versions russes de Windows

La présence du problème est confirmée sur les éditions russes de Windows 7/10 / Server 2019.

Description du problème

Il y a une erreur dans les versions russes de Windows qui rend le système de gestion des audits de sécurité inopérant.

Symptômes

La modification des politiques de sécurité avancées n'affecte pas les paramètres d'audit effectifs ou, en d'autres termes, les politiques ne sont pas appliquées. Par exemple, l'administrateur a activé la sous-catégorie "Connexion", redémarré le système, exécuté la commande auditpol /get /category:* , et cette sous-catégorie reste auditpol /get /category:* . Le problème concerne à la fois les ordinateurs de domaine gérés via des stratégies de groupe et les ordinateurs hors domaine gérés à l'aide d'un objet de stratégie de groupe local configuré via le composant logiciel enfichable Stratégies de sécurité locales.

Raisons

Le problème se produit si l'administrateur a activé au moins une des sous-catégories «défaillantes» des stratégies d'audit avancées. Ces catégories ayant échoué, en particulier, comprennent:

1. Utilisation des droits -> Auditer l'utilisation des droits affectant les données confidentielles. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
2. Utilisation des droits -> Auditez l'utilisation des droits qui n'affectent pas les données confidentielles. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
3. Accès aux objets -> Auditer les événements créés par les applications. GUID: {0cce9222-69ae-11d9-bed3-505054503030}.

Recommandations pour résoudre le problème

Si le problème ne s'est pas encore produit, n'activez pas les sous-catégories «échouées» indiquées. Si les événements de ces sous-catégories sont très nécessaires, utilisez l'utilitaire auditpol pour les activer ou gérez l'audit à l'aide de stratégies de base.

En cas de problème, vous devez:

1. Dans le répertoire de stratégie de groupe de domaine, supprimez le fichier \ Machine \ microsoft \ windows nt \ Audit \ audit.csv
2. Sur tous les ordinateurs qui rencontrent des problèmes d'audit, supprimez les fichiers:% SystemRoot% \ security \ audit \ audit.csv,% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv

Quelle est l'essence du problème?

La présence de ce problème réduit le nombre d'événements de sécurité qui peuvent être surveillés régulièrement grâce à des stratégies d'audit avancées, et crée également des menaces de déconnexion, de blocage et de déstabilisation de la gestion du système d'audit dans le réseau d'entreprise.

Problème numéro 6 (critique). Merde "Nouveau texte document.txt ... ainsi que Nouveau bitmap.bmp"

Le problème a été confirmé sur Windows 7. Le problème est manquant dans Windows 10 / Server 2019.

Description du problème

Il s'agit d'un problème très étrange découvert par accident. L'essence du problème est que le système d'exploitation a une faille qui vous permet de contourner l'audit de la création de fichiers.

Partie préparatoire:

1. Prenez un Windows 7 fraîchement installé.
2. Réinitialisez tous les paramètres d'audit à l'aide de la commande auditpol /clear . Cet élément est facultatif et ne sert qu'à l'analyse des magazines.
3. Nous configurons l'audit du système de fichiers en exécutant auditpol /set /subcategory:" " .
4. Créons le répertoire C: \ TEST et assignons des paramètres d'audit pour le compte «Everything»: «Create Files / Write Data», «Create Folders / Write Data», «Write Attributes», «Write Additional Attributes», «Delete Subfolders and fichiers "," Supprimer "," Changement d'autorisations "," Changement de propriétaire ", c'est-à-dire tout ce qui concerne l'écriture de données dans le système de fichiers.

Pour plus de clarté, avant chaque expérience, nous effacerons le journal de sécurité du système d'exploitation.

Expérience 1.
Nous faisons:

À partir de la ligne de commande, exécutez la commande: echo > "c:\test\ .txt"
On observe:

Lors de la création du fichier, un événement avec le code 4663 est apparu dans le journal de sécurité, contenant le nom du fichier en cours de création dans le champ "ObjectName" et 0x2 dans le champ "AccessMask" ("Ecriture de données ou ajout d'un fichier").



Pour effectuer les expériences suivantes, nous effaçons le dossier et le journal des événements.

Expérience 2.
Nous faisons:

Ouvrez le dossier C: \ TEST via l '"Explorateur" et utilisez le menu contextuel "Créer -> Document texte", appelé par un clic droit, créez le fichier "Nouveau document texte.txt".



On observe:

Cette action n'était pas reflétée dans le journal des événements !!! De plus, il n'y aura aucune entrée si vous utilisez le même menu contextuel pour créer un «bitmap».



Expérience 3.
Nous faisons:

A l'aide de l'Explorateur, ouvrez le dossier C: \ TEST et à l'aide du menu contextuel "Créer -> Document au format RTF", appelé par un clic droit, créez le fichier "Nouveau document au format RTF.rtf".

On observe:

Comme dans le cas de la création du fichier via la ligne de commande, un événement avec le code 4663 et le contenu correspondant est apparu dans le journal.

Quelle est l'essence du problème?

Bien sûr, la création de documents texte ou d'images n'est pas particulièrement nuisible. Cependant, si l '"Explorateur" est capable de contourner la journalisation des opérations sur les fichiers, les logiciels malveillants pourront le faire.

Ce problème est peut-être le plus important de tous, car il porte gravement atteinte à la crédibilité des résultats de l'audit des opérations sur les fichiers.

Conclusion

La liste de problèmes ci-dessus n'est pas exhaustive. Dans le processus, j'ai réussi à tomber sur un nombre encore assez important de diverses failles mineures, qui incluent l'utilisation de constantes localisées comme valeurs de paramètres pour un certain nombre d'événements, ce qui nous oblige à écrire nos scripts d'analyse pour chaque localisation du système d'exploitation, la division illogique des codes d'événements en opérations qui ont une signification proche, par exemple, la suppression d'une clé de registre est une séquence d'événements 4663 et 4660, et la suppression d'une valeur dans le registre est 4657, et aussi de petites choses ...

En toute honnêteté, nous notons que malgré toutes les lacunes, le système d'enregistrement des événements de sécurité dans Windows présente un grand nombre d'aspects positifs. La résolution des problèmes critiques répertoriés ici pourrait remettre la couronne à une meilleure solution pour la journalisation des événements de sécurité hors de la boîte.

FAITES DE PLUS EN PLUS LA CONNEXION DES ÉVÉNEMENTS DE SÉCURITÉ WINDOWS!