Falso correo de phishing de Bank of America "Acción requerida" entrega ScreenConnect en su lugar

Agradecimientos: Huntress desea reconocer los aportes de Andrew Schwartz, del equipo DE&TH, por su trabajo en el seguimiento de las tendencias de abuso de herramientas de monitoreo y gestión remota (RMM).

TL;DR: Huntress recibió un correo enviado a una cuenta trampa (honeytrap) que simula provenir de Bank of America. El correo invita al destinatario a visitar lo que dice ser el sitio web del banco. Sin embargo, un enlace al "Centro de seguridad" en realidad entrega un script de Visual Basic que, al ejecutarse, inicia una cadena de varias etapas que decodifican contenido complejo y termina en la descarga de un instalador de ScreenConnect. 

Huntress recibió un mensaje en una cuenta de correo trampa para spam (spamtrap) el 28 de julio que parecía provenir de Bank of America: el correo llegó desde onlinebanking@ealerts[.]bkofamerica[.]com.

Figura 1: El malspam te invita a una visita

Como se ve en la Figura 1, el correo inicial del actor de amenazas usa un recurso conocido: una advertencia urgente de una institución financiera. El mensaje advierte al destinatario que tiene cerca de dos semanas para "confirmar" la información de su cuenta, e insta a "actuar rápido para evitar restricciones en la cuenta". El mensaje incluye la dirección del destinatario tanto en el cuerpo (al pie de la página) como en la cadena de consulta del enlace incrustado en el mensaje. 

Como se ve en la Figura 2, el enlace del mensaje original es una redirección que lleva a una página web, también diseñada para imitar de cerca la imagen corporativa de Bank of America. 

Figura 2: La URL del correo no te lleva al sitio web de Bank of America, sino a un sitio que te redirige a la página de phishing

En esta etapa, el ataque se configura de forma distinta según el tipo de dispositivo que use la víctima. Cuando un objetivo visita la página desde una Mac (o un navegador que reporta un User-Agent distinto de Windows), se le redirige a una página de phishing convencional que solicita el nombre de usuario y la contraseña del cliente bancario (dos veces, simulando un error que sugiere que el objetivo escribió mal su contraseña). Luego pasa a otra página que pide el nombre del cliente, su dirección postal completa, datos de identificación oficial, el número de Seguro Social y los datos de la tarjeta de crédito o débito de Bank of America del objetivo. 

Figura 3: Usar una Mac (o solo una cadena de User-Agent de Mac) te lleva a una página de phishing ligeramente distinta

Figura 4: Se te invita a descargar e instalar "Account Guard" mediante un botón de "Update My Information"

Al hacer clic en el botón "Update My Information" de la página se entrega un archivo llamado AccountGuardSetup.zip, que contiene un archivo de Visual Basic Script (AccountGuardSetup.vbs). 

Figura 5: Esta es una señal de alerta

Querido lector, nunca ejecutes un archivo con extensión .vbs a menos que tú mismo lo hayas creado o sepas exactamente qué hace.

Ejecutar ese archivo lleva a la instalación del RMM ScreenConnect en el sistema del objetivo, que puede elevar sus propios privilegios en silencio mediante un script en C# (también entregado en la cadena de ataque) que invoca el bypass de UAC de la interfaz COM ICMLuaUtil (que corresponde al método MITRE ATT&CK T1548.002).

Pero antes, retrocedamos un paso y veamos el archivo en sí. 

Para complicar el análisis, el atacante usa una cantidad inusual de blobs de datos incrustados y codificados en base64 dentro de cada script que ejecuta una etapa del ataque. Como base64 es una forma de codificar contenido binario como texto de apariencia inofensiva, esto ya dificulta el escaneo estático, pero al anidar varias capas así, pueden retrasar aún más los esfuerzos de triaje. 

Yo dawg, supe que te gusta decodificar base64

El fragmento de datos y comandos codificados en base64 del script guarda los datos decodificados como un script de PowerShell en la carpeta Mis Documentos del usuario, y luego lo ejecuta tras una espera.

Figura 6: Una mirada más de cerca al script que contiene base64 y código para extraer algo de él

Ese script de PowerShell solo contiene otro blob de datos codificado en base64 y una instrucción para decodificar e invocar el contenido.

Figura 7: Tienes tu base64 dentro de mi base64

El nivel final de decodificación produce… otro script de PowerShell más. 

Figura 8: Por fin llegamos a algo... así que podemos descargar y decodificar más base64

Para ser claros, eso es un script de PowerShell, dentro de un script codificado en base64, dentro de un blob de datos codificado en base64 que otro script decodifica.

La versión final decodificada del script de PowerShell cumple varios propósitos.

Primero, descarga un archivo codificado en base64 desde el sitio público para compartir archivos, por lo demás legítimo, UploadToURL.com, y luego decodifica el contenido. El archivo, de 17 MB, se decodifica para convertirse en un instalador de ScreenConnect .msi que el script escribe en %localappdata%\Microsoft\sc.msi. 

Y entonces las cosas empiezan a ponerse raras.

Llaves bajo la maceta

