Encontré una página que suplantaba a Claro y ofrecía descargar la supuesta aplicación del operador.
Ya no es el phishing típico con un formulario para robar usuario, contraseña o tarjeta. El botón de descarga entregaba directamente un APK para Android.
La página también decía que la aplicación estaba disponible para iOS. El botón de iOS no tenía ningún link. Android sí tenía el enlace de descarga.
No había un IPA,ni otro payload para dispositivos Apple.
Este análisis corresponde a la cadena que vi en el paquete de Android.
Página utilizada para distribuir la supuesta aplicación de Claro.
La landing
La página estaba en español y copiaba todo el look and feel de Claro.
El botón principal descargaba:
CLARO_5G.apk
La landing anunciaba ambas plataformas, pero solo Android tenía un enlace de descarga.
El código estaba generado con Next.js y estaba minificado. También conservaba metadatos canonical y Open Graph hacia claro-red[.]app, aunque la muestra que analicé estaba en otro dominio.
Puede ser un rastro de otra versión de la misma plantilla.
Primera etapa
El archivo descargado se presentaba como CLARO 5G.
Package:
com.app.service.manager
SHA-256:
049cdecfd9a765a1cb8f2abafa168453cd6eb8431646dcb82737600b251a5854
El APK era un dropper.
Al ejecutarlo aparecía otra interfaz con el logo de Claro, pero en portugués:
Preparando ambiente seguro...
Instalação em andamento
Aplicativo passou na verificação
de segurança Play Protect.
Esa pantalla se veía un HTML local cargado dentro de un WebView:
file:///android_asset/install.html
La página de distribución estaba en español. La interfaz del primer APK estaba en portugués.
Más adelante, durante la segunda etapa, también aparecen textos en español para solicitar permisos. Ese cambio de idioma apunta a una base reutilizada o adaptada, algo bastante común en este tipo de kits.
dbliqgnjl.dat
Dentro de los assets del primer APK había un archivo de aproximadamente 5 MB:
assets/dbliqgnjl.dat
A simple vista no era un APK.
Al revisar MainActivity apareció la rutina que lo reconstruía. El código abre el archivo, ignora los primeros 16 bytes y procesa el resto mediante XOR con una secuencia generada por un generador congruencial lineal.
Los valores estaban directamente en el código:
seed = 276813
multiplier = 1664525
increment = 1013904223
modulus = 2^32
La operación principal en resumen es así:
state = (state * 1664525 + 1013904223) & 0xffffffff
output = input XOR ((state >> 24) & 0xff)
Código descompilado de MainActivity. Se ve el descarte de 16 bytes, el LCG, la operación XOR y la validación posterior con PackageManager.
Recuperando la segunda etapa
Reproduje la misma rutina fuera de Android.
El archivo original tenía 5,150,184 bytes. Después de quitar los primeros 16 y aplicar la transformación, el resultado quedó en 5,150,168 bytes y comenzó con:
50 4b 03 04
La cabecera PK de un ZIP.
file lo reconoció como un paquete Android válido con AndroidManifest.xml y bloque de firma APK.
El nombre que usa el dropper al escribirlo dentro de la sesión de instalación es:
puxlolj.apk
Su SHA-256:
13e17da25058211b42f1af9cdac1f9edce218f9bd4349b798c013961c72536cc
Buscando puxlolj.apk aparecen varias referencias en Dr.Web asociadas a malware Android, incluyendo variantes de SpyMax, Android.Hidden y Android.Spy.
No puedo asegurar que esta muestra pertenece a una de esas familias solo por el nombre del archivo, pero la correlación sí es interesante: puxlolj.apk ya aparece en muestras maliciosas anteriores.
Resultados de búsqueda para puxlolj.apk con referencias previas en Dr.Web.
Y el package:
ayqd.vvvdds.xeepqqr
El archivo reconstruido es un APK válido. El package ayqd.vvvdds.xeepqqr coincide con el que apareció durante el análisis dinámico.
Con eso quedó conectada la cadena completa.
La cadena que pude reconstruir corresponde a Android.
El segundo APK
El segundo APK ya era otra cosa.
MobSF identificó 32 activities, 17 services, 12 receivers y 2 providers. También pedía permisos para cámara, micrófono, SMS, contactos, ubicación, llamadas, almacenamiento y ejecución después del arranque.
El código tenía funciones para:
- leer mensajes SMS y sus remitentes
- enviar SMS
- consultar contactos
- consultar el historial de llamadas
- obtener ubicación
- capturar la pantalla
- acceder a la cámara
- consultar aplicaciones instaladas
- comprobar privilegios de Device Admin
- ejecutar acciones mediante Accessibility
También registraba BootReceiver y solicitaba RECEIVE_BOOT_COMPLETED.
Accessibility, pantalla y cámara
El RAT trabajaba con AccessibilityNodeInfo.
Podía obtener la ventana activa, buscar elementos por texto o por View ID y ejecutar acciones sobre la interfaz. En el código también aparecen referencias a PIN, pantallas de desbloqueo y componentes usados por distintos fabricantes de Android.
También había código para capturar la pantalla y para abrir la cámara.
Con esos permisos y Accessibility ya tenía bastante control sobre lo que ocurría en el dispositivo.
Comunicación
Durante el análisis dinámico vi comunicación HTTP con infraestructura remota y una ruta bajo:
/yaarsa/private/
La misma cadena aparece dentro del código del segundo APK.
También consultaba:
checkip.amazonaws[.]com
Ese servicio devuelve la IP pública del dispositivo. Eso confirma IP discovery. No vi suficiente evidencia para decir que lo usaran como geofencing.
El APK también tenía implementación de WebSocket y la constante estándar de RFC 6455:
258EAFA5-E914-47DA-95CA-C5AB0DC85B11
Además llevaba JSch, una implementación Java de SSH. Eso confirma que el APK tiene soporte SSH, pero durante la ejecución analizada no vimos una sesión SSH activa.
Anti-análisis y ofuscación
APKiD detectó comprobaciones de:
Build.FINGERPRINT
Build.MANUFACTURER
Build.BOARD
Esas comprobaciones pueden usarse para identificar emuladores o entornos de análisis. ANY.RUN también le puso la etiqueta evasion.
El código del RAT estaba bastante ofuscado. Además de nombres de clases y paquetes generados, parte de las cadenas usa un mapa de sustitución de 18 caracteres del bloque árabe extendido, entre U+06D6 y U+06EC.
No hacía falta recuperar cada string para entender lo principal. Entre el manifest, el código visible y lo que vimos en ejecución ya se podían confirmar las capacidades más importantes.
Dos APK, casi el mismo score
MobSF calificó el primer APK con:
46/100
Medium Risk
Grade B
La segunda etapa quedó en:
48/100
Medium Risk
Grade B
Solo dos puntos de diferencia.
Pero eran dos APK bastante distintos. El primero era un dropper pequeño. El segundo podía acceder a SMS, contactos, ubicación, pantalla y cámara, además de usar Accessibility y mantenerse después de un reinicio.
Para esta muestra, el score sirve como referencia, pero el número por sí solo decía poco sin revisar el flujo completo.
De phishing a APK
La página servía para llevar el ataque al teléfono.
landing falsa
↓
APK Android
↓
dropper
↓
payload oculto
↓
RAT
Una página de phishing puede desaparecer en horas. El APK, una vez instalado, puede seguir ejecutándose, pedir permisos, leer mensajes, capturar pantalla y mantener comunicación con su infraestructura.
La cadena que pude reconstruir fue para Android. La landing mencionaba iOS, pero ese botón no tenía enlace y no encontramos ningún payload para Apple.
La página estaba en español. La falsa instalación estaba en portugués. La segunda etapa volvía a tener textos en español.
Es bastante evidente que reutilizan estos kits y se pueden adaptar dependiendo de a quién quieran atacar.
Últimamente he visto más campañas de phishing de este tipo.
Ya no solamente están buscando usuarios y contraseñas. Ahora están buscando comprometer el dispositivo y mantener acceso persistente.
En esta muestra el APK podía leer SMS, acceder a contactos, capturar pantalla, usar la cámara, obtener ubicación y apoyarse en Accessibility.
También había código relacionado con minería.
En fin, habrá que ver qué pasa con este tipo de campañas ahora que Google está dificultando bastante el sideloading en Android.
Para instalar aplicaciones de desarrolladores no verificados, el nuevo flujo agrega varios pasos, incluyendo activar el modo Desarrollador, reiniciar el teléfono y esperar 24 horas antes de poder continuar con la instalación.
Eso le mete bastante fricción justamente a campañas como esta, donde todo depende de convencer a la víctima de descargar e instalar un APK fuera de Google Play.
No creo que este tipo de malware desaparezca. Lo interesante será ver cómo se adaptan y si empiezan a abusar de cuentas de desarrolladores verificadas, cambian la forma de distribución o simplemente buscan otro camino para llegar a los dispositivos.
Indicadores
| Tipo | Indicador |
|---|---|
| Dominio de distribución | nuevarred-actualizar-5g[.]com |
| SHA-256 dropper | 049cdecfd9a765a1cb8f2abafa168453cd6eb8431646dcb82737600b251a5854 |
| Package dropper | com.app.service.manager |
| Payload embebido | assets/dbliqgnjl.dat |
| APK recuperado | puxlolj.apk |
| SHA-256 segunda etapa | 13e17da25058211b42f1af9cdac1f9edce218f9bd4349b798c013961c72536cc |
| Package segunda etapa | ayqd.vvvdds.xeepqqr |
| Ruta observada | /yaarsa/private/ |
| IP discovery | checkip.amazonaws[.]com |
| Certificado | CN=editor |
Alcance
Este análisis cubre la landing y los dos APK recuperados.
Usé análisis estático y dinámico para separar lo que estaba en el código de lo que realmente apareció durante la ejecución.