Problemas de registro de eventos de seguridad del sistema de Windows

Los sistemas operativos Windows tienen un sistema de registro de eventos de seguridad bastante bueno. Se han escrito muchas cosas buenas sobre ella en varias publicaciones y reseñas, pero este artículo tratará sobre otra cosa. Aquí hablamos de problemas y deficiencias en este sistema. Algunos de los problemas considerados no serán críticos, solo complicarán los procedimientos para analizar eventos, mientras que otros plantearán amenazas de seguridad muy graves.

Los problemas identificados se probaron en Windows 7 Maximum (versión rusa), Windows 7 Professional (versión inglesa), Windows 10 Pro (versión rusa), Windows Server 2019 Datacenter (versión rusa). Todos los sistemas operativos han sido completamente actualizados.

Problema No. 1. Sistema de gestión de parámetros de auditoría fallido

El problema se confirma en Windows 7/10 / Server 2019.

Descripción del problema

Tome Windows 7 e instálelo con la configuración predeterminada. No ingresaremos al dominio. Veamos la configuración de auditoría de eventos de seguridad. Para hacer esto, abra el complemento Políticas de seguridad local (secpol.msc o Panel de control -> Herramientas administrativas -> Políticas de seguridad local) y observe la configuración básica de auditoría (Configuración de seguridad -> Políticas locales -> Políticas de auditoría) )



Como puede ver, la auditoría no está configurada. Ahora veamos las políticas de auditoría avanzadas ("Configuración de seguridad -> Configuración de política de auditoría avanzada -> Políticas de auditoría del sistema - Objeto de política de grupo local").



Aquí la auditoría tampoco está configurada. Si es así, en teoría no debería haber ningún evento de seguridad en los registros. Lo comprobamos Abra el registro de seguridad (eventvwr.exe o "Panel de control -> Herramientas administrativas -> Ver eventos").



Pregunta: "¿De dónde viene el evento en el registro de seguridad si la auditoría no está configurada?"

Explicación

Para comprender la razón de este comportamiento, debe "ocultarse" al sistema operativo. Para empezar, trataremos con políticas de auditoría básicas y avanzadas.

Antes de Windows Vista, solo había una política de auditoría, que ahora se llama básica. El problema era que la granularidad de la gestión de auditoría en ese momento era muy baja. Entonces, si se requería rastrear el acceso a los archivos, entonces incluían la categoría de la política básica "Auditar el acceso a los objetos". Como resultado, además de las operaciones de archivo, un montón de otros eventos de "ruido" se vertieron en el registro de seguridad. Esto complicó enormemente el procesamiento de registros y usuarios desconcertados.

Microsoft escuchó este "dolor" y decidió ayudar. El problema es que Windows se basa en el concepto de compatibilidad con versiones anteriores, y realizar cambios en el mecanismo de gestión de auditoría existente habría eliminado esta compatibilidad. Por lo tanto, el vendedor fue por el otro lado. Creó una nueva herramienta y la llamó Políticas avanzadas de auditoría.

La esencia de la herramienta radica en el hecho de que las categorías de políticas avanzadas se hicieron a partir de las categorías de políticas básicas de auditoría, y que, a su vez, se dividieron en subcategorías que pueden activarse y desactivarse individualmente. Ahora, si necesita rastrear el acceso a los archivos en las políticas de auditoría avanzadas, debe activar solo la subcategoría "Sistema de archivos", que se incluye en la categoría "Acceso a objetos". Al mismo tiempo, los eventos de "ruido" relacionados con el acceso al registro o el filtrado del tráfico de red no se incluirán en el registro de seguridad.

Una gran confusión en todo este esquema es que los nombres de las categorías de políticas básicas de auditoría y avanzadas no coinciden, y al principio puede parecer que estas son cosas completamente diferentes, pero esto no es así.

Aquí hay una tabla de conformidad de los nombres de las categorías básicas y avanzadas de gestión de auditoría.

