La estación de trabajo del usuario es el lugar más vulnerable de la infraestructura en términos de seguridad de la información. 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 utilidad útil para el trabajo desde un lugar desconocido. Se pueden imaginar varios casos de cómo el malware puede infiltrarse en los recursos internos a través de los usuarios. Por lo tanto, las estaciones de trabajo requieren una atención especial, y en este artículo, explicaremos de dónde y qué eventos deben rastrearse para detectar ataques.
Para detectar un ataque en la etapa más temprana en sistemas operativos Windows, hay tres fuentes de eventos útiles: el registro de eventos de seguridad, el registro de monitoreo del sistema y los registros de Power Shell.
Registro de eventos de seguridad (Security Log)
Este es el principal lugar de almacenamiento de los registros de seguridad del sistema. Aquí se almacenan los eventos de inicio/cierre de sesión de los usuarios, acceso a objetos, cambios en políticas y otras actividades relacionadas con la seguridad. Por supuesto, esto es válido si se ha configurado la política correspondiente.
Enumeración de usuarios y grupos (eventos 4798 y 4799). El malware, al principio del ataque, a menudo está buscando cuentas de usuario locales y grupos locales en la estación de trabajo para encontrar credenciales para sus oscuros propósitos. Estos eventos ayudarán a detectar el código malicioso antes de que progrese y, utilizando los datos recopilados, se propague a otros sistemas.
Creación de cuenta local y cambios en grupos locales (eventos 4720, 4722-4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 y 5377). El 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 ingresan con una cuenta de dominio, y la detección de un inicio de sesión con una cuenta local puede significar el comienzo de un ataque. El evento 4624 también incluye inicios de sesión con una cuenta de dominio, por lo que al procesar los eventos hay que 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 ocurre cuando el proceso se ejecuta en modo 'Ejecutar como'. No debería haber tales eventos en un modo de operación normal del sistema, por lo que estos eventos deben ser monitoreados.
Bloqueo/desbloqueo de estaciones de trabajo (eventos 4800-4803). Se pueden considerar sospechosos cualquier acción que ocurriera en una estación de trabajo bloqueada.
Cambios en la configuración del firewall (eventos 4944-4958). Es evidente que al instalar 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 esos cambios, pero es bueno estar al tanto de ellos.
Conexión de dispositivos Plug’n’play (evento 6416 y solo para Windows 10). Esto es importante de monitorear 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 más detallada. El conjunto mínimo de subcategorías que hay que 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íticas
- Cambio de política de auditoría;
- Cambio de política de autenticación;
- Cambio de política de autorización.
Monitor del sistema (Sysmon)
Sysmon es una herramienta integrada en Windows que puede registrar eventos en el registro del sistema. Generalmente, requiere instalación separada.
Estos eventos también se pueden encontrar en el registro de seguridad (activando la política de auditoría necesaria), pero Sysmon proporciona más detalles. ¿Qué eventos se pueden extraer de Sysmon?
Creación de procesos (ID de evento 1). El registro del sistema de eventos de seguridad también puede indicar cuándo se inició algún *.exe y mostrará su nombre y ruta de ejecución. Pero a diferencia de Sysmon, no puede mostrar el hash de la aplicación. Un malware puede llamarse incluso como un inofensivo notepad.exe, pero el hash lo desenmascarará.
Conexiones de red (ID de evento 3). Es obvio que hay muchas conexiones de red y no se pueden monitorear todas. 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 añadirte al inicio automático es registrarte en el registro. Security Log puede hacerlo, pero Sysmon muestra quién realizó los cambios, cuándo, desde dónde, el ID de 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 supervisar todo, pero se pueden auditar ciertos directorios.
Y ahora lo que no hay en las políticas de Security Log, pero sí en Sysmon:
Cambio en la fecha de creación del archivo (ID de evento 2). Algunos programas maliciosos pueden cambiar la fecha de creación del archivo para ocultarlo de los informes sobre 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 monitorizado.
Eventos RawAccessRead (ID de evento 9). Operaciones de lectura desde el disco mediante “.”. En la gran mayoría de los casos, esta actividad debe considerarse anormal.
Creación de un flujo de archivo con nombre (ID de evento 15). El evento se registra cuando se crea un flujo de archivo con nombre 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 un named pipe.
Actividad de WMI (ID de evento 19). Registro de eventos generados al acceder al sistema a través del protocolo WMI.
Para proteger Sysmon mismo, es necesario seguir los eventos con ID 4 (detención y arranque de Sysmon) y ID 16 (cambio de configuración de Sysmon).
Registros de Power Shell
Power Shell es una potente herramienta de gestión de infraestructura de Windows, por lo que es muy probable que un atacante elija precisamente esta. Para obtener datos sobre los eventos de Power Shell, se pueden utilizar dos fuentes: el registro de Windows PowerShell y el registro de Microsoft-WindowsPowerShell / Operational.
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 visualizarlos y gestionarlos. Por ejemplo, los proveedores integrados pueden incluir variables de entorno de Windows o el registro del sistema. Es importante estar atento a la aparición de nuevos proveedores para detectar actividad maliciosa a tiempo. Por ejemplo, si observa 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 / Operacional en PowerShell 6)
Registro de módulos (ID de evento 4103). Los eventos contienen información sobre cada comando ejecutado y los parámetros con los que se invocó.
Registro de bloqueo de scripts (ID de evento 4104). El registro de bloqueo de scripts muestra cada bloque de código PowerShell ejecutado. Incluso si un atacante intenta ocultar el comando, este tipo de evento mostrará el comando de PowerShell que se ejecutó realmente. Además, en este tipo de evento se pueden registrar algunas llamadas a la API de bajo nivel que se ejecutan, estas 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 para la 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 recopila para la auditoría de seguridad de la información y qué herramientas utiliza para ello. Uno de nuestros enfoques son las soluciones para la auditoría de eventos de seguridad de la información. Para la tarea de recopilación y análisis de registros, podemos proponer considerar , que puede comprimir los datos almacenados con una tasa de 20:1, y una de sus instancias instaladas puede procesar hasta 60,000 eventos por segundo de 10,000 fuentes.
Fuente: habr.com
