Serie SOCwise: Consideraciones prácticas sobre SUNBURST


Este weblog es parte de nuestra serie SOCwise, en la que profundizaremos en todo lo relacionado con SecOps desde el punto de vista de un profesional, lo que nos ayudará a permitir que los defensores creen contexto y confianza en lo que hacen.

Aunque se ha hablado mucho sobre los ataques a la cadena de suministro, vamos a ofrecerles una perspectiva ligeramente diferente. En lugar de hablar sobre la técnica, hablemos de lo que significa para un SOC y, lo que es más importante, nos centraremos en el ataque SUNBURST, donde el adversario aprovechó una aplicación confiable de SolarWinds.

A continuación, verá la fascinante discusión entre nuestro propio Ismael Valenzuela y Michael Leland, donde hablarán sobre los trucos de la cadena de suministro y la premisa detrás de ellos. Más importante aún, por qué este en specific tuvo tanto éxito. Y, por último, cubrirán las mejores prácticas, el refuerzo de la prevención y la detección temprana.

Miguel: Ismael, comencemos hablando un poco sobre los tipos comunes de ataques a la cadena de suministro. Sabemos de experiencia pasada que han sido principalmente program sin embargo, no es extraño tener también ataques a la cadena de suministro basados ​​en hardware. Pero en realidad, se trata de secuestrar o hacerse pasar por un proveedor o un proveedor confiable y objetar el código malicioso en aplicaciones autorizadas confiables. A veces, incluso secuestrar el certificado para que parezca legítimo. Y este último fue acerca de inyectar en bibliotecas de terceros.

En relación a SUNBURST, fue un juego largo, ¿verdad? Este fue un ataque de juego largo del adversario en el que tuvieron más de 12 meses para planificar, organizar, desplegar, armar y cosechar los beneficios. Y vamos a hablar más sobre lo que hicieron, pero lo que es más importante, también sobre cómo nosotros, como profesionales, podemos aprovechar las fuentes de telemetría que tenemos tanto para la detección como para la prevención futura. La primera pregunta que hace la mayoría de la gente es si esta nueva y claramente esta no es una técnica o táctica nueva, pero hablemos un poco sobre por qué esta fue diferente.

Ismael: ¡Correcto! La pieza más interesante sobre SolarWinds no es que gran parte de ella sea un ataque a la cadena de suministro porque, como usted dijo, es verdad. No es nuevo. Hemos visto cosas similares en el pasado. Sé que hay mucha controversia en torno a algunos de ellos como Supermicro, nosotros y muchos otros en los últimos años y es difícil probar este tipo de ataques. Pero para mí, la pieza más interesante no es solo cómo llegó al entorno, sino que hablamos de actualizaciones maliciosas en aplicaciones legítimas. Por ejemplo, hemos visto algo de eso en el pasado con la modificación del código en GitHub, ¿verdad? Informes desprotegidos, atacantes, actores de amenazas están modificando el código.

Vamos a hablar un poco sobre lo que las organizaciones pueden hacer para identificarlos, pero lo que realmente quiero resaltar de esto es sobre los atacantes, tienen un system, ¿verdad? Comprometen el medio ambiente con cuidado, permanecieron inactivos durante aproximadamente dos semanas y, después de eso, como hemos visto en una investigación reciente, comenzaron a implementar cargas útiles de segunda etapa. La forma en que lo hicieron fue muy, muy interesante, y está cambiando el juego. No es radicalmente nuevo, pero siempre hay algo nuevo que quizás no hayamos visto antes. Y es importante que los acusados ​​comprendan estos comportamientos para que puedan comenzar a intentar detectarlos. En resumen, tienen un program y deberíamos preguntarnos si tenemos un strategy para este tipo de ataques. No solo el vector inicial, sino también lo que sucede después de eso.

Miguel: Echemos un vistazo a la línea de tiempo (figura 1 a continuación) y hablemos sobre el arco de la historia de lo que sucedió. Creo que lo importante es que, de nuevo, el adversario sabía mucho antes del ataque, mucho antes de que se armara la aplicación, mucho antes del despliegue, que tenían esto planeado. Sabían que iban tras un proveedor muy específico. En este caso, SolarWinds sabía desde 2018, principios de 2019, que ya tenían un dominio de registro registrado para él. Y ni siquiera le dieron una búsqueda de DNS hasta casi un año después. Pero la aplicación de código 2019 fue un armamento en 2020. Estamos hablando de meses que pasó casi un año, y sabían muy bien cuál era su intención.

