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!.

En este artículo vamos a realizar un análisis forense inicial de lo ocurrido. Es decir, vamos a desgranar en forma de timeline los distintos sucesos que fueron aconteciendo en los momentos previos al fatal desenlace. La diferencia entre un análisis inicial de hechos y un análisis final de causas, es que mientras el primero es una exposición de hechos objetivos que han ocurrido, el segundo tipo de análisis entra a valorar las causas que produjeron esos hechos. Como decía, este será un análisis inicial, ya que no se dispone de la información suficiente como para poder establecer una causa de forma objetiva (al menos yo). Otro de los objetivos de este artículo, es refundir en un solo post, todas las publicaciones que he estado realizado en mis cuenta de X.com y Linkedin.com desde las 16:00 horas del día del propio apagón, momento en el que ya había detectado que el principal desencadenante de lo ocurrido fue la desestabilización de la frecuencia de la red eléctrica.

Existen distintas HIPÓTESIS de trabajo que se están analizando, las cuales, hasta tener una información mas detallada de lo ocurrido, no se pueden considerar probadas, las principales hipótesis NO CONFIRMADAS que se están barajando son:

• Alta penetración de energías no síncronas (fotovoltaica y eólica) en un momento de baja inercia del sistema. Al mismo tiempo que existía un exceso de generación renovable frente a una demanda baja.
• Desconexión de las lineas de exportación de energía eléctrica hacía Portugal y Francia, que provocó una sobretensión de red y desconexión automática por cascada de todas las estaciones de generación eléctrica de España.
• Ciberataque a la infraestructura de control o comunicaciones del sistema eléctrico que provocó una desestabilización de la red. Esta es la opción menos probable de todas, pero como de momento no se ha podido descartar todavía, la hay que citar.

Es importante entender, que cuando se realiza un análisis forense, una hipótesis, por alocada que sea, no se puede confirmar o desestimar hasta que no existan pruebas que demuestren una cosa u la otra, por lo tanto, ante la falta de información sobre el suceso, no es el momento de confirmar o desechar ninguna hipótesis. Por ejemplo, el día del apagón se habló que este había sido provocado por un fenómeno atmosférico inusual que provocó oscilaciones en las líneas eléctricas de alta tensión, esta idea tuvo la consideración de hipótesis, y la Agencia Española de Meteorología la descartó al certificar que ese día no existió ningún fenómeno atmosférico inusual.

Este es el camino que hay que seguir con todas las hipótesis que puedan ser plausibles: realizar un análisis sobre la misma para determinar su realidad o no. Otra cosa, son hipótesis no plausibles (al menos para mi), como que los extraterrestres vinieron con sus naves espaciales y absorbieron la electricidad de los cables de la red eléctrica española para poder tener energía y regresar a su planeta.

Antes de comenzar con el análisis cronológico de lo ocurrido, decir que me voy a centrar solamente en el día 28 de abril, pero los días 16 y 17 de abril de ese mismo año, ya se detectaron sobretensiones importantes en distintos puntos de la red final o distribución española, lo que al no poder confirmar que tenga relación con lo ocurrido el día 28, no lo analizaré en este artículo.

Para entender lo que ocurrió, es esencial explicar dos conceptos fundamentales: frecuencia e inercia del sistema eléctrico. La frecuencia en España está normalizada a 50 Hz, y se mantiene estable mientras exista un equilibrio exacto entre la potencia activa generada y la demandada. Si ese equilibrio se rompe, aunque sea momentáneamente, la frecuencia comienza a variar. En un sistema convencional con generación síncrona (como hidroeléctrica, nuclear o térmica), las masas giratorias de los generadores (que pesan varias toneladas) aportan una gran inercia, lo que actúa como amortiguador frente a estas variaciones. Sin embargo, en los sistemas no síncronos como la fotovoltaica o eólica, la frecuencia se genera de forma digital a través de inversores que simulan una onda sinusoidal, y carecen de inercia física real. En mi libro: «Así monté mi propia instalación de Energía Solar» ya explicaba la importancia de la frecuencia en la red eléctrica, y como los inversores fotovoltaicos no pueden establecer esa frecuencia de forma simple, como si lo hace un rotor de una turbina que lo podemos tener girando de forma sencilla a 50 vueltas por segundo y por lo tanto estableciendo una frecuencia estable de 50Hz.

La frecuencia del sistema es como el metrónomo de toda la red. Cuando la producción la establece un generador rotativo, este impone su ritmo físico, y el resto de generadores simplemente se sincronizan a ese ritmo. Pero si ese generador es sustituido por inversores que sólo siguen o copian la frecuencia existente (sin crearla), el sistema depende completamente de que esa frecuencia externa sea estable. Es como ser DJ, tienes dos vinilos, los dos pueden estar sonando a 130 BPM, pero si no están acompasados, será un horror.

Comenzamos: a las 12:04 horas CEST del 28 de abril de 2025, se registraron variaciones notables en la frecuencia de la red eléctrica, como se muestra en la siguiente gráfica de las lecturas de dos sondas que miden la frecuencia en diferentes puntos de la Península Ibérica. En la gráfica, la línea amarilla representa la lectura de Málaga, mientras que la línea azul corresponde a Oporto, en Portugal. Como se mencionó anteriormente, la frecuencia de la red eléctrica debería mantenerse alrededor de 50 Hz, con una fluctuación normal de +/- 0,02 Hz (es decir, entre 49,98 y 50,02 Hz). Sin embargo, antes de que ocurriera el apagón total, Málaga ya estaba registrando picos de frecuencia de 50,08 Hz y 49,92 Hz. Estas variaciones anómalas en la zona de Málaga, comparadas con Oporto, sugieren que el origen del problema podría estar relacionado con esa región de España, es decir, el problema que originó el problema estaría físicamente mas cerca de Málaga que de Oporto.

Si nos vamos a ver lo que estaba ocurriendo exactamente a las 12:20 CEST en la red eléctrica española cuando comenzaron a aparecer las variaciones en la frecuencia de la red, justo en ese momento (había un pico) la producción de energía renovable estaba superando la demanda total de España. Es decir, solo con energías renovables, sin contar con el resto de fuentes de energía que en ese momento se estaban generado, ya se había cubierto totalmente la demanda de electricidad en España. En ese momento la red española ya estaba exportando energía a Francia y Portugal en su máximo de ese día, aproximadamente unos 4GW, que se mantuvieron hasta las 12:33, momento en el que se produjo el apagón.

Exactamente a las 12:33 CEST, el 70% de los 30 GW de generación eléctrica total española procedía de fuentes como la solar fotovoltaica y la eólica (renovables), esto era debido a que las condiciones eran óptimas para la fotovoltaica: primavera, sol a una altura media, no mucho calor, cielo despejado en toda la península. Estas tecnologías renovables, aunque limpias y necesarias, no aportan inercia física al sistema eléctrico. De los 30 GW generados, 4 GW estaban siendo exportados a Francia y Portugal, lo que significa que el sistema interno español estaba gestionando un equilibrio frágil entre generación y consumo real.

A nivel doméstico, muchos usuarios registraron valores de tensión muy por encima del límite legal de 246V, establecido por el RD 1955/2000. Algunos sensores midieron hasta 254V justo antes del apagón. En sistemas eléctricos, cuando la generación supera significativamente la demanda, la energía sobrante tiende a elevar el voltaje de la red. Y aunque el voltaje no está directamente vinculado a la frecuencia, las variaciones bruscas de carga o producción pueden dificultar el control de la frecuencia, especialmente cuando se cuenta con poca inercia. Aunque como digo, voltaje y frecuencia no están directamente ligados, ambos pueden verse afectados por un desbalance de potencia activa o reactiva. Esto ocurre porque las fuentes renovables, al operar mediante inversores, inyectan predominantemente potencia activa (P), pero su capacidad para gestionar potencia reactiva (Q) es limitada. En escenarios de alta generación renovable y baja demanda, el exceso de potencia reactiva puede elevar el voltaje en la red, lo que obliga a los inversores a desconectarse por protecciones de sobretensión o a reducir su aportación de potencia activa. Esta desconexión brusca de generación altera el equilibrio entre generación y demanda, provocando un desbalance de potencia activa que, en un sistema con baja inercia, deriva en fluctuaciones críticas de frecuencia (Δf).

En una situación en la que el 70% de la generación es no síncrona, la red queda vulnerable: si hay una ligera variación de potencia, por ejemplo, una caída repentina de consumo o una sobreproducción puntual, el sistema no puede amortiguar el efecto. Si, además, la exportación es alta, como en este caso (4 GW), se pierde una parte de la capacidad del sistema para absorber internamente esos excesos o déficit. Aquí es dónde entran las hipótesis de lo que hizo explotar esas vulnerabilidad de la propia red, bien, causas intrisicas como la propia saturación de energía no inercial en ese momento, o extrínsicas, como una actuación de un agente exterior, ya sea de forma voluntaria (sabotaje o ciberataque) o involuntaria (imprudencia o negligencia en la operación).

Lo más probable es que a las 12:30 horas CEST, una desestabilización importante de la frecuencia de la red, forzara a algunas plantas de generación eléctrica a desconectarse por seguridad, así es como están diseñadas para evitar problemas mayores, como incendios y sobrecalentamiento. Es como si en nuestras casas hay una derivación a tierra de más de 30 mA y salta automáticamente el diferencial del cuadro eléctrico o salta el magnetotérmico en caso haber un cortocircuito. Esta desconexión provocó que en 3,5 sg se desacoplaran de la red 16GW de producción. Es decir, en 175 ciclos (3,5sg x 50 Hz) «desaparecieran» 16GW de la red, lo que era prácticamente toda la producción fotovoltaica en ese momento. Esto provocó una reacción en cadena del resto de estaciones de generación que llevó al apagón nacional en cuestión de 5 segundos. Un dato muy importante que falta por saber, es la frecuencia que había en los distintos nodos de Red Eléctrica Española a las 12:33 horas.

Para entender cuán frágil puede ser un sistema con poca inercia, basta hacer un cálculo básico sobre cuánto desequilibrio se necesita para modificar la frecuencia del sistema. La siguiente es una fórmula que permite estimar cuánta potencia activa neta se requiere para producir una variación de frecuencia de 0,15Hz en un sistema de potencia síncrona con inercia y potencia rotacional agregada:

• Delta de P: el resultado que queremos obtener, en este caso el exceso o déficit de energía que hace falta para cambiar la frecuencia en +/- 0,15Hz
• H: constante de inercia.
• S potencia síncrona total.
• Delta de F: cambio que se quiere analizar en la frecuencia.
• f: frecuencia nominal.

La constante de inercia (H) de un sistema eléctrico no es un valor fijo ni uniforme en toda la red, sino que depende de la mezcla de generación en tiempo real y de la distribución geográfica de las unidades síncronas (nuclear, carbón, hidroeléctrica, ciclos combinados). En el caso de España, el valor agregado de H ha ido disminuyendo en los últimos años debido al aumento de generación renovable no síncrona (eólica y fotovoltaica), que ya hemos dicho que no aporta inercia natural. En 2023 Red Eléctrica Española ya reportó que en horas de alta generación renovable, la inercia equivalente del sistema rondaba H ≈ 3 s. Para mi calculo, he optado por un valor mas conservador de H = 4, pero en zonas con alta penetración renovable como Andalucía o Extremadura, el valor de H podría llegar a 2.

Es decir, un exceso de tan solo 216 MW, menos del 1% de la generación total en ese momento, podría haber bastado para provocar una desviación significativa de la frecuencia (0,15Hz). En condiciones normales, este tipo de variación sería absorbido sin problemas, pero con una inercia tan baja, ese exceso no encuentra «amortiguación» en la red y se convierte en una señal crítica que puede provocar el inicio de una cascada de desconexiones automáticas. Incluso, en una situación extrema de H=1,5 esa misma variación en la potencia, provocaría un desfase en la frecuencia de 0,3Hz. Lo que pone de manifiesto la dificultad de operar un sistema eléctrico altamente renovable sin una arquitectura de respaldo síncrono o almacenamiento. No se trata de que la fotovoltaica sea mala, sino de que se necesita una red que permita convivir con ella de forma segura, y para esto es necesario disponer de sistemas de estabilización inercial que permitan mantener la red estable a una frecuencia los mas próxima posible a 50Hz. Ejemplos de estos sistemas son:

• Volantes de inercia: Son dispositivos mecánicos que almacenan energía cinética en un rotor giratorio. Pueden acoplarse a la red mediante convertidores electrónicos, liberando o absorbiendo potencia muy rápido.

• Baterías con funciones de «inercia sintética»: Aunque las baterías en sí no tienen inercia física, pueden emularla mediante el control de convertidores electrónicos, respondiendo instantáneamente a variaciones de frecuencia.

• Supercondensadores: Al igual que las baterías, no ofrecen inercia física pero pueden actuar como «inercia virtual», ayudando en la regulación rápida de la frecuencia.

El problema de todo estos sistemas de estabilización es que requieren una importante inversión económica, hasta ahora, los sistemas de generación eléctrica implícitamente y como consecuencia de su propio funcionamiento, ya realizaban funciones de estabilización inercial. Pero hoy en día, con el gran aumento de la potencia renovable, la estabilización inercial, ya no es algo que venga por defecto con los sistemas de generación, si no que lo hay que añadir en forma de complementos a la generación. En las nuevas plantas fotovoltaicas ya se está estudiando que sea obligatorio incluir estos sistemas, por ejemplo, en plantas de mas 50MW de generación, deberán disponer de estos sistemas de estabilización inercial. Pero… ¿y que pasa con los 32.000MW de potencia fotovoltaica que existe ahora mismo desplegada en España y que no dispone de estos sistemas de protección inerciales? ¿Tendrán las empresas generadoras que añadir estos caros sistemas de protección a los parques fotovoltaicos antiguos?

Volviendo un poco a las causas que provocaron esa desestabilización en la red, si mis cálculos no fallan, que no lo tengo yo muy claro Un exceso o falta de tan solo 216 MW, es la mitad de lo que puede generar una sola planta fotovoltaica cualquiera del sur de España, en el lugar en el que las sondas apuntan que ocurrió el suceso, podría haber desencadeno el incidente. Por ejemplo, cualquiera de estas plantas fotovoltaicas de Extremadura tienen potencia de generación suficiente para causar esa desestabilización si se desconectan de repente y no hay un sistema de protección que aísle el fallo:

• Francisco Pizarro (Cáceres): con 590 MWp

• Núñez de Balboa (Badajoz): con 500 MWp

• Ceclavín (Cáceres): con 328 MWp

• Talasol (Talaván, Cáceres): con 300 MWp