Es importante comprender que las categorías básicas y avanzadas controlan esencialmente lo mismo. La inclusión de una categoría de política de auditoría básica lleva a la inclusión de la categoría de política de auditoría extendida correspondiente y, como resultado, todas sus subcategorías. Para evitar consecuencias imprevistas, Microsoft no recomienda el uso de políticas de auditoría básicas y avanzadas al mismo tiempo.

Ahora es el momento de averiguar dónde se almacenan las configuraciones de auditoría. Para comenzar, presentamos una serie de conceptos:

1. Políticas de auditoría efectivas : información almacenada en la RAM que determina los parámetros operativos actuales de los módulos del sistema operativo que implementan funciones de auditoría.
2. Políticas de auditoría guardadas : información almacenada en el registro en HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv y utilizada para determinar políticas de auditoría efectivas después de un reinicio del sistema.

Consideraremos varias herramientas administrativas e indicaremos qué parámetros de auditoría muestran y qué conjunto. Los datos en la tabla se basan en experimentos.

Expliquemos la tabla con ejemplos.

Ejemplo 1

Si ejecuta auditpol para ver la configuración de auditoría:
auditpol /get /category:* , luego se mostrarán las configuraciones de auditoría guardadas, es decir, las almacenadas en el registro en HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv.

Ejemplo 2

Si ejecuta la misma utilidad, pero ya para establecer los parámetros:
auditpol /set /category:* , se modificará la configuración de auditoría efectiva y la configuración de auditoría guardada.

Un comentario separado requiere el orden en que se muestran las configuraciones de auditoría en las "Políticas básicas de auditoría" del complemento "Políticas de seguridad local". La categoría de la política de auditoría básica se muestra como establecida si se instalan todas las subcategorías de la política de auditoría extendida correspondiente. Si al menos uno de ellos no está instalado, la política se mostrará como no instalada.

Ejemplo 3

Usando el auditpol /set /category:* , el auditpol /set /category:* configuró todas las subcategorías de auditoría en el Modo de éxito de auditoría. Además, si va a las "Políticas básicas de auditoría" del complemento "Políticas de seguridad local", se instalará una Auditoría de éxito frente a cada categoría.

Ejemplo 4

Ahora el administrador ha auditpol /clear y ha restablecido todas las configuraciones de auditoría. Luego configuró la auditoría del sistema de archivos ejecutando auditpol /set /subcategory:" " . Ahora, si va a las "Políticas básicas de auditoría" del complemento "Políticas de seguridad locales", todas las categorías se definirán en el estado "Sin auditoría", ya que no hay una sola categoría de la política de auditoría extendida completamente definida.

Ahora, finalmente, podemos responder a la pregunta de dónde provienen los registros en el sistema operativo recién instalado. La cuestión es que después de la instalación, la auditoría en Windows se configura y define en la configuración de auditoría guardada. Puede verificar esto ejecutando el auditpol /get /category:* .



En las Políticas básicas de auditoría del complemento Políticas de seguridad local, esta información de auditoría no se muestra, ya que una o más subcategorías no están definidas en todas las categorías. En las Políticas de auditoría avanzadas del complemento Políticas de seguridad local, esta información no se muestra porque el complemento solo funciona con la configuración de auditoría almacenada en el archivo% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv.

¿Cuál es la esencia del problema?

Al principio puede parecer que todo esto no es un problema, pero no lo es. El hecho de que todas las herramientas muestren los parámetros de auditoría de diferentes maneras crea la oportunidad para la manipulación maliciosa de las políticas y, como resultado, los resultados de la auditoría.

Considere el escenario probable

Deje que una estación de trabajo tecnológica basada en Windows 7 funcione en la red corporativa.

La máquina no está incluida en el dominio y realiza las funciones de un robot que envía informes diariamente a las autoridades reguladoras. Los atacantes de una forma u otra obtuvieron acceso remoto con derechos de administrador. Al mismo tiempo, el objetivo principal de los atacantes es el espionaje, y la tarea es permanecer sin ser detectados en el sistema. Los atacantes decidieron en secreto que no debería haber eventos con el código 4719 "Cambios en la política de auditoría" en el registro de seguridad, para deshabilitar la auditoría de acceso a archivos, pero al mismo tiempo que todas las herramientas de administración dicen que la auditoría está habilitada. Para lograr la tarea, realizaron las siguientes acciones:

1. En la estación de trabajo atacada, se otorgaron permisos de escritura a la clave de registro HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv y exportaron esta clave a un archivo llamado "+ fs.reg".
2. Importamos este archivo en otra computadora, lo reiniciamos y luego desactivamos la auditoría del sistema de archivos usando auditpol, después de lo cual exportamos la clave de registro anterior al archivo "-fs.reg".
3. En la máquina atacada, el archivo "-fs.reg" se importó al registro.
4. Hicimos una copia de seguridad del archivo% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv ubicado en la máquina atacada y luego eliminamos la subcategoría del sistema de archivos.
5. Reiniciaron la estación de trabajo atacada y luego reemplazaron el archivo% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv con una copia de seguridad previamente guardada y también importaron el archivo "+ fs.reg"

Como resultado de todas estas manipulaciones, no hay entradas de cambio de política en el registro de seguridad, todas las herramientas muestran que la auditoría está habilitada, pero en realidad no funciona.

Problema No. 2. Registro fallido de operaciones para eliminar archivos, directorios y claves de registro

El problema se confirma en Windows 7/10 / Server 2019.

Descripción del problema

Para que una operación elimine un archivo, directorio o clave de registro, el sistema operativo genera una secuencia de eventos con los códigos 4663 y 4660 . El problema es que de toda la secuencia de eventos, esta pareja no es tan fácil de conectarse entre sí. Para hacer esto, los eventos analizados deben tener los siguientes parámetros:

Evento 1. Código 4663 "Se intentó obtener acceso al objeto". Parámetros del evento:
"ObjectType" = Archivo.
"ObjectName" = nombre del archivo o directorio que se va a eliminar.
"HandleId" = manejar el archivo que se va a eliminar.
"AcessMask" = 0x10000 (Este código corresponde a la operación ELIMINAR. Puede encontrar el descifrado de todos los códigos de operación en el sitio web de Microsoft ).



Evento 2. Código 4660 "Objeto eliminado".
Parámetros del evento:

"HandleId" = "Eventos de HandleId 1"
"System \ EventRecordID" = "System \ EventRecordID del evento 1" + 1.



Con la eliminación de la clave de registro (clave), todo es igual, solo en el primer evento con el código 4663, el parámetro "ObjectType" = Clave.

Tenga en cuenta que la eliminación de valores en el registro es descrita por otro evento (código 4657 ) y no causa tales problemas.

Características de eliminar archivos en Windows 10 y Server 2019

En Windows 10 / Server 2019, hay dos formas de eliminar un archivo.

1. Si el archivo se elimina a la papelera, entonces, como antes, la secuencia de eventos 4663 y 4660.
2. Si el archivo se elimina permanentemente (más allá de la papelera de reciclaje), entonces con un solo evento con el código 4659 .

Algo extraño sucedió. Si antes, para determinar los archivos eliminados, era necesario monitorear la totalidad de los eventos 4663 y 4660, ahora Microsoft ha "ido a conocer a los usuarios", y en lugar de dos eventos, ahora necesitamos monitorear tres. También vale la pena señalar que el procedimiento para eliminar directorios no ha cambiado; como antes, consta de dos eventos 4663 y 4660.

¿Cuál es la esencia del problema?

El problema es que descubrir quién eliminó el archivo o directorio se convierte en una tarea no trivial. En lugar de la búsqueda banal del evento correspondiente en el registro de seguridad, es necesario analizar la secuencia de eventos, lo que es bastante difícil de hacer manualmente. En habr incluso sobre esto había un artículo: "Auditar la eliminación y el acceso a archivos y grabar eventos en un archivo de registro usando Powershell" .

Problema número 3 (crítico). Registro fallido de la operación de cambio de nombre para archivos, directorios y claves de registro

El problema se confirma en Windows 7/10 / Server 2019.

Descripción del problema

Este problema tiene dos subproblemas:

1. En los eventos generados por el sistema durante el cambio de nombre, el nuevo nombre del objeto no se fija en ningún lado.
2. El procedimiento de cambio de nombre es muy similar a la eliminación. Solo se puede distinguir por el hecho de que el primer evento con el código 4663, con el parámetro "AcessMask" = 0x10000 (DELETE) no tiene el evento 4660.

Vale la pena señalar que con respecto al registro, este problema se aplica solo a las claves. El cambio de nombre de los valores en el registro se describe mediante una secuencia de eventos 4657 y no causa tales quejas, aunque, por supuesto, sería mucho más conveniente si solo hubiera un evento.

¿Cuál es la esencia del problema?

Además de la dificultad de buscar operaciones de cambio de nombre de archivos, esta característica del registro en diario no permite el seguimiento del ciclo de vida completo de los objetos del sistema de archivos o las claves de registro. Como resultado, se vuelve extremadamente difícil determinar el historial de un archivo que ha sido renombrado muchas veces en un servidor de archivos utilizado activamente.

Problema número 4 (crítico). No se puede rastrear la creación de directorios y claves de registro

El problema se confirma en Windows 7/10 / Server 2019.

Descripción del problema

Windows no rastrea la creación de un directorio del sistema de archivos y una clave de registro. Esto consiste en el hecho de que el sistema operativo no genera un evento que contendría el nombre del directorio creado o la clave de registro, y cuyos parámetros indicarían que esta es la operación de creación.

Teóricamente, por signos indirectos, el hecho de crear un catálogo es posible. Por ejemplo, si se creó a través del "Explorador", durante el proceso de creación, se generarán eventos de sondeo para los atributos del nuevo directorio. El problema es que si crea un directorio a través del comando mkdir , no se genera ningún evento. Lo mismo es cierto para crear claves en el registro.

¿Cuál es la esencia del problema?

Este problema hace que sea muy difícil investigar los incidentes de seguridad de la información. No hay una explicación razonable para el hecho de que esta información no se registra en las revistas.

Problema número 5 (crítico). Configuración de auditoría incorrecta en versiones rusas de Windows

La presencia del problema se confirma en las ediciones rusas de Windows 7/10 / Server 2019.

Descripción del problema

Hay un error en las versiones rusas de Windows que hace que el sistema de gestión de auditoría de seguridad no funcione.

Síntomas

Cambiar las políticas de seguridad avanzadas no afecta la configuración de auditoría efectiva o, en otras palabras, las políticas no se aplican. Por ejemplo, el administrador activó la subcategoría "Iniciar sesión", reinició el sistema, ejecutó el auditpol /get /category:* y esta subcategoría permanece auditpol /get /category:* . El problema es relevante tanto para equipos de dominio administrados a través de políticas de grupo como para equipos que no son de dominio administrados usando un GPO local configurado a través del complemento Políticas de seguridad local.

Razones

El problema surge si el administrador ha activado al menos una de las subcategorías "fallidas" de las políticas de auditoría avanzadas. Tales categorías fallidas, en particular, incluyen:

1. Uso de derechos -> Auditar el uso de derechos que afectan los datos confidenciales. GUID: {0cce9228-69ae-11d9-bed3-505054503030}.
2. Uso de derechos -> Auditar el uso de derechos que no afectan los datos confidenciales. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
3. Acceso a objetos -> Auditar eventos creados por aplicaciones. GUID: {0cce9222-69ae-11d9-bed3-505054503030}.

Recomendaciones para resolver el problema.

Si el problema aún no se ha producido, no active las subcategorías "fallidas" indicadas. Si los eventos de estas subcategorías son muy necesarios, utilice la utilidad auditpol para activarlos o administre la auditoría utilizando políticas básicas.

Si ocurre un problema, debe:

1. Desde el directorio de directivas de grupo de dominio, elimine el archivo \ Machine \ microsoft \ windows nt \ Audit \ audit.csv
2. De todas las computadoras que tienen problemas con la auditoría, elimine los archivos:% SystemRoot% \ security \ audit \ audit.csv,% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv

¿Cuál es la esencia del problema?

