Hay muchísimos artículos y guías rápidas que les aconsejan a los defensores cómo monitorear, cazar y detectar al adversario en su entorno. Pero a veces parece que hay menos publicaciones que nos aconsejen qué hacer una vez que atrapamos al adversario.
Todos lo hemos vivido durante un incidente: atrapaste al adversario con las manos en la masa, en plena campaña y antes de que cause daños graves. Ahora tienes la tarea de negarle al adversario cualquier otra oportunidad. ¡Es el turno del defensor de hacerle pasar un mal rato al atacante!
Buscar en Google “cómo sacar a un atacante de mi active directory” o “cómo matar la shell de un hacker desde una computadora Windows” realmente no ofrece muchos consejos. Y lo realmente irónico es que este es el tipo de consejo que a todos los defensores nos vendría bien.
En este blog, describiré varias cosas que te ayudarán la próxima vez que atrapes a un atacante. Veremos…
- Cómo se ve el ataque desde las perspectivas del defensor y del atacante
- Cómo profundizar y encontrar datos que arrojen luz sobre las actividades de los adversarios
- Algunos comandos que te permitirán expulsar al adversario
Escenario
Nota: ¡Ninguno de los nombres de usuario ni de las capturas de pantalla de este artículo proviene de nuestros socios o clientes! Todos los detalles son ficticios, pero las técnicas de seguridad son reales.
Imagínalo: son las 2 a. m. Recibes una alerta de que tres usuarios están haciendo algo sospechoso en un servidor clave. Te conectas a la máquina y empiezas a investigar exactamente qué está pasando.
Conoces a los usuarios: AFairfax, BMason y ERochester. Tienen privilegios medios en tu Active Directory, ¡pero definitivamente no estarían trabajando a las 2 a. m.! Puedes profundizar con un poco de PowerShell para averiguar qué están haciendo en este momento en este servidor:
Este one-liner de PowerShell nos da visibilidad del proceso que se está ejecutando en la primera columna, la cuenta de usuario asociada con el proceso en la columna del medio, así como el ejecutable y los comandos subyacentes que iniciaron el proceso en la última columna.
Algunos de estos procesos no parecen especialmente maliciosos, ya que son programas legítimos (como rdpclip y wsmprovhost.exe), mientras que otros procesos se ven muy mal (sharphound.exe tiene una extraña relación de redirección con un recurso compartido SMB local).
Podrías simplemente matar los procesos individuales, pero eso no expulsaría al adversario de tu entorno. Sería solo una leve molestia para el adversario, ya que probablemente tiene credenciales comprometidas y obtuvo acceso remoto a la máquina, lo que le permite volver a conectarse de forma remota y reiniciar el proceso que acabas de matar. Además, esto le haría saber que los defensores le siguen la pista (al final te explico por qué esto es un problema).
Entonces, ¿qué deberías hacer?
Bueno, expulsemos estas tres cuentas manipuladas de tu Active Directory y evitemos que el adversario las siga aprovechando de forma permanente.
Comunicación remota de PowerShell (WinRM)
Monitoreo
Empezaremos con el usuario AFairfax. En nuestro primer examen, el único proceso de AFairfax en ejecución en el servidor era wsmprovhost.exe. Si echamos un vistazo a nuestra instancia de Elastic, que recopila nuestros logs, vemos que detectó que wsmprovhost generó un ‘whoami’.
Wsmprovhost es un ejecutable que da soporte a la comunicación remota de PowerShell y Windows Remote Management. Es una funcionalidad legítima e integrada que le permite a un usuario iniciar sesión de forma segura en otras máquinas y ejecutar comandos (piénsalo como una alternativa a SSH, si quieres). Pero en nuestro escenario, esto definitivamente es malo. Sabemos que el usuario AFairfax está en la cama durmiendo profundamente, así que alguien malintencionado secuestró su cuenta.
Desde el punto de vista del adversario, puede aprovechar WinRM para acceder a nuestro servidor desde su máquina de ataque proporcionando las credenciales del usuario.
Profundizando
El adversario inició sesión y ejecutó whoami. Como teníamos monitoreo implementado, ¡atrapamos esta travesura fácilmente!
Sin embargo, si tu solución de logs aún no está implementada, o necesitas verificarlo desde el servidor, tengo un fragmento de código de PowerShell increíble para ti.
En la flecha roja, se nos indica que la shell todavía está conectada y activa. La flecha rosa nos indica que AFairfax es el usuario que actualmente está conectado de forma remota, y el ShellRunTime junto a la flecha azul nos indica que AFairfax ha estado usando WinRM durante los últimos 26 minutos.
Expulsar la shell remota de PowerShell de AFairfax
Ya basta. ¡Echemos al atacante! Para expulsar una shell remota de PowerShell a mitad de sesión, podemos deshabilitar por completo esa cuenta de usuario en Active Directory.
Desde la perspectiva del adversario, perderá la autorización en la sesión remota a mitad de camino. Además, cuando intente volver a autenticarse, se decepcionará al ver que deshabilitamos la cuenta por completo.
WMIexec de Impacket
Antes notamos que los procesos que pertenecían al usuario ERochester tenían comandos subyacentes extraños. Estos comandos, como redirigir la salida a un recurso compartido de localhost, son indicativos del kit de herramientas de Impacket, específicamente de WMIexec en nuestro caso. WMIexec aprovecha Windows Management Instrumentation para tener un impacto potente y silencioso en una máquina víctima.
Monitoreo
Aunque Impacket es un kit de herramientas sigiloso, una solución de logs madura capturará suficientes rastros de actividad como para justificar la sospecha de un defensor.
En el recuadro rosa, vemos el proceso que ejecuta el `net time` de ERochester, y en el recuadro verde, vemos el inicio del proceso que ejecuta ‘whoami’. Así se ve WMIexec de Impacket del lado receptor. Observa la redirección hacia ADMIN$: una señal reveladora.
Para que el atacante ejecute comandos en nuestro servidor, basta con un one-liner relativamente simple que, de nuevo, depende de tener las credenciales del usuario objetivo.
Como adelanto extra especial, aquí tienes un pequeño vistazo de cómo el equipo del SOC de Huntress vería esta misma actividad de procesos mientras el actor de amenazas se hace pasar por ERochester.
Profundizando (aún) más
Si no tienes una solución de logs, te aseguro que no todo está perdido. Si necesitas revisar más datos para determinar actividad maliciosa de Impacket u otras herramientas, he escrito en otro lugar sobre cómo aprovechar técnicas de análisis forense digital y respuesta a incidentes en una investigación sin logs.
Un lugar donde podemos mirar rápidamente es el directorio prefetch, disponible en endpoints Windows y no en servidores.
Expulsar el Impacket-WMIexec de ERochester
Bueno, ya todos vimos suficientes datos para concluir que se trata de actividad maliciosa. Resolvámoslo.
Primero, cambiamos dos veces la contraseña comprometida de ERochester.
Esta no es la solución definitiva. El almacenamiento en caché de contraseñas puede presentar una complicación que beneficia al adversario. Cambiar la contraseña dos veces ayuda a garantizar que no le regalemos al adversario acceso persistente con la contraseña o el hash anterior que todavía sirva para autenticarse.
Para estar seguros, podríamos y deberíamos deshabilitar la cuenta por completo por ahora, como hicimos con la cuenta de AFairfax.
Como capa final adicional de expulsión, también podemos sacar a ERochester del grupo de administradores, negándole al adversario los privilegios que antes necesitaba para ejecutar Impacket de forma efectiva.
Desde la perspectiva del adversario, pasa de poder ejecutar comandos (en el recuadro verde) a perder su shell y ya no poder volver a autenticarse como ERochester (recuadro rojo).
Protocolo de escritorio remoto (RDP)
Si recuerdas nuestra primera evaluación de los procesos del servidor, BMason estaba asociado con un simple ‘rdpclip’. Sin embargo, como sabemos que el verdadero BMason está dormido a las 2 a. m., sabemos que debemos investigar más a fondo para deducir qué hizo el adversario.
Monitoreo
RDP es un servicio legítimo, como WinRM, que puede ser aprovechado por los adversarios. Como es una funcionalidad legítima e integrada, su uso podría no activar una alerta si no configuras alarmas específicas. Además, muchas detecciones de RDP dependen del puerto 3389, a pesar de que se puede cambiar este puerto predeterminado.
Desde la perspectiva del defensor, podemos ver que Elastic capturó todos los rastros de una sesión RDP generada por BMason. Pero observa la columna ‘source.domain’, que delata que el usuario BMason está interactuando desde la máquina ‘kali’. En la vida real, quizás la máquina de un atacante no tenga un nombre tan obvio. Este tipo de telemetría puede ayudarte a determinar si la sesión RDP que estás observando es maliciosa o legítima.
Desde la perspectiva del adversario, ¡basta con una línea relativamente simple para aprovechar las credenciales robadas de BMason y obtener una sesión RDP en nuestro servidor! 😱
Profundizando (aún) más
Pero quizás no tenías tu SIEM configurado, ¡y tus logs están ahí en el servidor, sin analizar y olvidados!
No te preocupes: tengo un one-liner genial para ti. Consultará el log de RDP, pedirá los momentos en que un usuario se conectó de forma remota al servidor y delatará su nombre de usuario y su dirección IP de origen.
Expulsar el RDP de BMason
Ahora que determinamos con precisión que el adversario está abusando de la cuenta de BMason para conectarse por RDP, ¡expulsémoslo! Este es uno de los métodos de expulsión más sencillos:
BMason se ve obligado a cerrar sesión, y terminamos la GUI de RDP que el adversario disfrutaba hasta ahora. Ahora podemos repetir con BMason el cambio de contraseña y la deshabilitación de la cuenta que hicimos con los usuarios anteriores.
¿El adversario está en algún otro lugar?
Quizás el adversario tiene otras cuentas comprometidas. Tal vez haya iniciado sesión en otro lugar de tu dominio de Active Directory.
Para profundizar en esto, te recomiendo los scripts de YossiSassi Get-UserSession.ps1 y Get-RemotePSSession.ps1.
Estos te mostrarán qué cuentas de usuario tienen sesión iniciada en este momento, y en qué máquinas, en todo tu dominio. Eso sí, esto generará MUCHÍSIMOS datos en un Active Directory del mundo real.
Alertar al adversario
Los incidentes tienen una relación interesante con el tiempo. Cuando se descubre al adversario, los defensores deben, al mismo tiempo, reconstruir lo que pasó en el pasado a través de logs y artefactos, trabajar a toda velocidad en el presente para bloquear al adversario y luego implementar defensas mejoradas en el futuro inmediato. En otras palabras, a los defensores nos jalan en muchas direcciones.
Si sigues la guía de este artículo, expulsarás al adversario con facilidad. Pero antes de salir volando a arruinarles el día a los atacantes, considera que, en el momento en que empiezas a intervenir e interrumpir su campaña, estás alertando al adversario; él ahora sabe que tú sabes. Un adversario presionado y apurado puede priorizar borrar sus huellas (lo que dificulta identificar sus métodos de acceso inicial) o ejecutar algo devastador como despedida final (ransomware en las máquinas a las que todavía tiene acceso).
Prioriza tu tiempo siguiendo estos pasos:
- Alguien del equipo de defensa necesita revisar a fondo los logs. Debe encontrar el método de acceso inicial y luego identificar y deshacer cualquier mecanismo de persistencia que el atacante se haya regalado.
- Un defensor enfocado en el presente puede combatir al atacante, pero es mejor hacerlo una vez que entiendas con seguridad el acceso inicial y la persistencia del adversario. Por supuesto, si ves que el adversario llega a máquinas clave o empieza actividades devastadoras, interviene.
- Después del incidente, los equipos de TI y de seguridad deben trabajar juntos para implementar de inmediato los cambios tecnológicos y culturales necesarios para evitar un nuevo compromiso similar.
¡Y eso es todo!
Analizamos las herramientas que los adversarios pueden aprovechar para moverse por un entorno, nos enfocamos en cómo se ven estas herramientas en acción y luego, lo más importante, tuvimos una conversación detallada sobre los comandos y técnicas defensivas para expulsar al adversario de tu red.
Consulta las Blue Team Notes para ver más comandos geniales para defensores. Escríbeme en Twitter si reconociste la literatura clásica a la que hago referencia a lo largo de este artículo.
¿Quieres descubrir cómo la detección y respuesta administradas pueden ayudarte a encontrar y expulsar a hackers? Descarga nuestro eBook, Detección y respuesta administradas: la capa que falta en tu stack de seguridad.