Ismael: Sí, absolutamente. Y como mencioné antes, incluso una vez que tienen la puerta trasera en su lugar, el infame DLL ahora permanece inactivo durante dos semanas. Y luego comienzan un descubrimiento de reconocimiento cuidadoso tratando de averiguar dónde están, qué tipo de información tienen a su alrededor, los usuarios y la administración de identidad. En algunos casos, los hemos visto pivotar y robar los tokens y las credenciales y luego pasar a la nube, todo eso lleva tiempo. ¿derecho? Lo que indica que el atacante tiene mucho conocimiento sobre cómo hacer esto de manera sigilosa. Pero si pensamos en términos de cadenas de ataque, también nos ayuda a comprender dónde podríamos tener mejores oportunidades para detectar este tipo de actividades.

Miguel: Hemos preparado el escenario para comprender qué sucedió exactamente y mucha gente ha hablado sobre la metodología y el ciclo de vida del ataque. Pero tenían un approach, no estaban específicamente avanzados en la forma en que aprovechaban las herramientas. Fueron muy específicos sobre el aprovechamiento de múltiples métodos algo novatos o novedosos para hacer uso de la vulnerabilidad. Más importante aún, fue la cantidad de esfuerzo que pusieron en la planificación y la cantidad de tiempo que pasaron tratando de no ser vistos, ¿verdad? Observamos la telemetría todo el tiempo, ya sea en una herramienta SIEM o en una herramienta EDR, y necesitamos esas piezas de telemetría que nos dicen lo que está sucediendo, y fueron muy sigilosas en la forma en que aprovecharon las técnicas.

Hablemos un poco sobre lo que hicieron que fue exclusivo de este ataque específico y luego hablaremos más sobre cómo podemos definir mejor nuestras defensas y prevención en torno a lo que aprendimos.

Ismael: ¡Sí, absolutamente! Y una de las cosas interesantes que hemos visto recientemente es cómo disociaron la etapa uno y la etapa dos para asegurarse de que la etapa uno, la puerta trasera / DLL, no fuera detectada ni quemada. Entonces, una vez más, estabas hablando del juego largo. Estaban planeando, estaban diseñando su ataque a largo plazo. Incluso si encontrara un artefacto de una máquina específica, sería más difícil rastrearlo hasta la puerta trasera primary. Así que mantendrían la persistencia en el medio ambiente durante bastante tiempo. Sé que esto no es necesariamente nuevo. Les hemos estado diciendo a los defensores durante mucho tiempo: Debes concentrarte en encontrar la persistencia, porque los atacantes, deben permanecer en el entorno.

Necesitamos mirar el mando y el control, pero obviamente estas técnicas están evolucionando. Hicieron todo lo posible para asegurarse de que los artefactos, los indicadores de compromiso en cada uno de estos sistemas diferentes para la etapa dos, y en este punto, sabemos que utilizan balizas de impacto de colon. Cada una de estas balizas period única, no solo para cada organización, lo que tendría sentido, sino también para cada computadora dentro de cada organización. ¿Qué significa eso para un SOC? Bueno, imagina que estás haciendo esto y en respuesta encuentras algún comportamiento extraño saliendo de la máquina, miras los indicadores y qué vas a hacer a continuación … alcance, ¿verdad? Veamos en qué otro lugar de mi crimson. Veo actividad que ingresa en ese dominio a esos IPS o esas claves de registro o ese, ya sabes, consumidor de WMI, por ejemplo. Pero la verdad es que esos indicadores no se utilizaron en ningún otro lugar, ni siquiera en su entorno. Eso fue interesante.

Miguel: Dado que no tenemos indicadores específicos que podamos atribuir a algo malicioso en esa etapa, lo que sí sabemos es que están aprovechando los protocolos comunes de una manera poco común. La mayor parte de esta táctica se llevó a cabo desde una perspectiva C2 ​​a través de la exfiltración parcial que se realiza mediante DNS. Para las organizaciones que no monitorean de manera exitosa o efectiva los tipos de tráfico de DNS, el DNS que tiene lugar en puertos no estándar o más trimestralmente, el volumen de DNS que se origina en máquinas que normalmente no lo tienen y el análisis de métricas de volumen cuéntanos mucho. Si, de hecho, hay algún valor heurístico que podemos aprovechar para detectar. ¿En qué más deberíamos pensar en términos del lado de la protección de las cosas, un abuso de confianza?

