GLIDER.es

Forensic, Hacking & Cibersecurity

¡Agente, yo no he sido! Análisis Forense de IA OpenClaw

Publicado el Por

Si lleváis un tiempo siguiendo esta web o mis redes sociales, sabéis que la irrupción de la Inteligencia Artificial no solo ha traído cosas buenas, sino que ha puesto en manos de cibercriminales herramientas de automatización, creación de deep fakes o generación de malware al alcance de casi cualquier persona. Hoy no nos vamos a quedar en la teoría, vamos a realizar un análisis forense de un servidor real de OpenClaw, este es un framework diseñado para operar agentes de IA de forma autónoma, que en este caso ha sido configurado para interactuar mediante Telegram, pero se podría controlar desde Whatsapp o Discord. Lo más interesante en este caso, es que OpenClaw se puede conectar a modelos locales a través de un servidor tipo: Ollama o LM Studio. De este modo, si se utiliza además un modelo sin censura o bloqueos, se podrá operar el sistema de inteligencia artificial sin ningún tipo de restricción, es decir, se le podrá solicitar cualquier tipo de información o acción, que OpenClaw la ejecutará sin contemplación, ya sea para bien o para mal.

Si todavía no sabes lo que es OpenClaw, decirte que es un sistema de orquestación que actúa como el sistema operativo de un agente autónomo de IA, transformando un modelo de lenguaje estático (como puede ser ChatGPT o Gemmini) en un operador capaz de ejecutar acciones en el mundo real. Su funcionamiento se basa en conectar el «cerebro» (el LLM) con «extremidades» (APIs, scripts o acceso a archivos, emails, agendas, sistemas… ) para que la IA no solo responda preguntas, sino que planifique y ejecute acciones de forma independiente. Todo esto bajo un entorno que, al integrarse con servidores locales como Ollama, permite lleva un paso mas allá la potencia de estos agentes de IA.

Por otra parte, lo que estamos viendo con OpenClaw es un hito sin precedentes en el código abierto: OpenClaw ha pulverizado los récords de GitHub al superar las 250.000 estrellas en apenas 3 meses, dejando atrás la progresión histórica de titanes como Linux o React. Incluso la explosión de OpenClaw ha provocado que el famoso mini pc Apple Mac Mini vuele de las estanterías y si quede sin stock en muchas tiendas en cuestión de semanas, esto es debido a que la eficiencia y arquitectura de un Mac Mini lo han convertido en la hardware ideal para que estos agentes autónomos corran localmente las 24 horas sin descanso ni vigilancia, por un coste irrisorio.

^{Fig. Estrellas del proyecto OpenClaw en GitHub}

Este crecimiento vertical no es solo cuestión de «hype», sino la prueba de que el interés de la industria ha mutado de los simples chatbots hacia la autonomía absoluta, permitiendo a cualquier desarrollador desplegar agentes locales sin restricciones mediante Ollama, pero no os equivoquéis, esta adopción masiva a la velocidad del rayo es un arma de doble filo, ya que ha creado un ecosistema tan potente como caótico donde la seguridad a menudo se queda en un segundo plano frente a la urgencia de automatizarlo todo, y ya no digamos los aspectos forenses, que es lo que vamos a tratar hoy.

Un ejemplo del o que digo es el siguiente: hace unos días le pedí a OpenClaw que me escribiera un código fuente de ransomware, ya que estaba utilizando un modelo local sin bloqueos, hasta aquí todo normal, si no fuese por la respuesta que me dio:

^{Fig. OpenClaw atacándome con un ransomware}

Efectivamente, no solo me generó un código fuente válido para un ransomware, si no que además: ¡Me lo ejecutó en mi propio ordenador!, por eso es importante tomar precauciones a la hora de darle demasiados permisos a estos agentes de IA.

El artículo que vais a leer a continuación desgrana dónde y cómo OpenClaw almacena su información más crítica, ideal para investigaciones forenses y respuesta a incidentes (DFIR), con evidencias reales extraídas del servidor. Y como siempre digo, esto no es un manual para que montéis vuestro propio Skynet ofensivo, es una guía técnica para que, cuando os topéis con un servidor comprometido operando IA, sepáis exactamente dónde buscar y qué buscar.

^{Fig. Interfaz de Telegram interactuando con OpenClaw}

