Hace días publicaba una entrada aquí en DragonJAR sobre una aplicación fake que habían colado en el repositorio de software Open Source llamado Sourceforge, en la primera entrada, hicimos alguna búsqueda de strings en la aplicación, con pyew, extrajimos alguna información además de que hicimos un análisis usando BSA pero sin tener acceso a internet, continuamos con el artículo de hoy Fake Skype analysis II, primero que todo dando algo de información del binario.
Actualización 2026: el troyano disfrazado sigue vivo
Esta muestra es de 2010 y el análisis de 2013, pero la técnica que la hizo peligrosa sigue intacta en 2026: el instalador malicioso entregaba una copia funcional de Skype mientras descargaba componentes adicionales en segundo plano. Esa es exactamente la receta que los atacantes siguen usando hoy. En febrero de 2026, investigadores de Malwarebytes documentaron una campaña que distribuía un instalador troyanizado de 7-Zip a través de un dominio lookalike (7zip[.]com): el instalador entregaba el 7-Zip legítimo y, en silencio, instalaba tres componentes (Uphero.exe, hero.exe y hero.dll) que convertían el equipo en un nodo de proxy residencial.
Tabla de Contenido
Los datos confirman que el vector no es anecdótico: Kaspersky reportó un aumento del 59% en las detecciones de infostealers en PC entre 2024 y 2025, y encontró que cerca del 35% de las infecciones por infostealers comienza con usuarios que ejecutan archivos descargados directamente desde carpetas temporales, muchos de ellos disfrazados de instaladores de software legítimo.
Por eso la metodología de este artículo —strings del binario, detonación en sandbox con y sin internet, simulación de servicios con FakeNET y análisis del tráfico de red (DNS, beacons, descargas)— sigue siendo la base del análisis de malware moderno. Lo que cambió son las herramientas, no el método.
Fake Skype analysis II información del binario
Si nos fijamos en la fecha de creación es de 2010!
Como comentaba, en la primera parte hicimos un análisis de la aplicación en una sandbox pero sin que esta tuviera acceso a internet, le simulamos algunos servicios usando FakeNET.
¿El análisis cambia con o sin acceso a internet?
Pues la respuesta es si, podemos encontrarnos en varios casos en los que el malware realiza ciertas acciones antes de hacer sus maldades.
- Peticiones DNS
- Llamadas al sistema
El paquete entero de Fake Skype, YA contenía un EXE con el instalador, no le hacía falta conectarse a internet. Pero si por lo que sea, no podía conectarse con su panel de Control no hacía nada y daba un error. En cuanto le di acceso a Internet estos fueron los cambios que se hicieron en la sandbox.
Como veis la diferencia de actividad en el sistema de archivos es brutalmente mas grande. Si miramos el registro.
Aquí solo he puesto una pequeña porción, el contenido entero está aquí => https://justpaste.it/skype
Otra de las cosas que cambiaban en la sandbox una vez que le dimos acceso a internet es el tráfico de red.
En este registro de tráfico de red podemos ver como cosas «maliciosas»:
Después de analizar los orígenes me encontré con un directory listing
Hay varios ficheros interesantes cnt.txt que son todos los usuarios que picaron al instalar la aplicación.
Los PHP que son los encargados de crear el archivo y hacer la redirección.
Para el uso y disfrute lo he colgado en mediafire para que lo podáis analizar.
- https://www.mediafire.com/?xw69xzqga6ly38z
Del análisis manual al sandbox moderno
En 2013, analizar esta muestra exigía montar una sandbox local con Buster Sandbox Analyzer, simular servicios de red con FakeNET y revisar a mano los cambios en el sistema de archivos, el registro y el tráfico. Hoy ese flujo está automatizado. Lo primero que haría un analista con un binario como SkypeSetup.exe sería consultar su hash (MD5/SHA1) en VirusTotal, el agregador que compara el archivo contra más de 70 motores antivirus y ofrece un veredicto colectivo en segundos.
Para la detonación, sandboxes interactivas en la nube como ANY.RUN ejecutan la muestra en una máquina virtual Windows real, permiten interactuar con el instalador en tiempo real (diálogos, clics, credenciales) y capturan automáticamente el comportamiento: procesos lanzados, archivos creados, llamadas al sistema y tráfico de red, mapeado a MITRE ATT&CK y reglas YARA/Suricata. Es el equivalente automatizado de lo que aquí se hizo a mano: las peticiones DNS a dominios como serrasulshopping.com.br, las descargas de 119.9.14.47/BBK3.zip o las conexiones a 162.209.15.123/k1/notify.php aparecerían hoy como indicadores (IoCs) extraídos automáticamente, listos para alimentar la threat intelligence y buscar infraestructura relacionada.
La lección permanente de este análisis: un instalador que «funciona» no es un instalador confiable. Verificar el hash, descargar solo de fuentes oficiales y detonar lo sospechoso en una sandbox aislada sigue siendo la defensa mínima frente a este vector.
¿Detectó un binario sospechoso en su infraestructura?
Un instalador que parece legítimo puede estar exfiltrando información o abriendo una puerta trasera mientras el usuario trabaja con normalidad. En DragonJAR realizamos análisis forense de malware, respuesta a incidentes y pruebas de penetración para detectar, contener y erradicar este tipo de amenazas antes de que se conviertan en una brecha. Solicite una evaluación de seguridad informática.
