En Huntress, nos encanta compartir internamente en hilos nuestros enfoques de investigación sobre hallazgos interesantes, para que otros equipos vean en qué andamos y aprendan una o dos cosas.
En este blog, haremos un breve recorrido por cómo diseccionamos una vaga alerta de Managed Antivirus y, en el camino, ofreceremos algunas ideas y métodos para analistas de seguridad de todas partes. Tenemos un buen equilibrio entre enfoques específicos de Huntress y métodos que cualquiera puede aplicar en cualquier equipo. (Inserta aquí una imagen cursi de un equipo chocando las manos.)
¿Defender dice quéééééé?
Desde hace mucho, Huntress se ha subido a la Tribuna de la Justicia para promover que todos ingieran las alertas de su antivirus preferido. (¿Ya nos imaginas parados en lo alto de un edificio con una capa ondeando al viento??)
Ahora bien, aunque el antivirus (AV) no suena súper le3t, confiamos ciegamente en un buen AV, y ya hemos compartido en otros lugares que a menudo el AV contiene todos los secretos para iluminar las actividades de un adversario; solo tienes que arremangarte y consultar los datos de las alertas.
En Huntress, implementamos Managed AV y, a través de eso, Defender nos da un empujoncito de vez en cuando para decirnos: “algo está pasando aquí”. No subestimes MAV; detecta a los grandes, malos y feos como Cobalt Strike tanto como detecta adware. El truco que hemos encontrado para MAV —o para cualquier producto de seguridad, a decir verdad— es podar. Sé selectivo con las alertas que se destacan.
El enfoque de Huntress poda drásticamente el ruido de detección para que solo las mejores señales de amenazas lleguen a los analistas del Huntress SOC y, posteriormente, al socio. Una contrapartida de ofrecer esta eficacia de seguridad con poco ruido es que requiere una inversión inicial de tiempo y esfuerzo para afinar las detecciones y podar los falsos positivos / alertas mediocres para que no generen ruido innecesario.
En fin, bajémonos de esa tribuna y entremos en algunos datos de amenazas. 👿💪
Las posibilidades de una alerta
Esta mañana, bien temprano, la cola avisó que un equipo recibió una señal de amenaza que Defender había neutralizado y clasificado como ‘remoteexec’.
Examinar los detalles de la alerta da ALGO de información, pero en realidad no revela la naturaleza de la amenaza, solo la forma (un .exe). De inmediato, la mente de un analista de amenazas adopta el lente de la teoría de investigación para determinar qué nos dicen los datos, así como los hilos ocultos que esperan que alguien tire de ellos.
Por ejemplo, esta alerta de MAV indica que la cuenta implicada era “SYSTEM”, pero habrá un usuario detrás de esto. ¿A dónde tenemos que ir para averiguarlo?
Además, los ejecutables con nombres aleatorios en C:\windows son un clásico del movimiento lateral o de los beacons remotos - algo que aparentemente corrobora el nombre que Defender asignó a esta amenaza: RemoteExec. Pero, para ser francos, hemos visto alertas igual de extrañas que resultaron ser falsos positivos, y aunque a los analistas del SOC nos encanta reportar amenazas, no nos encanta reportar falsos positivos.
TL;DR: el contexto humano es el diferenciador que Huntress aporta a la comunidad.
Claro, Huntress EDR combinado con una o dos automatizaciones detecta cosas realmente feas, pero es el operador humano el que marca toda la diferencia. Inundar a un socio con interminables reportes ruidosos que son vagos o técnicos en vano es algo que me saca de quicio. Como gerente del SOC, me obsesiona asegurarme de que, junto con la tecnología usada para detectar actividad maliciosa, un analista de amenazas también esté investigando la validez de dicha detección y luego prepare un reporte simple y conciso que transmita detalles y datos accionables.
Pivotar a partir de la alerta
Te diremos qué haremos: dejemos de lado la telemetría del EDR y, en su lugar, compartamos métodos y técnicas independientes del stack de Huntress, ya que eso será más útil para quienes no trabajan en Huntress (todavía 😉). Y, por cierto, compartimos con regularidad enfoques independientes de Huntress para resolver intrusiones de seguridad, ¡así que no solo estamos presumiendo para el blog!
Después de recibir una alerta como esta, nuestros primeros pasos serán recopilar algo de telemetría forense predeterminada selecta en un equipo Windows:
- Los registros de eventos de Windows (WEVTXs)
- Prefetch e historial de PowerShell
- Al final, nada de esto resultó relevante, pero buscábamos evidencia de que alguno de esos EXE de la alerta de MAV se hubiera ejecutado, así como otros ejecutables sospechosos en esa ventana de tiempo y evidencia de cualquier PowerShell que el adversario pudiera haber ejecutado
Si te interesa saber un poco más sobre estos artefactos, ¡tenemos un webinar para TI!
Huntress ya tiene tareas ‘predefinidas’ dedicadas que nos facilitan la vida a la hora de recopilarlos con un solo clic.
Nos enfocaremos en los registros de eventos de Windows, ya que fueron los que arrojaron los datos más relevantes. Claro, algunos proveedores de seguridad se ponen un poquito nerviosos cuando llega el momento de usar los registros de eventos para el análisis de seguridad, pero en Huntress es algo realmente natural. 😜
Podemos usar Chainsaw, que básicamente nos permite hacer ‘grep’ rápidamente en los WEVTXs. Chainsaw tiene un modo de resumen ‘hunt’, pero no dependas solo de esta función. En cambio, el modo de búsqueda de Chainsaw es una forma avanzada y quirúrgica de usar la herramienta. Además, si quieres recorrer más rápido los WEVTXs con consultas específicas, la herramienta de Harlan Event Ripper será una joya - sobre todo si estás combatiendo Qakbot.
Podemos empezar ejecutando Chainsaw en modo ‘hunt’, que nos ofrece un resumen basado en reglas sigma de lo que ocurre en estos datos. Pero este método tiene algunas limitaciones.
- La principal es que no todos los resultados serán maliciosos. Un analista perspicaz puede filtrar el ruido, pero aun así no siempre queda claro qué es, en última instancia, legítimo.
- Además, las reglas sigma no van a ser perfectas, y no todos los datos maliciosos o relevantes se incluirán en el modo hunt. Un analista que dependa de los datos del resumen hunt probablemente se esté perdiendo el 80 % restante de los datos de amenazas de la intrusión.
Aun así, el modo hunt de Chainsaw arrasa con el WEVTX de Windows Defender. Aquí obtenemos más contexto sobre las alertas de Defender que vimos en el dashboard de Huntress. Ahora podemos copiar y pegar el nombre del ejecutable y prepararnos para lanzar Chainsaw en modo de búsqueda.
Haz preguntas específicas
Ejecutar chainsaw search ./ -s "KAUpyFdi" -i básicamente hará ‘grep’ en los WEVTXs recopilados y, cuando esa cadena aparezca en una de las entradas de eventos, nos imprimirá el XML completo.
Uno de los resultados XML fue increíblemente interesante.
Aquí corroboramos lo que pensamos antes, cuando vimos la alerta de MAV y nos preguntamos si se trataba de algún tipo de instalación de servicio. El Event ID 7045 es una señal de instalación de un servicio.
Además de la información de la instalación del servicio, también obtenemos más claridad sobre todo el asunto de la cuenta SYSTEM. Obtenemos un SID de usuario: una cadena única asignada a una cuenta de usuario en un equipo Windows.
Pero aún tenemos algunas dudas pendientes:
- ¿Cuál es el nombre de usuario que corresponde a este SID?
- ¿El ejecutable que detectó Defender, al intentar instalar un servicio, era algún tipo de beacon o vestigio de movimiento lateral?
Rastrear el movimiento lateral
Ahora necesitamos un nombre de usuario y ver si hay evidencia de Event ID 4624 de algún equipo desde el que esta cuenta de usuario se haya movido.
Pero, para que quede claro, los datos y las marcas de tiempo del 4624 deben estar estrechamente correlacionados si queremos afirmar que hay evidencia de movimiento lateral. Si hay un inicio de sesión 30 minutos antes de la instalación del servicio, ese es un vínculo débil con el movimiento lateral. Lo que buscamos es un 4624 lo más cercano posible a la instalación del servicio. Quizás incluso prácticamente simultáneo.
Podemos usar Chainsaw de nuevo, buscando una marca de tiempo increíblemente cercana a la instalación del servicio identificada antes (EventID 7045) y filtrando por autenticaciones exitosas 4624.
chainsaw search ./ -s "2022-12-30T13:54:37" -e 4624 -s "S-1-5-21-746137067-1390067357-682003330-500" -i
Obtenemos resultados que corroboran lo que ya sabíamos, pero que ofrecen algunos hallazgos nuevos muy reveladores:
- Nuestra marca de tiempo de la autenticación 4624 es prácticamente la misma que la de la instalación del servicio 7045. Sumado al tipo de inicio de sesión (Logon Type), esto es indicativo de movimiento lateral
- Pasamos de entender que la cuenta implicada era SYSTEM, luego a tener solo el SID, y ahora por fin tenemos un nombre de cuenta: Administrator
- No obtenemos el nombre de una estación de trabajo (endpoint/equipo), pero sí una IPv4 interna
Genial, entonces nuestra hipótesis basada en la evidencia hasta ahora sugiere:
- Alguien que controla la cuenta Administrator realizó algún tipo de movimiento lateral desde 192.168.0.15 hacia el equipo.
- Este movimiento lateral derivó en un intento de instalación de un servicio que Defender neutralizó.
Al revisar los Huntress Agent instalados en esta red, ninguno reporta tener esa IPv4 privada.
Esto significa una de las siguientes cosas:
- Esta organización usa asignación dinámica de IP y, por lo tanto, lo que era 192.168.0.15 ya cambió ➡️ posible, pero poco probable
- No tenemos el Agent en el equipo con la IPv4 interna 192.168.0.15 ➡️ lo más probable.
Entonces, ¿eso significa que 192.168.0.15 es el equipo del adversario?
¿Cuál fue la alerta de Defender?
Así que ahora nuestras mentes están a mil. Repasemos nuestros hallazgos.
MUCHAS herramientas de seguridad ofensiva usan este movimiento lateral para todo tipo de jugadas —hablamos de Impacket, Cobalt Strike, Havoc—todos los chicos cool. Estamos viendo actividad rara y sospechosa, indicativa de la actividad maliciosa mencionada, con una cuenta privilegiada (Administrator) que actúa desde un equipo en el que no tenemos el Agent (192.168.0.15).
Pero, al mismo tiempo, nos falta mucha evidencia para hacer alguna afirmación aquí. No podemos dictaminar que esto es malicioso. Hemos aprovechado una constelación de artefactos diferentes, pero en realidad no podemos afirmar con autoridad que esto es maligno o adversario.
Podemos examinar los archivos implicados que Defender neutralizó. Podemos recuperar los archivos que Defender puso en cuarentena y someterlos a análisis de malware. Un análisis rápido de malware con Thor indica que este binario estaba asociado con remcom.
- Puedes pensar en remcom como algo parecido a psexec (más o menos)
Esta no es la prueba irrefutable que podría haber sido.
Pero también podría ser completamente legítimo, como hemos comentado en el pasado sobre otros binarios / servicios asociados con movimiento lateral.
La importancia de los reportes
Entonces, ¿a dónde vamos desde aquí?
La evidencia puede sumarse e interpretarse como movimiento lateral malicioso, neutralizado por Defender y desentrañado por el Huntress Security Operations Center (SOC)… pero, al mismo tiempo, el socio podría contextualizar la evidencia como legítima y, por lo tanto, no como una amenaza de seguridad.
Antes mencionamos brevemente la teoría de investigación. Sin importar la teoría exacta, como investigadores de ciberseguridad creemos que todos necesitamos conceptos cognitivos que nos guíen precisamente en estas situaciones. Todas estas teorías se basan en dejar que la evidencia hable, en lugar de permitir que el analista imponga su hipótesis como la verdad.
Dos figuras clave que lideran esta conversación son Katie Nickels y Chris Sanders. El objetivo de estos principios rectores es establecer parámetros y procesos para los métodos de investigación y análisis, con el fin de aportar mayor rigor y confiabilidad y superar las limitaciones de los sesgos o las suposiciones.
Ahora bien, no necesitamos empezar a dibujar tablas y gráficos ni hacer nada demasiado loco para adherirnos a un principio así. En nuestro caso, debemos recordar nuestro objetivo final: resumir y asesorar a nuestros socios. Nuestro reporte de incidente no necesita hipótesis contrapuestas ni anexos sobre los sesgos de nuestros investigadores. Solo necesitamos resúmenes técnicos sólidos de lo que hemos observado y recomendaciones accionables basadas en esas observaciones.
En este caso, escribimos un reporte para nuestro socio basado en nuestros hallazgos y luego lo anotamos para este blog.
Las anotaciones son, sin duda, un poco ‘Pepe Silvia', así que no te enganches demasiado con la locura. De todos modos, no tienes que leerlo todo, ya que abajo tienes, para tu deleite, algunas de las pautas y conclusiones que tuvimos en mente al escribirlo:
- Sé preciso cuando tenga sentido que el socio tome medidas de su lado, como con marcas de tiempo, cuentas de usuario, nombres de equipo y direcciones IP).
- No seas técnicamente preciso sin necesidad cuando el socio no pueda tomar medidas o no tenga sentido (por ejemplo, probablemente no sea necesario que entre en detalle en el reporte sobre qué es remcom, cómo funciona y a qué se parece).
- Ofrece recomendaciones accionables al socio cuando tenga sentido según el contexto. Observa que no le pido al socio una lista interminable de cosas, pero sí pido respuestas adecuadas al contexto.
- Encontrar el equipo 192.168.0.15 e instalarle un Huntress Agent, o identificarlo como desconocido; si la actividad le parece sospechosa, priorizar sus copias de seguridad; deshabilitar temporalmente la cuenta específica de este reporte para que el adversario no pueda controlarla.
- Habla con y a través de la evidencia. Observa que este reporte abre la mayoría de las oraciones con frases como “la evidencia sugiere”. No es casualidad. Observa también que, cuando no sabemos algo, no lo afirmamos (por ejemplo, no llamamos malicioso al movimiento lateral).
- Esto puede parecer pura gimnasia semántica arbitraria, pero te aseguramos que un reporte conciso y con autoridad, bien respaldado por evidencia y libre de suposiciones se siente diferente.
- Es probable que un lector tome en serio la amenaza porque te está tomando en serio a TI. Te estás presentando a ti mismo, tu análisis, tus hallazgos y las recomendaciones resultantes como confiables y bien fundamentados.
Y eso es todo lo que tenemos para ti
Esta investigación tomó más tiempo en redactarse que en ejecutarse y analizarse. 😂 Pero nos pareció apropiado, ya que en ella se aprovecharon varias técnicas, herramientas y consejos que quizás damos por sentado como reflejos.
Nada de lo que hacemos aquí en Huntress requiere un doctorado en hackología. Simplemente tenemos personas inteligentes, dedicadas y trabajadoras en todos los equipos. Y en la comunidad de infosec contamos con una increíble colección de personas, herramientas y documentación que pueden enseñarte a realizar investigaciones de seguridad con la misma letalidad, tenacidad y precisión que busca Huntress.
Lo que le falta a la mayoría de las personas —a menudo— es confianza. Lo vemos una y otra vez, dentro y fuera de Huntress. El personal tiene la capacidad, pero le falta confianza en su ejecución y su método.
Para ser transparentes, una crisis de confianza podría habernos asaltado muchísimas veces durante esta investigación:
- ¿Y si nos equivocamos al pensar que esto es movimiento lateral malicioso?
- ¡¿Y si nos equivocamos y el servicio se instaló correctamente, Defender no lo detuvo y el socio está comprometido en este momento?!
- ¡¿Y si estamos totalmente equivocados, todo esto es un falso positivo obvio y quedamos como unos tooontos?!
Esos pensamientos sin duda pasan por nuestras mentes.
Diríamos que el analista promedio duda de sí mismo el 40 % del tiempo y confía en su salsa el 60 %. A estas alturas, en Huntress confiamos en nuestra salsa un 95 % y dudamos de nosotros mismos un 5 %. No porque seamos infalibles, sino porque confiamos en que seguiremos aprovechando la constelación de telemetría y probando enfoques de investigación hasta encontrar alguna evidencia a la cual aferrarnos y un hilo del cual tirar.
Como dijo no hace mucho el analista sénior del SOC Matt Anderson:
“Si no tienes un buen proceso, probablemente tus resultados no serán buenos; si tienes un buen proceso, probablemente tus resultados serán buenos.” 🤯
Esperamos que este blog anime a tu equipo a probar nuevas técnicas o confirme que tus técnicas y procesos actuales son buenos.
Tienes que confiar en tu propia salsa, amigos. Si tienes curiosidad por los ingredientes de la salsa de Huntress, echa un vistazo a nuestros webinars Tradecraft Tuesday.
