Hace mucho tiempo, me hicieron pedazos en una sesión de retroalimentación posterior a un incidente.
Pensé que era un buen informe. En realidad, fue uno de mis primeros, hace muchos años.
Sin embargo, uno o dos ejecutivos en esa sesión de retroalimentación empezaron a cuestionar la credibilidad del informe. “¿Por qué no tenía cien páginas?”, y “¿cómo puedes asegurar que algo pasó durante una ventana de tiempo?”, e incluso “¿cómo podemos estar seguros de que le diste toda tu atención?”
Al oler sangre en el agua, una voz disidente se convirtió en un frenesí de tiburones tratando de arrancarme un pedazo. El resto de esa sesión no se dedicó a explicar los matices de la intrusión, sino a recuperar la confianza, la credibilidad y la seguridad que mi informe no había logrado transmitir al cliente después de su incidente.
Una desafortunada constelación de factores hizo que uno de mis primeros informes de respuesta a incidentes no fuera bien recibido. Parte de esto se debió a mi inexperiencia y a mi evidente juventud. Un error importante fue que no había aprovechado todo el potencial del informe; no había logrado usarlo para generar una impresión de credibilidad en mi lector.
Triangulación para generar credibilidad
Estamos entrelazados en nuestros informes de incidentes, en nuestros resúmenes de nuevos días cero, en nuestros hilos de Twitter. En la redacción técnica hay algo de ego y vanidad, y cualquier duda sobre la eficacia de lo que escribimos es, por extensión, una duda sobre nuestra credibilidad.
No quiero que te derrumbes ante la primera crítica. En cambio, quiero que protejas tu vanidad y tu reputación dejando en tu lector cero dudas de que eres un experto que llega a conclusiones bien fundamentadas y basadas en evidencia. Con la evidencia y a través de ella, hablarás con una autoridad impecable.
La triangulación es un concepto de investigación tomado de las ciencias sociales que podemos pedir prestado y adaptar. Aquí, el investigador enriquece la validez y la fiabilidad de sus afirmaciones al aprovechar múltiples métodos y al combinar evidencia de varias fuentes de datos que apuntan al mismo fenómeno.
Dicho de forma más específica para la gente de seguridad informática, triangular implica usar múltiples fuentes de telemetría en una máquina para enfocarse en una teoría a la vez y así refutarla o confirmarla.
Después de esa terrible sesión de retroalimentación, cambié mi forma de escribir. La triangulación fue una de las muchas técnicas que usé para asegurarme de que el lector recibiera (de forma implícita o explícita) la impresión de que ese informe era lo más cercano posible a un hecho, y de que yo era un investigador de buena reputación y atención al detalle.
Ahora bien, tú y yo sabemos que soy un payaso (si no el circo entero) para la mayoría de las cosas, incluso si tu único contacto conmigo ha sido a través de mis blogs. Pero no cuando se trata de informes, quiero decir que voy en serio cuando escribo informes.
Y me gustaría que tú también fueras en serio cuando escribas los tuyos. Me gustaría que escribieras informes técnicos que no contengan ni una sola suposición o afirmación sin sustento, y que en cambio actúen como tu propia primera capa de revisión por pares. Puedes triangular tus hallazgos para corroborar tus hipótesis, teorías e ideas, y así producir informes que transmitan una confianza inquebrantable en tu lector además de contener excelencia técnica.
La triangulación en la vida real
¿Cuándo te he dado la receta sin sacar también algo fresco de la cocina? Usaremos un caso real como ejemplo de cómo se puede aplicar la triangulación en investigaciones reales.
Hace poco, mi colega Cat Contillo y yo encontramos tiempo libre para hacer un trabajo honesto de seguridad. Recibimos una alerta que nos pareció demasiado vaga, así que decidimos profundizar y elaborar un informe para el socio con un buen contexto y hallazgos aún más prácticos.
Pocas veces tenemos la suerte de contar con buenos registros de eventos de seguridad de Windows en una máquina determinada. En esta ocasión, Cat y yo no encontramos mucho en los registros, pero aprovechamos algunos artefactos forenses digitales para armar nuestra investigación.
La alerta que recibimos era sobre un posible movimiento lateral que terminó siendo PsExec. Podríamos haber enviado un informe genérico que apenas comunicara la amenaza... pero ese no es nuestro estilo. En cambio, recurrimos a varias fuentes de datos para contar una historia mucho más detallada y convincente que le diera al socio confianza en nuestro informe y nuestras recomendaciones.
Para triangular PsExec, voy a recrear nuestra investigación y mostrarte un par de artefactos interesantes que podemos recolectar, contrastar y comparar:
- Los datos del registro de Windows relacionados con PsExec
- El registro del Background Activity Moderator (BAM)
- La frecuencia de ejecución según Prefetch
Un momento sobre PsExec
Nuestra investigación debe partir de una buena base del fenómeno que queremos estudiar. Así que detengámonos un momento en PsExec.
PsExec es tanto una herramienta legítima de administración de sistemas como una herramienta que los adversarios usan para moverse lateralmente dentro de un dominio. En el ejemplo de este artículo, cuando ejecutamos PsExec desde nuestra máquina de origen (Thornfield), creamos una sesión remota en la máquina de destino (MoorHouse) y obtenemos una sesión interactiva con nuestro usuario 'JEyre'.
Explicación simplificada. Para más detalles, lee la publicación del blog de ExtraHop.
Una parte poco valorada de PsExec es el agente recíproco que aparece de forma efímera en la máquina de destino.
Monitorear la aparición de PsExeSVC.exe en algún punto de tu entorno es una gran oportunidad de detección. Una conexión de PsExec generará un EventID 7045 (Servicio) en el System.evtx de la máquina de destino para PsExeSVC. Esto nos dará la hora de la conexión en la que enfocarnos, además de confirmar la cuenta de usuario mediante el SID (que te mostraré cómo convertir en un momento).
Pero ten en cuenta que los adversarios pueden controlar el nombre del servicio usando la marca `-r` en PsExec, por lo que este no es un método de detección infalible.
Ahora que dedicamos tiempo a PsExec y reunimos algunos datos básicos para investigar, subamos el nivel y veamos qué artefactos podemos triangular para contar una historia más completa.
EULA aceptado en el registro
Los atacantes pueden intentar cambiar el nombre del ejecutable de PsExec para evadir la detección, pero algo que es menos probable que logren evadir es el impacto en el registro de Windows.
Podemos revisar nuestro registro para buscar EulaAccepted, que aparecerá con el valor '1' si PsExec se depositó en esta máquina y se aceptó la ventana emergente del EULA.
Podemos recorrer el registro desde HKEY_USERS para identificar qué cuentas de usuario (mediante sus SID) usaron PsExec.
HKEY_USERS\S-*\Software\Sysinternals\PsExec
Sin embargo, notarás que no obtenemos el nombre de usuario correspondiente de regalo. En cambio, obtenemos la larga cadena del SID. Para convertirla en un nombre de usuario, intenta esto:
¡O sobrediseña una solución!
Un problema de cerrar nuestra investigación aquí y ahora es que no tenemos idea de cuándo se modificó el registro ni de cuándo, o si, PsExec se ejecutó realmente.
Si una cuenta de usuario usó PsExec antes y de forma legítima, eso pone en duda la validez de suponer que ESTA actividad particular de PsExec fue del actor de amenazas y fue maliciosa. De los datos del registro, solo podemos concluir que PsExec estuvo en disco y asociado con la cuenta JEyre.
Background Activity Moderator (BAM)
Background Activity Moderator es una fuente interesante de telemetría, aparentemente disponible desde Windows 10 en adelante.
He escuchado afirmaciones de que BAM SOLO se puede encontrar en máquinas con Win10, pero esto definitivamente no es cierto: los datos de abajo se extrajeron de un Windows Server (Server 2022, versión 2009 build 20348). Sin embargo, no puedo decir que tenga ningún conocimiento preciso sobre exactamente en qué sistema operativo, builds y versiones BAM está o no presente. 🤷
BAM es útil para iluminar la ruta completa de un programa ejecutado, la hora en que se ejecutó y el SID o cuenta de usuario asociado con esa ejecución. Esto nos ofrece una capa de evidencia diferente a la de la aceptación del EULA, que podía decirnos que PsExec existió alguna vez bajo JEyre, pero no podía ofrecernos una hora.
Para consultar BAM, tienes dos opciones:
- La primera es simplemente revisar manualmente los datos del registro. Esto puede ser desordenado y no convierte los SID por ti, pero, ¿acaso no se siente bien ensuciarse las manos de vez en cuando?
- La segunda es aprovechar el script de PowerShell Get-BAMParser.ps1 de Matthew Green, que incluye un formato más agradable y convierte los SID en cuentas de usuario. Hice una solicitud de cambio en este script para que funcionara con Server 2022.
Si es manual: ¡no necesitas un script elegante! Solo buenos ojos. Sin embargo, lo que perdemos aquí son las marcas de tiempo.
Y si usas el script, prepárate para hacer ZOOM. Obtenemos marcas de tiempo mediante el script de PowerShell, lo cual es una capa de evidencia enorme y necesaria.
Al analizar los datos de BAM sobre PsExec, obtenemos la cuenta de usuario JEyre junto con la ruta completa de ejecución. Esto es útil, ya que corrobora lo que indicaban los datos del registro del EULA sobre JEyre, y ahora tenemos directorios específicos que podemos investigar para ver si el actor de amenazas depositó otras herramientas. Además, BAM ofrece un contexto más amplio de algunas actividades que ocurrieron, y podemos empezar a contextualizar lo que hizo el actor de amenazas mientras estuvo en nuestro entorno.
Una limitación de BAM es que confía en el nombre del ejecutable. Si lo renombramos NotPsExec.exe, así es como BAM lo registrará y nos lo informará después de analizarlo. A diferencia de revisar los datos del registro del EULA, que confirman que PsExec se ejecutó y se aceptó, BAM se basa en la sinceridad del nombre del ejecutable. Además, BAM ofrece poca claridad sobre la frecuencia de ejecución. ¿Es esta la primera vez, la última vez, o cualquier otra vez que el actor de amenazas usó la cuenta de JEyre para ejecutar PsExec?
Tenemos una imagen mucho más clara que cuando empezamos. Pero ahora necesitamos empezar a reunir información procesable para nuestro lector.
Prefetch
Ya he hablado de prefetch antes. Está deshabilitado automáticamente en Windows Servers, pero se puede habilitar con facilidad. Si no puedes aprovechar prefetch para triangular, te sugiero usar Amcache y Shimcache en su lugar.
Puedes obtener información temprana si revisas el directorio de prefetch en el endpoint. Lo que se ejecuta tendrá un archivo .PF, pero con solo mirar este directorio ya obtienes información útil.
Puedes tomar un archivo .PF y analizarlo usando la herramienta PECmd de Eric Zimmerman:
Al aprovechar prefetch, obtenemos algo bastante interesante que no teníamos antes: la frecuencia precisa de ejecución. Se nos indica que un ejecutable llamado PsExec.exe se ejecutó seis veces, y las horas de ejecución se muestran con precisión. Además, prefetch no confirma una cuenta de usuario, pero sí ofrece información sobre los directorios referenciados cuando se invocó PsExec.
Digo un ejecutable llamado PsExec.exe, porque prefetch no puede verificar el nombre del ejecutable. Al igual que BAM, confía en el nombre del ejecutable y basa el registro de los datos en ese nombre. Así que, si se renombró como NotPsExec.exe, eso es lo que veríamos.
Sin embargo, la manipulación del nombre no vuelve inútiles los datos de prefetch. Podemos seguir triangulando nuestros hallazgos pivotando hacia la máquina de destino. En el directorio de prefetch del destino, podemos encontrar un registro de PsExeSVC.exe: el agente recíproco de PsExec.
Al analizar el archivo de prefetch de PsExeSVC, obtenemos una marca de tiempo más certera. Esto supone que el actor de amenazas no cambió el nombre del servicio (como ya señalamos), pero podemos ver un momento mucho más específico que respalda nuestras seis horas de PsExec mencionadas antes, según el prefetch.
Y cerrando el círculo de nuestra triangulación, en realidad ya habíamos visto esta marca de tiempo cuando revisamos el EventID 7045 en el registro del sistema de la máquina objetivo. Así, tenemos conclusiones casi certeras sobre el momento de la actividad.
Una limitación del prefetch es que, primero, debe estar presente en el equipo, y segundo, que carece de la capacidad de atribuir cuentas de usuario y confía demasiado en la sinceridad de los nombres de los ejecutables. Pero estas fallas se compensan con la información de otra telemetría que hemos aprovechado, y además, ahora tenemos una ventana de tiempo más precisa para ofrecerle al lector sobre la actividad maliciosa.
Capas de evidencia
Como capas de queso suizo, las distintas fuentes de telemetría tienen vacíos por separado, pero combinadas forman un bloque más sólido; se cuenta una historia más definitiva y creíble una vez que reunimos y triangulamos nuestros datos.
Nuestro informe sobre el movimiento lateral se volvió más preciso gracias a la triangulación. Pudimos confirmar que el movimiento lateral era efectivamente PsExec mediante los eventos 7045 en el registro del sistema, los datos del EULA y del BAM en el registro, además del prefetch, que aportó mayor detalle sobre la frecuencia y la ubicación de la ruta.
Al triangular estas distintas fuentes de telemetría, y usar las fortalezas de cada una para compensar sus debilidades, reunimos datos increíblemente específicos sobre los que nuestros lectores pueden actuar. Corroboramos la cuenta de usuario asociada con PsExec (JEyre), establecimos los directorios involucrados (C:\Users\JEyre\Downloads\PsTools) y determinamos una ventana de tiempo (4 de abril de 2022, de 02:32 a 03:17 UTC).
Espero haber logrado transmitir que la triangulación es un concepto que vale la pena tener presente durante una investigación. Es probable que ya la estés aplicando, y ahora conoces una palabra elegante para describirla.
El objetivo de la triangulación no es demostrar lo mismo diez veces. El objetivo de la triangulación es conocer las limitaciones de cada componente forense digital individual, y reunir varios de estos artefactos para compensarlas y aportar hallazgos únicos que den más matices al fenómeno que estamos investigando.
Para cerrar
Todos sabemos que el resumen ejecutivo de la primera página será donde la mayoría de los lectores empiecen y terminen. Quizás queramos que la gente lea nuestros informes de principio a fin. Pero también queremos que nuestros lectores confíen en nosotros, en nuestras recomendaciones y hallazgos desde la primera página en adelante.
Gracias a la triangulación, podemos ofrecer informes cargados de información procesable para que el lector actúe, con la confianza de que nosotros, los investigadores, hemos informado con la mayor precisión posible.
No necesitamos escribir con rodeos para comunicar nuestros hallazgos; se trata de usar un lenguaje específico y ciertas frases que demuestren que eres un investigador que habla con autoridad respaldada por evidencia sobre el tema. Quizás en algún momento escriba sobre el vocabulario particular que adopto al redactar informes (mantente atento). En todo caso, espero que hayas disfrutado leer sobre la triangulación, y espero que te salve el pellejo la próxima vez que tengas que reportarle a un superior técnico o a un ejecutivo.
Una limitación importante de la triangulación es que requiere que el investigador conozca y tenga acceso a múltiples fuentes de datos que puedan dar cuenta del fenómeno que está estudiando. Me temo que no tengo una buena respuesta para esto: tendrás que revisar algunos materiales de la comunidad DFIR y empezar a formarte por tu cuenta. O simplemente puedes seguir leyendo mis artículos en nuestro blog de Huntress. 😉 ¡Por qué no ambas cosas!