¡OJO! No estoy diciendo que el apagón sea culpa de estas plantas; es un ejemplo como cualquier otro para exponer la potencia que tiene una planta fotovoltaica. Pongo Extremadura porque es una comunidad que está entre Málaga y Oporto, pero también podría haber puesto Andalucía. Otra circunstancia que tienen estas plantas fotovoltaicas es que están físicamente lejos de otras plantas de generación inercial (como las nucleares o de ciclo combinado), lo que puede complicar todavía más la amortiguación de una frecuencia desfasada.

En el caso de Cáceres, está la central nuclear de Almaraz, pero en el momento del apagón solamente estaba operando el reactor de Almaraz II, con 1050 MW, ya que Almaraz I estaba en recarga. Por ejemplo, si solo tenemos en cuenta Almaraz II, con tan solo una caída de 25,2 MW en una planta fotovoltaica próxima ya se produciría una variación de 0,15 Hz en la red. Este ejemplo teorico es simplemente para mostrar la importancia de los sistemas inerciales en una red eléctrica.

Otro ejemplo: Si en Córdoba hay un exceso de solar y una caída repentina de demanda de por ejemplo 300 MW, el sistema intentará compensarlo, pero al no haber generación síncrona en la zona la frecuencia caerá aproximadamente a los 49.8 Hz, y los inversores fotovoltaicos (sin inercia) no pueden amortiguar ese golpe. (SPOILER: En el informe oficial que se publicó meses después, el día 17 de junio de 2025, se determinó que la primera desconexión realmente se produjo en una subestación eléctrica de Granada que estaba inyectado 355MW. Es decir: 0,17 % de margen de error entre la estimación que calculé en este artículo y lo que ocurrió realmente) Como las térmicas de Huelva o la nuclear de Almaraz tardan segundos en reaccionar, si la caída es mas pronunciada, es posible que para cuando las centrales de inercia puedan actuar, ya será tarde. En condiciones normales aunque la frecuencia caiga hasta los 49.8 Hz, no debería activar protecciones de generadores críticos, pero en un sistema con baja inercia como por ejemplo: H < 2, la caída puede ser tan rápida que salta escalones de 50.0 Hz a 48.5 Hz en segundos, disparando desconexiones en cascada.

Por debajo de 47,5 Hz, todas las centrales de producción se tendrían que desacoplar (si o si) de la red por seguridad, en este escenario de inercia H=2 el desequilibrio de potencia necesario para una caída directa de frecuencia de 2,5 Hz sería de 1800 MW. Este sería el ejemplo mas extremo, ya que las protecciones por subfrecuencia, van saltando de forma escalonada, de entornos menos importantes a mas importantes. Creo recordar, que leí en algún sitio (que ahora no encuentro) que por debajo de 49Hz, primero se desconectan cargas no prioritarias como las industriales y si la frecuencia sigue bajando hasta los 47,5 Hz se tendrían que desconectar todas las estaciones de generación (corte total) . Sin embargo, en caso de sobrefrecuencia, el valor de desconexión total es mas conservador, cortando a 51,5Hz.

El sistema que permite desconectar en remoto a las instalaciones industriales y fábricas en caso de necesidad se llama SRAD, este es un mecanismo que permite a Red Eléctrica de España (REE) solicitar a grandes consumidores industriales que reduzcan temporalmente su consumo eléctrico. Esta herramienta se utiliza para mantener la estabilidad del sistema eléctrico en momentos críticos, como picos de demanda o caídas inesperadas en la generación, especialmente de fuentes renovables, como fue el caso del pasado 28 de abril. Sin embargo, una de las situaciones que se le reprochan a REE, es que a principios de 2025 modificaran la operativa del SRAD, impidiendo su activación durante las horas centrales del día. Esta decisión se basó en la idea de que la alta disponibilidad de energía solar durante esas horas reduciría la necesidad de activar el mecanismo.

El SRAD, tampoco es un sistema de protección de seguridad que se esté activando a todas horas, en el año 2024 solamente se activó en 4 ocasiones: 22 de mayo; 10 de julio; 11 de diciembre y 12 de diciembre. Gracias a esta activación, en aquellos momentos se logro estabilizar un desbalance entre la generación y la demanda eléctrica, movilizando (desconectado) una potencia industrial de 609 MW .

Este mecanismo de protección no existe solo en España, en el año 2021, el día 8 de enero, aproximadamente a las 14:05 CET, la frecuencia en la zona noroeste de Europa continental bajó hasta los 49,74 Hz en un período de unos 15 segundos. Al mismo tiempo, la frecuencia en el área sureste aumentó hasta 50,6 Hz, lo que produjo un desfase de 1Hz dentro de Europa. En este momento entró en funcionamiento el sistema de protección similar al SRAD español, desconectando servicios industriales en Francia e Italia por una potencia 1,7 GW, de este modo se logró reducir la desviación de frecuencia y estabilizar la situación.

El problema que el SRAD, no es un sistema automático, tiene un tiempo de retraso en su activación de aproximadamente 15 minutos. Por lo que de nuevo, la clave será obtener todos los datos de la frecuencia en la red española a partir de las 12:00. Ya hemos visto que a las 12:05 horas de ese mismo días en Málaga, ya se estaban detectado problemas con la frecuencia. Pero de 10:50 a 12:33, no he podido conseguir las métricas de frecuencia de todos los sensores de la red, solo de dos y uno de ellos no es ni de España, por lo que no se puede saber si minutos antes del apagón total, hubo desfases en las frecuencia de otras zonas que pudieran haber sido corregidos con el SRAD.

La dificultad de escribir este artículo, es que lo estoy haciendo sin datos oficiales y a muy pocas horas de haber sucedido el apagón. Toda la telemetría que he utilizado para realizar este análisis la obtuve de realizar consultas en bases de datos públicas. Obviamente los operadores de red que están realizando el análisis oficial del suceso, tienen acceso a muchos mas datos y logs de lo ocurrido, que espero que en un futuro se hagan públicos, pero de momento, nos tenemos que conformar que este análisis inicial.

ACTUALIZACIÓN: 01/05/2025 19:00 horas:

En la siguiente gráfica se muestra con mucho más detalle como estaba la frecuencia eléctrica a las 12:33 horas del 28 de abril. Se puede apreciar como a las 12:33:05 CEST (en la gráfica aparece 10:33:35 ya que está en formato UTC) hay una fuerte sub-frecuencia, en la que en 40 segundos, la frecuencia cae de 49,990 Hz a 49,840 Hz. Son exactamente los 0,15 Hz que había calculado de desfase cuando escribí el artículo inicial.

En los cinco segundos, entre las 10:33:35 a 10:33:40 horas se produce una fuerte oscilación de la onda desde los 49,950 Hz a los 49,865 Hz, una caída, recuperación y otra caída de 0,085 Hz. La curva que sigue la frecuencia, puede ser compatible con la respuesta de generadores tipo grid-following (los que copian la frecuencia, que ya comenté anteriormente) ya que se aprecia como la curva parece reaccionar ante un aumento repentino de carga en la red. Al no tener la capacidad de establecer frecuencia por sí mismo, estos generadores dependen completamente de la red para sincronizarse. En el momento en que la carga se incrementa bruscamente, la frecuencia de la red sufre una caída. Esta caída viene acompañada de oscilaciones que reflejan una respuesta inestable y lenta, al tratar el inversor o generador de crear una onda digital similar a la de la red.

ACTUALIZACIÓN: 17/06/2025 19:00 horas:

El Ministerio para la Transición Ecológica y el Reto Demográfico (Miteco) de España, ha publico el informe oficial dónde analizan las causas que han provocado el gran apagón que sufrió España el pasado 28 de abril. El encabezado de este informe es: «El cero eléctrico se produjo por un problema de sobretensión con un origen multifactorial: el sistema contaba con una capacidad de control de tensión insuficiente, se produjeron oscilaciones que condicionaron la operación del sistema y se desconectaron instalaciones de generación, en algunos casos de un modo aparentemente indebido»

Ya analizado pormenorizadamente el informe oficial, podemos llegar a las siguientes conclusiones:

Inestabilidad de tensiones previa: Se registraron variaciones atípicas de tensión durante las semanas y horas anteriores al apagón, especialmente el 22 y 24 de abril, que evidenciaron una creciente fragilidad en el sistema eléctrico peninsular.

Oscilaciones del sistema sin precedentes: Durante la mañana del 28 de abril se detectaron oscilaciones anómalas de frecuencia (0,2 Hz y 0,6 Hz) con amplitudes significativas que indicaban una pérdida de amortiguamiento del sistema, lo que comprometió su estabilidad.

Sobretensiones críticas: A partir de las 12:32h se produjo una subida súbita y sostenida de tensión que superó los umbrales normales y activó protecciones en numerosas instalaciones de generación, provocando desconexiones automáticas.

Desconexiones masivas de generación: Las sobretensiones y la inercia reducida del sistema generaron una pérdida escalonada de generación eléctrica —incluyendo unidades nucleares y ciclos combinados— lo que precipitó el colapso total de tensión.

Limitaciones estructurales del sistema: El sistema eléctrico presentaba una alta dependencia de generación renovable (82% en ese momento), una baja demanda y una configuración de red poco flexible para responder dinámicamente a oscilaciones rápidas de tensión y frecuencia.

Interconexiones ineficaces para estabilizar: Aunque se intentó reducir el intercambio eléctrico con Francia y Portugal, las interconexiones no pudieron amortiguar las oscilaciones ni sostener el sistema debido a su propia inercia limitada y problemas de sincronización.

Así que, en este caso, no ha sido cosa de un ciberataque ni delos extraterrestres que vinieron a repostar sus naves espaciales. Puedes consultar el informe oficial en este enlace: Informe Apagón MITECO

Linux es un sistema operativo sumamente flexible y capaz de ejecutarse en una amplia variedad de arquitecturas de hardware. Sin embargo, no en todas las arquitecturas donde puede ejecutarse Linux es estrictamente necesario un gestor de arranque. Su presencia depende en gran medida de la estructura del sistema y del contexto en el que se use el sistema operativo. 

En el caso de Windows, el gestor de arranque juega un papel fundamental en el proceso de inicio del sistema. Windows utiliza un bootloader llamado Windows Boot Manager (BOOTMGR), que se encarga de localizar y cargar el núcleo del sistema operativo desde el disco duro a la memoria RAM. Este gestor de arranque trabaja en conjunto con el BCD (Boot Configuration Data), una base de datos que almacena la información de configuración del arranque. A diferencia de Linux, donde se pueden emplear distintos bootloaders según la distribución y el hardware, Windows está diseñado para operar con su propio gestor de arranque, optimizado para su ecosistema y asegurando compatibilidad con su arquitectura cerrada.

En el caso de macOS, el gestor de arranque es boot.efi, que forma parte del firmware EFI (Extensible Firmware Interface) utilizado en los Mac modernos. Cuando se enciende el equipo, el firmware EFI detecta el hardware y busca el sistema operativo en el disco de arranque. Luego, boot.efi se encarga de cargar el núcleo de macOS en la memoria RAM y transferirle el control para completar el proceso de inicio. A diferencia de Windows y Linux, macOS está diseñado para funcionar exclusivamente en hardware de Apple, lo que permite una integración más controlada entre el software y el hardware, asegurando estabilidad y optimización en el arranque del sistema.

Volviendo a Linux, en arquitecturas de procesador como x86 y x86_64, desarrolladas por Intel y AMD, es común que se requiera un gestor de arranque para iniciar el kernel de Linux. Entre los gestores más utilizados en estos entornos se encuentran GRUB o LILO. No obstante, en arquitecturas como ARM y ARM64, que están diseñadas para ofrecer un alto rendimiento con un consumo energético reducido, no siempre es indispensable un gestor de arranque tradicional. En estos casos, el firmware o un bootloader integrado en el hardware, como U-Boot en sistemas embebidos, puede encargarse directamente de la carga del kernel. Algo similar ocurre con la arquitectura PowerPC en algunos sistemas embebidos, donde el firmware gestiona la carga del kernel debido a que la configuración del hardware es generalmente fija, eliminando la necesidad de un gestor de arranque avanzado.

Dentro de los gestores de arranque más populares se encuentra GRUB (Grand Unified Bootloader), que es ampliamente utilizado en sistemas Linux. GRUB permite, además, la coexistencia de varios sistemas operativos en una misma máquina, como Linux y Windows, facilitando que el usuario pueda elegir qué sistema iniciar en cada arranque. No obstante, con el auge de la virtualización, donde un sistema operativo puede ejecutar otro dentro de sí mismo sin restricciones significativas, la utilidad de los gestores de arranque para sistemas dual-boot ha disminuido. Ya no es imprescindible elegir entre un sistema u otro al encender el equipo, pues ambos pueden ejecutarse simultáneamente y estar disponibles para el usuario en todo momento.

El origen de los gestores de arranque en Linux se remonta a LILO (Linux Loader), un gestor que en la actualidad ha quedado prácticamente obsoleto. Posteriormente, apareció GRUB Legacy, el cual tenía la limitación de ser compatible únicamente con particiones MBR y no podía ser utilizado en sistemas con UEFI, aquí es dónde está el “kit” de la cuestión.

Los esquemas de partición juegan un papel crucial en la organización de los datos en un disco duro, y los dos más comunes son MBR (Master Boot Record) y GPT (GUID Partition Table). MBR es un esquema más antiguo con restricciones significativas, como el soporte máximo para discos de 2 TB y la posibilidad de crear únicamente cuatro particiones primarias. Por otro lado, GPT es una alternativa más moderna que permite trabajar con discos de mayor tamaño y admite un mayor número de particiones. 

Otro aspecto importante del arranque del sistema está relacionado con la BIOS (Basic Input/Output System) y UEFI (Unified Extensible Firmware Interface), que son los sistemas de firmware responsables de la inicialización del hardware antes de cargar el sistema operativo. La BIOS, al ser una tecnología más antigua, trabaja generalmente en conjunto con MBR, mientras que UEFI ha sido desarrollado como su reemplazo, optimizado para funcionar con GPT. Si me dieran un euro cada vez que alguien me han dicho que el disco duro de 4Tb había dejado de funcionar, y en realidad el único problema que había es que lo estaba conectando a un ordenador con BIOS… Por otra parte UEFI ofrece diversas ventajas, como tiempos de arranque más rápidos y una mayor seguridad mediante Secure Boot.

El propósito de Secure Boot es impedir la ejecución de software malicioso en el arranque del sistema, permitiendo únicamente la carga de sistemas operativos que hayan sido firmados digitalmente por entidades de confianza. Esto ha generado conflictos con algunas distribuciones de Linux, ya que ciertos fabricantes de placas base, siguiendo las normativas de Microsoft, han configurado sus sistemas para que solo arranquen sistemas operativos firmados por esta compañía. Como resultado, al intentar instalar o ejecutar Linux en estos equipos, el proceso de arranque puede fallar debido a la activación de Secure Boot. En tales casos, es necesario deshabilitar esta función para poder instalar o iniciar el sistema operativo.

