Ataques de phishing usan páginas de navegador dentro del navegador y persistencia con RMM fraudulento

Antecedentes

El Centro de Operaciones de Seguridad de Huntress (SOC) detectó recientemente dos variantes interesantes de un mismo ataque que involucra una técnica de phishing de tipo browser-in-the-browser (BiTB). 

BiTB es una táctica en la que un atacante crea una ventana de navegador falsa completa (incluida la barra de direcciones, la URL, el ícono de candado, el favicon y más) dentro del contenido real de la página web, generalmente usando HTML/CSS/JavaScript. Como la ventana forma parte de la página web y no de una interfaz de navegador separada, la técnica puede eludir algunas de las señales de ingeniería social que los usuarios están entrenados para reconocer, como revisar la barra de direcciones en busca de un dominio sospechoso o ilegítimo.

Como se ve en la Figura 1, ambos incidentes de agosto comenzaron con un mensaje de phishing. Aunque no tenemos acceso a los señuelos de phishing en sí, nuestra telemetría indicó que los destinatarios del phishing objetivo hicieron clic en enlaces maliciosos dentro de los mensajes. Luego fueron redirigidos a una página de destino controlada por el atacante, donde se les pedía ver archivos a través de Adobe Acrobat (el lector de PDF de Adobe). Después de hacer clic en un aviso para "Ver archivos", a los objetivos se les presentó una página BiTB dentro de la página web. Esta página falsa parecía ser el sitio web oficial de Adobe (mostraba un subdominio oficial y legítimo de Adobe en la URL). Al seguir las instrucciones en la página BiTB, los objetivos descargaron sin saberlo un instalador de ScreenConnect, lo que llevó a la implementación de múltiples instancias no autorizadas de ScreenConnect en sus endpoints y binarios de evasión de defensas. 

Figura 1: La secuencia del ataque

Las técnicas BiTB no son nuevas, pero resaltan cuán persistentemente trabajan los actores de amenazas para convencer a los objetivos de caer en la trampa, no solo en el mensaje de phishing inicial, sino en cada etapa del ataque. A continuación, describimos la cadena de ataque para los dos incidentes y los Indicadores de Compromiso (IoC) relacionados para los defensores. 

Ingeniería social en profundidad

Incidente 1: un señuelo de prueba CAPTCHA, BiTB y persistencia 

El 25 de agosto, Huntress detectó actividad maliciosa en un endpoint vinculada a una instancia de RMM no autorizada sospechosa. 

