Detección del «próximo» ataque cibernético al estilo de SolarWinds

El ataque de SolarWinds, que tuvo éxito al utilizar el malware sunburst, conmocionó a la industria de la seguridad cibernética. Este ataque logró persistencia y pudo evadir los sistemas internos el tiempo suficiente para obtener acceso al código fuente de la víctima.

Debido a las implementaciones de SolarWinds de gran alcance, los perpetradores también pudieron infiltrarse en muchas otras organizaciones, en busca de propiedad intelectual y otros activos.

Entre las co-víctimas: gobierno de los EE. UU., contratistas del gobierno, empresas de tecnología de la información y ONG. Se robó una cantidad increíble de datos confidenciales de varios clientes después de que se instalara una versión troyana de la aplicación de SolarWinds en sus estructuras internas.

En cuanto a las capacidades técnicas del malware, como verá, este ataque en particular fue bastante impresionante. Un archivo en particular, llamado SolarWinds.Orion.Core.BusinessLayer.dll es un componente firmado digitalmente de SolarWinds del marco de software de Orion.

Los actores de amenazas instalaron una puerta trasera que se comunica a través de HTTP con servidores de terceros. Después de un período inactivo inicial de hasta dos semanas, recupera y ejecuta comandos, llamados «Trabajos», que incluyen la capacidad de transferir archivos, ejecutar archivos, perfilar el sistema, reiniciar la máquina y deshabilitar los servicios del sistema.

Entonces, ¿cómo se podría proteger a la organización de Sunburst o un ataque similar? Los ataques a la cadena de suministro tienen la ventaja de establecer un punto de apoyo inicial bajo la apariencia de un tercero de confianza. Pero ahí es donde termina la distinción; a partir de ahí progresan como cualquier otro ataque, y pueden ser detectados si sabemos dónde buscar.

Desarrollo de reglas SIEM, usando el ataque de SolarWinds como ejemplo

Comencemos con las reglas Sigma; estos crean una especie de lenguaje común para crear y compartir consultas de calidad independientemente del SIEM que utilice su organización. La plataforma Cymulate producirá reglas Sigma para que descargue estas consultas a su SIEM. Esto permitirá a los equipos de operaciones de seguridad desarrollar los elementos necesarios para detectar futuros ataques. Como puede ver a continuación en los 3 ejemplos, la regla Sigma es la misma, pero la consulta personalizada es específica para el idioma de ese SIEM. Con solo hacer clic en un botón, puede cambiar a su SIEM preferido.

Ejemplo 1: Splunk:

Ejemplo 2: Radar:

Ejemplo 3: Azure Sentinel:

Aunque las reglas Sigma están diseñadas principalmente para consultas, se pueden usar para crear una regla SIEM o EDR de cadena antiataque completa. En el caso del ataque SolarWinds Sunburst y muchos otros ataques, las reglas de Cymulate Sigma son consultas que buscan las IOB del ataque. Cada regla sigma consultará al SIEM por un IOB de una etapa del ataque.

Cuando se combinan los IOB de las reglas sigma, pueden dar como resultado una regla específica para el sistema de destino, algo que puede, con un alto grado de confianza, señalar el ataque sin «inventar la rueda» nuevamente. Todos los IOB requeridos están en su lugar, en las reglas de Sigma, solo necesita extender la mano y tomarlos.

Veamos el caso específico de un ataque de SolarWinds recreado en la plataforma Windows y busquémoslo juntos.

Cazando SolarWinds en Microsoft Windows

La plataforma Cymulate nos brinda la capacidad de replicar el ataque a la cadena de suministro, que comienza con una exportación del buzón del servidor de Exchange. Las etapas posteriores del ataque, disponibles en la plataforma Cymulate para simular el ataque, se pueden ver en la captura de pantalla.

Windows no activará el primer evento, pero se escribirá en varios registros de red. Dado que el evento en sí no puede ser muy específico, lo dejaremos como opcional para su ubicación en una regla general. Continuemos.