Un problema habitual ocurre cuando se intenta arrancar un live CD de Linux en un equipo con Windows que tiene activado Secure Boot en UEFI, ya que esto puede impedir la carga del sistema operativo. Es importante entender que deshabilitar Secure Boot en un ordenador con chip TPM para iniciar un live CD (por ejemplo, una distribución Linux forense) puede traer consigo implicaciones de seguridad graves, hasta el punto de dejar el sistema inutilizable. 

Además, en sistemas Linux donde Secure Boot está habilitado, pueden surgir problemas relacionados con la carga de ciertos módulos del kernel. Dado que Secure Boot garantiza que solo se ejecuten binarios firmados y verificados, si se intenta cargar un módulo que no tiene una firma válida, el sistema lo bloqueará. Esto puede afectar a controladores de hardware propietarios o módulos compilados manualmente, generando errores en el arranque. Un ejemplo típico es cuando módulos esenciales para la virtualización o la gestión de sensores de la placa base son rechazados por el sistema. En apariencia, el sistema podría arrancar con normalidad, pero algunos servicios esenciales podrían quedar inactivos debido a la imposibilidad de cargar los módulos requeridos.

El TPM (Trusted Platform Module) es un chip de seguridad diseñado para proteger claves de cifrado, garantizando la integridad del sistema durante el arranque. Este módulo permite funciones como el cifrado de disco y la autenticación segura. Actualmente, muchos ordenadores incluyen este chip de forma predeterminada, ya que Windows 11 requiere su uso para reforzar la seguridad del sistema.

– ¡Que no!, ¡que me dejes en paz, yo no necesito saber todo esto para ser forense!

– Continuemos, el TPM también desempeña un papel importante en la verificación de la integridad del sistema durante el arranque, asegurando que no haya cambios no autorizados en el hardware o software. En sistemas Windows que emplean el TPM para proteger el cifrado de BitLocker, desactivar Secure Boot puede tener consecuencias graves. Si Secure Boot se deshabilita en un ordenador con BitLocker activado, las claves de recuperación se invalidarán y el sistema pedirá que se introduzcan en el siguiente arranque. Si el usuario no dispone de estas claves, el sistema quedará bloqueado y cifrado de manera irreversible para siempre. Es decir, perderás toda la información del equipo.

– Nah, vuelvo a activar el SecureBoot y ya estará todo como antes.

– No, una vez que el equipo entre en modo seguridad, necesitarás la clave de recuperación para poder acceder a tus datos. Sí, esa misma clave sobre la que, cuando instalaste Windows, apareció un mensaje recomendando imprimirla o guardarla en otro lugar, pero que decidiste ignorar.

Y por este motivo, para ser un buen forense, no hay que saber solo cómo recuperar o interpretar datos, hay que conocer a bajo nivel cómo funcionan las distintas características de los sistemas operativos para saber lo que se puede hacer y lo que no. En este caso, un perito informático no puede poner la excusa de: “era mi primerito día” o “esto yo no lo sabía”. A la hora de trabajar con este tipo de sistemas, es necesario conocer en profundidad este tipo de circunstancias para no “liarla parda”.

Si te ha gustado este artículo, recuerda que en mi libro: “Linux, de cero a ninja”, explico estas y otras cosas en detalle. Lo puedes comprar en Amazon siguiendo este enlace.

En España la piratería del futbol comenzó mas o menos por esa fecha, por aquellos tiempos en los domicilios de las familias y bares no existía una conexión a Internet que pudiera soportar el caudal de una retrasmisión televisiva en directo, por eso, la señal legal llegaba a los domicilios mediante satélite. En España el satélite que daba y sigue dando, cobertura de televisión de pago es el ASTRA 19.2 E. Este satélite envía a tierra la señal de cientos de canales de televisión, la mayor parte de ellos de pago. Esta señal es recibida por el LNB de una antena parabólica y enviada a un dispositivo decodificador conectado a la televisión. Como esta señal se retrasmite de forma cifrada, si no se disponen de las claves de descifrado la televisión no podrá mostrar ningún tipo de contenido de video. Estas claves se suministran de forma legal a cada consumidor mediante unas tarjetas NAGRA-VISIÓN que llevan en su interior la semilla generadora de claves de descifrado, por lo tanto, son capaces de “desbloquear” los canales de pago y mostrar su contenido. Para hacer esta operación no se necesita ningún tipo de conexión a internet, ya que la propia tarjeta NAGRA es autosuficiente para la generación de estas claves.

Aquí es donde entra en juego la piratería, las personas que no quería pagar la cuota de la suscripción a la televisión de pago, utilizaban tarjetas “trucadas” obtenidas de forma ilegal, estas tarjetas eran capaces de emular las claves generadas por las tarjetas NAGRA legales y por lo tanto mostrar el contenido televisión sin contratar ningún servicio con el proveedor oficial. Normalmente estas tarjetas piratas las había que comprar, pero a un precio bastante inferior a la suscripción legal de NAGRA y el operador correspondiente.

Aproximadamente, por los años 2000, los proveedores que habían comprado los derechos de emisión del futbol en España, que mueve casi tanto dinero como el boxeo en Estados Unidos. Comenzaron a ver que parte de sus potenciales clientes no les contrataban el servicio, ya que preferían comprar las tarjetas piratas y ver el futbol en sus casas a un precio mucho mas reducido. Fue en ese momento, cuando comenzaron a implementar las primeras medidas técnicas para evitar la piratería. Esta medida fue el barrido de tarjetas pirata en momentos álgidos de las competiciones deportivas, el típico Real Madrid – Barça, en el que instantes antes de comenzar el partido, los servicios de antipiratería de Vía Digital lograban bloquear un gran número de tarjetas pirata y por lo tanto dejar al pirateadores sin servicio en el peor momento de todos.

Este sistema de lucha contra la piratería se mantuvo durante bastantes años, hasta que poco a poco, los domicilios españoles y bares, comenzaron a disponer de conexiones a internet mediante ADSL con una velocidad y latencia de conexión suficiente para poder trasladar la piratería a la red. En este momento comienza a crecer la difusión mediante CCCAM. Esto no es otra cosa, que un protocolo de Internet, en el que un decodificar pirateado, es capaz de solicitar las claves de desbloqueado de la señal de televisión a un servidor de internet en vez de a una tarjeta física que estaba introducida en su interior.

El protocolo CCCAM, se basaba y basa, ya que sigue operando actualmente, en una serie de líneas C, cada línea incluye la dirección IP del servidor remoto de Card Sharing, un puerto de conexión y un usuario y contraseña. Ya que normalmente, estas líneas C son de pago. Es decir, el cliente tendrá que pagar una cantidad de dinero a un vendedor para que le facilite 5 o 6 líneas C. Normalmente no tiene sentido activar mas de 6 líneas ya que el decodificador posiblemente nunca llegue a utilizarlas todas.

Esto significa, que un usuario doméstico, se tendrá que conectar a un servidor remoto para poder obtener las claves del servidor CCCAM que ha contratado, normalmente por unos meses. Y para conectarse a este servidor pirata, lo tendrá que hacer mediante su propia conexión a Internet, que en España, habrá conectado con alguno de los principales operadores telefónicos, como Movistar, Vodafone, Orange y Yoigo. Que normalmente, algunas de estas compañías telefónicas también son las titulares autorizadas para revender contenidos de futbol a sus propios clientes.

Hace unos días en España, La Liga, empresa organizadora de una de las mayores competiciones futbolísticas del país, y la cual tiene los derechos de emisión de sus propias competiciones. Anunció que un Juzgado de lo Mercantil de Barcelona, había emitido un Auto Judicial que obligaba a los principales operadores telefónicos del país a identificar a los usuarios que desde sus redes accedan a contenidos relacionados con el fútbol pirata. Aunque sobre el papel parezca algo sencillo, en realidad es un tema tecnológicamente complejo, por un lado están las compañías telefónicas a las que nos conectamos para disponer de internet en nuestras casas o dispositivos móviles, como por ejemplo: Movistar, Vodafone, Orange y Yoigo. Estas compañías conocen los datos personales de sus clientes: Nombre completo, dirección postal, DNI, cuenta bancaria, etc…

A nivel técnico, las compañías telefónicas no proveen de internet a sus clientes en base a sus datos personales, sino que a cada cliente se le asigna una dirección IP temporal y con este parámetro técnico pueden relacionar las conexiones a internet que pasan por sus redes con sus propios clientes.

Lo que se propone en este Auto Judicial, que de momento no se conoce en su integridad, por lo tanto solamente se pueden hacer especulaciones sobre su contenido y si realmente se podrá llevar a cabo, es que sean las compañías telefónicas españolas quien identifiquen con nombre, apellidos, DNI, dirección postal… a todas aquellas de sus conexiones de Internet que se conecten a alguno de esos servidores que proporcionan o bien las claves secretas CCCAM o directamente el contenido IPTV pirata. El listado de estos servidores pirata, sería el propio servicio de Antipiratería de La Liga quien se lo proporcionaría a las compañías telefónicas para que estas hicieran la monitorización en sus redes y descubrieran quienes de sus clientes se conectan a esas direcciones IP que ofrecen contenidos piratas. Para el descubrimiento de los servidores que ofrecen estos contenidos ilegales, existe un equipo técnico privado que están investigando en la red para localizarlos y bloquearlos.

En la parte que se ha difundido de ese Auto Judicial, se entiende que la medida se se sustenta en el artículo LEC 256.1.11. (Ley de Enjuiciamiento Civil. No es un tema Criminal, que estaría únicamente circunscrita para delitos penales). Es decir, lo que se persigue según dicho artículo de la LEC es a los que difunden la señal de TV de forma ilegal, no a los que meramente la consumen. Por lo tanto, se trata según este artículo de identificar a los «pirateadores» que mediante sistemas de CCAM, IKS o IPTV se lucran revendiendo esta señal de TV de forma ilegal, ya sean las claves de descifrado del satélite o directamente la señal de video sobre IP. Es decir, por ejemplo, alguien que contrata una señal legal y luego la distribuyen a distintos usuarios de forma ilegal. Aunque podría, incluir otras autorizaciones más amplias para tratar de identificar a todo aquel que se conecte a un servidor pirata. Aunque si finalmente el Juez ordena a las compañías telefónicas que aporten los datos de titularidad de cualquiera de sus usuarios que se ha conectado contra una IP y Puerto concreto dado por La Liga, si se podría llegar a determinar quiénes son los titulares de las conexiones a Internet que están al menos moviendo tráfico de red contra unos servidores pirata determinados. Técnicamente esto no sería tan secillo como puede parecer un principio, las compañías telefónicas conforman ASNs (Servicios Autónomos de Red), los distintos ASN se tienen que conectar fisicamente entre sí para conformar lo que conocemos como Internet, una de las formas para que un ASN intercambie tráfico con otro ASN, es mediante las conexiones peering, esto no es mas que un acuerdo entre dos proveedores de servicios de Internet para intercambiar tráfico de red directamente entre sus redes, sin pasar por un tercero. Este intercambio directo de tráfico entre redes ayuda a mejorar la eficiencia y la velocidad de la conexión a Internet para los usuarios finales, pero a nivel de poder identificar el tráfico real de un usuario final contra una dirección IP concreta puede ser complicado, ya que estos enlaces de datos mueven grandes volumenes de tráfico por segundo.

Este tipo de medidas no son nuevas en España, ya hace unos años que La Liga, tiene la capacidad de enviar a los distintos operadores telefónicos un listado (black list) de direcciones IP de servidores que ofrecen estos contenidos ilegales, para que sean los ISP quienes bloqueen directamente todo el tráfico contra estas IP y así que los usuarios finales no se puedan conectar a esos servicios, algo parecido a un gran firewall nacional. El problema que esta medida de bloqueo antigua, podrá ser incompatible con la nueva medida que trata de identificar a los usuarios. Ya que si la conexión ha sido bloqueada por el operador telefónico para un IP y Puerto concreto, el usuario en realidad nunca podrá conectarse a ese servicio para descargar ningún tipo de contenido.

Por otra parte, hace menos de un año, que el Tribunal Supremo con Sentencia número 581/2023, de 11 de julio, ya indicaba que un partido de fútbol que se emite por televisión, pese a que se haga de forma ilegal, no es una obra literaria, científica o artística, por lo que su emisión no es un delito contra la propiedad intelectual: «El fútbol, desde luego, no es literatura. Tampoco es ciencia. Es cierto que en un partido de fútbol -en general, en cualquier espectáculo deportivo- pueden sucederse lances de innegable valor estético, pero interpretar esos momentos o secuencias de perfección técnica como notas definitorias de un espectáculo artístico puede conducir a transgredir los límites del principio de tipicidad”. Quedando la piratería de futbol, relegado en el ámbito penal a un delito leve contra el Mercado y los Consumidores (art.  286.4 CP).

Pero no hay que olvidar, que aunque en el ámbito penal, la piratería de futbol conlleva actualmente solo penas de multa. En el ámbito civil, puede acarrear importantes multas de dinero. Es por lo que si finalmente, La Liga, logra obtener los datos de titularidad de los usuarios que se están conectado a los servidores de piratería de futbol, podría iniciar un proceso civil contra estas personas. Hasta la fecha, la única circunstancia que recoge el Código Penal español, en la que una persona pueda cometer un delito por el mero acceso a un contenido online, eso sí, tiene que ser a sabiendas, es cuando acceda a sitios web que ofrezcan contenidos relacionados con delitos graves, como por ejemplo una página web que muestre videos que contengan pornografía infantil, como así lo recoge el artículo 189 del Código Penal.

Esta medida de investigación civil será un tema controvertido, no solo por los aspectos técnicos-legales que de ella se derivarán, sino que además pondrá de nuevo en el candelero los precios y condiciones de contratar un canal de futbol de forma legal en España. Por lo tanto, la única forma de ver el impacto real de esta medida, será ir analizándola a media que avanza el tiempo y cada uno de los distintos actores vayan moviendo ficha.

Es importante entender, que este es un artículo que describe una serie de hechos desde un punto de vista objetivo e histórico, en ningún momento opinaré de forma personal sobre si me parecen correctas o inadecuadas este tipo de medidas. Lo que si que no veo correcto, es la publicación de algunos titulares periodísticos, que mas allá de tratar de buscar la verdad, solamente buscan el sensacionalismo y el clickbaiting. No creo que la «investigación» que realicé en mi tiempo libre para escribir este artículo y poder determinar el alance real de la medida acordada por un Juzgado de lo Mercantil de Barcelona fuese tan complicada como para que no pudiera haber sido realizada por un medio de prensa profesional.