Confiamos en una aplicación confiamos en un proveedor. Este fue un claro abuso de eso. La confianza cero sería una metodología que puede incorporar tanto la microsegmentación como la verificación explícita y, lo que es más importante, la metodología de menor confianza que podamos garantizar. También pienso en el hecho de que estamos otorgando a estas aplicaciones derechos y privilegios sobre nuestro entorno y privilegios administrativos. Debemos asegurarnos de que estamos monitoreando tanto las cuentas como las cuentas de servicio que utilizan estas aplicaciones específicamente, para que podamos prescribir un dominio, muros y barreras alrededor de lo que tienen acceso. ¿Qué más podemos hacer en términos de detección o proporcionar visibilidad para este tipo de ataques?

Ismael: Cuando hablamos de un ataque complicado o avanzado, me gusta pensar en términos de marcos como el nuevo marco de ciberseguridad, por ejemplo, que habla de prevención, detección y respuesta, pero también identifica los riesgos y los activos primero. Si lo miras desde esa perspectiva y miras una cadena de ataque, aunque algunos de los aspectos de estos ataques eran muy avanzados, siempre existen limitaciones desde la perspectiva del atacante. No existe el ataque perfecto, así que ten en cuenta la falacia del ataque perfecto. Siempre hay algo que el atacante va a hacer que puede ayudarte a detectarlos. Con eso en mente, piense en poner los comportamientos, tácticas y técnicas de ataque MITRE en un lado de la matriz y en el otro lado, como el marco de ciberseguridad del NIST identifica, protege y detecta.

Algunas de las cosas que sugeriría es identificar los activos de riesgo, y siempre hablo de BCP. Esta es la planificación de la continuidad. A veces trabajamos en silos y no aprovechamos parte de la información que puede estar en su organización y que puede señalarle la joya de la corona. No puede proteger todo, pero necesita saber qué proteger y cómo fluye la información. Por ejemplo, ¿dónde están sus puntos débiles, dónde se encuentran sus proveedores en la purple, sus productos, cómo se actualizan? Le resultará útil determinar o definir una arquitectura segura defendible que la refuerce tratando de proteger ese … el flujo de datos.

Cuando falla la protección, podría ser una regla de firewall que puede ser cualquier tipo de protección. Los intentos de eludir los firewalls se pueden convertir en detecciones. Es muy importante tener visibilidad en todo su entorno, eso no significa solo administrar dispositivos, también significa la purple, los puntos finales y los servidores. Los atacantes van a ir tras los servidores, los controladores principales, ¿verdad? ¿Por qué? Debido a que quieren robar esas credenciales, esas identidades se usan en otro lugar y tal vez pasen a la nube. Por lo tanto, tener suficiente visibilidad en la crimson es importante, lo que significa que la cámara apunte a los lugares correctos. Es entonces cuando pueden entrar en juego EDR o XDR, productos que mantienen esa telemetría y le brindan visibilidad de lo que está sucediendo y potencialmente detectan el ataque.

Miguel: Creo que es importante al concluir nuestra discusión conversar sobre el hecho de que la telemetría puede venir en varios sabores lo que es más importante, tanto la telemetría histórica como en tiempo real que tiene un valor significativo, no solo en el lado de la detección, sino también en el lado de la investigación forense y del alcance, y comprende exactamente dónde puede haber aterrizado un adversario. No se trata solo de tener acceso a la telemetría, a veces también es la falta de telemetría. Ese es el indicador que nos dice cuando el registro se deshabilita en un dispositivo y dejamos de escucharlo, entonces el SIEM comienza a ver una brecha en su visibilidad de un activo específico. Es por eso que la combinación de tecnologías de protección de endpoints en tiempo actual implementadas tanto en endpoints como en servidores, así como la telemetría histórica que normalmente consumimos en nuestros marcos de análisis y tecnologías como SIEM.

Ismael: Absolutamente, y para reiterar el punto de encontrar aquellos lugares donde van a estar los atacantes, se pueden detectar más fácilmente. Si observa toda la cadena de ataque, tal vez el vector inicial sea más difícil de encontrar, pero comience a ver cómo obtuvieron los privilegios, su escalamiento y su persistencia. Michael, mencionaste que los registros de limpieza aparentemente deshabilitaban los registros de auditoría mediante el uso de auditpol en el punto ultimate o la creación de nuevas reglas de firewall en los puntos finales. Si consume estos eventos, ¿por qué alguien deshabilitaría el registro de eventos temporalmente apagándolo y volviéndolo a encender después de un tiempo? Bueno, estaban haciendo esto por una razón.

Miguel: Correcto. Así que vamos a concluir nuestra discusión, con suerte esto fue informativo. Suscríbase a nuestro weblog Securing Tomorrow, donde puede mantenerse actualizado con todo lo relacionado con SOC y no dude en visitar McAfee.com/SOCwise para obtener más material de SOC de nuestros expertos.






Enlace a la noticia initial