Podríamos aprender una o dos cosas sobre lo que significa la agilidad de nuestros adversarios, también conocidos como actores de amenazas.
¿Algo no funciona? El plan B ya está listo.
¿La contraseña no se descifra? A fuerza bruta.
¿La shell que dejaron no da frutos? Inviértela.
Hace poco encontramos una reverse shell en los sistemas de uno de nuestros socios, con bastante ofuscación y otras actividades sospechosas que dejaron al equipo del Huntress Security Operations Center (SOC) negando con la cabeza. Vamos directo al grano y hablemos de las reverse shells.
¿Qué es una reverse shell?
Lo primero es lo primero: ¿qué es una reverse shell?
Hay muchas formas legítimas en que un administrador de sistemas puede conectar su equipo de administración a otra computadora: SSH, RDP, PowerShell remoting. Estos métodos para obtener una shell son legítimos y forman parte de la administración necesaria.
Las reverse shells, en cambio, pertenecen al arsenal malicioso del actor de amenazas.
Una reverse shell invierte la forma en que uno obtendría acceso legítimo a un equipo. En este caso, el equipo de la víctima se ve obligado a conectarse al equipo del atacante y regalarle una shell. Por ejemplo, si un atacante explota un servidor web Apache Tomcat vulnerable y puede ejecutar comandos mediante el exploit, iniciará una reverse shell para ejecutar comandos de forma mucho más fluida y sencilla.
A partir de ahí, el atacante tiene una conexión más confiable y cómoda para llevar a cabo su campaña.
Es la carta de reversa de UNO definitiva en el mundo de la ciberseguridad.
Cómo encontramos y analizamos el payload
Comportamiento de procesos maliciosos, nuestra función de Managed EDR, fue lo que primero nos alertó sobre esta actividad. Recibimos una alerta de que se estaba ejecutando un comando de PowerShell codificado en una de las computadoras de nuestro socio:
Revisamos el proceso padre para ver qué había generado esta tarea y nos horrorizó descubrir que era la instancia de ScreenConnect del socio. Eso nos indicó que el atacante tenía acceso al servidor de ScreenConnect. 💀
Lo especialmente aterrador de que un adversario controle la infraestructura de monitoreo y administración remotos (RMM) es que puede obtener acceso a las miles de computadoras conectadas, lo que le da una forma rápida y fácil de causar daños en cascada en toda la red.
Sin tiempo que perder, nos enfocamos en el payload codificado.
Fuimos directo a CyberChef para ver qué estaba pasando realmente con este script. El texto Base64 decodificado se convirtió en este comando de una sola línea, simple (pero intimidante):
Puedes interactuar con este payload tú mismo en CyberChef.
Desglosándolo un poco, el comando usa el método Invoke-WebRequest de PowerShell (IWR para abreviar), que envía solicitudes HTTP y HTTPS a hxxps[://]onerecoveryclick. Luego analiza la respuesta y devuelve colecciones de enlaces, imágenes y otros elementos HTML importantes, lo que al principio parecía normal.
Si revisas el sitio web con una herramienta como urlscan.io, lo único que verías es "loading...", y el código fuente del sitio tampoco muestra nada interesante.
Mucha gente podría ver esto y suponer que el dominio de preparación del actor de amenazas está inactivo y ya no representa una amenaza.
Sin embargo, en el Huntress SOC somos bastante curiosos, así que quisimos asegurarnos de cubrir todas las bases.
Cuando lo intentamos desde la línea de comandos con el comando wget, vimos algo un poquito picante. Hacerlo desde la línea de comandos nos permitió pasar el mensaje Loading… para ver si realmente había algo en el sitio.
Lo que encontramos era lo bastante 🌶️ como para necesitar un antiácido.
Enfocándonos en la reverse shell
Vamos a desglosarlo.
En este fragmento podemos ver que sin duda se devolvió contenido, incluida una dirección IPv4 pública (88[.]119[.]175[.]55), algunos scripts de PowerShell y una ruta SSH.
Eso ya era definitivamente sospechoso, así que extrajimos el resto del script con wget hxxps[://]onerecovery[.]click).rawcontent. Devolvió todavía más contenido ardiente. 🌶
No quiero que nos perdamos en los detalles, así que aquí tienes un resumen de las artimañas turbias de arriba:
- Una regla de firewall que permite conexiones SSH entrantes
- Dejó el ejecutable de SSH en esa carpeta
- Persistencia en forma de tarea programada
- Un archivo llamado
go.bat, que se usó para ejecutar el siguiente script por lotes
Podemos detenernos brevemente en el script por lotes, que creó el listener de la reverse shell hacia la IP que vimos en el script original, ¡¿y además creó persistencia en forma de tarea programada para iniciar el listener de la reverse shell SSH y que el atacante siempre tuviera acceso?!
Eso sí que es una persistencia insistente.
Si quieres echarle un vistazo al script de PowerShell, te tenemos cubierto.
Cómo rechazar y repeler las reverse shells
Sé que pasamos un buen rato hablando de lo genial que es lo malicioso, pero volvamos al TRABAJO. No trabajamos para Chicos Malos, S.A.
Tenemos algunos consejos defensivos específicos basados en los hallazgos de esta investigación.
1. Asegúrate de tener 2FA y credenciales sólidas en tu RMM.
Y compruébalo de verdad. No te imaginas cuántas veces alguien jura que 2FA está implementado en todas las cuentas, solo para descubrir que había una excepción en una cuenta.
2. Monitorea el tráfico de red entrante (¡y saliente!) en busca de comportamientos anómalos.
Sabemos que es más fácil decirlo que hacerlo. Y tendrás que tomar decisiones y hacer concesiones al monitorear el tráfico de red. ¿Vas a monitorear el tráfico DNS e ICMP, que generan mucho volumen (y el primero pronto estará cifrado), pero que son protocolos muy sigilosos que los actores de amenazas pueden usar? Monitorearlos implica costos de almacenamiento y procesamiento.
3. Considera implementar un sistema de detección de intrusiones/sistema de prevención de intrusiones (IDS/IPS) para detectar y prevenir este tipo de comportamiento.
No importa qué tan sólido hagas tu perímetro, las intrusiones son inevitables. Si el actor de amenazas va a entrar de todos modos, implementar los controles de seguridad adecuados te permitirá detectarlo, expulsarlo y recuperarte rápidamente.
4. ¡No descargues cosas al azar de internet!
La mayoría de las intrusiones que vemos en Huntress comienzan con adversarios que aprovechan el envenenamiento de SEO, envían archivos adjuntos masivamente por correo electrónico, o simplemente con usuarios que descargan cosas que no tienen por qué descargar. Educar a los usuarios sobre buenas prácticas de higiene cibernética es tu mejor defensa aquí, y es algo en lo que te ayudaremos muy pronto. 😉
***
Esperamos que hayas disfrutado este análisis técnico de una amenaza. Vemos este tipo de cosas 24/7, y nuestro equipo es tremendamente eficiente para investigar, asesorar y luego compartir sus hallazgos.
Si quieres conocer Huntress Managed EDR, puedes comenzar una prueba gratuita aquí!