Con esto no quiero defender a los que ven el fútbol pirata, no voy a entrar en que si es muy caro, que si lo bajaran de precio no se piratearía tanto, etc… Eso ya sería otra discusión. Me centro simplemente en el aspecto legal y técnico, y esto significa que difundir una señal de TV sin sus correspondientes derechos puede ser un delito (si se vulnera la propiedad intelectual, como películas o series) o una infracción administrativa (si hay una vuleración de marca). Lo que si que tengo claro, tanto a nivel personal, como profesional, es que la piratería de futbol mueve millones de euros de dinero negro todos los años, dinero que en no pocas ocasiones termina financiando las macroestructuras de Organizaciones Criminales dedicadas a delitos realmente aberrantes. Por lo tanto, nunca podré estar de acuerdo con la piratería que financia actividades totalmente ilegales. Prueba de ello, son estos tuits al azar de algunas operaciones policiales que publiqué en su día:

Sobre el tema de si bajar los precios acabaría con la piratería, os recomiendo el documental sobre la creación de Spotify, creo que explica muy bien todo este asunto.

ACTUALIZACIÓN «in extremis»: Justo cuando estaba a punto de publicar este artículo, el Consejo General del Poder Judicial de España, de forma excepcional, ha hecho público el Auto de Diligencias Preliminares 27/2024-F del Juzgado de lo Mercantil número 8 de Barcelona, en el que efectivamente, la medida acordaba se basa en el artículo LEC 256.1.11. Lo que significa que este auto judicial únicamente requiere a las teleoperadoras para que faciliten los datos personales de quienes comparten ilícitamente sus contenidos, es decir, únicamente de los “cardsharers” que re difunden a terceros la señal y obtienen un lucro con ello y no, por tanto, de los que únicamente defraudan la cuota.

En la propia web del Consejo General del Poder Judicial, han publicado Esta Noticia en la que explican la finalidad de la medida acordada y el alcance real de la misma.

ACTUALIZACIÓN «bis»: Sin embargo en la propia web de La Liga, interpretan el Auto de un modo distinto al Consejo General del Poder Judicial, basándose en la literalidad de uno de los parrafos en los que según su parecer si autoriza la medida de averiguar los datos de identidad de los usuarios que simplemente accededan al contenido pirata y que estos datos sean aportados directamente a La Liga por parte de los operadores telefónicos.

En este punto si que voy a dar mi opinión, pero tiene que quedar claro que esta opinión puede estar a la altura e importancia, de la opinión de un «cuñado» cualquiera, no como la opinión de mi cuñado, que normalmente sabe muy bien de lo que habla. En resumen, no espereis demasiado criterio técnico-legal en las siguientes lineas. Lo que creo que ha pasado, es que el Juzgado ha autorizado esta medida de investigación en base al artículo LEC 256.1.11, que dice litaralmente: «el prestador de servicios de la sociedad de la información aporte los datos necesarios para llevar a cabo la identificación de un usuario de sus servicios, con el que mantengan o hayan mantenido en los últimos doce meses relaciones de prestación de un servicio, sobre el que concurran indicios razonables de que está poniendo a disposición o difundiendo de forma directa o indirecta, contenidos, obras o prestaciones objeto de tal derecho sin que se cumplan los requisitos establecidos por la legislación de propiedad intelectual«. Por lo tanto, La Liga aunque pidió la identificación de todos los ususarios que se conecten a los servidores pirata para ver un contenido ilegal, el Juzgado solamente puede autorizar medidas que sean legales, es decir medidas acordes a la legislación española, y en este caso, la legislación solamente permite realizar una medida de este tipo contra los revendedores, no contra los usuarios finales, como así dice el artículo LEC 256.1.11.

Por lo tanto, en principio La Liga, aportará a los operadores telefónicos las direcciones IP y Puertos de los servidores CCCAM o IKS pirata, con la idea de que sean los operadores telefónicos los que identifiquen a los revendores que se conecten a ellos desde conexiones de red en territorio español. Lo que en la práctica, igual no tiene el resultado esperado.

No quiero terminar este artículo sin recordar que aunque en España la distribución ilegal de futbol pirata no es un delito contra la propiedad intelectual, si es un delito leve contra el mercado y los consumidores, además de una infracción adminsitrativa.

Antes de comenzar con los ciberconsejos, creo que es importante definir lo que es un ransomware en pleno año 2023, antiguamente un ransomware era un tipo de malware que bloqueaba un equipo informático y pedía un rescate económico para el desbloqueo (100€), como ese bloqueo era básico se podía reparar sin mucha complicación. Al poco tiempo comenzaron a lanzarse campañas de ransomware que lograban cifrar los ficheros de un ordenador en vez del sistema operativo en sí, las primeras remesas de este tipo de ransomware también se podían descifrar debido a fallos del proceso de cifrado. La tercera fase comenzó cuando la única forma de lograr recuperar los ficheros cifrados era tomando el control del servidor C&C desde el cual se había lanzado el ataque, una vez intervenido el servidor se podían recuperar las claves privadas de descifrado de cada víctima. Todas estas fases formaban parte de los ataques de ransomware 1.0.

El ransomware 2.0 nació cuando además de cifrar los ficheros, los cibercriminales primero los exfiltraban y así en caso de que la víctima no quisiese pagar el rescate por la recuperación de los ficheros, la extorsionarían para que pagase el rescate a cambio de no difundir los ficheros confidenciales de la empresa que habían sido robados. Es decir, exfiltraba y cifraba.

El ransomware 3.0, en el cual nos encontramos hoy en día, es el que además de cifrar los ficheros y exfiltrarlos, en caso de que la víctima no pague, los cibercriminales lanzarán un ataque de DDoS contra los sistemas de la empresa u organización afectada, la finalidad de este nuevo ataque es dejarlos sin servicio y así presionar para que finalmente realicen el pago.

Finalmente, el ransomware 4.0 es el que una vez ejecutadas las dos o tres fases anteriores, los cibercriminales comienzan a vender los datos personales de los clientes que han sido exfiltrados de la empresa atacada, el objetivo es que un tercero los pueda utilizar para cometer fraudes a nombre de los clientes. Es decir, los perjudicados ya no solamente son las empresas atacadas, todos los clientes de esa empresa son potenciales víctimas.

Aquí os comparto 10 Ciber Consejos con los que una empresa u organización podrá protegerse contra el ataque de un ransomware, además, también la protegerán de otros muchos tipos de malware:

• Segmentación de red: Divide la red en segmentos para limitar la propagación de un posible ransomware que consiga acceder correctamente a un equipo de la red, de este modo también te protegerás de posibles exfiltraciones masivas de datos que pudieran estar almacenados en otros lugares de la red. Para realizar esta tarea se deberá separar la red a nivel lógico mediante VLAN, cada una de ellas con un gateway y direccionamiento IP independiente. En caso de tener que interconectar dos VLAN, por ejemplo para acceder a una web o cualquier otro recurso que se encuentre en la intranet, solamente se deberá permitir el tráfico en una sola dirección de una red o rango concreto al puerto y dirección IP en el que está publicado el servicio en cuestión, esto es lo que significa minimizar la superficie de ataque, de poco sirve tener la red segmentada en VLANs si después en el firewall alguien permite que todo el tráfico, por ejemplo TCP, pueda llegar de la red A a la red B, es decir, un plan sin fisuras.

• Mantén el software actualizado: Asegúrate de que todos los sistemas operativos, hipervisores, firmwares, apps y software en general esté actualizado con los últimos parches de seguridad para evitar vulnerabilidades conocidas, o incluso los temidos Zero Days (cuando ya son conocidos). Para que os hagáis una idea, durante los cuatro días que tardé en escribir este artículo, se han publicado las siguientes vulnerabilidades criticas: vulnerabilidad CVE 2023-36802 de elevación de privilegios del proxy del servicio de transmisión de Microsoft y la CVE 2023-36761 en la que con un fichero de Microsoft Word malicioso se pueden sustraer los hashes NTLM (gestión de contraseñas de usuarios), estos dos según Microsoft eran Zero Day que estaban/están siendo explotados hasta que se parcheen los sistemas afectados. Chrome y Firefox no se quedan atrás con su correspondiente vulnerabilidad CVE 2023-4863 que permitía un desbordamiento de búfer. Por no hablar de las vulnerabilidades Zero Day: CVE 2023-41064 y 2023-41061 que afectaban a los iPhone con iOS inferior a 16.6.1, y que obligaron a Apple a tener que sacar una actualización de emergencia para corregir estos problemas de seguridad. A Microsoft Teams también le salió un peligroso phishing que se aprovechaba de tenants maliciosos que enviaban ficheros comprometidos a los usuarios de esta plataforma. Volviendo a lo mundano, a nivel internacional tenemos el ransomware a la telco IFX, por otro lado a CoinEx le robaron 55 millones de dólares y el grupo de casinos y hoteles MGM sufrieron un ransomware que les obligó a desconectar todos sus sistemas de la red. Todo esto en menos de una semana. – Entonces… ¿actualizamos o no actualizamos?

• Utiliza una solución de seguridad confiable: Implementa un software antimalware de calidad en todos los dispositivos que se puedan conectar a la red y estén bajo tu control (y responsabilidad), en caso contrario, crea una red “sucia” e independiente para que se puedan conectar los dispositivos que no puedas controlar y así tenerlos al menos en una zona segura bajo un control más estricto. Por supuesto, mantén actualizados los sistemas: antivirus, IDS, IPS, EDR, Firewall, SIEM, etc… Además, revisa los logs que generan estos sistemas de seguridad para poder ver que está ocurriendo en la red, por mucha IA que tengas implementada tus sistemas de protección, nunca está de más que un ser humano eche un vistazo. Este control no deberá limitarse a los equipos físicos, hoy en día si cabe es más importante el control de la red, para ello implementa herramientas de monitoreo de red y sistemas de detección de amenazas que identifiquen comportamientos sospechosos y actividades maliciosas de manera temprana.

• Copias de seguridad regulares y válidas: Realiza copias de seguridad de todos los datos críticos y sistemas de la empresa/organización de forma regular, de poco sirve si haces un backup de la base de datos, si luego el sistema en el que corre la base de datos tardarías tres semanas en volver a ponerlo en producción. No es necesario que todas las copias de seguridad tengan la misma periodicidad, pero si es necesario que dispongas de copia de todos los elementos, tanto a nivel de datos como de sistemas en los que se visualizan o utilizan esos datos. Las copias de seguridad deberán estar desconectadas físicamente de la red principal, de este modo en caso de que el ransomware se propague por la red, nunca llegará a cifrar las copias de seguridad. Recuerda que no solamente existen los “ciber riesgos”, también deberás proteger las copias de seguridad de problemas relacionados con la seguridad física, como por ejemplo un robo, o un incendio. La forma de solucionar este último problema es por un lado que las copias estén cifradas, y que se almacenen en una caja fuerte especial a prueba de incendios.

• Control de acceso y privilegios: Implementa políticas de control de acceso y privilegios para limitar el acceso a los recursos de forma mínima e indispensable. Es decir, si un empleado de contabilidad tiene que acceder a una carpeta compartida con otro departamento, el acceso será limitado a una serie de trabajadores por cada recurso concreto. No tiene sentido que todos los empleados de una empresa tengan acceso a todos los recursos de la misma. Cuando hablo de acceso limitado, no solo me refiero a que se haga esta limitación por tipo de usuario con sus credenciales, lo ideal es que esta segmentación comenzase a nivel de red como ya expliqué anteriormente (VLAN). Por supuesto, para acceso a servicios un poco más críticos se deberá utilizar autenticación de múltiples factores (2FA) siempre que sea posible. También es importante tener el control sobre las aplicaciones que se puedan estar ejecutando en los equipos de la red, para este punto los antimalware y los EDR son tus amigos. Normalmente es necesario ir un poco más allá y no solo controlar las aplicaciones que se ejecutan, lo ideal es bloquear directamente cualquier aplicación no reconocida o que no sea necesaria para el correcto funcionamiento del departamento. Se hará configurando políticas de seguridad que limiten la ejecución de archivos en directorios temporales y otros lugares donde los archivos maliciosos a menudo se intentan ejecutar.

• Plan de respuesta a incidentes: Desarrolla un plan de respuesta a incidentes que incluya procedimientos claros para lidiar con ataques de ransomware o de cualquier otro tipo. Este plan deberá ser conocido y entendido por todos los departamentos que estén incluidos en el mismo. Una vez se disponga de un plan maduro y suficientemente estudiado por todas las partes, se pueden realizar simulacros de infección con la finalidad de buscar posibles fallas en el plan y así corregirlas antes de que se produzca un incidente real, porque seamos sinceros, acabará sucediendo. Este plan deberé contemplar puntos tan importantes como: si es necesarios apagar los equipos, aislar o desconectar la red, número de servicios implicados, qué hacer con ellos, quien se encargar del DFIR, jerarquía en la toma de decisión, tiempos máximos de respuesta, cuadrantes de personal en incidencias prevenidos 24×7, notificaciones a agencias de protección de datos, control de la información que sale al exterior (prensa y empleados), comunicados públicos, ruedas de prensa…

• Filtrado de contenido web y correo electrónico: Implementa soluciones de filtrado de contenido web y correo electrónico para bloquear sitios web y correos electrónicos maliciosos antes de que lleguen a la red de la empresa. De este modo, evitarás en gran medida que ficheros maliciosos puedan llegar al ordenador final de un trabajador, hoy en día la mayor parte de malware y por supuesto de ransomware, entra a una empresa mediante un correo electrónico, ya sea de forma directa adjuntándose en un email, o de forma indirecta a través de un “downloader” que descarga y ejecuta el ransomware propiamente dicho. Existe un porcentaje de ransomware que logra infectar un equipo o una red mediante la explotación de vulnerabilidades en equipos que están conectados a la red, por decirlo así, este tipo de ataques no necesitarán de una interacción humana para poder llevarse a cabo. Por eso es tan importante filtrar lo que llega a la empresa, como controlar lo que está ocurriendo en la red y en sus sistemas.

• Actualización de políticas de seguridad y educación continua: Revisa y actualiza regularmente las políticas de seguridad de la empresa u organización, deberás buscar la forma de proporcionar educación continua a los empleados para mantenerlos al tanto de las amenazas actuales y como protegerse de ellas. El objetivo es enseñar a los usuarios de la red a identificar y evitar posibles amenazas de ransomware, como correos electrónicos de phishing. Los empleados deberán aplicar políticas de contraseña robustas (se puede forzar a hacerlo), no compartir contraseñas, implementación de políticas de bloqueo de cuentas después de múltiples intentos fallidos y uso de sistemas 2FA seguros.