Si queremos entender de verdad cómo funciona OpenClaw y cómo identificar los rastros de su uso, tenemos que bajar al barro del análisis forense. El entorno de estudio es un servidor Linux (Ubuntu 24.04) en el que se ha desplegado un servicio de OpenClaw, conectado por un lado a la API de Telegram para recibir órdenes, y por otro a un servidor local Ollama para ejecutar el “cerebro” de la bestia, este cerebro será un modelo local de IA sin restricciones de uso. En este caso, el host es un ordenador con un procesador Intel i7-13650HX con una gráfica Nvidia RTX 4060 de 8Gb de VRAM, que carga un modelo Gemma-4 de 6Gb.

A diferencia del malware tradicional, un agente de IA no tiene un código estático y predecible. Es dinámico, razona y toma decisiones. En este laboratorio controlado el cual vamos a analizar, el servidor ejecuta un motor que delega el pensamiento a modelos de lenguaje (LLMs), en este caso un Gemma-4. Al no querer usar APIs comerciales censuradas (como las de OpenAI o Anthropic), he optado por desplegar modelos locales. Y aquí es donde la cosa se pone interesante: nuestro trabajo es encontrar las trazas de qué se le ha pedido exactamente a esta IA a través de su agente, cómo este lo ha razonado y, sobre todo, quién está moviendo esos hilos y que tareas le ha hecho ejecutar al agente de OpenClaw.

A la hora de abordar en análisis forense de OpenClaw, me he decantando por una aproximación tradicional, realizar una análisis estático de los ficheros que se han generado al ejecutar OpenClaw. El análisis de la estructura de directorios en el servidor es el primer paso de este camino. Aquí tendremos unos ficheros que nos darán el control central de OpenClaw y una información muy valiosa.

^{Fig. Directorio de configuración /openclaw}

En la ruta /openclaw, encontramos el núcleo del sistema. Para que este agente funcione, el usuario debe haber configurado los endpoints y los modelos. Toda esta lógica reside en el fichero principal de configuración llamado: openclaw.json. Este fichero contiene las credenciales, los modelos configurados, topología, endpoints locales, perfiles activos y las políticas del sistema.

Al realizar un análisis estático de este archivo, nos encontramos con toda la configuración del sistema.

^{Fig. Extracto del fichero openclaw.json mostrando el modelo principal y los tokens}

Desde el punto de vista forense, este fichero nos da datos los siguientes parametros fundamentales:

Modelo de IA número 1: Se puede observar en las primeras lineas el uso de modelos sin censura. El modelo principal configurado es: Gemma-4-Uncensored-XXXX-Aggressive:e4b. Hablamos de un modelo explícitamente diseñado para ser agresivo y no tener filtros o bloqueos.

Modelo de IA número 2: También se listan configuraciones para LM Studio, como el caso del modelo local y sin censura XorXXXXUncensored2025.1-GGUF.

Tokens y Autenticación: Se expone el token de autenticación del gateway local y los tokens de la API de los bots de Telegram utilizados para el control remoto del agente, como en este caso son:
- Default: 86XXXXX23:AAFGH
- Agente Q: 85XXXXX52:AAGjE

Entorno: Muestra el directorio de trabajo donde la IA tiene permisos (/home/airi/.openclaw/workspace).

Endpoints: Se evidencian conexiones a APIs locales, se puede saber que es compatible con Ollama al ver el puerto TCP de escucha: http://127.0.0.1:11434.

Restricciones (DenyList): Vemos una lista denyCommands en el gateway que bloquea explícitamente acciones como camera.snap, screen.record o contacts.add. Esto nos da una pista del poder real que puede llegar a tener OpenClaw en el sistema operativo si se le quitan estos bloqueos. Normalmente,la la ejecución de comandos genéricos (exec) sí está permitida. Por lo que podríamos ejecutar cualquier comando de forma remota desde nuestro Agente, como si de un SSH se tratase.

Llegamos a un punto crítico de la investigación: la atribución, es decir, identificar quién controla el bot es fundamental. OpenClaw gestiona el acceso mediante listas blancas para evitar que cualquier persona pueda hablar con el agente.

Seguir leyendo

Análisis Forense de un Spoofing tipo Vishing. Parte 2

Publicado el Por