El siguiente evento del ataque es la descarga de contenido con PowerShell. Tal evento se puede monitorear con los ID de evento de Windows 4103 y 4104, que también pueden mostrar el código real que se está ejecutando, pero no queremos limitarnos a un método específico porque, seamos sinceros: PowerShell no es la única herramienta atacante puede utilizar.

Lo que es común a todas las herramientas es que al descargar contenido, se crea un objeto en el sistema, y ​​para eso, existe un Windows Event ID 4663 con un indicador de Máscara de acceso 0x1 o, si usa Sysmon, Event ID 11.

A continuación se muestra una captura de pantalla general de un ID de evento 4663 con los campos relevantes resaltados. Este es el evento que detecta la regla Cymulate Sigma, y ​​también es el primer IOB en la regla que crearemos. Puede encontrar más información sobre este ID de evento aquí.

El siguiente en la línea es la siguiente etapa en el ataque: Programador de tareas: Tareas enmascaradas activadas en la pantalla de bloqueo de Windows para movimiento lateral. Una vez más, es irrelevante exactamente qué Tareas se están enmascarando; lo importante es que existen identificadores de eventos de Windows que pueden ayudarnos a identificar esta cadena de eventos.

Los ID del evento son:

4698 – tarea creada

4700 – Tarea programada habilitada.

4702 – Tarea programada actualizada.

4699 – Tarea programada eliminada.

Lo que es relevante para nosotros es, por supuesto, 4698, ya que aparecerá cuando se cree una nueva tarea. Los eventos de actualización, habilitación y/o eliminación de una tarea son una buena mejora pero opcional. Personalmente, recomendaría agregar una opción de 4699, ya que siempre existe la posibilidad de que el atacante desee eliminar la tarea después de completarla para cubrir sus huellas.

Entonces, lo que querremos para los requisitos mínimos es 4698 con un conjunto de expresiones regulares específicas en el campo «Comando» en caso de que coincidan con tipos de ejecutables conocidos, por ejemplo:

– ‘.exe’ – ‘.py -‘ .ps1 ‘-‘ .msi – ‘.msp’ – ‘.mst’ – ‘.ws’ -‘ .wsf ‘-‘ .vb ‘-‘ .vbs’ – ‘ .jst ‘-‘ .cmd ‘-‘ .cpl ‘

Para casos complejos, se pueden usar expresiones regulares, como las siguientes:

  1. – ‘^ ([A-Za-z0-9+/]{4}) * ([A-Za-z0-9+/]{3} = |[A-Za-z0-9+/]{2} ==)? $ ‘
  2. – ‘^ ([A-Za-z0-9 /]{4}) * ([A-Za-z0-9 /]{3} = |[A-Za-z0-9 /]{2} ==)? $ ‘

Preste especial atención a los dos últimos IOB (regexes): estos coinciden con un patrón base64. Aunque «Tarea programada» recibe una cadena como entrada, es posible escribir en ella una forma ofuscada/encriptada de un comando. Por ejemplo, «python» como comando y «base64.b64decode (algo de carga útil base64) «como argumento, convirtiendo así su tarea en una herramienta de» decodificación de carga útil base64 «.

Una vez más, todos los indicadores se pueden encontrar en las Reglas Sigma proporcionadas por Cymulate. Llamaremos a esta lista y otras próximas listas de IOB simplemente «lista de IOB relevante» por conveniencia. A continuación se muestra la vista general del ID de evento 4698 de la creación de una nueva tarea.

Entonces, por ahora, hemos cubierto dos eventos en la cadena. Estos deben ocurrir en la misma máquina y con el mismo nombre de usuario. Después de eso, se ejecutará el proceso en su tarea, lo que resultará en 4688 ID de evento con nombre de proceso de creador: TaskScheduler o TaskScheduler.dll o taskeng.exe (según la versión de compilación que use), y Nuevo nombre de proceso tendrá uno de esos IOB en la lista de ejecutables. Entonces, en esta etapa, nuestra regla se ve así:

(4663 + Máscara de acceso 0x1) 🡪 (4698 y lista de IOB relevantes) 🡪 (4688 + lista de nombres de procesos creadores relevantes + lista de IOB relevantes como parte del nombre del nuevo proceso)

CORCEL

4663 + Máscara de acceso 0x1 o Sysmon 11) 🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe))]

El signo 🡪 representa la operación «seguido por»

La siguiente etapa del ataque es ejecutar el archivo DLL con rundll32. Este es un IOB simple que, por cierto, también se puede ejecutar en un paso anterior. En este caso específico es 4688 + rundll.32

El siguiente es ADFind: enumeración de un grupo de AD mediante ADFind enmascarado como csrss.exe. Este paso es un poco complicado. Durante este paso, un atacante enmascara su herramienta de enumeración como un archivo legítimo. Sin embargo, antes de que esto suceda, el archivo ilegítimo debe escribirse en algún lugar de una de sus unidades (preferiblemente en la carpeta del sistema) con el nombre legítimo.

En este caso específico es csrss.exe, pero hay una gran cantidad de nombres de archivo que podrían usarse para el mismo propósito, por ejemplo:

– ‘svchost.exe’. -rundll32.exe. – servicios.exe. -powershell.exe. -regsvr32.exe. – spoolsv.exe

– lsass.exe. – smss.exe. -csrss.exe. -conhost.exe. -wininit.exe. -winlogon.exe. – explorer.exe

– taskhost.exe. – Taskmgr.exe. -sihost.exe -RuntimeBroker.exe -smartscreen.exe.

Nuevamente, no es necesario buscarlos todos, ya se proporcionan en la regla Sigma relevante.

A continuación se muestra un ejemplo de una posible regla Sigma para este paso específico, que detecta la creación de un archivo con uno de los nombres especificados anteriormente. Pero con un hash diferente al original. Ya sea que se anule un archivo del sistema o se cree una nueva ruta, el resultado seguirá siendo un ID de evento 4663 (o un ID de evento de Sysmon 11), y uno de los nombres a continuación se encontrará en la carga útil.

Trabajar con archivos del sistema también requiere acceso privilegiado, por lo que inevitablemente habrá una escalada de privilegios, que también se documenta como 4688 ID de evento (acceso a archivos) y tipo de elevación de token de %% 1936 o %% 1937, que son tipos para el acceso del administrador y del sistema. respectivamente.

A continuación se muestra una captura de pantalla del ID de evento 4688 con los campos relevantes resaltados.

Opcionalmente, puede buscar el ID de evento 4672 con cualquiera de las cadenas de escalada de privilegios, pero el evento de escalada de privilegios puede ocurrir en cualquier paso del ataque. Recomendamos una regla separada para esto, que debe estar correlacionada con la regla que estamos construyendo.

Echemos un vistazo a nuestra regla en esta etapa:

(4663 + Máscara de acceso 0x1 o Sysmon 11) 🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe)) 🡪 (4688 and rundll32) 🡪 (4663 or Sysmon 11 + generic list of system files) 🡪 (4688 and 1 of files in list and Token Elevation Type (%%1936 OR %%1937))]

El siguiente paso es «Ejecute PowerShell codificado en base64 desde el Registro de WindowsLo que sucede aquí es que un atacante ejecuta un código ofuscado previamente escrito en un valor de registro. Como puede comprender, antes de poder hacer esto, necesita crear un nuevo valor de registro o modificar uno existente.

Un ID de evento de Windows 4657 y un patrón base64 que coincida con el valor (que se puede identificar con expresiones regulares que ya vimos en un paso anterior) pueden ayudar a identificar este paso. El evento puede incluir «Valor de registro existente modificado» o «Creación de nuevo valor de registro» como el Tipo de operación. Todos los IOB, como se mencionó anteriormente, se pueden obtener de las Reglas Sigma suministradas.

Este evento puede mostrarle otra información valiosa, como:

1) Qué clave estaba involucrada.

El formato es: REGISTROHIVERUTA donde:

COLMENA:

  • HKEY_LOCAL_MACHINE = REGISTROMAQUINA
  • HKEY_CURRENT_USER = REGISTROUSUARIO[USER_SID]donde [USER_SID] es el SID del usuario actual.
  • HKEY_CLASSES_ROOT = REGISTROMAQUINASOFTWAREClases
  • HKEY_USERS = REGISTROUSUARIO
  • HKEY_CURRENT_CONFIG = REGISTRO MÁQUINA SISTEMA ControlSet001 Perfiles de hardware Actual

2) Cuál es el proceso de origen.
3) ¿Cuál es el valor antiguo y el valor nuevo?

    A continuación puede ver una representación general de 4657 ID de evento.

    Teniendo en cuenta los posibles marcos de tiempo, dado que toda la operación probablemente estará programada, podemos decir con seguridad que, si tiene éxito, los pasos 2 a 6 no llevarán más de 5 segundos. La cadena completa hasta la ejecución del código almacenado en el registro no podía durar más de 10 minutos.

    Después de agregar esas variables, lo que tenemos es una cadena de eventos que se pueden correlacionar:

    1. Todo se originará en una máquina.
    2. Se iniciará como el mismo usuario.
    3. La regla operativa se verá como la siguiente:

    {

    (4663 + Máscara de acceso 0x1 o Sysmon 11) 🡪

    [ (4698 + relevant IOB list) 🡪

    (4688+(TaskScheduler.dll or taskeng.exe)) 🡪

    (4688 and rundll32) 🡪

    (4663 or Sysmon 11 + generic list of system files) 🡪

    (4688 and 1 of files in list and Token Elevation Type(%%1936 OR %%1937))🡪 (4657 +New value created OR existing value modified+ base64 matching pattern in value in time frame up to 5s)]

    en un marco de tiempo de 10 minutos

    }

    Entonces, si ha creado esta regla SIEM o EDR, utilizando las reglas Sigma proporcionadas por Cymulate, y ve una alerta, es muy probable que esté experimentando el ataque de SolarWinds en este momento.

    Si aún tiene dudas, siempre puede agregar algunas etapas opcionales y mejorarlas aún más agregando dos etapas siguientes a la regla. Estos son Limpieza de exportación de buzones de Exchange Server y Exfiltración de intercambio mediante solicitud HTTP básicarespectivamente.

    Aunque Windows no tiene un ID de evento integrado para solicitudes HTTP/S, siempre habrá {4660 en el buzón🡪 (solicitud HTTP + 4663 de nombre de archivo.zip/rar/tar/otro)}. Para obtener un evento de solicitudes HTTP / S, los sistemas adicionales, por ejemplo, un sistema de análisis de tráfico de red, pueden ayudar aquí.

    Optimice sus operaciones de seguridad con las reglas Cymulate y Sigma

    Como ha visto en el desglose de este ataque en particular, puede usar IOB en Sigma Rules. Esto ayudará a sus operaciones de seguridad a desafiar, evaluar, medir y optimizar. Esto se puede lograr fácilmente mediante la plataforma Cymulate en todas las áreas. Los pasos que se muestran en este artículo están destinados a ayudar con la optimización y guiar a través de cómo prevenir un ataque de tipo SolarWinds. Como ha visto en la plataforma Cymulate, un escenario, ya sea simple o complejo, puede ayudarlo a optimizar sus reglas SIEM o EDR. Esto mejorará la seguridad de su organización contra las amenazas más sofisticadas con poco esfuerzo.

    ¡Buena caza para ti!

    Y como dicen en Los Juegos del Hambre, «que las probabilidades estén siempre a tu favor».

    Este artículo fue escrito por Michael Ioffe, investigador sénior de seguridad en Cymulate.

    Continua leyendo

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Newsletter Signup

    Suscríbete a nuestra lista si te interesa recibir turcos exclusivos sobre hacking y seguridad informática