• Cifrar antes de que te cifren: Hoy en día los ransomware avanzados o 2.0, no solamente cifran los datos de sus víctimas para luego solicitar un rescate económico por recuperarlos, si no que previamente exfiltran o roban estos datos antes de cifrarlos. De este modo si la empresa decide no pagar el rescate al haber recuperado los datos cifrados, por ejemplo gracias a un back-up que tenían, los cibercriminales amenazarán de nuevo a la empresa con difundir todos sus datos confidenciales si no realizan el pago a la organización criminal. La única forma de evitar esto, es por un lado controlar el volumen de tráfico de red que sale de la organización y hacía que red sale, pero a veces no es suficiente, ya que la exfiltración puede durar meses e incluso hacerse contra servidores “confiables” como AWS, OVH, Azure, etc… Por lo tanto el mejor sistema para evitar la exfiltración, no tanto el cifrado posterior, es mantener toda la información en los servidores cifrada, de este modo, en caso de que secuestren por ejemplo los datos de un cabina o volumen de almacenamiento, los “malos” se llevarán datos que no los podrán utilizar para extorsionar a nadie (ni a la empresa atacada, ni a los dueños de los datos robados). Siempre y cuando no los consigan descifran, esto significa que no solamente hay que cifrar los datos, lo hay que hacer bien: contraseñas robustas, sistemas de cifrado que no tengan vulnerabilidades ni fallas, segmentar los volúmenes cifrados y que estos no usen la misma contraseña y por supuesto, mantener los volúmenes permanentemente cifrados, solamente montarlos cuando sea necesario. De este modo si el ransomware “cae” en el departamento de logística, como mucho dañará los recursos que en ese momento estén en uso y accesibles, al resto no les afectará.

• Auditoría de registros y monitoreo de eventos: Establece una sólida política de auditoría de registros y monitorea constantemente los eventos de seguridad para detectar comportamientos anómalos. No solamente en los logs que puedan ir dejando los sistemas de seguridad, hipervisores, busca en los propios sistemas operativos, logs de acceso remoto, aplicaciones en uso, horarios de funcionamiento, etc… Cuanto más profundo sea el conocimiento que tienes de la red o infraestructura que proteges, más sencillo te resultará detectar cualquier tipo de comportamiento anómalo o peligroso.

La prevención del ransomware implica un enfoque integral desde el punto de vista de la ciberseguridad, ya que afectará tanto a los técnicos de sistemas, alta dirección y trabajadores que sus funciones nada tienen que ver con ámbito cyber, para todos ellos y no solamente para estos últimos, la concientización constante es un pilar fundamental en la protección. Suena a tópico, pero la realidad es que es más barato invertir dinero en formar a los trabajadores en ciberseguridad que implementar docenas de medidas automatizadas que al final, si un “humano” trata de saltarlas, posiblemente lo logrará. Además, es importante recordar que no se debe pagar un rescate, ya que esto solo perpetúa el ciclo de los ataques de ransomware y no garantiza la recuperación de los datos, en algunos países está penando que las empresas paguen los rescates de un ransomware. Por supuesto, es imprescindible poner en conocimiento de la policía o del CERT designado el incidente ocurrido, para que de este modo tomen las medidas necesarias para desmantelar estas organizaciones criminales que han visto su nicho de mercado en los servicios de ransomware por suscripción, como el ejemplo que os dejo a continuación con el nuevo procedimiento de operaciones del RaaS Lockbit:

Pero en el artículo de hoy vamos a hablar de algo parecido: el “vishing”, esta es una técnica de ingeniería social que mediante una llamada telefónica busca engañar a su victimas haciéndolas creer que las están llamando desde un teléfono oficial de una empresa, cuando en realidad es todo un engaño. Los cibercriminales con esta técnica maliciosa son capaces de hacerse pasar por una empresa y engañar a su victima para que revele datos confidenciales como sus contraseñas de la banca online o se instalen algún tipo de malware. Existen dos grandes modus operandi que utilizan esta técnica, el primer es la conocida como “Estafa de Microsoft”, en la que un cibercriminal mediante una llamada telefónica se hace pasar por un trabajador de Microsoft y con la escusa de haber detectado una malware en nuestro ordenador, nos incita a instalar de forma remota un supuesto antivirus que en realidad es el propio malware. El otro caso se da cuando el cibercriminal se hace pasar por un trabajador de una entidad bancaria, para lograr que la victima le indique el número de su tarjeta bancaria, las contraseñas de la banca online o el SMS con pin del 2FA que le llegará durante el proceso de estafa.

Pero… – ¿Qué tiene de interesante este tipo de estafas desde el punto de vista cyber?. – La clave es que para lograr el engaño, los cibercriminales consiguen modificar el número de teléfono que aparece en la pantalla del móvil de la victima por el de la entidad o empresa a la que están suplantando, de este forma pueden engañar más fácilmente a sus victimas. – ¿Y que clase de brujería es esta?. – Bueno, no voy a entrar a explicar muy en detalle como lo hacen los cibercriminales, ya que no es el objetivo de GLIDER.es . Básicamente, el procedimiento es desplegar en un servidor propio una centralita de VoIP como por ejemplo Asterisk, darla de alta en un SIP Trunking y luego en el propio Asterisk modificar la configuración del Caller ID para utilizar el identificador de llamadas de la empresa a la que se va a suplantar, es decir, el objetivo de todo esto es que en la pantalla del teléfono al que llamamos aparezca el número de teléfono de la empresa que estamos suplantando en vez del real.

Antes de explicar que son todas esas siglas que he escrito en el párrafo anterior, os voy a poner un ejemplo para que se pueda entender mas fácilmente el “truco” del spoofing en el número de teléfono, también conocido como vishing. El ejemplo es el siguiente: imaginaos que vamos a enviar una carta postal, las de toda la vida, en el anverso escribimos los datos del destinatario de la carta, en el reverso escribiremos la dirección del remitente, es decir, nuestra dirección ya que somos quien enviamos la carta. Pero. – ¿Hay algún problema si en el remitente escribimos la dirección de otra persona?. – La realidad es que no, la carta llegará a su destino sin ningún tipo de complicación, cuando el destinatario mire el remitente creerá que la carta se la ha enviado esa persona, cuando en realidad ha podido ser cualquier otra, esto ocurre al no comprobar por parte de Correos la identidad real del remitente. Exactamente esto es lo que ocurre con el Caller ID en una llamada de VoIP. Es posible modificar maliciosamente el identificador de llamada del remitente/llamante para hacerse pasar por cualquiera otro llamante legitimo, ya que el sistema de tránsito de llamadas no comprueba la veracidad del CallerID (existen proyectos que están trabajando en la implementación de un sistema que si lo compruebe a nivel global). En el caso del smishing funciona exactamente igual, la única diferencia es que en vez de generarse una llamada maliciosa de voz, se envía un mensaje de texto con un remitente suplantado.

Aunque en la teoría modificar el Caller ID pueda parecer un proceso sencillo, en la vida real no es tan fácil, ya que además de tener que disponer de un servidor propio de VoIP en el que se pueda modificar el Caller ID, es necesario encontrar un SIP Trunking que permita enrutar llamadas salientes sin comprobar que provienen de su titular legitimo y esto no es tan sencillo.

Vamos ahora a por unas cuantas definiciones básicas que serán de utilidad para entender todo esto del spoofing via VoIP (Voz mediante IP).

• Caller ID: Es el identificador del llamante, se trata de un dato que se trasmite junto con la llamada en sí para informar al destinatario quien lo está llamando. Este dato es la clave de todo el engaño, si se consigue realizar una modificación de este parámetro, se podrán realizar llamadas suplantando cualquier número de teléfono real.
• SIP Trunking y Proveedor SIP: Son las siglas de Session Initiation Protocol, se trata de un protocolo que permite enrutar una llamada desde la centralita de VoIP (PBX) al destinatario de la misma. Si la llamada tiene que salir fuera de la organización o empresa, será necesario contratar un proveedor SIP para que esas llamadas puedan llegar a cualquier centralita de otro destinatario a través de Internet. Un símil sería como tener un DNS local o usar un DNS global, el DNS local lo podemos administrar de forma interna en nuestros servidores sin ningún tipo de coste, mientras que el global es necesario alquilar el uso del servicio a un proveedor externo.
• SIP ID: Es un identificador que puede ser un nombre de usuario, una dirección de correo electrónico o un número único asignado a cada usuario o dispositivo. El SIP ID es esencial para el enrutamiento de las comunicaciones y asegura que las llamadas y otras sesiones se dirijan correctamente al destino deseado en una red VoIP. Este termino no lo hay que confundir con el Caller ID, ya que no son lo mismo, mientras que el SIP ID es un identificador utilizado en el protocolo SIP para enrutamiento y gestión de sesiones en una red VoIP, el Caller ID es la información que se muestra en el teléfono receptor para identificar quién está llamando.

• Asterisk: Es un software de código abierto que funciona como una centralita telefónica (PBX). Utiliza el protocolo SIP para establecer y gestionar llamadas de voz y vídeo a través de redes IP. Es uno de los sistemas mas conocidos en el mundo del VoIP, entre otras cosas gracias a que es una plataforma extensible y que permite crear servicios personalizados como IVR.
• FreePBX: Un PBX (Private Branch Exchange) es la propia centralita de llamadas en si, este sistema actúa como intermediario en las comunicaciones telefónicas internas y externas de una organización, facilitando la administración y gestión de las llamadas. En el caso de FreePBX se trata de una herramienta de código abierto que permite realizar esta tarea a nivel software sin necesidad de necesitar ningún tipo de hardware específico.
• CDR: (Call Detail Record) Es un registro detallado de la llamada telefónica que contiene datos como la duración,  fecha, número de origen y destino, identificación del dispositivo, etc. Estos registros son generados automáticamente por la propia centralita que almacena toda la información en una base de datos. Normalmente estos datos tambien se guardan en el SIP Trunking en caso de tenerlo contratado.
• IVR: (Interactive Voice Response) Es el sistema automatizado que permite a los usuarios interactuar con una grabación utilizando comandos de voz o teclas numéricas en sus teléfonos. Es el típico «pulse 1 para hablar con ventas» o «pulse 2 para hablar con fábrica».
• Softphone: Es el programa que tienen que instalar los usuarios de un sistema VoIP para poder realizar llamadas desde un ordenador a través de la centralita asignada. Es similar a un teléfono virtual, con su teclado, agenda de contactos y botón de llamar y colgar. Para utilizarlos es necesario disponer de un micrófono y altavoz conectado al ordenador. Tambien existen teléfonos VoIP hardware, que serían practicamente iguales a un telefono tradicional analógico.

A nivel forense, toda la información que necesitamos estará en el servidor de VoIP desde el que se generan las llamadas maliciosas, normalmente son servidores Linux tipo VPS, desplegados en un CPD de cualquier parte del mundo, al cual el cibercriminal se conectará mediante un SSH para administrarlo de forma remota.+

Como este es un artículo especializado en el análisis forense de un servidor VoIP con Asterisk y FreePBX dedicado a realizar llamadas maliciosas tipo vishing, voy a omitir toda la parte genérica de análisis forense en la nube y análisis forense en Linux, ya que además tengo tres artículos publicados en esta misma página web en los que explico detalladamente todo el proceso para este tipo de análisis forense, puedes consultar estos artículos en los siguientes enlaces:

Aunque se trata de artículos genéricos, son ideales para entender lo básico de este tipo de sistemas y por lo tanto necesarios para realizar un análisis forense de un servidor de VoIP administrado remotamente. No hay que olvidar la importancia de los logs de acceso al SSH (VNC, RDP…) del sysadmin o cualquier otro usuario, el fichero bash_history y las direcciones IP de conexión a la red del propio VPS.

Para poder realizar este artículo sin utilizar los datos de un servidor real de una organización criminal dedicada al fraude online mediante vishing, he desplegado mi propio servidor de VoIP configurado de forma maliciosa para lograr realizar llamadas modificando el Caller ID, obviamente aunque este servidor VPS tenía que estar conectado a Internet, lo he bastionado para que nadie mas lo pudiera utilizar sin mi autorización. He utilizado la configuración típica de Asterisk en VPS más un softphone Zoiper instalado en mi ordenador desde el cual he ido realizado las llamadas maliciosas durante dos meses, de este modo pude generar todas las trazas y rastros reales que dejaría un servidor real dedicado a realizar un vishing. Sobra decir que todas las llamadas que realicé fueron en un entorno controlado y nadie fue engañado para la creación de este artículo, salvo un par de bromas que le hice a unos amigos los cuales recibieron llamadas VIP desde altos órganos del Estado, pero que cuya conducta penal fue atípica

Otro problema de desplegar un servidor funcional para este tipo de análisis forenses son los costes, aunque se utilice software libre y el VPS ya esté en producción para realizar otras tareas, el proveedor SIP lo hay que contratar y pagar. No suelen ser precios muy elevados, normalmente al no contratar ningún tipo de pack o servicio anual solamente se cobran las llamadas salientes que se realizan, el precio suele ser fijo por minuto. 

Hasta aquí la primera parte más teórica de este artículo, en la segunda parte ya empezaremos a desmenuzar de forma pormenorizada el funcionamiento técnico de este tipo de servidores, así como buscar los lugares en los que se guardan las trazas mas importante en un análisis de este tipo.

TO BE CONTINUED…

Granito a granito, fue creando una comunidad de buenas personas, una comunidad de hackers buenos. Algunas de estas personas no eran tan buenas, o mejor dicho, eran personas que se habían equivocado en alguna decisión de su vida y acabaron cara a cara en una sala de declaraciones con un buen hombre de verde. Este hombre ayudó a muchos de estos “especialistas en ciberseguridad”, que hoy en día cobran por encima de los 100K, él los ayudó a reconducir sus vidas. Niños por aquellas, frente a todo un hombre que les explicaba con toda la paciencia del mundo las implicaciones de lo que habían hecho, niños a los que les explicaba que tenían dos posibilidades: seguir cometiendo estafas online, ciberataques y demás, o utilizar todo su potencial para trabajar y vivir de la ciberseguridad. Esos niños hoy le deben mucho al gran Angelucho, le deben todo lo que son.

No buscaba el dinero, ni la fama, simplemente buscaba hacer el bien.Prueba de ello fue su primer libro que publicó: “X1RED+SEGURA”, lo podía haber vendido o comercializado, pero no, decidió difundirlo gratuitamente para que nadie se quedara sin él, por que su lema era: “Por una red más Segura”. Fue un precursor en el mundo de la divulgación sobre ciberseguridad, fue el mejor. Todavía hoy se puede descargar su libro de forma gratuita en formato PDF, lo puedes descargar desde Este Enlace. Yo tuve suerte, un día mientras tomábamos un café me regaló uno de los ejemplares impresos de su libro, después de leerlo, quedó en mi biblioteca para siempre, igual que su recuerdo.

Cuando llegué a casa y comencé a leer el libro, me di cuenta que me había firmado el libro, no lo había visto hasta ese momento, ese tipo de detalles eran los que definían a Angelucho. Hoy es un día triste, hoy se cumple la segunda línea de la dedicatoria de su libro mas famoso: “A los que estuvisteis y ya no estáis”, hoy eres tú Ángel, hoy eres tú el que no está entre nosotros, pero en realidad, siempre estarás ahí.

