Permitimos la recopilación de eventos sobre el lanzamiento de procesos sospechosos en Windows e identificamos amenazas usando Quest InTrust





Uno de los tipos más comunes de ataques es la generación de un proceso malicioso en un árbol bajo procesos bastante buenos. La ruta al archivo ejecutable puede causar sospechas: a menudo, el malware usa las carpetas AppData o Temp, lo cual es poco común en programas legítimos. Es justo decir que algunas utilidades de actualización automática se ejecutan en AppData, por lo que solo verificar la ubicación de inicio no es suficiente para afirmar que el programa es malicioso.



Un factor adicional de legitimidad es la firma criptográfica: muchos programas originales están firmados por el proveedor. Puede utilizar la ausencia de una firma como método para identificar elementos de inicio sospechosos. Pero, de nuevo, hay malware que usa un certificado robado para firmar.



También puede verificar el valor de los hash criptográficos MD5 o SHA256, que pueden corresponder a algún malware detectado previamente. Puede realizar un análisis estático mirando las firmas en el programa (usando reglas de Yara o productos antivirus). Y luego está el análisis dinámico (lanzar un programa en un entorno seguro y rastrear sus acciones) y la ingeniería inversa.



Puede haber muchos signos de un proceso malicioso. En este artículo, describiremos cómo habilitar la auditoría de los eventos correspondientes en Windows, analizaremos las señales en las que se basa la regla de InTrust incorporada para identificar un proceso sospechoso. InTrust es una plataforma CLM para recopilar, analizar y almacenar datos no estructurados, que ya contienen cientos de respuestas predefinidas a varios tipos de ataques.



Cuando se inicia un programa, se carga en la memoria de la computadora. El archivo ejecutable contiene instrucciones de computadora y bibliotecas auxiliares (por ejemplo, * .dll). Cuando un proceso ya se está ejecutando, puede crear subprocesos adicionales. Los subprocesos permiten que un proceso ejecute diferentes conjuntos de instrucciones al mismo tiempo. Hay muchas formas en que el código malicioso puede penetrar en la memoria y ejecutarla, veamos algunas de ellas.



La forma más fácil de iniciar un proceso malicioso es forzar al usuario a que lo inicie directamente (por ejemplo, desde un archivo adjunto de correo electrónico), luego use la tecla RunOnce para iniciarlo cada vez que encienda la computadora. Esto también incluye malware "sin archivos" que almacena scripts de PowerShell en claves de registro que se ejecutan en función de un disparador. En este escenario, el script de PowerShell es un código malicioso.



El problema de ejecutar software malintencionado de forma explícita es que es un método conocido y se detecta fácilmente. Algunos programas maliciosos hacen cosas más sutiles, como utilizar un proceso diferente para comenzar a ejecutarse en la memoria. Por lo tanto, un proceso puede crear otro proceso ejecutando una instrucción de computadora específica y especificando un archivo ejecutable (.exe) para ejecutar.



El archivo se puede especificar utilizando una ruta completa (por ejemplo, C: \ Windows \ system32 \ cmd.exe) o una ruta incompleta (por ejemplo, cmd.exe). Si el proceso original no es seguro, permitirá que se ejecuten programas ilegítimos. El ataque puede verse así: el proceso lanza cmd.exe sin especificar la ruta completa, el atacante coloca su cmd.exe en tal lugar para que el proceso lo inicie antes que el legítimo. Después de iniciar un programa malicioso, este, a su vez, puede iniciar un programa legítimo (por ejemplo, C: \ Windows \ system32 \ cmd.exe) para que el programa original siga funcionando correctamente.



Una variación del ataque anterior es la inyección de DLL en un proceso legítimo. Cuando se inicia un proceso, encuentra y carga bibliotecas que amplían su funcionalidad. Mediante la inyección de DLL, un atacante crea una biblioteca maliciosa con el mismo nombre y API que la legítima. El programa descarga una biblioteca maliciosa y, a su vez, descarga una legítima y, según sea necesario, para realizar operaciones, la llama. La biblioteca maliciosa comienza a actuar como proxy de la biblioteca buena.



Otra forma de guardar código malicioso en la memoria es insertarlo en un proceso inseguro que ya se está ejecutando. Los procesos reciben información de varias fuentes: leen de la red o de archivos. Por lo general, verifican para asegurarse de que la entrada sea legítima. Sin embargo, algunos procesos no están protegidos adecuadamente al ejecutar instrucciones. En tal ataque, no hay una biblioteca en el disco o un archivo ejecutable con código malicioso. Todo se almacena en la memoria junto con el proceso que se explota.



Ahora veamos la metodología para habilitar la recopilación de tales eventos en Windows y con la regla en InTrust, que implementa protección contra tales amenazas. Primero, lo activamos a través de la consola de administración de InTrust.



imagen



La regla utiliza las capacidades de seguimiento de procesos de Windows. Desafortunadamente, la inclusión de la colección de tales eventos está lejos de ser evidente. Debe cambiar 3 configuraciones diferentes de la Política de grupo:



Configuración del equipo> Políticas> Configuración de Windows> Configuración de seguridad> Políticas locales> Política de auditoría> Seguimiento del proceso de auditoría



imagen



Configuración del equipo> Políticas> Configuración de Windows> Configuración de seguridad> Configuración avanzada de la política de auditoría> Políticas de auditoría> Seguimiento detallado> Creación de procesos de auditoría



imagen



Configuración del equipo> Políticas> Plantillas administrativas> Sistema> Creación de procesos de auditoría> Incluir línea de comando en eventos de creación de procesos



imagen



Una vez habilitadas, las reglas de InTrust permiten detectar amenazas previamente desconocidas,que exhiben un comportamiento sospechoso. Por ejemplo, puede identificarel malware Dridex descrito aquí . Gracias al proyecto HP Bromium, sabemos cómo funciona esa amenaza.



imagen



Dridex usa schtasks.exe en su cadena de acciones para crear una tarea programada. El uso de esta utilidad en particular desde la línea de comandos se considera un comportamiento muy sospechoso, de manera similar al iniciar svchost.exe con parámetros que apuntan a carpetas de usuario o con parámetros similares a los comandos "net view" o "whoami". Aquí hay un fragmento de la regla SIGMA correspondiente :



detection:
    selection1:
        CommandLine: '*\svchost.exe C:\Users\\*\Desktop\\*'
    selection2:
        ParentImage: '*\svchost.exe*'
        CommandLine:
            - '*whoami.exe /all'
            - '*net.exe view'
    condition: 1 of them


En InTrust, todos los comportamientos sospechosos están incluidos en una regla, porque la mayoría de estas acciones no son específicas de una amenaza específica, sino que son sospechosas en un complejo y en el 99% de los casos se utilizan para fines no del todo nobles. Esta lista de acciones incluye, pero no se limita a:



  • Procesos que se ejecutan desde ubicaciones inusuales, como carpetas temporales personalizadas.
  • Proceso del sistema conocido con herencia sospechosa: algunas amenazas pueden intentar usar el nombre de los procesos del sistema para pasar desapercibidas.
  • Ejecución sospechosa de herramientas administrativas como cmd o PsExec cuando utilizan credenciales del sistema local o herencia sospechosa.
  • — - , :



    — vssadmin.exe;

    — WMI.
  • .
  • , at.exe.
  • net.exe.
  • netsh.exe.
  • ACL.
  • BITS .
  • WMI.
  • .
  • .


La regla combinada funciona muy bien para detectar amenazas como RUYK, LockerGoga y otros virus ransomware, malware y juegos de herramientas para ciberdelitos. La regla ha sido verificada por el proveedor en entornos de producción para minimizar los falsos positivos. Y gracias al proyecto SIGMA, la mayoría de estos indicadores producen el número mínimo de eventos de ruido.



Porque en InTrust, esta es una regla de monitoreo, puede ejecutar un script de respuesta como reacción a una amenaza. Puede utilizar uno de los scripts integrados o crear uno propio e InTrust lo distribuirá automáticamente.



imagen



Además, puede verificar toda la telemetría relacionada con el evento: scripts de PowerShell, ejecución de procesos, manipulación de tareas programadas, actividad administrativa de WMI y utilizarlos para postmortems en incidentes de seguridad.



imagen



InTrust tiene cientos de otras reglas, algunas de las cuales son:



  • Identificar un ataque de PowerShell a una versión anterior, cuando alguien usa deliberadamente una versión anterior de PowerShell porque la versión anterior no tenía la capacidad de auditar lo que estaba sucediendo.
  • Detección de inicio de sesión con privilegios elevados: cuando las cuentas que son miembros de un grupo privilegiado en particular (por ejemplo, administradores de dominio) inician sesión interactivamente en las estaciones de trabajo por accidente o debido a incidentes de seguridad.


InTrust permite las mejores prácticas de seguridad en forma de reglas de detección y respuesta predefinidas. Y si cree que algo debería funcionar de manera diferente, puede hacer su propia copia de la regla y configurarla según sea necesario. Puede enviar una solicitud para un piloto o recibir distribuciones con licencias temporales a través del formulario de comentarios en nuestro sitio web.



Suscríbete a nuestra página en Facebook , publicamos notas breves y enlaces interesantes allí.



Lea nuestros otros artículos sobre el tema de la seguridad de la información:



Cómo InTrust puede ayudar a reducir la frecuencia de los intentos de autorización fallidos a través de RDP Detectar un ataque de ransomware, obtener



acceso a un controlador de dominio y tratar de resistir estos ataques



Qué es útil obtener de los registros de una estación de trabajo de Windows (artículo popular)



Seguimiento del ciclo de vida de los usuarios sin alicates ni cinta adhesiva ¿



Y quién lo hizo? Automatizamos la auditoría de seguridad de la información



Cómo reducir el costo de propiedad de un sistema SIEM y por qué necesita Central Log Management (CLM)



All Articles