Este script de PowerShell realiza una tarea de descifrado sobre dos blobs de datos adicionales incrustados en sí mismo. Los blobs de datos están cifrados con el algoritmo AES-128-CBC y aparecen en el script como largas cadenas de bytes hexadecimales.

Figura 9: Los datos AES convenientemente traen consigo sus propios secretos de descifrado

Para descifrar estos blobs de datos, el algoritmo AES necesita tanto un valor de clave como una cadena de 16 bytes llamada vector de inicialización, o IV. El script guarda la clave como una cadena de texto plano en UTF-8 en una variable llamada $key, y la subrutina de descifrado del script toma los primeros 16 bytes (32 caracteres hexadecimales) de cada blob de datos para usarlos como IV. 

Es el equivalente, en materia de cifrado, de colgar la llave de tu puerta principal en la misma puerta con una etiqueta que dice "puerta principal".

Escalada de privilegios y otras jugarretas

Los dos blobs cifrados con AES son un poco más interesantes que un simple script de PowerShell más. 

Uno de los blobs se convierte en el código fuente de un pequeño programa escrito en el lenguaje C# (descifrado en una variable llamada, convenientemente, $csharpCodeDecrypted). 

Figura 10: Este exploit permite que el malware se instale sin una solicitud de UAC

El script descifra este código C#, luego lo compila y ejecuta el producto final, usando una omisión del Control de cuentas de usuario (UAC) para que los objetivos no se den cuenta. Las solicitudes de UAC son una de las señales visibles que recibe un usuario cuando algo intenta cambiar configuraciones a nivel del sistema, y omitirlas permite que el malware se instale en silencio. 

En este caso, el script usa un exploit conocido de omisión de UAC a través de la interfaz COM elevada ICMLuaUtil. El exploit permite al actor de amenazas ejecutar comandos de PowerShell arbitrarios con privilegios de administrador sin activar una solicitud de "escalada de privilegios" de UAC al usuario. 

El código del exploit parecía haber sido tomado, tal cual, de un repositorio de Github donde un investigador de seguridad lo publicó hace años. 

El script de PowerShell usa este exploit para ejecutar el archivo sc.msi de ScreenConnect, de modo que se instala con privilegios de administrador. El instalador también configura ScreenConnect bajo el nombre de servicio Windows Security, para que no sea evidente de inmediato qué es.

El segundo blob cifrado con AES se descifra en un VBScript que hace dos cosas: elimina la clave del Registro que apunta al instalador de ScreenConnect e impide que ScreenConnect aparezca en la lista de aplicaciones instaladas (o que se pueda desinstalar normalmente). 

Figura 11: El script hace que el payload sea invisible, inmodificable e irremovible

El script luego usa el Lenguaje de Definición de Descriptores de Servicios de Windows (SDDL) y las Listas de Control de Acceso (ACL) para impedir que los objetivos hagan cambios en su computadora y para ocultar el proceso de ScreenConnect.

Las cadenas SDDL describen quién es el propietario de un objeto, quién puede acceder a él y qué se audita, mientras que las ACL de auditoría son parte del descriptor de seguridad que hace cumplir ese acceso. Al establecer un conjunto de descriptores de seguridad SDDL y ACL de auditoría, el script intenta esquivar el servicio (real) Windows Security de Microsoft para tratar de ocultar el servicio y negar a usuarios, administradores y otros servicios la capacidad de hacerle cualquier cambio, verlo, ver cualquier registro que genere, e incluso oculta la carpeta C:\ProgramData\Windows Security para que no se vea a simple vista usando el Explorador.

Finalmente, después de que ambos scripts se ejecutan, el PowerShell principal elimina a los dos del sistema de archivos del objetivo.

Una vez instalado ScreenConnect, la computadora del objetivo abre una conexión a 217.60.195[.]167 por el puerto 8041/tcp y espera a que el actor de amenazas se conecte a ella. La dirección IP se geolocaliza en los Emiratos Árabes Unidos y tiene una reputación cuestionable, dado que parece que varias otras familias de malware usan esta dirección como comando y control (C2). 

Figura 12: El mapa de red muestra solo una conexión en común, una IP de hosting usada tanto por el dominio de redirección del enlace inicial como por el sitio que aloja la página de phishing y el malware

Guía de mitigación 

La manera más simple de mitigar un ataque como este es prestar mucha atención a de dónde viene un correo y hacia dónde apuntan los enlaces. En este caso, la dirección de remitente del correo no apuntaba al dominio legítimo de Bank of America, sino a bkofamerica[.]com. El enlace en el mensaje apuntaba, de nuevo, no a Bank of America, sino a kleinschnitg[.]com, que luego abría una página en sectioncompil[.]com desde la cual se originaba el zip malicioso. Un usuario atento podría identificar la anomalía solo prestando atención a la barra de direcciones.

La remediación, en este caso, podría ser mucho más difícil debido al uso de las ACL de SDDL que impiden que un usuario haga cambios en la computadora y ocultan el proceso de ScreenConnect. Esta práctica infografía destaca los cambios que este actor de amenazas hace en las computadoras Windows objetivo.

Figura 13: Este gráfico desglosa cómo el actor de amenazas usó SDDL para ocultar su rastro

Indicadores de compromiso (IOC)

Huntress ha publicado estos indicadores en nuestro repositorio de Github.