Pero la dedicatoria de su libro iba dirigida a mas personas: “a mi familia, a los que sufrís mi ausencia aún estando presente, a los que me aguantáis cada día, a los que me animáis… “. Hoy en la última despedida de Ángel ahí estaban: familia, amigos y compañeros que dejaron todo lo que estaban haciendo para viajar de madrugada desde: Madrid, Valencia, Alicante, Santander, Zaragoza, Sevilla y otros muchos sitios para poder estar a las 9:00 de la mañana junto a una buena persona, junto a una gran persona.

Aún me acuerdo amigo cuando venías por casa y me decías que en mi jardín de noche no se escuchaba nada, te quedabas callado solamente para escuchar la nada. Ayer por la noche me quedé yo callado en el jardín escuchando la nada. Justo a media noche pasó una gran estrella fugaz que cruzó el cielo iluminándolo de punta a punta, algunos dirán que fue una Perseida, yo estoy seguro que no. Era el gran ÁNGEL que LUCHÓ hasta el final, vuela alto amigo.

En este artículo de GLIDER voy a centrarme en realizar un “review” sobre las capacidades de auditoría WiFi de un dispositivo Flipper Zero con su correspondiente placa de ampliación WiFI dev. Si todavía no sabéis lo que es capaz de hacer un Flipper Zero, os dejo Este Artículo titulado: “Desmitificando un Flipper Zero” dónde explico de forma pormenorizada todas las capacidades o discapacidades de un Flipper Zero.

Antes de comenzar vamos a explicar los distintos protocoles con los que pueden operar las redes WiFi:

Existen varios protocolos de redes WiFi, entre los más comunes se encuentran: 802.11a que opera en la banda de frecuencia de 5 GHz y tiene una velocidad máxima de 54 Mbps. El 802.11b opera en la banda de frecuencia de 2.4 GHz y tiene una velocidad máxima de 11 Mbps y el 802.11g opera en la banda de frecuencia de 2.4 GHz con una velocidad máxima de 54 Mbps. Estos tres estándares de la IEEE (Institute of Electrical and Electronics Engineers) están prácticamente en desuso, ya que se trata de tecnología desfasada.

El 802.11n opera en las bandas de frecuencia de 2.4 GHz y 5 GHz y tiene una velocidad máxima de 600 Mbps. Normalmente utilizado a nivel doméstico para lanzar redes WiFi a 2.4 GHz.

El estándar 802.11ac opera en la banda de frecuencia de 5 GHz y tiene una velocidad máxima de varios gigabits por segundo. Hoy en día es el estándar más utilizado en redes de 5 GHz

Finalmente, el 802.11ax (también conocido como WiFi 6) es la última versión del protocolo WiFi y opera en las bandas de frecuencia de 2.4 GHz y 5 GHz. Ofrece una velocidad máxima teórica de 10 Gbps mejorando la eficiencia del espectro y la gestión de dispositivos. Hoy en día es uno de los estándares que todavía se está desplegando, por lo tanto, su uso está bastante limitado.

Es importante tener en cuenta que para que los dispositivos se comuniquen correctamente, deben ser compatibles y usar el mismo protocolo WiFi, es decir, si nuestro Access Point (emisor) opera como máximo con el estándar 802.11g, no se podrá utilizar en redes de 5GHz. ¿Para qué explico todo esto?, muy sencillo, el ESP 32 que utiliza la placa WiFi Dev del Flipper Zero solamente puede operar en la frecuencia de 2.4GHz, lo que significa que cualquier red que funcione en la frecuencia de los 5 GHz no podrá ser auditada con este dispositivo, es decir, las redes exclusivas de 5GHZ no son compatibles con este módulo WiFi.

¿Y qué podemos hacer en los 2.4GHz con el Flipper Zero y su modulo WiFi?, vamos a verlo:

En primer lugar, es necesario explicar que el Flipper Zero solamente hace las funciones de pantalla y teclado del módulo WiFi, toda la carga de procesamiento se ejecutará en el ESP32 integrado en el módulo WiFi que se conecta al Flipper Zero mediante sus GPIOS.

Una vez ya le hemos cargado el correspondiente firmware al módulo WiFI, podemos manejarlo si queremos desde un ordenador. Para esto conectaremos un cable USB-C desde el Flipper Zero a nuestro ordenador, y activaremos el modo que simula una interfaz COM (puerto serie) para controlar el módulo mediante una consola de telnet remota en nuestro PC.

Desde este modo podremos ir ejecutando todos los ataques disponibles, pero en realidad esta configuración no tiene mucho sentido, ya que el verdadero potencial del Flipper Zero es su autonomía e independencia de cualquier otro dispositivo. Si que es cierto que para hacer un escaneo de redes WiFi desde el propio Flipper Zero es bastante complicado, ya que si existen muchas redes WiFi en la zona será prácticamente imposible verlas correctamente en la pequeña pantalla del Flipper Zero. Una opción intermedia sería simular el puerto serie a través de una conexión bluetooth y conectarnos al telnet desde nuestro teléfono móvil, pudiendo utilizar de este modo una pantalla más grande y manteniendo el sistema autónomo e independiente. Por ejemplo, podremos ver todas las redes WiFi disponibles en nuestra zona junto con sus parámetros técnicos en una pantalla grande, como se puede mostrar a continuación:

La imagen anterior muestra la potencia de señal de cada Access Point WiFi, su BSSID (Dirección MAC) y SSID (Nombre de Wifi), así como los beacon: unas balizas que utilizan las redes WiFi para poder coordinarse con sus clientes (dispositivos que se conectarán al WiFi). Esta información es muy similar a la que podemos obtener utilizando la herramienta Airodump-NG en Linux, con la diferencia de que aquí ya está todo automatizado y listo para funcionar. Eso sí, el Flipper no muestra tanta información como Airodump-NG, por ejemplo, los “probe request” (emisiones del SSID que hace el cliente) o los clientes no asociados (no conectados a un WiFi), no los muestra. En caso de Airodump-NG muestra más información técnica sobre las redes WiFi que un Flipper Zero con su modulo WiFi, como se puede observar en la siguiente imagen:

Este “ataque/scan”, nos puede servir para ver todas las redes que tenemos a nuestro alcance y obtener una serie de parámetros técnicos sobre ellas, nada que sea critico o especialmente peligroso para la seguridad de los clientes o los Access Point.

Operando desde el propio Flipper Zero, también se puede obtener la misma información, lo que ocurre es que es bastante más difícil ver los datos en su minúscula pantalla. En este caso, solamente tenemos que entrar en el menú de “WiFi Marauder” como se muestra en la siguiente imagen:

Ya dentro del menú WiFi Marauder, la primera de las opciones será la de “Scan AP”, que nos mostrará la misma información que en el punto anterior, pero a través de la pantalla del Flipper Zero. En este caso, la red WiFi de una impresora multifunción marca HP modelo ENVY.

Al analizar las redes WiFi cercanas (Access Point), el WiFI Marauder del Flipper Zero, asignará automáticamente un identificador único a cada una de las redes, esto nos servirá posteriormente para poder seleccionar el objetivo que queremos atacar. Normalmente esto se hace seleccionando la dirección MAC del emisor WiFi, en este caso para evitar tener que escribir una dirección MAC utilizando solamente los cinco botones del teclado del Flipper Zero, nos facilita la tarea permitiendo escribir solo el número (identificador único) asignado a la red WiFi en cuestión. Por ejemplo, en la siguiente imagen se muestra la red 5 y la 6 para auditar, las anteriores (1, 2, 3 y 4) y las siguientes (7, 8, 9…), las podremos visualizar subiendo y bajando el cursor del Flipper Zero.

Si lo que queremos es seleccionar un cliente y no un AP como target (objetivo), también lo podremos hacer, ya que, con esta opción, nos listará todos los AP disponibles y los clientes que están conectados a cada uno de ellos. Esto sirve para afinar la puntería y no realizar un ataque contra todos los clientes conectados a esa red, pudiendo seleccionar uno solo, dejando el resto de clientes operar normalmente. En la siguiente imagen se muestra los AP en la primera línea (AP: 5 y 6) y los clientes conectados a los AP con una tabulación respecto a los AP (clientes: 0; 1 y 22)

Una vez que ya sabemos cuál será nuestro objetivo, un AP o varios clientes, desde la opción “select” tendremos que indicar si lo que vamos a seleccionar es un AP o un cliente.

Para seleccionar el objetivo solamente indicaremos el número o identificador que he comentado anteriormente, en realidad lo que estamos haciendo es escribir el comando: “select –a IDENTIFICADOR”, pero como el select –a ya está escrito, solamente nos preocuparemos de poner correctamente el Identificador.

Si, por ejemplo, comparamos un Flipper Zero, con la ancestral WiFI Pinneapple (la Piña WiFi es otra herramienta de hardware hacking orientada a la auditoria de redes WiFi, que también funciona únicamente en redes de 2,4GHz), la información que muestra y los módulos que permite ejecutar son bastante más potentes, por contra, la Piña WiFi no tiene batería, ni pantalla, ni teclado, por lo que siempre se necesitará un ordenador o teléfono móvil para poder usarla. En la siguiente imagen se muestra el interfaz de uso de la WiFi Pinneapple en modo scan.

Y ahora es cuando viene lo de hablar de los ataques que es capaz de realizar el Flipper Zero con el módulo WiFi Dev. ¿Será un “bluf” como el caso del Artículo anterior de GLIDER dónde comentaba los ataques de radio que podía hacer un Flipper Zero?, vamos a verlo para que podáis valorar por vosotros mismos:

El primero de los ataques que vamos a realizar se llama “Deauth Atack”, básicamente un ataque que intentará desautenticar un cliente de su AP o todos los clientes de un AP, es decir, desconectar un dispositivo de la red WiFI a la que está conectada. ¡OJO! No hay que olvidar que realizar este tipo de pruebas o ataques sin consentimiento de los usuarios puede ser constitutivo de un delito de daños informáticos, dentro del epígrafe de denegaciones de servicio. Ya que en realidad lo que hace esta herramienta, es saturar de tal modo el AP, que al final no tiene la capacidad de poder mantener la conexión estable con su cliente, terminando por desconectarlo de la red.

Para poder ejecutar este ataque, tuvimos que haber seleccionado previamente el AP o los clientes a desautenticar mediante el comando “select –a IDENTIFICADOR”. En la siguiente imagen se muestra el ataque ejecutándose, mientras se muestre por pantalla, se estará enviando de forma continua los paquetes de desautenticación al cliente a mayor velocidad que el AP trate de conectar al cliente, de este modo se podrá lograr desconectar a los clientes seleccionados por un tiempo determinado.

Como este ataque se basa en un estándar del paquete legítimo de desautenticación del IEE 802.11, es complicado protegerse de él, una de la formas más optimas, es disponer de una red WiFi con roaming de varios AP, así cuando nos desautentiquen de uno, el cliente se irá automáticamente al otro AP más cercano. No es una solución infalible, ni barata, pero permitirá mitigar en gran medida este tipo de ataques.

Otra forma de protegernos de un ataque tipo deauth, es activando los PMF en el Access Point (Protected Management Frames). Los PMF se utilizan para proteger los mensajes de gestión que se envían en las redes Wi-Fi, como los mensajes de asociación, autenticación y desautenticación, de la interceptación y manipulación por parte de posibles atacantes. Esto se logra mediante la adición de un cifrado adicional a los mensajes de gestión que se envían entre dispositivos inalámbricos y puntos de acceso. Los PMF descritos en el estándar 802.11w están disponibles en las redes Wi-Fi más recientes, como el estandar 802.11ac. Sin embargo, no todos los dispositivos inalámbricos y puntos de acceso son compatibles con los PMF, por lo que es importante verificar la compatibilidad antes de implementarlos en una red Wi-Fi. En redes WiFi con seguridad WPA-2 son opcionales, sin embargo si utilizamos la tecnología WPA-3 ya vienen implementados por defecto y no se pueden desactivar. Gracias a @Sergio_deLuz Director de @redeszone por la pista de las tramas PMF.

Si os estáis preguntando a quien se le ha ocurrido meter dentro un estándar como el IEE 802.11 un paquete tan “peligroso” como el “deauth”, pensad que es peligroso si se utiliza para hacer el mal, pero en condiciones normales de uso, es un paquete necesario cuando un AP tenga que impedir que se conecte un cliente por ejemplo por haber introducido incorrectamente la contraseña de la WiFi o si ya hay demasiados clientes conectados y han superado el límite de capacidad del AP.

En la imagen anterior, se muestra un paquete de desautenticación estándar, otra forma de mitigar este ataque sería aceptando solo paquetes deauth de una lista blanca de direcciones MAC, pero al existir herramientas que permiten suplantar una dirección MAC o la problemática de gestionar estas listas blancas al querer aumentar el número de estaciones, al final es complicado bloquear paquetes malintencionados de este tipo.

De los tres tipos de tramas que se pueden generar con el estándar IEE 802.11, la de desautenticación se encuentra dentro del grupo de Gestión (Control y Datos son las otras dos). Esta trama está dividida en ocho campos, que son los siguientes:

• Campo 1: Es dónde se indica que tipo de trama de las existentes se está transmitiendo. Por ejemplo, la trama de desautenticación es del tipo gestión (00) y subtipo 1100 o 0x000C (desautenticación). Si fuese de autenticación el valor del subtipo sería de 1011.

• Campo 2: Un valor en microsegundos para declarar el tiempo de vida que tendrá la trama.

• Campo 3: La dirección MAC de destino.

• Campo 4: La dirección MAC de origen.

• Campo 5: El BSSID, normalmente es el mismo que el campo 3, salvo en entornos de redes complejas.

• Campo 6: Indica el número de orden en la secuencia de tramas, se usa para ordenarlas en caso de que lleguen al destinatario sin el orden correcto.

• Campo 7: El código que indica la razón para la desautenticación, es un dato meramente informativo, podríamos escribir de motivo: “PARA HACKEARTE”, y el cliente se seguiría desconectado igual, cosas de los protocolos… Antes de que algún ingeniero de teleco o de sistemas se asuste, en realidad no podríamos hacer esto, en informática se suele utilizar códigos para definir situaciones, ya que pensad que transmitir el mensaje: “PARA HACKEARTE”, ocupa 14 bytes, mientras que asignar un código hexadecimal de dos cifras a un mensaje predefinido solamente ocupa unos pocos bits, y los datagramas en redes no están precisamente para derrochar “bits”. En realidad, este campo solo acepta un número limitado de códigos predefinidos, por ejemplo, el código 4 significa: desautenticado por inactividad o el 23 significa: autenticación fallida. En Esta Tabla tenéis el listado de CISCO de códigos con el motivo para desautenticar un cliente de un AP (si no recuerdo mal, en total existen un poco menos de 60 códigos distintos).

• Campo 8: (FCS o Frame Check Sequence) Una suma de verificación para realizar el control de la integridad de la trama y descartarla si este valor no concuerda con el esperado. Es decir, si algún dato se ha corrompido, esta suma de verificación no corresponderá con el cálculo que hace el destinatario y el paquete se rechaza.