Más vale tarde que nunca. Como os adelanté en la primera parte de Este Artículo, no nos íbamos a quedar solo en la teoría, os había prometido realizar un análisis técnico en un entorno real de un sistema diseñado para realizar spoofing de llamadas tipo VoIP. El artículo que vais a leer a continuación lo he escrito casi por completo hace tres años, pero lo he tenido guardado bajo llave todo este tiempo. Esto ha sido de forma totalmente deliberada por una cuestión de responsabilidad ética y seguridad colectiva, ya que hasta la reciente entrada en vigor de la normativa española de 2025 y 2026 que comentaré a continuación, el vacío legal y técnico permitía que este tipo de artículos fuese un arma de doble filo. Publicar los detalles técnicos de la suplantación de identidad mediante VoIP sin un marco regulatorio que obligase a las operadoras a filtrar y bloquear activamente el spoofing internacional, corría el riesgo de convertirse involuntariamente en un manual para actores maliciosos en lugar de en una herramienta para analistas forenses. Sin embargo, con la actual normativa, el escenario ha cambiado lo suficiente como para que podamos desgranar estos artefactos forenses sin miedo a facilitar el camino al cibercrimen. En todo caso, no diré ni comentaré en ningún momento cuáles son los SIP que permiten realizar este tipo de llamadas maliciosas, por lo que si has llegado hasta aquí buscando ese listado de SIP de normativa laxa, te has equivocado totalmente de lugar. Por contrario, si buscas información técnica y forense para analizar este tipo de ataques, este es tu sitio.

^{Fig. Llamada simulada desde el 666666666}

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.

^{Fig. 1: Inicio de sesión y estado del servidor FreePBX}

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.

^{Fig. 2: Directorio de configuración /etc/asterisk}

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.

Seguir leyendo

Análisis forense del apagón eléctrico en España: ¿Exceso de renovables? ¿Ciberataque? ¿Extraterrestres?

Publicado el Por

El día 28 de abril de 2025 a las 12:33 horas CEST se produjo un apagón eléctrico total en la red española, también conocido por «cero» eléctrico o «blackout«. Se trató de un fenómeno totalmente excepcional, nunca ocurrido en los tiempo recientes de España. Este apagón provocó al menos cinco muertes confirmadas, afectó gravemente al transporte ferroviario, con 116 trenes detenidos y 35.000 pasajeros afectados, además de causar interrupciones en servicios básicos, centros educativos y comercios. El sistema ferroviario tardó casi dos días en recuperarse, y muchas zonas quedaron sin comunicación de ningún tipo ni electricidad durante mas de 12 horas.

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.

^{Tuit sobre el apagón a las 16:00 horas}

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.

^{Tuit AEMT sobre la hipótesis del fenómeno atmosférico}

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.

^{Foto de una nave extraterreste pillados robándonos la electricidad}

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.

Seguir leyendo

¡Déjame en paz!, yo no necesito saber todo esto para ser un buen forense.

Publicado el Por

Comencemos por el principio, un gestor de arranque, también conocido como bootloader en inglés, es un programa esencial que se encarga de poner en marcha el sistema operativo cada vez que el ordenador se enciende o se reinicia. Su función principal es cargar el núcleo del sistema operativo en la memoria RAM y, una vez hecho esto, transferirle el control para que continúe con el proceso de inicio del sistema.

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.

Seguir leyendo

Piratería de Fútbol vía CCCam ¿TakeDown?

Publicado el Por

En el año 2017 viajé a Moscú, Rusia, para dar una conferencia titulada: “CCAM – Card Sharing TakeDown”, esta charla trataba sobre el mundo de la piratería de televisión de pago mediante los protocolos: CCCAM, IKS e IPTV. La primera diapositiva que utilicé en esta charla fue un fotograma de la segunda temporada de Los Simpsons, mas concretamente el capítulo titulado: “Homer contra Lisa y el Octavo Mandamiento”, en el que Homer se conecta a la televisión por cable de forma ilegal para ver un combate de boxeo que solamente se retrasmite en un canal de pago. Este capitulo se emitió en el año 1991, lo que nos indica que esto de la piratería de contenidos deportivos televisados ya viene de muy atrás.

Fig. *Homer instalando televisión por cable pirata.*

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.

Seguir leyendo