La estación de trabajo del usuario es el lugar más vulnerable de la infraestructura en términos de ciberseguridad. Los usuarios pueden recibir un correo electrónico en su bandeja de entrada que parece provenir de una fuente segura, pero contiene un enlace a un sitio infectado. Es posible que alguien descargue una herramienta útil para su trabajo desde una fuente desconocida. Se podrían imaginar decenas de casos de cómo el software malicioso puede infiltrarse en los recursos corporativos a través de los usuarios. Por lo tanto, las estaciones de trabajo requieren atención especial, y en este artículo contaremos de dónde y qué eventos se deben monitorear para detectar ataques.
Para detectar un ataque en su fase más temprana, hay tres fuentes de eventos útiles en el sistema operativo Windows: el registro de eventos de seguridad, el registro de monitoreo del sistema y los registros de PowerShell.
Registro de eventos de seguridad (Security Log)
Este es el principal lugar donde se almacenan los registros del sistema relacionados con la seguridad. Aquí se registran eventos de inicio/cierre de sesión de usuarios, accesos a objetos, cambios en las políticas y otras actividades relacionadas con la seguridad. Por supuesto, siempre que se haya configurado la política adecuada.
Enumeración de usuarios y grupos (eventos 4798 y 4799). El software malicioso, al inicio de un ataque, frecuentemente intenta enumerar las cuentas de usuario locales y los grupos locales en la estación de trabajo para encontrar credenciales para sus oscuros propósitos. Estos eventos ayudan a detectar el código malicioso antes de que avance más y, utilizando la información recopilada, se propague a otros sistemas.
Creación de cuentas de usuario locales y cambios en grupos locales (eventos 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 y 5377). Un ataque también puede comenzar, por ejemplo, con la adición de un nuevo usuario al grupo de administradores locales.
Intentos de inicio de sesión con una cuenta local (evento 4624). Los usuarios legítimos inician sesión con cuentas de dominio, y la detección de un inicio de sesión con una cuenta local puede indicar el inicio de un ataque. El evento 4624 también incluye inicios de sesión con cuentas de dominio, por lo que al procesar los eventos es necesario filtrar aquellos en los que el dominio difiere del nombre de la estación de trabajo.
Intento de inicio de sesión con una cuenta específica (evento 4648). Esto sucede cuando el proceso se ejecuta en modo 'Ejecutar como'. En el modo de operación normal del sistema, esto no debería ocurrir, por lo que tales eventos deberían estar bajo control.
Bloqueo/desbloqueo de la estación de trabajo (eventos 4800-4803). Se pueden considerar sospechosos cualquier acción que ocurra en una estación de trabajo bloqueada.
Cambios en la configuración del firewall (eventos 4944-4958). Es evidente que al instalar un nuevo software, la configuración del firewall puede cambiar, lo que provocará falsas alarmas. En la mayoría de los casos, no es necesario controlar dichos cambios, pero no está de más saber sobre ellos.
Conexión de dispositivos Plug’n’play (evento 6416 y solo para Windows 10). Es importante vigilar esto si los usuarios normalmente no conectan nuevos dispositivos a la estación de trabajo y de repente lo hacen.
Windows incluye 9 categorías de auditoría y 50 subcategorías para una configuración detallada. El conjunto mínimo de subcategorías que vale la pena habilitar en la configuración es:
Inicio/Cierre de sesión
- Inicio de sesión;
- Cierre de sesión;
- Bloqueo de cuenta;
- Otros eventos de inicio/cierre de sesión.
Gestión de cuentas
- Gestión de cuentas de usuario;
- Gestión de grupos de seguridad.
Cambio de política
- Cambio de política de auditoría;
- Cambio de política de autenticación;
- Cambio de política de autorización.
Monitor de sistema (Sysmon)
Sysmon es una utilidad integrada en Windows que puede registrar eventos en el registro del sistema. Por lo general, requiere que se instale por separado.
Estos mismos eventos se pueden encontrar en el registro de seguridad (activando la política de auditoría necesaria), pero Sysmon ofrece más detalles. ¿Qué eventos se pueden extraer de Sysmon?
Creación de procesos (ID de evento 1). El registro de eventos de seguridad también puede indicar cuándo se ejecutó un archivo *.exe y mostrar su nombre y ruta de ejecución. Pero a diferencia de Sysmon, no puede mostrar el hash de la aplicación. El malware puede llamarse incluso notepad.exe inofensivo, pero el hash lo delatará.
Conexiones de red (ID de evento 3). Es evidente que hay muchas conexiones de red, y no se puede vigilar todo. Pero es importante tener en cuenta que Sysmon, a diferencia del registro de seguridad, puede vincular la conexión de red a los campos ProcessID y ProcessGUID, mostrando el puerto y IP el origen y el receptor.
Cambios en el registro del sistema (ID de evento 12-14). La forma más sencilla de agregarte al inicio automático es registrarte en el registro. Security Log puede hacerlo, pero Sysmon muestra quién hizo los cambios, cuándo, desde dónde, el ID del proceso y el valor anterior de la clave.
Creación de archivo (ID de evento 11). A diferencia de Security Log, Sysmon mostrará no solo la ubicación del archivo, sino también su nombre. Es obvio que no se puede controlar todo, pero se pueden auditar ciertos directorios.
Y ahora lo que no está en las políticas de Security Log, pero sí en Sysmon:
Cambio de la hora de creación del archivo (ID de evento 2). Algunos malware pueden modificar la fecha de creación de un archivo para ocultarlo de los informes de archivos creados recientemente.
Carga de controladores y bibliotecas dinámicas (ID de eventos 6-7). Seguimiento de la carga en memoria de DLL y controladores de dispositivos, verificación de la firma digital y su validez.
Creación de un hilo en un proceso en ejecución (ID de evento 8). Uno de los tipos de ataque que también necesita ser monitoreado.
Eventos RawAccessRead (ID de evento 9). Operaciones de lectura en disco utilizando "..". En la gran mayoría de los casos, tal actividad debe considerarse anormal.
Creación de un flujo de archivo nombrado (ID de evento 15). El evento se registra cuando se crea un flujo de archivo nombrado que genera eventos con el hash del contenido del archivo.
Creación de un named pipe y conexiones (ID de eventos 17-18). Seguimiento del código malicioso que se comunica con otros componentes a través de named pipe.
Actividad por WMI (ID de evento 19). Registro de eventos generados al acceder al sistema mediante el protocolo WMI.
Para proteger a Sysmon mismo, es necesario monitorear eventos con ID 4 (detención y inicio de Sysmon) e ID 16 (modificación de la configuración de Sysmon).
Registros de Power Shell
Power Shell es una poderosa herramienta de gestión de infraestructura Windows, por lo que hay grandes posibilidades de que el atacante elija precisamente esto. Para obtener datos sobre eventos de Power Shell se pueden utilizar dos fuentes: el registro de Windows PowerShell y el registro operativo de Microsoft-WindowsPowerShell.
Registro de Windows PowerShell
Proveedor de datos cargado (ID de evento 600). Los proveedores de PowerShell son programas que sirven como fuentes de datos para PowerShell, permitiendo su visualización y gestión. Por ejemplo, los proveedores integrados pueden incluir variables de entorno de Windows o el registro del sistema. Es importante monitorear la aparición de nuevos proveedores para identificar actividades maliciosas a tiempo. Por ejemplo, si nota que ha aparecido WSMan entre los proveedores, significa que se ha iniciado una sesión remota de PowerShell.
Registro operativo de Microsoft-WindowsPowerShell (o MicrosoftWindows-PowerShellCore / Operativo en PowerShell 6)
Registro de módulos (ID de evento 4103). Los eventos almacenan información sobre cada comando ejecutado y los parámetros con los que fue invocado.
Registro de bloqueo de scripts (ID de evento 4104). El registro de bloqueo de scripts muestra cada bloque de código de PowerShell ejecutado. Incluso si un atacante intenta ocultar el comando, este tipo de evento mostrará el comando de PowerShell que realmente se ejecutó. Además, en este tipo de evento pueden registrarse algunas llamadas a la API de bajo nivel que se ejecutan, y estos eventos generalmente se registran como Verbose, pero si se utiliza un comando o script sospechoso en el bloque de código, se registrará con una gravedad de Warning.
Tenga en cuenta que después de configurar la herramienta de recopilación y análisis de estos eventos, se requerirá tiempo adicional para depurar y reducir la cantidad de falsos positivos.
Comparta en los comentarios qué registros está recopilando para la auditoría de seguridad de la información y qué herramientas utiliza para ello. Una de nuestras áreas es la solución de auditoría de eventos de seguridad de la información. Para abordar la tarea de recopilación y análisis de registros, podemos sugerir considerar , que puede comprimir los datos almacenados con una tasa de 20:1, y un solo ejemplar instalado puede procesar hasta 60,000 eventos por segundo de 10,000 fuentes.
Fuente: habr.com