Por ejemplo, si quisiéramos lanzar un ataque de desautenticación contra el cliente con dirección MAC: AA:AA:AA:AA:AA:AA haciéndonos pasar el AP con dirección MAC: 55:55:55:55:55:55, la trama que tendríamos que lanzar sería algo parecido a esto: 00-1100-100-AAAAAAAAAAAA-555555555555-AAAAAAAAAAAA-1-23 (los guiones los he insertado para marcar visualmente el límite de cada campo, en la vida real no se transmiten). ¿Y cómo hemos podido averiguar las direcciones MAC del cliente y del AP para poder lanzar el ataque?. Estos datos por definición del propio protocolo son públicos y no se envían cifrados, por lo tanto con cualquier receptor WiFi configurado en modo monitor podemos recibir todas las tramas de gestión que están lanzando al aire los AP y los clientes, extrayendo las direcciones MAC y utilizándolas para ejecutar este tipo de ataques. Así de sencillo.

Un riesgo de este estándar, es que al fin y al cabo las direcciones MAC se asignan públicamente a fabricantes concretos, luego el fabricante dentro del rango asignado las va asociando a los componentes que fabrica. ¿Qué riesgo puede suponer esto?, por ejemplo, permite saber la disposición y capacidades de la alarma de una casa. Un ejemplo es el de una conocida compañía de alarmas española que tiene asignada un encabezado de direcciones MAC fijo y por lo tanto, cualquier dispositivo que comience con esta dirección MAC sabremos que se trata de un sensor de alarma de esta compañía de seguridad y como son datos que se envían por radio al aire, cualquier persona desde la calle los puede ver.

Y así es como funciona un ataque de desautenticación a bajo nivel, ya veis que no es magia, simplemente es utilizar una tecnología existente para un uso en el que en un primer momento no se había pensado (o sí).

Otro ataque que se puede realizar con un Flipper Zero y su placa WiFI Dev, es el “RICK ROLL ATACK”, posiblemente uno de los ataques más peligrosos y complejos que he visto en mi vida ( << imaginad aquí el emoticono del hombre golpeando su frente >> ). Si no sabéis cómo funciona este ataque, os recomiendo que veáis primero el siguiente tutorial de YouTube dónde se explica su funcionamiento a bajo nivel:

Si os habéis quedado como estabais después de escuchar la canción de: Rick Astley – Never Gonna Give You Up, no os preocupéis, es totalmente normal. ¿En qué consiste este ataque entonces?, pues ni más ni menos, que en crear puntos de acceso WiFi falsos con la letra de esta famosa canción de Rick Astley , o mejor dicho, lanzar al aire tramas WiFi publicando la existencia de varias redes WiFi que sus SSID (Nombre de la red) coincide con la letra de la canción. Por ejemplo:

• SSID de la WiFI 1: “We’re no strangers to love”

• SSID de la WiFI 2: “You know the rules and so do I (do I)”

• SSID de la WiFI 3: “A full commitment’s what I’m thinking of”

• SSID de la WiFI 4: “You wouldn’t get this from any other guy”

• SSID de la WiFI 5: “I just wanna tell you how I’m feeling”

• SSID de la WiFI 6: “Gotta make you understand”

Este tipo de ataque no influye en el funcionamiento del resto de redes publicadas en la zona, simplemente muestra 10 o 12 nombres de WiFi a mayores, que como mucho molestarán a la hora de seleccionar en el móvil a la que verdaderamente nos queremos conectar. Como podéis comprobar, más que ataque, se debería llamar broma o vacilada delante de los amigos, poco más que añadir.

El siguiente tipo de ataque que vamos a analizar es el de tipo «probe«. En este tipo de ataques se intenta descubrir redes Wi-Fi que están en modo oculto. Una red Wi-Fi oculta es la que no emite su nombre de red (SSID) públicamente, lo que significa que la red no aparece en la lista de redes disponibles en el dispositivo del cliente y por lo tanto (en principio) para poder conectarnos a ella, es necesario conocer y escribir previamente el nombre de la red (SSID) y después su contraseña.

Para descubrir una red oculta, una técnica que se puede utilizar es enviar paquetes de solicitud de sondas (probes) a la dirección de broadcast de la red (Calculada normalmente con la máscara de subred y la dirección IP, por ejemplo, para una red /24 con IP 192.168.1.5 la dirección de broadcast es la 192.168.1.255). Estos paquetes se envían de forma maliciosa en busca de una respuesta del punto de acceso de la red. Si el punto de acceso responde, se podrá averiguar el SSID de la red.

Los ataques de tipo «probe» son especialmente peligrosos, ya que cuando pregunto en mis conferencias de ciberseguridad sobre quien oculta el SSID de la red para aumentar su seguridad, siempre hay alguien que levanta la mano, explicando que lo hace para evitar que ningún cibercriminal se pueda conectar a esa red de forma maliciosa, ya que, si supuestamente la red “no se ve”, es imposible atacarla al no poder vulnerar lo que no se ve. En realidad, esto no es así del todo, es más, dependiendo de si queremos evitar ataques de script kiddies o de alguien más profesional, ocultar el SSID de la red no es para nada recomendable. Si lo que queremos evitar es que el vecino del cuarto nos robe el WiFi, vecino que los únicos conocimientos de hacking que tiene es un par de videos de YouTube que ha visto, no es mala idea ocultar el SSID, pero hoy en día esta técnica de “seguridad por oscuridad”, ya no resulta tan interesante como hace unos años. Ocultar el SSID de una red WiFi, puede hacer que los clientes que se han conectado a ella con anterioridad, tengan que estar continuamente lanzando tramas para localizarla, lo que permitirá localizar más fácilmente tanto a los clientes como a los AP con esta configuración.

Hasta aquí la descripción de funcionalidades que se pueden llevar a cabo con Flipper Zero y su placa WiFi dev, no hay que olvidar que el WiFi dev no deja de ser un ESP32, por lo que se podrán programar otras herramientas con unas funcionalidades más prometedoras, pero de momento, al menos en las versiones de firmware por defecto o el avanzado llamado “unleashed”, las funcionalidades son bastante limitadas, más allá de presumir delante de los amigos al ser capaces de desconectar una televisión o un teléfono del WiFi al que estaba conectado.

Un Flipper Zero es un dispositivo de hardware hacking portable, con su batería de 200mAh  y pantalla monocrómatica de 1,4 pulgadas lo convierte en una herramienta 100% autónoma que no necesitará de ningún otro componente para hacer su “magia”. Su interior oculta todo su potencial: una serie de antenas que lo hacen compatible con distintas tecnologías como:

• RFID (Identificación por Radio Frecuencia) de 125KHz para llaveros tag o los chips de identificación de mascotas.
• NFC (Comunicación de Campo Cercano) como las tarjetas bancarias o documentos de identidad.
• Infrarrojos que usan los mandos a distancia de las televisiones, aire acondicionados, juguetes…
• Uno de sus puntos fuertes es la comunicación por debajo de 1GHz, como por ejemplo el estándar de 433MHz, frecuencia que utilizan la mayor parte de mandos de garaje, puertas automáticas, llaves de coche o estaciones meteorológicas.
• Pines GPIO de 3.3V o 5V, para controlar todo tipo de addons externos como sensores o antenas WiFi.
• Lectura y clonado de llaves tipo iButton para abrir puertas vía portero automático.
• 2FA o llave de segundo factor de autenticación física, para logarnos en sitios que sean compatibles con esta tecnología.
• Clon del BadUSB, un sistema que permite replicar un teclado físico para ejecutar comandos predefinidos mediante scrips externos.
• Desde hace poco también permite simular señales digitales en distintas frecuencias.
• Conexión Bluetooth para controlar el Flipper Zero en remoto desde el smartphone.

Pero vamos a lo que importa, ¿realmente hace lo que dice?, vamos a verlo.

Comenzamos por las conexiones GPIO, esta parte quizás sea la mas multifuncional ya que permite miles de opciones. Aprovechando que tenía un sensor de temperatura y humedad DHT22 por casa, le cargué al Flipper Zero un controlador de este sensor y tan solo configurando el PIN de datos y la salida de 3.3V comenzó a mostrar todos sus datos por pantalla, tal y como se ve a continuación funcionando correctamente. ¡TEST APPROVED!

La siguiente prueba será con el sensor / emisor de infrarrojos, la mayor parte de controles remotos que tenemos en nuestra casa funcionan con esta tecnología. En este punto existen distintas formas de utilizar el Flipper Zero. Una de ellas es con el sistema de captura de infrarrojos y posterior remisión del RAW capturado, por ejemplo, pulsamos el botón del mando de encender una tira led con la opción de captura infrarrojos del FlipperZero activada, una vez capturada le podremos asignar un alias y reenviar la señal todas las veces que sea necesaria, así ya no tenemos que usar el mando original.

Como es muy tedioso estar capturando y guardado la señal que emite cada botón de un mando, el Flipper Zero ya trae precargados los controles remotos de miles de televisiones, aires acondicionados o reproductores multimedia. No es compatible con el 100% de los electrodomésticos que existen, pero si funciona con un gran número de ellos. ¡TEST APPROVED!

Al disponer de una antena de 125KHz el Flipper Zero es capaz de leer tags o tarjetas Mifare 1, que se usan en algunas tarjetas antiguas de pago del autobús urbano o metro. En este caso se puede leer y replicar la tarjeta íntegramente, ya que además de ser capaz de leer los 16 sectores de la tarjeta es capaz de leer la clave A y B de cada sector, pudiendo suplantarla de este modo con el Flipper Zero. ¡TEST APPROVED!

La realidad, es que hoy en día ya son pocos los establecimientos que utilizan tarjetas Mifare 1 para el pago de servicios o el control de accesos, por lo tanto su uso real se queda limitado a esas pocas tarjetas que todavía sigan utilizando una tecnología tan antigua. Por ejemplo, en los documentos de identidad o las tarjetas bancarias que disponen de antena NFC v3 la cosa ya no es tan sencilla. Los sistemas contactless actuales no permiten leer íntegramente los datos de la tarjeta para poder ser replicados posteriormente, es decir, existe una zona de la tarjeta que no puede ser emulada o replicada. Por eso con el Flipper Zero no se pueden clonar la mayor parte de tarjetas bancarias que se usan hoy en día. Si lo intentamos hacer solamente podremos extraer como mucho su identificador único (UID), incluso, si lo hacemos desde la app del móvil este identificador se podrá ir modificando de forma aleatoria. Por lo tanto, aquí nos encontramos con un ¡TEST FAIL! en esta característica atribuida al Flipper Zero. En la siguiente imagen se pueden ver los únicos datos que aparecen al escanear una tarjeta bancaria actual con NFC tipo B.

Una característica interesante del Flipper Zero, es que al tener una antena RFID puede leer los microchips identificativos de animales de compañía, estos chips que tienen el tamaño de un grano de arroz y llevan un transpondedor en su interior, emiten un código numérico único. Este código está dado de alta en el correspondiente servicio web para consultar los datos personales del propietario del animal. Para ayudar a localizar la posición exacta del microchip, el Flipper Zero dispone de una luz led que irá cambiando de color cuanto más cerca se encuentre la antena del microchip. No es tan fácil leer el chip como con el propio lector que se usa para identificar animales, ya que el Flipper Zero solo puede leer el chipt si está alineado a la antena, mientras que los lectores normales son circulares y lo pueden leer en cualquier dirección.

Decir que esta funcionalidad de lectura NFC no es exclusiva de un Flipper Zero, con una Raspberry o un Arduino y el módulo RFID RC522 o un Proxmark se podrán leer y escribir de igual modo cualquier tarjeta NFC compatible. En la foto siguiente os dejo una imagen comparativa del Flipper Zero con el modulo RFID RC522 al lado.

Bajando un poco en las frecuencias, llegamos al estándar de 433MHz. Esta es la frecuencia que se utiliza en los mandos de las puertas de los garajes, llaves de apertura de los coches o estaciones meteorológicas. Vamos a ver que se puede hacer en esta frecuencia con el Flipper Zero.

Comenzaremos por un mando de garaje, normalmente con un solo botón se puede abrir la puerta del garaje: una pulsación abre la puerta y otra pulsación en el mismo botón cierra la puerta. Esto significa que el mando solamente emite un código que es el mismo para abrir y cerrar la puerta. El Flipper Zero tiene una opción de captura, lo ponemos a grabar y en cuanto detecta la señal que emite el mando se verá en una gráfica por pantalla.

Luego la señal se podrá guardar y replicar todas las veces que sea necesaria, lo que significa que podemos abrir y cerrar la puerta sin necesidad de tener el mando real con nosotros. Esto puede suponer un riesgo de seguridad, ya que si cuando pulsamos el botón de abrir la puerta del garaje, alguien está cerca de nosotros con un Flipper Zero nos podrá capturar la señal y luego replicarla cuando quiera.

Es cierto que hay que haber capturado inicialmente la señal del mando real, pero el peligro es que una vez capturado nos pueden abrir la puerta del garaje sin nuestro permiso. Por lo tanto: ¡TEST APPROVED!. Para evitar este tipo de riesgos necesitaremos cambiar el sistema de apertura de nuestro garaje por uno que utilice un sistema de “Rolling Codes” como el que veremos a continuación.

Otros videos que estoy cansado de ver en TikTok, es en los que alguien abre un coche simplemente utilizando un Flipper Zero, incluso en algunos vídeos muestran como pueden arrancar el coche y se lo llevan simulando la llave real. Siento desilusionarlos, pero en la vida real, fuera del TikTok, esto no es tan sencillo. A diferencia que en el ejemplo anterior con el mando del garaje, una llave de un coche no utiliza siempre el mismo código para abrir o cerrar la puerta, es mas, nunca se utiliza el mismo. Sin entrar en una explicación demasiado técnica, cada vez que pulsamos el botón de la llave del coche se genera un código de un solo uso, similar a un “Token” (Por ejemplo como el Google Authenticator) que se envía por radiofrecuencia a 433,92MHz al coche, si este código de 64 o 66 bits es correcto el coche se abrirá, si no, no ocurrirá nada. Por lo tanto, aunque consigamos capturar la señal que emite el mando de nuestro coche, cuando la repliquemos ya no será un código válido y por lo tanto no servirá de nada.

