Contenido de detección proactiva: CVE-2019-0708 frente a ATT&CK, Sigma, Elastic y ArcSight
Creo que la mayoría de la comunidad de seguridad ha acordado que la vulnerabilidad CVE-2019-0708 es de prioridad crítica para tratar. Y aunque decir «¡instala tus actualizaciones!» puede parecer lo primero que uno debería pensar, los recuerdos de WannaCry y NotPetya aún están frescos en mi mente. Sabemos que la instalación de parches no sucederá a la velocidad y en la escala que necesita ser. Y así estamos, una vez más, desarrollando las reglas de detección.
Un pequeño pero importante detalle: la vulnerabilidad CVE-2019-0708 está relacionada con Remote Desktop Services (RDS), por lo que la implementación real de Microsoft al usar el Remote Desktop Protocol (RDP) en Windows. El protocolo RDP en sí mismo está bien. Siento que esta declaración necesita estar aquí para evitar todo tipo de alboroto similar al que vimos durante el brote de Wannacry.
El hashtag “BlueKeep” fue utilizado por primera vez por Kevin Beaumount. Lo elegí por 2 razones: la referencia a GoT y para encontrar publicaciones relevantes en Twitter, ya que uno no puede simplemente hashtag un CVE (a menos que se eliminen los guiones). BlueKeep solo está facilitando twiterops 😉
https://twitter.com/GossiTheDog/status/1128348383704485895
Dando vuelta la balanza a favor de los defensores.
Para establecer la teoría de detección, debemos considerar dos modelos de amenaza:
- Amenaza tipo gusano, similar al escenario de WannaCry.
- Actor APT, utilizando la vulnerabilidad como parte de una campaña más sofisticada, al igual que EternalBlue & SMB fueron solo una parte del desastre de NotPetya.
Para identificar activos en riesgo, nos referiremos a la siguiente tabla, compartida gracias a la cortesía de Dragos:
fuente: https://dragos.com/blog/industry-news/ics-impact-from-microsoft-rdp-vulnerability/
¿Puede el CVE-2019-0708 usarse para el acceso inicial a gran escala similar a Wannacry? Un vistazo rápido a los datos de Shodan revela muchas máquinas en internet con el puerto 3389 expuesto y ejecutando versiones potencialmente vulnerables de Windows:
https://www.shodan.io/search?query=port:3389+os:»Windows+7+or+8″
https://www.shodan.io/search?query=port:3389+2003
https://www.shodan.io/search?query=port:3389+2008
https://www.shodan.io/search?query=port:3389+os:»Windows+XP»Y en total estamos observando 2.375 millones de hosts con RDP accesible desde internet, ¡pero no saques la conclusión aún!
https://www.shodan.io/search?query=Remote+Desktop+Protocol
Citamos el tweet de Dan Tentler del 23 de abril de 2017: «no todos esos hosts son Windows, y no todos esos puertos son SMB». Adaptando esto al día de hoy: “No todos esos 2.3 millones de hosts son Windows y no todos esos puertos son servicios vulnerables al CVE-2019-0708”. Si comparamos esto con la cronología de WannaCry, estamos en la etapa donde MS-17010 ya está, EternalBlue aún no lo está y, por lo tanto, no podemos escanear para el próximo DoublePulsar. Y hasta que tal PoC exista y alguien escanee por backdoor presente, como lo hizo Dan hace 2 años, no podemos estar absolutamente seguros de que las cosas van a ir mal. Sin embargo, están «a punto» de llegar a esa etapa y tal vez aún tengamos 30 días para poner defensas en su lugar, quizás menos.
https://twitter.com/Viss/status/856227372785221632
Si bien podemos debatir sobre si esas máquinas son utilizadas por organizaciones reales, su estado de parches, segmentación de red, etc., es de conocimiento común que muchas empresas todavía operan las versiones vulnerables de Windows y los ciclos de parches pueden ser difíciles para esos sistemas. Además, en comparación con Wannacry, vemos aproximadamente 24K+ hosts potencialmente explotables frente a 140K+ hosts con DoublePulsar enfrentando internet 3 semanas antes del incidente.
El mayor peligro en esta etapa es la explotación del CVE-2019-0708 una vez dentro de la organización para comprometer rápidamente hosts y para Movimiento Lateral. Y dado que el PoC de Exploit no está disponible al momento de escribir este artículo (sin embargo, hay muchos falsos), aprovecharemos todas las herramientas a nuestra disposición para construir la detección -antes- de que el exploit esté incluso disponible.
Considerando todo lo anterior, las 3 principales cosas que puedes hacer como defensor son:
- Desplegar contenido de detección proactiva.
- Abogar rigurosamente por aplicar parches o mitigar la vulnerabilidad.
- Mantenerse al tanto del desarrollo de la situación siguiendo la información de investigadores de tu confianza.
Para reforzar algunos de los puntos, me gustaría referirme a 2 tweets de Florian Roth sobre el problema:
 |
 |
