Más vale tarde que nunca. Como os adelanté en la primera parte de Este Artículo, no nos íbamos a quedar solo en la teoría, os había prometido realizar un análisis técnico en un entorno real de un sistema diseñado para realizar spoofing de llamadas tipo VoIP. El artículo que vais a leer a continuación lo he escrito casi por completo hace tres años, pero lo he tenido guardado bajo llave todo este tiempo. Esto ha sido de forma totalmente deliberada por una cuestión de responsabilidad ética y seguridad colectiva, ya que hasta la reciente entrada en vigor de la normativa española de 2025 y 2026 que comentaré a continuación, el vacío legal y técnico permitía que este tipo de artículos fuese un arma de doble filo. Publicar los detalles técnicos de la suplantación de identidad mediante VoIP sin un marco regulatorio que obligase a las operadoras a filtrar y bloquear activamente el spoofing internacional, corría el riesgo de convertirse involuntariamente en un manual para actores maliciosos en lugar de en una herramienta para analistas forenses. Sin embargo, con la actual normativa, el escenario ha cambiado lo suficiente como para que podamos desgranar estos artefactos forenses sin miedo a facilitar el camino al cibercrimen. En todo caso, no diré ni comentaré en ningún momento cuáles son los SIP que permiten realizar este tipo de llamadas maliciosas, por lo que si has llegado hasta aquí buscando ese listado de SIP de normativa laxa, te has equivocado totalmente de lugar. Por contrario, si buscas información técnica y forense para analizar este tipo de ataques, este es tu sitio.
Si queremos entender de verdad cómo funciona el vishing y cómo rastrearlo, tenemos que bajar al barro del análisis forense digital. En esta segunda entrega, vamos a diseccionar un servidor de VoIP basado en Asterisk y FreePBX que ha sido configurado para realizar ataques de suplantación de identidad.
El vishing, o «phishing de voz», es una sofisticada técnica de ingeniería social donde los atacantes utilizan llamadas telefónicas para manipular psicológicamente a sus víctimas, combinando guiones de estrés con el uso de herramientas técnicas como el spoofing de Caller ID a través de centralitas VoIP (como Asterisk o FreePBX). El engaño se basa en el secuestro del número de llamante o “Caller ID«: al recibir una llamada donde el identificador en pantalla coincide exactamente con el número real de tu banco o de una empresa oficial, el cerebro entra en modo alerta ante un escenario de urgencia fabricado, como un supuesto cargo fraudulento o compra no autorizada, lo que reduce drásticamente nuestra capacidad para tomar precauciones rutinarias, como por ejemplo no decirle a nadie una contraseña o información confidencial. Bajo esta falsa apariencia de autoridad, los criminales guían al usuario para que revele voluntariamente sus códigos de doble factor (2FA), entregue contraseñas de banca online o incluso instale software de control remoto que permite el acceso total a sus dispositivos, convirtiendo una simple conversación en una brecha de seguridad crítica que aprovecha la confianza humana y las debilidades del protocolo de identificación telefónica actual. Bueno, lo de actual, lo vamos a matizar.
De nada sirve que nosotros detectemos el fraude si las operadoras no ponen trabas técnicas para bloquearlo. En España, precisamente, nos encontramos en un momento de cambio radical gracias a una normativa muy reciente diseñada para atajar este problema de raíz. Desde 2024, España ha endurecido las reglas del juego. Gracias a la Orden TDF/149/2025, publicada por el Ministerio de Transformación Digital (y en la que han trabajado personas muy cercanas), obliga a las operadoras a implementar medidas técnicas que antes eran voluntarias. Medidas como las siguientes:
- Desde septiembre de 2025, las operadoras tienen la obligación de bloquear automáticamente las llamadas que vienen del extranjero pero que muestran un número español (el típico +34), a menos que sea un caso real de roaming. Esta norma corta de golpe la mayoría de ataques de vishing que usan centralitas VoIP fuera de nuestras fronteras.
- Otra de las medidas es el fin de los números móviles para realizar llamadas de «Spam»: Desde junio de 2025, está prohibido realizar llamadas comerciales desde números móviles. Si recibes una llamada de ventas desde un móvil, o es ilegal o es un fraude. Ahora solo pueden usar números fijos geográficos o números 800/900.
- Bloqueo de numeración no atribuida: Las operadoras deben bloquear llamadas que provengan de números que no han sido asignados a ningún cliente o que están «vacíos».
Además, con el Registro de Alias de la CNMC que entrara en vigor en el año 2026, se dificultará los ataques tipo smishing (spoofing de SMS). Si una empresa quiere enviarte un SMS poniendo como remitente «BANCO_X«, ese alias debe estar registrado y validado en la base de datos oficial. A partir de septiembre de 2026, cualquier mensaje con un remitente alfanumérico que no esté en este registro será bloqueado automáticamente por la operadora de destino.
Para este análisis, se ha desplegado un entorno de laboratorio controlado basado en un servidor VPS Linux securizado, donde reside una instancia de FreePBX actuando como interfaz de gestión sobre un motor de telefonía Asterisk. La infraestructura se apoya en un SIP Trunking de un proveedor externo que permite el enrutamiento de tráfico hacia la red pública (PSTN) sin filtros de cabeceras, lo que habilita la inyección de metadatos maliciosos y la manipulación de la variable TRUNK_CID_OVERRIDE en el protocolo de señalización. En el lado del cliente, se utilizó un terminal Softphone Zoiper configurado para interactuar con la centralita mediante el puerto 5060, generando así un flujo completo de artefactos forenses: desde paquetes INVITE y registros de registro en los logs de Asterisk (/var/log/asterisk/full), hasta la persistencia de los metadatos de cada llamada en el motor de base de datos MariaDB (dentro de la base de datos asteriskcdrdb). Este despliegue permite documentar con precisión técnica el rastro que deja un atacante al ejecutar una campaña de vishing, permitiendo el análisis de evidencias en un escenario que replica fielmente los métodos de las organizaciones criminales.
A la hora de abordar la extracción de evidencias, me he decantado por un análisis forense directo o «en vivo» en lugar de una adquisición estática post-mortem tradicional, una decisión técnica fundamentada en la necesidad de capturar información volátil como los sockets de red activos en el puerto 5060, los procesos en ejecución y el estado de las conexiones de red en tiempo real, lo que nos permite obtener una «fotografía» dinámica de la actividad maliciosa sin perder los datos de memoria que no han sido volcados a disco. Este enfoque metodológico, aunque altera mínimamente los metadatos del sistema de archivos, es esencial en incidentes de vishing para identificar la IP de origen del atacante y correlacionar los eventos de los logs de Asterisk con otros registros del sistema.
Una vez nos hemos conectado al sistema, ya sea por SSH, RDP, VNC o una conexión directa, podemos ver como se muestra en la captura anterior, la información crítica de red: la IP privada 192.168.1.26 bajo la interfaz eth0 y la dirección MAC del equipo. Un detalle técnico importante para el analista es el aviso de «5 notifications«. En FreePBX, estas notificaciones suelen alertar sobre módulos desactualizados o, lo que es más crítico, brechas de seguridad detectadas por el sistema Intrusion Detection. Esto implica que, aunque la centralita sea legítima, un cibercriminal podría haber tomado el control mediante alguna vulnerabilidad, camuflando así tráfico malicioso entre las llamadas habituales de la empresa.
Para que un ataque de vishing tenga éxito, el criminal debe configurar el Dialplan y los Trunks (troncales). Toda esta lógica reside en la ruta /etc/asterisk. Un listado de este directorio nos revela todos los parámetros técnicos del sistema.
Aquí encontramos ficheros clave como extensions.conf (donde se define qué pasa cuando se marca un número) y los ficheros de configuración SIP. Sin embargo, para un análisis de vishing, el «santo grial» es saber por dónde salen las llamadas al exterior.
Como mencionamos en la Parte 1, el atacante necesita un proveedor que le permita «sacar» la voz a la red telefónica pública (PSTN). Al analizar el fichero sip_registrations.conf, podemos ver la cadena de registro, más concretamente la línea: register => 11XXXX:u3XXXX9A@eu.st.ssl7.net. Lo que estamos viendo es el: usuario; contraseña de acceso y dominio del servidor.
Desde el punto de vista forense, esto nos da el ID del usuario (11XXXX) y el Host del proveedor (eu.st.ssl7.net). Estos datos son fundamentales para determinar el origen exacto del contratante, o lo que es lo mismo, la máquina que ha realizado el ataque.
Asterisk es extremadamente «verbose» si se configura adecuadamente. Los logs se almacenan en /var/log/asterisk/.
El fichero full contiene cada evento que ocurre en la centralita. Si sospechamos de un acceso externo para realizar las llamadas (un atacante usando un Softphone), debemos buscar registros de paquetes SIP_REGISTER o INVITE.
En la captura superior, mediante un grep sobre el puerto 5060, localizamos tráfico proveniente de la IP 81.23.XXX.XXX. Esta es la IP del dispositivo (Softphone) que el criminal está usando para conectarse a la centralita y lanzar el ataque.
Además, el fichero freepbx_security.log nos muestra intentos de acceso no autorizados, lo cual es común en servidores expuestos, con este log podremos determinar la dirección IP de la persona que está controlando la centralita de VoIP:
Aquí vemos intentos fallidos para el usuario m4nu y root. Esto nos ayuda a discernir si el servidor fue comprometido por un tercero o si fue el propio administrador quien realizó las acciones maliciosas.
Llegamos al núcleo de la investigación: ¿Cómo demostramos técnicamente que se cambió el identificador de llamada? Para esto, analizamos el flujo de ejecución del Dialplan en el log full. Asterisk utiliza macros para gestionar las llamadas salientes. Buscamos el momento en que se establece la variable CALLER_ID.
Observad la línea: Executing [s@macro-outbound-callerid:…] Set(TRUNKCIDOVERRIDE=34666666666). Aquí es exactamente dónde se está manipulando el Caller_ID con un override (anular) del número llamante. Es decir, el sistema anula el ID real y fuerza la salida de un número falso.
Aquí está la prueba irrefutable. El servidor está instruido para sobreescribir el Caller ID original y sustituirlo por el 34666666666 (un número que podría pertenecer a una entidad bancaria o soporte oficial), en este caso, es un número que a todas luces es falso y que simplemente lo he utilizado para no generar llamadas con números reales de entidades bancarias o empresas. Cuando el proveedor SIP recibe el comando INVITE, propaga este número falso hacia la víctima.
Aunque los archivos de log pueden ser rotados o borrados, Asterisk suele guardar una copia de cada transacción en una base de datos MariaDB o MySQL.
Contamos con dos bases de datos principales:
- asterisk: Contiene la configuración de usuarios, extensiones y permisos.
- asteriskcdrdb: Contiene el CDR (Call Detail Record), el registro histórico de todas las llamadas realizadas.
Al auditar tablas como ampusers o vicidial_list (si se usara un marcador automático), podemos recuperar nombres de usuario, contraseñas hash y, lo más importante, los registros de tiempo exactos de cada llamada de vishing, lo que permite correlacionar el ataque con la denuncia de la víctima.
El análisis forense de VoIP nos demuestra que, aunque el vishing parece una estafa intangible basada en la voz, deja un rastro digital masivo. La manipulación del TRUNK_CID_OVERRIDE es la clave técnica que diferencia una llamada legítima de una fraudulenta a nivel de servidor. Como analistas, nuestra misión es conectar esos registros de log con la actividad en la base de datos SQL para reconstruir la línea de tiempo del ataque.
Una vez que hemos identificado las bases de datos asterisk (configuración) y asteriskcdrdb (registros de llamadas), el procedimiento estándar en peritaje digital dicta que «lo suyo es dumpearla completamente» para realizar un análisis offline sin riesgo de alterar el sistema original. Utilizamos el comando mysqldump para generar un volcado íntegro de la estructura y los datos.
Una vez finalizado el volcado de las bases de datos, obtendremos dos ficheros de base de datos tipo SQL, en este caso los ficheros se llaman: dump_bd_asterisk.sql y dump_bd_asteriskdrdb.sql
Sin embargo, para que esta prueba sea válida, debemos garantizar la integridad de las bases de datos mediante un hash. Como se observa en la siguiente captura, generamos los hashes SHA1 de los archivos de bases de datos .sql. Esta «huella digital» es la que nos permitirá demostrar que los datos que analizaremos posteriormente no han sufrido ni una sola modificación respecto al estado original del servidor intervenido.
Aunque la potencia reside en la consola, la interfaz gráfica (GUI) de FreePBX es un artefacto en sí mismo. En un análisis forense, debemos revisar los permisos de acceso al panel web, ya que el atacante a menudo configura sus maniobras desde aquí.
Desde el módulo de administración, el sistema nos permite visualizar los Asterisk Log Files. Esto es extremadamente útil para realizar correlaciones rápidas sin necesidad de procesar archivos de texto masivos mediante grep.
En la interfaz web de FreePBX (Fig. 11), el sistema registra las transacciones en tiempo real. En el ejemplo de llamada de la Fig. 12, vemos el registro visual del servidor. Además, si capturamos el tráfico de la interfaz de red que está utilizando FreePBX, también podremos obtener trazas de la operatividad del servidor, de una forma muy sencilla podremos determinar el número de teléfono que se está suplantando y el SIP utilizado. En este caso, el fichero de captura de tráfico de red se almacenó en el archivo llamado: “cdr-2391311532.pcap”.
Al analizar el PCAP, observamos que en el paquete 1, el mensaje INVITE inyecta en su cabecera From el número suplantado 34666666666, mientras que la cabecera Call-ID delata la IP privada interna del servidor (192.168.1.26). En el paquete 5, localizamos la autenticación del atacante con el usuario 11XXXX2 y el User-Agent específico de la centralita. Finalmente, el flujo hacia la víctima (34630XXXXXX) se cierra en el paquete 10 con un código de error 480 Temporarily unavailable. Esta correlación entre el registro web y la telemetría de paquetes permite construir una línea de tiempo técnica e irrefutable del fraude.
El paso final de la investigación es la atribución. Necesitamos saber quién conectó el Softphone malicioso a nuestra centralita. Para ello, FreePBX mantiene registros de las IPs que interactúan con el protocolo SIP y con el panel de administración. Auditar estas tablas nos permite identificar la IP pública del atacante. En este caso laIP es la 2.155.XXX.XXX.
¡Misión Cumplida!.
¿Te ha gustado este artículo? Si quieres, puedes ayudarme a escribir el siguiente artículo de GLIDER invitándonme a un rico café.
Pulsa Aquí para invitarme a un café con hielo.
Salu2.