Si el coche es un poco viejo y no utiliza un sistema “Rolling Code” actualizado, si se podría intentar duplicar el código de apertura mediante un ataque de reply, pero aún así se tendrían que dar una circunstancias muy concretas. Sería necesario capturar un código de un solo uso de apertura que no se ha utilizado y por lo tanto seguirá siendo válido hasta que se “gaste”, para ello será necesario conseguir que se pulse el botón de apertura del mando real lejos del coche para que el código capturado no se marque como usado por el coche o mediante un jammer impidiendo que la emisión legitima llegue al receptor, luego se dispondrán de unos instantes para abrir el coche antes de que el código caduque o deje de ser válido. Dependiendo del sistema de seguridad de la llave del coche, para evitar que sin querer se pulse el botón del mando lejos del coche y automáticamente dejen de ser válidos todos los códigos que se generen posteriormente por el mando real (al faltar uno intermedio), el coche aceptará hasta un máximo de un rango de 256 códigos futuros, esto significará, que para que el mando deje de funcionar, tendríamos que pulsar mas de 256 el botón de abrir sin que el coche se encuentre cerca de nosotros (OJO con dejarle las llaves de nuestro coche a un bebé/niño para que juegue con ellas, que como le dé por ponerse a pulsar los botones tendremos un problema si nuestro coche no es muy moderno, ya que el mando se podría desincronizar con el receptor del coche. Ocurría lo mismo si tratamos de replicar demasiadas veces el codigo de nuestro mando con el Flipper Zero).

Por lo tanto, teniendo en cuenta todas las circunstancias y requerimientos necesarios para intentar abrir un coche actual sin su llave, no encontramos antes un ¡TEST FAIL!. La única forma de hacerlo, como cualquier otro proceso criptográfico, es obtener la semilla de generación de esas claves. Normalmente la semilla está formada por una parte fija que es el VIN del vehículo y una parte variable con la zona aleatoria de la clave, ambas partes suman un tamaño aproximado de 64 bits. Esto es la teoría, la práctica nos dice que a veces los fabricante de coches no hacen bien su trabajo y se «olvidan» de implementar las correspondientes medidas de seguridad en sus llaves, como fue el caso de Honda y el CVE-2022-27254.

Lo que si podríamos hacer en un coche moderno, como por ejemplo los TESLA, es abrirle la tapa del cargador de la batería. La curiosidad de TESLA es que la tapa de «repostaje» se puede abrir en remoto a 433MHz, a diferencia de los coches tradicionales que solo se puede abrir si el coche está también abierto, en TESLA se puede abrir la tapa de carga aunque el coche esté cerrado (lógico al ser cargas que pueden durar horas dependiendo de la potencia del cargador), lo que ocurre es que la señal que abre la tapa no lleva ningún tipo de cifrado o rolling-code, por lo tanto se podría aplicar una técnica similar a la utilizada con el mando de la puerta del garaje, simplemente es necesario cargar un script en el Flipper Zero que se tendrá que configurar en función de si estamos en Europa o USA (cambia la frecuencia de emisión). Aquí tendríamos un un ¡TEST APPROVED! para el Flipper Zero, pero un ¡TEST FAIL! para TESLA.

Finalmente, el Flipper Zero tiene una funcionalidad muy interesante con la frecuencia de 433MHz, como esta frecuencia es la que utilizan la mayor parte de estaciones meteorológicas domésticas, se puede activar el Flipper Zero en modo escucha y si detecta una emisión de una de estas balizas, la capturará mostrando los datos por pantalla como en la siguiente foto, en la que se puede ver la temperatura exterior, humedad y estado de la batería de la estación.

Otro proyecto en el que estoy inmerso es el poder leer los sensores TPMS (Sistema de Monitorización de Presión del Neumático)  de las ruedas de los coches, en principio también transmiten los datos a 433MHz, pero como cada fabricante implementa su propia codificación esto complica la tarea de poder interpretar los datos.

Ya pasando de radio a cable, el Flipper Zero también permite realizar ciertos ataques vía USB, el mas conocido es el que imita el funcionamiento de un dispositivo: Bad-USB, una herramienta visualmente igual que un pendrive, pero que en su interior lleva un microprocesador que permite simular un teclado y un ratón que al conectarlo a un ordenador, comenzará a ejecutar todas las ordenes que le hemos programado. Por ejemplo, al conectar el USB podrá ejecutar un script para que se descargue un binario con un RDP de Internet, lo ejecuté de forma automática y envíe el acceso al atacante. Al simular ser un teclado real conectado al ordenador, es como si la propia persona estuviera haciendo las acciones programadas, lo que permite evadir algunos sistemas antivirus.

Por defecto el Flipper Zero trae un script llamado “Demo Windows” que al conectarlo y ejecutarlo, automáticamente abre en un navegador web con el video de Youtube de “Rick Astley – Never Gonna Give You Up” ( https://www.youtube.com/watch?v=dQw4w9WgXcQ ) y lo comienza a reproducir en bucle.

He visto muchos videos en TikTok e Instagram en los que se veía como con un Flipper Zero se podía desbloquear en cuestión de segundos cualquier móvil Android solamente ejecutando un script de fuerza bruta. Este script comienza a probar contraseñas de forma indiscriminada hasta dar con la acertada y desbloquear el teléfono móvil. Sobre el papel es un plan sin fisuras, pero en la vida real todos los móviles actuales disponen de un sistema que impide que se puedan meter cientos de contraseñas por minuto, es cierto que hace unos años iPhone tuvo una vulnerabilidad en la que reiniciando el teléfono cada vez que se introducía una contraseña errónea esta no descontaba los intentos fallidos, a Android le ocurrió algo parecido con la opción de llamar al 112: todos los teléfonos permiten llamar a emergencias aunque el terminal este bloqueado, el problema era que al estar llamando si se pulsaba una combinación de teclas se podía entrar al escritorio del móvil sin tener el patrón de desbloqueo. Hoy en día al tercer error metiendo el PIN o el patrón ya tenemos que esperar 30 segundos para intentarlo de nuevo, al cuarto error tenemos que esperar 1 minuto, y así sucesiva y exponencialmente hasta que el móvil queda totalmente bloqueado y prácticamente inservible.

¿Entonces cómo es posible que en los videos de TikTok puedan desbloquear un móvil tan rápidamente sin que se quede inutilizado?, como seguro que ya os imagináis lo consiguen haciendo un poco de trampa, realmente la fuerza bruta de contraseñas se hace sobre un diccionario pre cargado en el script, lo que significa que si ponemos en segunda o tercera posición del script la contraseña correcta, efectivamente el móvil se desbloqueará mágicamente. Está muy chulo para quedar de “hackers” delante de los amigos, pero en la vida real es un autentico ¡TEST FAIL!. Otra cosa, es utilizarlo en sistemas de autenticación que no implementen medidas de retardo al introducir una contraseña errónea, pero hoy en día ya quedan pocos.

Una función que si es interesante es la de “Jiggler”, esta función simulará un ratón conectado al ordenador que se está moviendo constantemente un poco a la derecha y un poco a la izquierda, esto sirve para mantener un equipo informático desbloqueado sin que se active el salvapantallas y se bloquee la sesión. Por ejemplo, normalmente un teléfono móvil desbloqueado que no se toque en 30 segundos o un minuto se bloqueará automáticamente, con esta función esto ya no ocurrirá al simular que si se está usando. Esta característica funciona muy bien, por lo tanto se merece un: ¡TEST APPROVED!.

Otra opción que se puede utilizar mediante la conexión USB es la de simulación de teclado, en este caso, teclado real. Se nos mostrará un teclado en la pantalla del Flipper Zero y cada vez que seleccionemos un tecla en el Flipper Zero está se enviará al ordenador como si se hubiera pulsando en un teclado real, aquí se han ganado otro ¡TEST APPROVED!. Ojo, la dirección del keystroke es del Flipper Zero al Ordenador, no viceversa, por lo tanto esto no es un Keylogger.

Finalmente, también podremos conectar el Flipper Zero directamente a nuestro ordenador a través de un USB-C que simula un puerto COM para actualizarlo o mover ficheros entre ambos equipos, esta función se realiza mediante una aplicación llamada qFlipper disponible en Windows, Mac y Linux, he probado las versiones de Windows y Linux, ambas funcionan correctamente montando una consola virtual a través del puerto COM.

Y lo mejor de todo es que además el Flipper Zero dispone de videojuegos integrados, uno de ellos es el mítico “Snake” de los Nokia 3310, un detalle retro-gamer que se valora positivamente. Aunque me da la sensación que no funciona exactamente igual que cuando se ejecutaba en un teléfono móvil, tengo que indagar mas en este asunto.

En definitiva, el Flipper Zero es un gadget curioso, muy bien construido, con materiales aparentemente de muy buena calidad, con un diseño innovador, cómodo, portable y con una ingeniería detrás que se nota que han pensado hasta el mínimo detalle. Pero no, no es la herramienta “hacker” definitiva anunciado en TikTok, ni mucho menos (Prueba de ello son los 12 o 15 Flipper Zero que se ponen en venta cada día en portales de segunda mano por gente que lo compró pensando que iba a ser otra cosa). Es simplemente el compendio de un mando de televisión universal, un lector de chips de mascotas, un lector NFC como el de cualquier teléfono móvil de última generación, un mando de garaje universal, un Arduino o Raspberry, un Yubico y un Nokia 3310 con el Snake.

Hoy en día se puede comprar un Flipper Zero por entre 200 a 250€. Ahora la pregunta del millón: ¿Merece la pena?, pues como os imagináis, si pensabais que con esto os ibais a colar en todos los gimnasios de vuestra ciudad, viajar en metro sin pagar, desbloquear los móviles de vuestros amigos, abrir un coche para robarlo o entrar a cualquier garaje de vuestro barrio sin permiso, ya habéis visto que no. Aún así no hay que olvidar, que el Flipper Zero dispone de capacidades que en malas manos permitirá cometer ciertos tipos de actividades criminales, por eso mismo, este artículo: CONTINUARÁ…

…y continuó: si quieres leer la segunda parte del este artículo titulada: «Atacando Redes WiFi con un Flipper Zero», solamente tienes que pulsar en Este Enlace.

Al trabajar con entornos de consola de comandos, como servidores Linux sin GUI, SSH, o incluso herramientas de Forense o Hacking, vamos memorizando su uso y estructura de funcionamiento a base de ejecutar el mismo comando una y otra vez. Pero cuando hay que usar herramientas muy diversas, al final es complicado recordar todos los parámetros de cada uno de los comandos. Por eso nacieron las “Cheat Sheet” (Hojas de Chuletas en español). Estas hojas son resúmenes esquemáticos de todos los parámetros de funcionamiento de una herramienta, un lenguaje de programación o un sistema operativo. Personalmente utilizo a diario varias de estas “Cheat Sheet”, por ejemplo, para Linux me gusta mucho la que hizo @Manz llamada “Terminal de Linux”.

Para forense me quedo con los que edita gratuitamente SANS, son tan variados y tocan tantas especialidades que no pueden faltan en ningún laboratorio forense. Se pueden Descargar desde la Web de SANS.

Aunque también me gusta mucho el libro “BLue Team Field Manual” que aglutina todos estos comandos en forma de libro de consulta. Otra ventaja de leer Cheat Sheets que han creado otras personas, es que siempre se puede aprender algún comando o parámetro de una herramienta que utilizamos a diario y que no conocíamos.

Pero a veces, me gusta hacer mis propios Cheat Sheet, ya que me resulta mas sencillo utilizar mi propia estructura de explicación que tratar de entender las observaciones de un tercero. Este es el caso de Docker, como sabéis, Docker es un sistema de “micro” contenedores que permiten ejecutar casi cualquier aplicación sin necesidad de tener que virtualizar un sistema operativo completo. Por ejemplo, si necesito un servidor APACHE, puedo desplegar una máquina virtual Ubuntu, instalarle Apache y utilizar el servicio. Pero a veces, esto es un poco “matar moscas a cañonazos”. Así nació Docker, una forma de instalar solo el servicio o aplicación que necesitamos de forma aislada en un contenedor. A este contenedor le podemos dar conexión al host, a otros contenedores entre si o dejarlo totalmente aislado. Para los que nunca utilizasteis Docker, y de forma resumida, se puede decir que Docker es como una mini máquina virtual que no necesita un sistema operativo completo para ejecutar una aplicación.

Estos contenedores, como os imaginarias, a nivel de administración de sistemas, forense o pentesting son una herramienta muy potente, ya que en vez de estar ejecutando varias máquinas virtuales, con todos los recursos que estas pueden consumir, podemos ejecutar una sola instancia de Docker con varios contenedores que no necesitarán tantos recursos para mantener el servicio en producción. Eso si, como todo en la vida, Docker tiene limitaciones, si lo queremos utilizar para un servicio que necesite muchos recursos, posiblemente no sea lo más adecuado.

Una vez hecha la introducción de lo que es un Docker, os comparto el Cheat Sheet de Docker que he creado hace un tiempo y que utilizo a diario para descargar imágenes, gestionar redes o crear contenedores de Docker. Como veis su uso es muy sencillo, incluso hay comandos redundantes que se le puede eliminar alguno de los parámetros, al final he decidido dejar estos parámetros “dobles” para que se pueda entender bien cual es su estructura. Por ejemplo, no siempre hay que utilizar el parámetro “container”, ya que si implícitamente estamos invocando a un contenedor, excusamos indicárselo doblemente.

Puedes Descargar gratuitamente este Cheat Sheet de Docker en alta calidad y formato PDF pulsando AQUÍ.

Si todavía tienes dudas sobre si es interesante el uso de Docker… por ejemplo, a nivel forense, os cuento en lo que estuve trabajando este fin de semana y que en breve escribiré por aquí: Hay que analizar un servidor ASTERISK cuya base de datos opera bajo MySQL, una vez extraída la base de datos en formato SQL, podemos crear un servidor Linux, instalarle MySQL / PhPMyAdmin e importar la base de datos, o directamente ejecutar un contenedor Docker desde una imagen con una instancia de MySQL precargada que hemos descargado desde los repositorios de Docker. Con tres comandos ya tenemos un servidor MySQL corriendo. Rápido, Sencillo y Eficiente.

A nivel de sistemas, nos hemos ahorrado mucho tiempo y tenemos la tranquilidad de que en cuanto terminemos de analizar la base de datos, eliminamos el contenedor y volvemos a tener un entorno completamente limpio. Si fuese una máquina virtual, podríamos usar “snapshots” o incluso plantillas, pero posiblemente necesitaríamos mucho mas espacio en disco para abrir una simple base de datos de un par de gigas de tamaño.

En otras ocasiones podemos necesitar montar una red de contenedores un poco mas compleja, por ejemplo si queremos desplegar un Elastic Search + Kibana, necesitamos descargar sus dos imagenes, crear una red común entre los dos contenedores y desplegarlos con los parametros adecuados, aunque esto no es muy complicado, siempre podemos hacerlo mas sencillo utilizado Docker Compose. Compose permite especificar los parámetros de funcionamiento y ejecutar varios contenedores Docker desde un solo fichero YAML en el que previamente se han establecido las condiciones de funcionamiento. La ventaja de Docker Compose, es que con un simple fichero YAML que hemos podido descargar de sus repositorios (¡OJO! con ejecutar YAML de origenes no confiables) y el comando «docker-compose up» tendremos nuestros servicios desplegados sin habernos despeinado.