Reglas Sigma, primero al rescate.
La primera regla, referida más adelante como Sigma #1, fue compartida gracias a Markus Neis en el repositorio github de Sigma para abordar la técnica de Movimiento Lateral T12010 / Explotación de Servicios Remotos https://attack.mitre.org/techniques/T1210/ :
Dentro de una hora, una regla similar (Sigma #2) fue publicada en SOC Prime TDM por Roman Ranskyi como un recurso comunitario / de uso gratuito con algunas distinciones en la lógica de detección que se extiende a T1036 / Suplantación https://attack.mitre.org/techniques/T1036/ y T1046 / Escaneo de Servicios de Red https://attack.mitre.org/techniques/T1046/ .
Básicamente, tenemos detecciones TLP:WHITE y TLP:GREEN allí fuera, ¡antes del exploit! Pero ¿es esto suficiente para detectar un ataque a gran escala?
Machine Learning, llevándolo un paso más allá.
Exploremos cómo las capacidades de Machine Learning pueden darnos una ligera ventaja sobre el problema y comenzar con la creación de una receta para el stack Elastic.
Receta ML: Detectar Movimiento Lateral sobre RDP potencialmente relacionado con CVE-2019-0708
Teoría
Un número excesivo de direcciones IP de destino únicas en conexiones RDP iniciadas desde un solo host durante un tiempo limitado puede ser una indicación del Movimiento Lateral y la propagación del gusano que utiliza el protocolo RDP como método de propagación (usando el exploit RDS relacionado con la vulnerabilidad CVE-2019-0708).
Descripción
Esta receta de caso de uso identifica direcciones IP de origen que potencialmente pueden ser puntos de propagación de gusanos RDP o Movimiento Lateral vía RDP / T1076 a través de segmentos de red.
Efectividad
Esta receta de caso de uso se proporciona como parte de una Detección Proactiva automatizada para la Vulnerabilidad de Ejecución de Código Remoto de Remote Desktop Services (CVE-2019-0708) aún inexistente gusano RDP, que se espera explote la vulnerabilidad y utilice RDP para el Movimiento Lateral a través de segmentos LAN internos. La información adicional en relación al comportamiento del gusano RDP después de observarlo en la naturaleza puede usarse para ajustar la receta y producir resultados de detección más efectivos.
Tipo de Caso de Uso
Comportamiento de Ataque Elemental (EAB) – Este caso de uso detecta anomalías asociadas con comportamientos de ataque elemental. A cada anomalía detectada se le asigna una puntuación de anomalía normalizada, y se anota con valores de otros campos en los datos que tienen influencia estadística sobre la anomalía. Los comportamientos de ataque elemental que comparten influencias estadísticas comunes a menudo están relacionados con una progresión común del ataque.
Fuente de Datos del Caso de Uso
Eventos de Netflow, registros de flujo VPC o datos similares en formato ECS, que contienen registros de conexiones RDP entre hosts de Windows dentro de segmentos LAN internos.
Receta del Caso de Uso
| Para: | Conexiones RDP. |
| Modelo: | Cuenta única de Direcciones IP de Destino para cada Dirección IP de origen. |
| Detectar: | Número inusualmente alto de Direcciones IP de Destino para la Dirección IP de origen específica. |
| Comparado con: | Población de todas las (mayores registradas) Direcciones IP de origen en los resultados de búsqueda. |
| Dividir por: | Ninguno |
| Excluir: | Ninguno |
| Duración: | Ejecutar análisis en eventos Netflow por un período de 2 semanas o más. |
| Recetas relacionadas: | Ninguno |
| Resultados: | Los hosts influyentes podrían ser escáneres de vulnerabilidades, hosts de salto o hosts comprometidos que actúan como fuentes de propagación de gusanos RDP. |
Características de Entrada e Influenciadores Candidatos
| Campo requerido | Descripción | Ejemplo |
| Source.ip | Fuente de la sesión RDP | 10.10.1.1 |
| Destination.ip | Destino de la sesión RDP | 10.10.1.124 |
| Destination.port | Puerto TCP que identifica la conexión RDP | 3389 |
Patrones de Índices de Elasticsearch de Ejemplo:ecs-netflow*Consulta de Ejemplo de Elasticsearch:«query»: {«term»: {«destination.port»: {«value»: 3389″,»boost»: 1}}}
Análisis de Machine Learning / Configuración de Detector:
Detector(es): high_distinct_count(destination.ip) over source.ip
Bucketspan: 15m
Influencer(s): source.ip
Explorando resultados de ML en el stack Elastic.
La vista de métrica única nos encuentra los drones que estábamos buscando. Así que cuanto mejor sea el conjunto de datos que tengamos, más precisa será la detección de valores atípicos.
El Explorador de Anomalías ayuda a explicar la historia de las conexiones RDP habituales frente a un comportamiento similar a un gusano o un administrador super-trabajador que puede o no estar trabajando para el actor de amenaza APT 😉
El cálido sonido tubular del motor de correlación de ArcSight.
En esta etapa ya tenemos definida claramente la lógica de detección, veamos si podemos aplicarla a la tecnología que muchas compañías aún usan como herramienta primaria de SIEM. Hay varias tareas que intentaremos resolver con respecto a la amenaza que se avecina:
- Identificar los activos en riesgo de manera automatizada.
- Rastrear actividad RDP anómala en los activos anteriores.
- Intentar detectar Movimiento Lateral aprovechando las reglas Sigma y basadas en comportamiento.
Tarea #1: es donde podemos confiar en varias funciones en ArcSight.
Hacer una lista de activos vulnerables al CVE-2019-0708 aprovechando el modelo de activos y red que (debería estar) poblado por cualquier escáner de vulnerabilidades que proporcione salida CEF (Qualys, Nessus o incluso nmap hará el truco).
¿Y si no tenemos un escáner? Podemos rastrear hosts potencialmente vulnerables al hacer un filtro en activos Windows XP, 7, 2003 y 2008 usando el modelo de activos y red o basado en IDs de eventos de Windows generados por esas versiones que son distintas de versiones más nuevas de Windows.
Tarea #2: para sustituir Machine Learning haremos una regla que recoja eventos de Firewall y Netflow basados en Categorización y almacene IPs de origen & destino RDP en la Lista Activa. De esta manera podemos encontrar la primera conexión hacia/desde activos potencialmente/confirmados vulnerables. Adicionalmente construiremos Tendencias para perfilar conexiones RDP y detectar picos de tráfico por conteo de conexiones.
Tarea #3: portando la regla Sigma #1 de consulta a correlación en tiempo real cubrirá la detección de Movimiento Lateral T1210. Para lograr esto he copiado la fuente de Sigma #1 en Uncoder.io para producir la consulta ArcSight. Una cosa agradable de las consultas ArcSight es que teniendo algún conocimiento del lenguaje uno puede fácilmente convertir el código en el filtro para la regla de correlación en tiempo real.
¡Ponlo todo junto y enchúfalo a tu SOC!
Para ArcSight las piezas de contenido anteriores están vinculadas en un solo tablero que debería permanecer vacío bajo operaciones normales. Para hacer que los eventos lleguen al canal principal del SOC, añade una regla ligera para consumir alertas correlacionadas del canal activo “Detalles del Evento de Correlación”.
Para el SOC basado en Elastic hemos agregado un tablero simple de Kibana. Muestra picos RDP y visual de Machine Learning para encontrar valores atípicos basados en tráfico de netflow, así como detalles sobre disparadores de reglas Sigma, hosts impactados, etc.
Si ya estás usando el tablero SOC Prime para gestión de Watcher puedes explorar los datos a través del prisma de MITRE ATT&CK y pivotar entre las Tácticas, Técnicas, Usuarios afectados, Computadoras, observar la Línea de Tiempo de ataques, gestionar Watchers, pivotar a reglas Sigma y casos vía la aplicación SOC Workflow. Todo eso sin salir de la interfaz Kibana.
¿Elastic, ArcSight o Sigma?
Si solo usamos ATT&CK como referencia, Elastic es el ganador estando 1 técnica por delante.
La principal ventaja del stack Elastic es su capacidad para combinar tanto Machine Learning como consultas modernas de Caza de Amenazas basadas en Sigma. Recuerda que el refactor de reglas Sigma a consultas de correlación en tiempo real no encuentra Suplantación / T1036 en ArcSight.
Sin embargo, vale la pena señalar que en realidad es más fácil configurar ArcSight para aprovechar datos de escáneres de vulnerabilidades para correlación cruzada de dispositivos. Combinado con todas las demás fuentes de registros en el paquete de reglas de detección puede ser más efectivo para muchas organizaciones.
Si miramos la tarea desde el punto de la velocidad y costo del desarrollo de detección, Sigma claramente lidera el camino. Siempre y cuando tu SIEM o EDR soporte Sigma o tengas registros Sysmon de todas tus máquinas, incluyendo XP, 7, 2003 y 2008, esta será una solución óptima para ti. Una vez más, la ventaja de un paquete de detección más grande frente a una sola regla se basa principalmente en nuestra suposición de que un ataque real aprovechará RDP para movimiento lateral. No hay un tamaño único que se ajuste a todos cuando se trata de detección de amenazas. La puntuación final se establecerá cuando el exploit real funcione y podamos construir la detección, muy probablemente usando reglas Sigma. Al final del día, hemos construido un contenido de Detección Proactiva basado en Reglas y Machine Learning para el “conocido desconocido”, tal como el Dr. Anton Chuvakin declaró recientemente en su publicación: https://blogs.gartner.com/anton-chuvakin/2019/04/30/rule-based-detection/ .
No olvides la Prevención y aplica tus parches
Aprende de los errores de los demás, aplicar parches previamente será tan beneficioso como si tuvieras todo SMB parchado durante el brote de Wannacry. Si recibes un no en esto del equipo de parches, despliega detecciones, prueba las copias de seguridad y delega el riesgo. https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/
Enlaces a contenido de detección gratuito y asignaciones a MITRE ATT&CK
- Sigma #1 por Markus Neis https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_susp_rdp.yml Movimiento Lateral; T1210; fuentes de registro: microsoft sysmon.
- Sigma #2 por Roman Ranskyi https://tdm.socprime.com/tdm/info/2159/ Movimiento Lateral, Evasión de Defensa, Descubrimiento; T1210, T1036, T1046; fuentes de registro: microsoft sysmon.
- Paquete de reglas ArcSight .ARB https://tdm.socprime.com/tdm/info/2160/ Movimiento Lateral, Descubrimiento; T1210, T1046, T1076; fuentes de registros: firewall, netflow, escáner de vulnerabilidades, registros de MS Active Directory, Sysmon.
- Paquete de reglas de Elastic stack https://tdm.socprime.com/tdm/info/2160/Movimiento Lateral, Evasión de Defensa, Descubrimiento; T1210, T1036, T1046, T1076; fuentes de registros: netflow, registros de MS Active Directory, Microsoft Sysmon.
Edición comunitaria de SOC Workflow App: https://github.com/socprime/soc_workflow_app_ce
/Mantente seguro
