El ataque SolarWinds , que tuvo éxito al utilizar el malware sunburst , conmocionó a la industria de la ciberseguridad. 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 gran alcance de SolarWinds, 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 EE. UU., Contratistas del gobierno, empresas de tecnología de la información y ONG. Se robaron terabytes de datos de 18.000 clientes después de que se instalara una versión troyana de la aplicación SolarWinds en las estructuras internas de los clientes.
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 por SolarWinds del marco de software de Orion.
Los actores de amenazas instalaron una puerta trasera que se comunica a través de HTTP a servidores de terceros. Después de un período de inactividad 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 puede proteger a la organización de Sunburst o de 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í, avanzan como cualquier otro ataque, y se pueden detectar si sabemos dónde buscar.
Desarrollando reglas SIEM, usando el ataque SolarWinds como ejemplo
Comencemos con las reglas de 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 en 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íficamente para el lenguaje de ese SIEM. Con solo hacer clic en un botón, puede cambiar a su SIEM preferido.
Ejemplo 1: Splunk:
Ejemplo 2: Qradar:
Ejemplo 3: Azure Sentinel:
Aunque las reglas Sigma están diseñadas principalmente para consultas, se pueden usar para construir una regla completa SIEM o EDR anti-cadena de ataque. En el caso del ataque SolarWinds Sunburst y muchos otros ataques, las reglas Cymulate Sigma son consultas que buscan los IOB del ataque. Cada regla sigma solicitará al SIEM un IOB de una etapa del ataque.
Cuando los IOB de las reglas sigma se combinan, pueden dar como resultado una regla específica para el sistema objetivo, algo que puede, con un alto grado de confianza, señalar el ataque sin «inventar la rueda» de nuevo. 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 SolarWinds recreado en la plataforma Windows y busquemos juntos.
Buscando 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 Exchange. Las etapas posteriores del ataque, disponibles en la plataforma Cymulate para simular el ataque, se pueden ver en la captura de pantalla.
El primer evento no obtendrá ningún disparador de Windows, 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 colocarlo en una regla general. Continuemos.
El siguiente evento del ataque es la descarga de contenido con PowerShell. Tal evento se puede monitorear con Windows Event IDs 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 y el atacante puede usar.
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 ID de evento de Windows 4663 con un indicador de máscara de acceso 0x1 o, si usa Sysmon, el ID de evento 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í .
La siguiente en la línea es la siguiente etapa del ataque: Programador de tareas: Tareas de enmascaramiento activadas en la pantalla de bloqueo de Windows para el 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 de 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 son opcionales. Personalmente, recomendaría agregar una opción de 4699, ya que siempre existe la posibilidad de que el atacante quiera eliminar la tarea después de completarla para cubrir sus huellas.
Entonces, lo que buscaremos para los requisitos mínimos es 4698 con un conjunto de expresiones regulares específicas en el campo «Comando» en el evento, que coincida con los tipos de ejecutables conocidos, por ejemplo:
Para casos complejos, se pueden usar expresiones regulares, como las que se muestran a continuación:
- – ‘^ ([A-Za-z0-9 + /] {4}) * ([A-Za-z0-9 + /] {3} = | [A-Za-z0-9 + /] {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 (expresiones regulares): estos coinciden con un patrón base64. Aunque «Tarea programada» recibe una cadena como entrada, es posible escribir en ella una forma ofuscada / cifrada de un comando. Por ejemplo, «python» como comando y «base64.b64decode ( algo de carga útil de base64 )» como argumento, convirtiendo así su tarea en una herramienta de «decodificación de carga útil de base64».
Una vez más, todos los indicadores se pueden encontrar en las Reglas Sigma proporcionadas por Cymulate. Llamaremos a esta lista y otras listas futuras de IOB simplemente «lista de IOB relevante» por motivos de conveniencia. A continuación se muestra la vista general del ID de evento 4698 para crear una nueva tarea.
Entonces, a estas alturas, 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 de su tarea, lo que dará como resultado 4688 ID de evento con el nombre de proceso del creador: TaskScheduler o TaskScheduler.dll o taskeng.exe (según la versión de compilación que utilice), y el nombre del nuevo proceso tendrá uno de los siguientes 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 relevante) 🡪 (4688 + lista de nombre de proceso Creator relevante + lista de IOB relevantes como parte del nuevo nombre de proceso)
O
4663 + Máscara de acceso 0x1 o Sysmon 11) 🡪 [(4698 + lista IOB relevante) 🡪 (4688+ (TaskScheduler.dll o taskeng.exe))]
El signo 🡪 representa la operación «seguida de»
La siguiente etapa del ataque es ejecutar un 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: enumerar un grupo de AD utilizando ADFind enmascarado como csrss.exe . Este paso es un poco complicado. Durante este paso, un atacante disfraza 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 archivos que podrían usarse para el mismo propósito, por ejemplo:
– ‘svchost.exe’. – rundll32.exe. – services.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 están incluidos en la regla Sigma correspondiente.
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 anule un archivo del sistema o cree una nueva ruta, aún resultará en un ID de evento 4663 (o ID de evento 11 de Sysmon), y uno de los nombres a continuación se encontrará en la carga útil.
Trabajar con archivos del sistema también requiere acceso con privilegios, por lo que inevitablemente habrá una escalada de privilegios, que también se documenta como ID de evento 4688 (acceso a archivos) y Tipo de elevación de token de %% 1936 o %% 1937, que son tipos de acceso al sistema y al administrador. 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 + lista IOB relevante) 🡪 (4688+ (TaskScheduler.dll o taskeng.exe)) 🡪 (4688 y rundll32) 🡪 (4663 o Sysmon 11 + lista genérica de sistema archivos) 🡪 (4688 y 1 de archivos en la lista y tipo de elevación de token (%% 1936 OR %% 1937))]
El siguiente paso es » Ejecutar PowerShell codificado en base64 desde el Registro de Windows «. Lo que sucede aquí es que un atacante ejecuta un código ofuscado previamente escrito en un valor de registro. Como puede comprender, antes de que pueda hacer esto, debe crear un nuevo valor de registro o modificar uno existente.
Un ID de evento de Windows 4657 y un valor que coincida con el patrón base64 (que se puede identificar con expresiones regulares que ya hemos visto en un paso anterior) pueden ayudar a identificar este paso. El evento puede incluir «Valor de registro existente modificado» o «Creación de un nuevo valor de registro» como 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 estuvo involucrada.
El formato es: \ REGISTRY \ HIVE \ PATH donde:
COLMENA:
- HKEY_LOCAL_MACHINE = \ REGISTRO \ MÁQUINA
- HKEY_CURRENT_USER = \ REGISTRY \ USER \ [USER_SID], donde [USER_SID] es el SID del usuario actual.
- HKEY_CLASSES_ROOT = \ REGISTRY \ MACHINE \ SOFTWARE \ Classes
- HKEY_USERS = \ REGISTRO \ USUARIO
- HKEY_CURRENT_CONFIG = \ REGISTRY \ MACHINE \ SYSTEM \ ControlSet001 \ Hardware Profiles \ Current
2) Cuál es el proceso originario.
3) Cuál es el valor antiguo y el nuevo valor.
A continuación, puede ver una representación general del ID de evento 4657.
Teniendo en cuenta los posibles marcos de tiempo, dado que la operación completa probablemente estará programada, podemos decir con seguridad que si tiene éxito, los pasos 2-6 no tomarán más de 5 segundos. La cadena completa hasta la ejecución del código almacenado en el registro no puede durar más de 10 minutos.
Después de agregar esas variables, lo que tenemos es una cadena de eventos que se pueden correlacionar:
- Todo se originará en una sola máquina.
- Se iniciará como el mismo usuario.
- La regla operativa se verá como la siguiente:
{
(4663 + Máscara de acceso 0x1 o Sysmon 11) 🡪
[(4698 + lista IOB relevante) 🡪
(4688+ (TaskScheduler.dll o taskeng.exe)) 🡪
(4688 y rundll32) 🡪
(4663 o Sysmon 11 + lista genérica de archivos del sistema) 🡪
(4688 y 1 de los archivos en la lista y el tipo de elevación del token (%% 1936 OR %% 1937)) 🡪 (4657 + Nuevo valor creado O valor existente modificado + patrón de coincidencia base64 en valor en un período de tiempo de hasta 5 s)]
en un período 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 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 Exchange utilizando una solicitud HTTP básica , respectivamente.
Aunque Windows no tiene un ID de evento integrado para las solicitudes HTTP / S, siempre habrá {4660 en el buzón (solicitud HTTP + 4663 de filename.zip/rar/tar/other)}. Para obtener un evento de solicitudes HTTP / S, sistemas adicionales, por ejemplo, un sistema de análisis de tráfico de red, pueden ayudar aquí.
Optimice sus operaciones de seguridad con Cymulate y Sigma Rules
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 con 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 orientar sobre 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 senior de seguridad en Cymulate.