Tras una investigación más profunda, los analistas del SOC descubrieron que el objetivo había interactuado con un correo de phishing en Gmail. Se convenció al objetivo de hacer clic en un enlace incrustado en el correo, que lo llevó a un señuelo de prueba CAPTCHA falsa (en https[://]adoube[.]vu/2a8ed9baefcd). Esta página de destino de phishing mostraba una falsa verificación de navegador de "Acceso seguro", pidiendo a los visitantes "confirmar tu navegador para continuar de forma segura" (como se ve en la Figura 2).

Figura 2: El dominio de redirección con una falsa verificación de navegador de "acceso seguro", que luego lleva al objetivo a la siguiente etapa del ataque 

En realidad, cuando el usuario interactuaba con la página, se iniciaba un flujo falso de ingeniería social con estilo de prueba CAPTCHA, que lo redirigía a https[://]adoube[.]vu/filedocacess/file.html. 

Como se ve en la Figura 3, esta página incluía un señuelo falso de "Lector de PDF" de Adobe. La página web mostraba al objetivo lo que parecían ser varios archivos borrosos con una ventana emergente encima que le decía que necesitaba actualizar o descargar "Adobe PDF Reader" para ver los archivos. 

Figura 3: La siguiente página web a la que se dirige a las víctimas, que les indica descargar un Adobe PDF Reader actualizado para ver los archivos 

Figura 4: Al hacer clic en "Ver archivos", las víctimas son llevadas a una página BiTB

Cuando la víctima hacía clic en el botón "Ver archivos" de la Figura 3, se le presentaba la pantalla BiTB que renderizaba una ventana de navegador falsa dentro de la página web, para engañar aún más al objetivo.

Como se ve en la Figura 4, la página web estaba configurada para parecer una página web oficial de Adobe. El dominio en la URL es get.adobe.com, un subdominio legítimo propiedad de Adobe y operado por esta empresa. Esa página web falsa le decía a la víctima que descargara "Acrobat Reader", abriera su carpeta de Descargas y diera doble clic en el archivo msi descargado de PDF Reader para iniciar la instalación.

Sin embargo, el supuesto archivo de instalación de "Adobe" era en realidad ScreenConnect.ClientSetup.exe, un instalador de ScreenConnect que se descargaba desde la infraestructura controlada por el atacante, hosthiifran[.]screenconnect[.]com. Cuando el objetivo abría su carpeta de Descargas y ejecutaba este instalador, en realidad se iniciaba una cadena de entrega de payload en varias etapas que finalmente descargaba dos clientes maliciosos de ScreenConnect y creaba puntos de apoyo relacionados. Una vez ejecutados e instalados, los clientes le permitían al actor de amenazas obtener acceso remoto persistente al endpoint de la víctima.

El primer cliente remoto inicial instalado fue el Cliente de ScreenConnect no autorizado (9c1aea531ba4c511) configurado para comunicarse con instance-uxh86b-relay[.]screenconnect[.]com. El atacante usó un dominio legítimo de relé de prueba de ScreenConnect para evitar aún más la detección.

Este Cliente malicioso inicial de ScreenConnect (9c1aea531ba4c511) usó el shell de comandos nativo de Windows (cmd.exe) y curl para obtener e instalar un segundo Cliente malicioso de ScreenConnect (7c1d255d0efefde6) configurado para comunicarse con la IP controlada por el atacante 144.172.115[.]59. Ambos clientes establecieron persistencia basada en servicios para mantener el acceso remoto.

Después de la instalación, el atacante usó esa segunda sesión no autorizada de ScreenConnect para ejecutar HideCursor.exe (que se encuentra en C:\Users\REDACTED\Documents\ScreenConnect\Temp\HideCursor.exe). Este es un binario de evasión de defensas que busca ocultar la actividad en pantalla. En este punto, Huntress detuvo la amenaza antes de que empeorara y recomendó a la organización desinstalar los clientes no autorizados de ScreenConnect y los artefactos relacionados.

Incidente 2: un correo de RingCentral y una "actualización de Adobe Reader"

El 31 de agosto, el SOC respondió a otro incidente que comenzó con un correo de phishing, incluyó un componente BiTB y terminó con la instalación de instancias no autorizadas de ScreenConnect. Durante este ataque, el objetivo interactuó con un correo de phishing a través de AT&T Office@Hand (RingCentral), la plataforma legítima de comunicaciones unificadas en la cloud de AT&T para empresas. 

En este incidente, AT&T Office@Hand fue el canal de entrega (no necesariamente la marca suplantada): el objetivo interactuó con un mensaje de Office@Hand que contenía un enlace malicioso y luego hizo clic hasta llegar a una página controlada por el atacante.

El objetivo hizo clic en el enlace malicioso del mensaje, que lo llevó a selectstructure[.]com[.]au/freedom/adobedocument.html. Este dominio usa el mismo señuelo de Adobe PDF Reader que el del otro incidente descrito anteriormente, junto con la misma plantilla y los mismos avisos.

Figura 5: La misma plantilla de página de phishing usada en otro incidente 

Figura 6: La misma página BitB aparece en este incidente, esta vez disfrazando el instalador de ScreenConnect como una actualización de Adobe Reader (AdbRdBkUpsStUp.msi) 

En este incidente, el instalador fraudulento de ScreenConnect se disfrazó como una actualización de Adobe Reader (AdbRdBkUpsStUp.msi) y se descargó desde victory[.]mkc1[.]digitaloceanspaces[.]com. Una vez ejecutado, el instalador llevó de nuevo a la descarga de dos instancias no autorizadas de ScreenConnect. 

Implementó el primer cliente no autorizado de ScreenConnect (d751818fd46e5ca9), configurado para comunicarse con relay[.]goldenmelon[.]us. Ese cliente (de nuevo) usó el shell de comandos nativo de Windows (cmd.exe) junto con curl para obtener e instalar el payload del segundo cliente no autorizado de ScreenConnect (patch.msi) desde hxxps[://]wir[.]consultingics[.]com/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest&c=GOODVIBE&c=&c=&c=&c=&c=&c=&c=. Esto llevó entonces a la instalación del segundo cliente de ScreenConnect (c19e38a20f1ba492), que se descargó desde scx[.]illuminantgroup[.]net y se configuró para comunicarse con relay[.]illuminantgroup[.]net.

Ambos clientes de ScreenConnect se registraron como servicios de Windows, estableciendo persistencia basada en servicios y canales redundantes para mantener el acceso remoto.

Tras la instalación del segundo cliente, el actor de amenazas usó la sesión de ScreenConnect asociada para ejecutar HideUL.exe. Este binario se usó para evadir las defensas al suprimir u ocultar el cursor y potencialmente reducir los indicios visibles de actividad interactiva.

En este punto, Microsoft Defender detectó y marcó una línea de comandos asociada con patch.msi (marcada como Trojan:Win32/Commando.A!ml). Si bien Microsoft Defender remedió esta amenaza en particular, finalmente no logró bloquear la ejecución. El segundo cliente fraudulento de ScreenConnect completó la configuración e intentó técnicas de evasión de defensas antes de que Huntress finalmente detuviera el ataque. Este es un buen ejemplo de por qué los actores de amenazas suelen usar múltiples RMM: incluso si se detecta una instancia, el actor de amenazas aún conserva un punto de apoyo en el entorno de la víctima. 

BiTB, persistencia y más

Estos incidentes muestran cómo un señuelo de phishing conocido puede convertirse en acceso remoto persistente cuando los actores de amenazas combinan páginas BitB con marcas confiables y RMM fraudulentos. Una página falsa de Adobe convincente, incluso una que muestre una URL de apariencia legítima, puede llevar a los usuarios a instalar clientes de ScreenConnect que dan a los atacantes acceso repetido y les ayudan a evadir la detección.

Para defenderse proactivamente de este tipo de amenaza, los defensores deben combinar la capacitación de los usuarios con controles técnicos:

• Capacita a los empleados para que traten con precaución las solicitudes inesperadas de actualización de software y las páginas de visualización de archivos, y asegúrate de que sepan verificar las descargas a través de canales confiables.

• Restringe quién puede instalar herramientas de gestión remota, mantén un inventario aprobado de software RMM, y genera alertas ante clientes de ScreenConnect nuevos o no aprobados, conexiones de relay inusuales y ejecutables lanzados desde las carpetas de Descargas de los usuarios.

• Monitorea los IoC descritos en este blog (como HideCursor.exe y HideUL.exe) e investiga rápidamente cualquier actividad sospechosa vinculada a enlaces de phishing.

Indicadores de compromiso (IOC)

Incidente 1

Incidente 2