La presencia de este problema reduce la cantidad de eventos de seguridad que se pueden monitorear regularmente a través de políticas de auditoría avanzadas, y también crea amenazas para desconectar, bloquear y desestabilizar la administración del sistema de auditoría en la red corporativa.

Problema número 6 (crítico). Maldición "Nuevo texto document.txt ... así como Nuevo bitmap.bmp"

El problema se ha confirmado en Windows 7. Falta el problema en Windows 10 / Server 2019.

Descripción del problema

Este es un problema muy extraño que fue descubierto por accidente. La esencia del problema es que el sistema operativo tiene un vacío que le permite evitar la auditoría de la creación de archivos.

Parte preparatoria:

1. Tome un Windows 7 recién instalado.
2. Restablezca todas las configuraciones de auditoría utilizando el auditpol /clear . Este artículo es opcional y sirve solo para la conveniencia de analizar revistas.
3. Configuramos la auditoría del sistema de archivos ejecutando auditpol /set /subcategory:" " .
4. Creemos el directorio C: \ TEST y asignemos parámetros de auditoría para la cuenta "Everything": "Crear archivos / Escribir datos", "Crear carpetas / Escribir datos", "Escribir atributos", "Escribir atributos adicionales", "Eliminar subcarpetas y archivos "," Eliminar "," Cambio de permisos "," Cambio de propiedad ", es decir, todo lo relacionado con la escritura de datos en el sistema de archivos.

Para mayor claridad, antes de cada experimento, borraremos el registro de seguridad del sistema operativo.

Experimento 1.
Nosotros hacemos:

Desde la línea de comando, ejecute el comando: echo > "c:\test\ .txt"
Observamos:

Tras la creación del archivo, apareció un evento con el código 4663 en el registro de seguridad que contiene el nombre del archivo que se está creando en el campo "ObjectName" y 0x2 en el campo "AccessMask" ("Escribir datos o agregar un archivo").



Para realizar los siguientes experimentos, borramos la carpeta y el registro de eventos.

Experimento 2.
Nosotros hacemos:

Abra la carpeta C: \ TEST a través del Explorador y use el menú contextual "Crear -> Documento de texto", llamado haciendo clic derecho, cree el archivo "Nuevo documento de texto.txt".



Observamos:

¡Esta acción no se reflejó en el registro de eventos! Además, no habrá entradas si se usa el mismo menú contextual para crear un "mapa de bits".



Experimento 3.
Nosotros hacemos:

Usando el Explorador, abra la carpeta C: \ TEST y usando el menú contextual "Crear -> Documento en formato RTF", llamado haciendo clic derecho, cree el archivo "Nuevo documento en formato RTF.rtf".

Observamos:

Como en el caso de la creación del archivo a través de la línea de comando, un evento con el código 4663 y el contenido correspondiente apareció en el registro.

¿Cuál es la esencia del problema?

Por supuesto, crear documentos de texto o imágenes no es particularmente dañino. Sin embargo, si el "Explorador" puede omitir el registro de las operaciones de archivos, entonces el malware podrá hacerlo.

Este problema es quizás el más significativo de todos los considerados, ya que socava seriamente la credibilidad de los resultados de la auditoría de las operaciones de archivos.

Conclusión

La lista de problemas anterior no es exhaustiva. En el proceso, logramos tropezar con un número aún bastante grande de varios defectos menores, que incluyen el uso de constantes localizadas como valores de parámetros para una serie de eventos, lo que nos obliga a escribir nuestros scripts de análisis para cada localización del sistema operativo, la división ilógica de los códigos de eventos en operaciones de significado cercano, por ejemplo, eliminar una clave de registro es una secuencia de eventos 4663 y 4660, y eliminar un valor en el registro es 4657, bueno, e incluso las pequeñas cosas ...

Para ser justos, observamos que a pesar de todas las deficiencias, el sistema de registro de eventos de seguridad en Windows tiene una gran cantidad de aspectos positivos. La solución de los problemas críticos enumerados aquí podría devolver la corona a una mejor solución para registrar eventos de seguridad fuera de la caja.

¡HAGA QUE EL EVENTO DE SEGURIDAD DE WINDOWS REGISTRE DE NUEVO!