Más de 3.400 servidores fueron comprometidos por una campaña de malware que tiene como principales objetivos infraestructuras de inteligencia artificial expuestas directamente a Internet. El ataque resulta particularmente llamativo porque el malware no almacena de forma convencional la dirección de su servidor de comando y control: la obtiene leyendo determinadas palabras dentro de un poema publicado en GitHub.
La campaña ha sido bautizada como Canto Incognito por los investigadores de Black Lotus Labs, perteneciente a Lumen Technologies, mientras que el malware utilizado recibió el nombre de PoeLLM.
Desde abril de 2026, los atacantes han comprometido miles de servidores, muchos de ellos ejecutando herramientas open source relacionadas con inteligencia artificial como LiteLLM y Ollama.
También fueron encontrados sistemas que ejecutaban Gotenberg, Gitea y otras aplicaciones expuestas a Internet.
Una vez comprometidos, los servidores pueden utilizarse para:
- Minar criptomonedas.
- Buscar nuevos sistemas vulnerables.
- Lanzar intentos de explotación contra otros servidores.
- Ejecutar una shell remota.
- Participar en la expansión de la propia botnet.
Pero lo que convierte a PoeLLM en una campaña especialmente original es su método para localizar la infraestructura del atacante.
El malware consulta un poema alojado en GitHub, identifica cuatro palabras concretas y las transforma matemáticamente en la dirección IP de su siguiente servidor de comando y control.
Puede leer también | El lado oscuro de la inteligencia artificial: riesgos, dilemas y consecuencias
Una botnet construida alrededor de servidores de inteligencia artificial
Black Lotus Labs comenzó a seguir la actividad durante una investigación relacionada con infraestructura comprometida.
Los investigadores descubrieron posteriormente una campaña mucho más amplia que llevaba activa al menos desde abril.
El número acumulado de sistemas afectados superó:
3.400 servidorescon víctimas concentradas principalmente en:
- Estados Unidos.
- Europa occidental.
La mayoría de los sistemas identificados ejecutaban servicios relacionados con IA o herramientas open source utilizadas dentro de infraestructuras empresariales.
¿Por qué los atacantes están buscando servidores de IA?
Existe una razón bastante sencilla.
Una infraestructura utilizada para ejecutar modelos de inteligencia artificial puede disponer de:
- GPU potentes.
- CPU de muchos núcleos.
- Gran cantidad de memoria RAM.
- Conectividad de alta velocidad.
- Funcionamiento permanente.
Todo eso tiene valor para un atacante.
Especialmente cuando su objetivo es:
criptomineríaLa infraestructura ya fue comprada por la víctima.
La víctima paga:
- Electricidad.
- Hardware.
- Cloud.
- Refrigeración.
- Conectividad.
El atacante simplemente intenta apropiarse de esa capacidad de cómputo.
El cryptojacking vuelve a encontrar una nueva víctima ideal
Durante años, los atacantes buscaron:
servidores web
|
v
servidores cloud
|
v
Kubernetes
|
v
Docker
|
v
GPU
Ahora aparece otro objetivo:
infraestructura LLM
|
v
GPU costosa
|
v
gran capacidad de cálculo
El incentivo económico es evidente.
Los sistemas afectados no eran exclusivamente servidores de IA
Aunque la campaña ha llamado la atención por dirigirse especialmente a infraestructura relacionada con inteligencia artificial, conviene precisar la cifra.
Los más de 3.400 sistemas contabilizados por Black Lotus Labs no representan necesariamente 3.400 servidores LLM idénticos.
Entre las tecnologías encontradas se incluyen:
| Tecnología | Función |
|---|---|
| LiteLLM | Gateway/proxy para APIs de modelos LLM |
| Ollama | Ejecución local de modelos de IA |
| Gotenberg | Conversión de documentos a PDF |
| Gitea | Plataforma Git autogestionada |
| Ivanti Sentry | Gateway empresarial |
Por eso la descripción más precisa es que la campaña se concentra fuertemente en infraestructura de IA, pero afecta también otros servicios empresariales expuestos.
El error fundamental: servicios directamente expuestos a Internet
Uno de los grandes patrones encontrados por los investigadores fue la presencia de aplicaciones que podían localizarse directamente desde Internet.
En un entorno seguro, una aplicación interna podría tener una arquitectura similar a:
Internet | Firewall | Reverse proxy | Autenticación | Aplicación IA
Pero en muchos despliegues rápidos encontramos algo más parecido a:
Internet | v LiteLLM / Gotenberg / servicio IA
directamente accesible.
Eso facilita enormemente el reconocimiento automatizado.
Los atacantes comenzaron buscando puertos utilizados por estas aplicaciones
La telemetría de Lumen mostró escaneo dirigido especialmente contra servicios expuestos.
Entre ellos aparecían implementaciones de Gotenberg y LiteLLM.
Una vez identificado un servidor potencialmente vulnerable, la infraestructura atacante intentaba aprovechar vulnerabilidades conocidas.
La campaña demuestra una regla conocida de seguridad:
una aplicación que no necesita ser pública no debería estar publicada en Internet simplemente porque el despliegue por defecto lo permite.
LiteLLM aparece en el centro de una de las rutas de ataque
Black Lotus Labs analizó una muestra de PoeLLM que hacía referencia a un endpoint de LiteLLM asociado con:
CVE-2026-42271Esta vulnerabilidad afecta a determinadas versiones de LiteLLM y está relacionada con la ejecución de comandos mediante funciones utilizadas para probar configuraciones MCP.
Las versiones afectadas son:
LiteLLM >= 1.74.2 y < 1.83.7La corrección está disponible desde:
LiteLLM 1.83.7¿Qué podía ocurrir con CVE-2026-42271?
Determinados endpoints de prueba aceptaban configuraciones de servidores MCP.
Entre los parámetros podían encontrarse elementos destinados a:
- Comandos.
- Argumentos.
- Variables de entorno.
En una configuración vulnerable esto podía terminar ejecutando un proceso en el host donde funcionaba LiteLLM.
Por eso una herramienta pensada simplemente para:
probar conexión MCP
podía convertirse en una ruta hacia:
ejecución de comandos en el servidor
No significa que todo servidor Ollama o LiteLLM sea vulnerable
Este punto resulta fundamental.
La existencia de una campaña contra estas tecnologías no significa que:
Ollama instalado = servidor comprometido
ni tampoco:
LiteLLM = malware
El riesgo depende de:
- Versión utilizada.
- Configuración.
- Exposición a Internet.
- Autenticación.
- Vulnerabilidades existentes.
- Controles de red.
Las herramientas son objetivos del ataque, no la causa maliciosa del mismo.
El malware se hacía pasar por una biblioteca
La muestra analizada por Black Lotus Labs era un archivo ELF denominado:
libgcryptEl nombre puede resultar familiar porque recuerda a bibliotecas criptográficas legítimas presentes en sistemas Linux.
Esto puede ayudar a que un archivo sospechoso parezca menos llamativo durante una revisión superficial.
Pero en este caso contenía el malware PoeLLM.
PoeLLM no es simplemente un minero de criptomonedas
El análisis reveló varias funciones integradas.
Entre ellas:
- Shell remota.
- XMRig.
- Iron miner.
- Escaneo HTTP/HTTPS.
- Despliegue de exploits.
- Comunicación con infraestructura C2.
Es decir, su función puede representarse como:
PoeLLM | +-- minar | +-- escanear | +-- explotar | +-- recibir comandos | +-- infectar nuevos sistemas
Los servidores infectados trabajan para encontrar las siguientes víctimas
Éste es uno de los aspectos que permitió crecer a la campaña.
Una vez comprometido un servidor, éste podía transformarse en:
otro nodo atacante.
El flujo era:
Atacante | v Servidor A comprometido | +--> mina criptomoneda | +--> escanea Internet | v Servidor B vulnerable | v Servidor B comprometido | +--> mina +--> escanea
Este modelo permite que el operador distribuya el trabajo de reconocimiento entre las propias víctimas.
Eso también oculta parcialmente el origen real del ataque
Una organización podría ver:
Servidor X atacando nuestro sistema
pero el propietario del servidor X podría ser también una víctima.
En realidad:
Atacante real
|
v
Servidor comprometido
|
v
nuestro servidor
Esto dificulta la atribución y permite distribuir el tráfico de exploración.
Entonces aparece el detalle más extraño: un poema en GitHub
Los investigadores necesitaban comprender cómo los servidores infectados localizaban la infraestructura del atacante.
Lo normal sería encontrar dentro del malware:
IP C2
o:
dominio-malicioso.com
Pero PoeLLM utiliza una técnica diferente.
El malware consulta un repositorio público de GitHub.
El repositorio parecía una copia del sitio de Node.js
El repositorio utilizado por el atacante era un fork del código asociado al sitio web de Node.js.
Esto necesita una precisión:
Node.js no estaba implicado en la campaña.
El atacante simplemente utilizó un fork como contenedor aparentemente normal para alojar el contenido.
Dentro del repositorio apareció un archivo denominado:
dash.cssque no pertenecía al repositorio original.
Dentro de dash.css había un poema
El poema llevaba por título:
On the Nature of ConnectionA simple vista era únicamente un breve texto relacionado con:
- Máquinas.
- Datos.
- Conexiones.
- Servidores.
No contenía algo evidente como:
C2 = 92.xxx.xxx.xxxY ésa era precisamente la idea.
Cuatro palabras escondían una dirección IPv4
PoeLLM contenía una lista interna que relacionaba determinadas palabras con números.
El malware leía cuatro posiciones específicas del poema.
Después:
Palabra A -> número Palabra B -> número Palabra C -> número Palabra D -> número
Finalmente:
número.número.número.número
se convertía en una dirección IPv4.
El poema funcionaba prácticamente como un DNS clandestino
Conceptualmente, el comportamiento era:
PoeLLM | v GitHub | v poema | v 4 palabras | v diccionario interno | v 4 números | v dirección C2
El atacante no tenía que distribuir una nueva variante de malware cada vez que cambiaba su infraestructura.
Bastaba con modificar cuatro palabras
Imagine que el C2 anterior deja de funcionar.
En un malware convencional:
C2 antiguo cae
|
v
crear nuevo C2
|
v
actualizar malware
|
v
distribuir nueva versión
Con PoeLLM:
C2 antiguo cae
|
v
crear nuevo C2
|
v
editar palabras del poema
|
v
bots consultan GitHub
|
v
descubren nuevo C2
Mucho más sencillo.
El poema fue modificado 11 veces
Black Lotus Labs identificó:
11 actualizacionesdel poema desde el primer commit observado el:
13 de abril de 2026En cada modificación cambiaban fundamentalmente las palabras utilizadas para derivar la dirección del servidor.
El resto del poema permanecía prácticamente estable.
El malware sabía exactamente qué palabras buscar
PoeLLM no interpreta poesía mediante inteligencia artificial.
Éste es otro detalle importante.
No existe un modelo LLM leyendo el significado literario del poema.
El malware utiliza reglas deterministas para:
- Buscar determinados fragmentos.
- Extraer palabras.
- Consultar su tabla interna.
- Construir una IP.
Por tanto, el poema funciona como un sistema de codificación.
¿Fue el poema generado por inteligencia artificial?
Investigadores de Lumen consideran posible que sí.
El actor dejó diferentes comentarios y elementos en italiano, mientras el poema está escrito en inglés.
Ryan English, investigador de Lumen, explicó que el equipo cree que probablemente fue generado mediante IA.
Sin embargo:
esto es una valoración de los investigadores, no una prueba definitiva sobre qué modelo escribió el texto.
PoeLLM tiene IA en sus víctimas, pero no necesariamente en su funcionamiento
El nombre puede generar otra confusión.
PoeLLM no es un nuevo modelo de inteligencia artificial malicioso.
Es:
malware Linux
|
v
que ataca
|
v
infraestructura LLM
Su vínculo con IA proviene principalmente de:
- Los servidores atacados.
- La posible generación del poema mediante IA.
No necesita un LLM para ejecutar sus funciones maliciosas.
GitHub tampoco fue hackeado
Éste es otro matiz necesario.
El atacante utilizó:
GitHub como infraestructura públicaNo existe evidencia de que hubiera comprometido los sistemas internos de GitHub para realizar esta técnica.
Simplemente publicó contenido dentro de un repositorio bajo su control.
Esto se parece a otras campañas que aprovechan servicios legítimos para:
- Alojar configuraciones.
- Publicar instrucciones.
- Distribuir archivos.
- Resolver infraestructura.
¿Por qué utilizar GitHub?
Porque desde una red empresarial, esta conexión:
servidor -> github.compuede parecer mucho menos sospechosa que:
servidor -> dominio-malware-extraño.xyzGitHub es utilizado legítimamente por:
- Desarrolladores.
- CI/CD.
- Servidores.
- Sistemas de actualización.
Bloquearlo completamente puede no ser práctico.
Servicios legítimos pueden convertirse en infraestructura indirecta para malware
Esta técnica no es exclusiva de GitHub.
Históricamente los atacantes han aprovechado plataformas legítimas como:
- GitHub.
- Dropbox.
- Telegram.
- Discord.
- Paste services.
- Servicios cloud.
porque ofrecen:
- Alta disponibilidad.
- HTTPS válido.
- Buena reputación.
- Accesibilidad global.
PoeLLM mina criptomonedas mediante XMRig e Iron
Una vez que el malware controla un servidor, una de sus principales funciones es ejecutar mineros.
Entre ellos aparecen:
XMRigy:
IronXMRig es una herramienta legítima y open source utilizada para minería.
El problema no es XMRig en sí.
El problema aparece cuando:
atacante | v lo instala sin autorización | v en hardware ajeno
Eso es cryptojacking.
Las víctimas se conectaban con Kryptex
Black Lotus Labs observó sistemas comprometidos comunicándose con infraestructura asociada a:
Kryptexun servicio de minería de criptomonedas.
Este comportamiento reforzó la conclusión de que la principal motivación de la campaña era financiera.
El atacante obtiene dinero mientras la empresa paga la factura
El modelo económico es sencillo:
Empresa compra GPU
|
v
Empresa paga cloud
|
v
Empresa paga electricidad
|
v
PoeLLM compromete servidor
|
v
Atacante mina
|
v
Atacante cobra
Mientras tanto, la víctima puede experimentar:
- CPU elevada.
- GPU elevada.
- Más consumo eléctrico.
- Más factura cloud.
- Peor rendimiento de IA.
- Sobrecalentamiento.
En cloud, una infección puede convertirse rápidamente en una factura enorme
Las instancias GPU suelen costar considerablemente más que un servidor convencional.
Si un atacante consigue mantener activa una instancia durante días o semanas:
GPU x 24 horas x varios días
el coste económico puede crecer rápidamente.
Pero la minería puede ser el menor de los problemas
Una empresa podría detectar:
“Tenemos un cryptominer”.
y concentrarse únicamente en detenerlo.
Pero PoeLLM dispone también de:
- Shell remota.
- Capacidad de escaneo.
- Capacidad de explotación.
Eso significa que el atacante ya consiguió algo mucho más importante:
ejecutar código dentro del servidor.
Un servidor de IA puede contener información mucho más valiosa que su GPU
Un sistema LLM empresarial puede almacenar o tener acceso a:
- API keys.
- Credenciales cloud.
- Prompts internos.
- Documentos empresariales.
- Bases vectoriales.
- Repositorios.
- Datos de clientes.
Por eso Black Lotus Labs advierte que estas infraestructuras son atractivas no solamente por su capacidad de cálculo.
También pueden ser una fuente de inteligencia empresarial.
El próximo ataque puede no conformarse con minar criptomonedas
Una vez dentro de un servidor LLM, otro atacante podría intentar:
robar tokens
|
v
acceder cloud
|
v
moverse lateralmente
|
v
obtener datos
Por tanto, PoeLLM debería interpretarse también como una advertencia sobre la superficie de ataque que están creando las nuevas plataformas de IA.
Las empresas están desplegando IA más rápido de lo que la están asegurando
En muchas organizaciones existe presión por implementar:
- Chatbots.
- RAG.
- Gateways LLM.
- Agentes.
- MCP.
- Modelos locales.
El proceso puede ser:
instalar herramienta
|
v
abrir puerto
|
v
probar
|
v
funciona
|
v
dejar en producción
Pero faltan pasos fundamentales:
autenticación firewall TLS monitorización parches inventario logs
“Es solo un servidor de pruebas” es una frase peligrosa
Muchos sistemas expuestos nacieron inicialmente como:
- Pruebas.
- Laboratorios.
- PoC.
- Entornos de desarrollo.
Pero después permanecen activos.
Un atacante no sabe si el servidor es:
producción o laboratorio
Solo sabe que:
el puerto respondeGotenberg incluso advierte que no debería exponerse directamente
Black Lotus Labs destaca que la propia documentación de Gotenberg advierte a los administradores que no expongan directamente el servicio a Internet.
Sin embargo, los investigadores identificaron cientos de servidores relacionados con esta tecnología dentro de la campaña.
Eso demuestra otro problema clásico:
las advertencias de documentación no sirven si la arquitectura real no las respeta.
El pico llegó a casi 800 servidores activos en un solo día
El número acumulado de sistemas comprometidos supera los 3.400.
Pero eso no significa que todos estuvieran funcionando simultáneamente dentro de la botnet.
Durante el pico observado por Lumen, la actividad llegó a:
casi 800 víctimas activas por díamientras la campaña había alcanzado miles de sistemas a lo largo de su operación.
El número inicial publicado fue menor y después se actualizó
Existe una razón por la que algunos artículos iniciales pueden mostrar cifras diferentes.
Informes tempranos mencionaron alrededor de:
2.100 - 2.200 servidorespero Black Lotus Labs actualizó posteriormente su cálculo hasta:
más de 3.400 víctimasBleepingComputer modificó expresamente su publicación después de recibir la cifra actualizada de los investigadores.
También utilizaron routers vulnerables como infraestructura
Otro aspecto interesante es que parte de los servidores C2 parecían estar alojados detrás de:
routers previamente comprometidos.
Los investigadores encontraron interfaces administrativas vulnerables en varias direcciones utilizadas como C2.
Esto sugiere un esquema como:
Operador | v router comprometido | v C2 | v servidores PoeLLM
en lugar de comprar directamente toda la infraestructura criminal.
Una víctima puede convertirse en infraestructura para atacar a otra víctima
La campaña reutiliza constantemente recursos que pertenecen a terceros.
Eso reduce los costes para el atacante.
Puede utilizar:
- Routers ajenos.
- Servidores IA ajenos.
- GitHub como referencia pública.
- Capacidad GPU ajena.
Prácticamente toda la infraestructura puede terminar siendo pagada por otras personas.
Los investigadores atribuyen la campaña a un actor posiblemente italiano
Black Lotus Labs encontró:
- Comentarios en italiano dentro del malware.
- Infraestructura relacionada con Italia.
- Patrones de tráfico compatibles.
Por ello atribuye la operación, con:
confianza moderadaa un actor de habla italiana.
No existe una identidad pública confirmada del operador.
“Habla italiano” no significa necesariamente “está en Italia”
Las atribuciones cibernéticas deben tratarse con prudencia.
Un atacante puede:
- Utilizar VPN.
- Alquilar servidores en otros países.
- Falsificar comentarios.
- Utilizar idiomas ajenos.
Por eso Black Lotus Labs utiliza explícitamente un nivel de confianza y no presenta la atribución como certeza absoluta.
PoeLLM también parece experimentar con ataques de fuerza bruta
Los investigadores encontraron actividad más reciente hacia:
- SSH.
- Portales de login.
Esto sugiere que el operador podría estar experimentando con una capacidad distribuida de fuerza bruta.
Sin embargo, Black Lotus Labs señala que esa función todavía parecía:
en una etapa temprana de desarrollo.
Una botnet de servidores potentes puede servir para mucho más que minería
Si una persona controla miles de servidores distribuidos puede utilizar esa infraestructura para:
- Escaneo.
- Fuerza bruta.
- Proxy.
- Explotación.
- Criptominería.
Por eso eliminar únicamente el proceso minero no debería considerarse una limpieza suficiente.
¿Cómo saber si un servidor de IA pudo estar expuesto?
El primer paso es inventariar los servicios públicos.
En Linux:
sudo ss -tulpnTambién:
sudo lsof -i -P -n | grep LISTENLa pregunta es:
¿qué servicios están escuchando y realmente necesitan estar accesibles desde Internet?
Comprueba qué contenedores están publicados
En Docker:
docker psPresta atención a entradas similares a:
0.0.0.0:PUERTO->PUERTOEso normalmente significa que el servicio está escuchando sobre todas las interfaces del host.
Si solo debe utilizarse localmente, puede ser preferible:
127.0.0.1:PUERTOjunto con un reverse proxy o acceso privado apropiado.
No publiques Ollama, LiteLLM o MCP simplemente para “hacerlo funcionar”
Durante una prueba rápida es habitual cambiar:
localhost
por:
0.0.0.0
para poder acceder desde otra computadora.
Pero eso puede convertir:
servicio local
en:
servicio visible desde cualquier red
dependiendo del firewall y de la infraestructura.
Revisa inmediatamente la versión de LiteLLM
Si utilizas LiteLLM, identifica la versión:
python -m pip show litellmo dentro del entorno correspondiente:
pip show litellmPara CVE-2026-42271, la versión corregida es:
1.83.7 o posteriorEn producción debería utilizarse una versión actualmente soportada y con todas las actualizaciones de seguridad posteriores.
Actualizar una biblioteca no basta si el servidor ya fue comprometido
Supongamos:
1 mayo servidor explotado 10 mayo administrador actualiza
La actualización evita repetir el vector original.
Pero puede continuar existiendo:
- Malware.
- Usuarios nuevos.
- Claves SSH.
- Cron jobs.
- Servicios systemd.
- Contenedores maliciosos.
Por eso un sistema con evidencia real de compromiso debe analizarse como:
incidente de seguridad
y no únicamente como:
paquete desactualizado.
Busca procesos de minería inesperados
Una revisión inicial puede incluir:
ps aux --sort=-%cpu | head -30y:
topo:
htopEn servidores GPU:
nvidia-smiUna utilización alta de GPU sin una carga de IA prevista merece investigación.
No busques únicamente el nombre XMRig
Los atacantes pueden:
- Renombrar procesos.
- Renombrar binarios.
- Ejecutar dentro de contenedores.
Por eso conviene correlacionar:
- CPU.
- GPU.
- Red.
- Procesos.
- Archivos recientes.
Revisa conexiones salientes inesperadas
Puede utilizarse:
sudo ss -tpno herramientas de monitorización de red.
Una aplicación LLM interna normalmente debería tener un perfil relativamente conocido de conexiones externas.
Si comienza a conectarse persistentemente con infraestructura desconocida, es una señal que merece investigación.
Los indicadores publicados por Black Lotus Labs deberían entrar al SIEM
Lumen ha proporcionado indicadores de compromiso asociados a:
- Servidores C2.
- Infraestructura.
- Muestras del malware.
Una organización que opere servidores de IA expuestos puede incorporarlos temporalmente en:
- SIEM.
- Firewall.
- EDR.
- NDR.
y buscar actividad histórica.
No dependas únicamente de bloquear las IP conocidas
Este ataque demuestra exactamente por qué.
El operador podía cambiar el C2 modificando el poema.
Por tanto:
bloquear IP A
|
v
atacante cambia poema
|
v
bots obtienen IP B
El control debe incluir comportamiento y exposición, no únicamente listas estáticas.
El repositorio de GitHub utilizado por la campaña fue retirado
Después de la publicación de la investigación, el repositorio utilizado por PoeLLM dejó de estar accesible.
Lumen también bloqueó tráfico relacionado con la infraestructura C2 identificada para sus clientes.
Esto representa una interrupción importante de la campaña conocida.
Pero no significa que todos los servidores previamente comprometidos estén automáticamente limpios.
Interrumpir el C2 no desinfecta las víctimas
El esquema es:
C2 desaparece
|
v
bot pierde instrucciones
pero el servidor puede continuar teniendo:
- Malware almacenado.
- Minero.
- Persistencia.
- Credenciales comprometidas.
Los administradores todavía deben revisar los sistemas.
Una empresa afectada debería considerar reconstruir servidores críticos
Cuando existe evidencia de ejecución remota no autorizada, una estrategia frecuentemente más segura es:
preservar evidencia
|
v
rotar credenciales
|
v
reconstruir desde
imagen confiable
|
v
restaurar datos
|
v
validar
en lugar de intentar eliminar manualmente cada archivo malicioso.
La decisión concreta depende del entorno y de la respuesta forense.
Las credenciales del servidor deben tratarse como potencialmente expuestas
Si PoeLLM consiguió ejecutar una shell, debemos considerar qué información estaba disponible para el proceso.
Por ejemplo:
- Variables de entorno.
- API keys.
- Tokens.
- Credenciales cloud.
- Secrets de Kubernetes.
Cuando corresponda deberían rotarse después de contener el incidente.
Los servidores IA necesitan mínimo privilegio
Una aplicación LLM no debería ejecutarse como:
rootsi no necesita esos privilegios.
Es preferible:
usuario específico
|
v
permisos mínimos
|
v
acceso limitado
De esta forma, una vulnerabilidad dentro de la aplicación proporciona al atacante menos capacidades iniciales.
Los contenedores tampoco deberían utilizar --privileged
Un despliegue como:
docker run --privileged ...elimina muchas de las barreras proporcionadas por el aislamiento de contenedores.
Para una aplicación expuesta, eso puede convertir una vulnerabilidad en un compromiso mucho más profundo.
Segmenta las GPU y servidores de IA
Una arquitectura empresarial puede separar:
Internet | WAF / Gateway | API | ------------------ Red IA ------------------ | LLM servers | ------------------ Datos sensibles ------------------
En lugar de permitir que el servidor del modelo pueda comunicarse libremente con toda la organización.
Controla también el tráfico saliente
Los firewalls suelen concentrarse en:
¿quién puede entrar?
Pero Canto Incognito recuerda la importancia de:
¿a dónde puede salir un servidor comprometido?
Una política de egress puede dificultar:
- C2.
- Descarga de malware.
- Exfiltración.
- Conexión con pools de minería.
La seguridad de IA no es solamente proteger el modelo
Gran parte de las conversaciones sobre AI Security se concentran en:
- Prompt injection.
- Jailbreaks.
- Model stealing.
- Datos de entrenamiento.
Pero una infraestructura LLM continúa siendo:
Linux + Python + APIs + contenedores + red + dependencias
y cada una de esas capas puede tener vulnerabilidades tradicionales.
PoeLLM ni siquiera necesitó “hackear la inteligencia artificial”
Ésta es quizá una de las principales enseñanzas.
El atacante no necesitó convencer al modelo mediante:
prompt injectionNo necesitó atacar los pesos del modelo.
No necesitó romper el algoritmo de IA.
Atacó:
el servidor que ejecutaba la IAutilizando vulnerabilidades de software convencionales.
Un modelo avanzado sobre un servidor inseguro sigue siendo un servidor inseguro
Puedes instalar:
modelo de última generación + GPU de US$30.000
pero si el servicio está:
desactualizado + expuesto + sin autenticación adecuada
la tecnología más avanzada puede terminar trabajando para un cryptominer.
Puede leer también | OpenHands: la plataforma de desarrollo de software con IA de código abierto
Checklist urgente para servidores de IA autogestionados
- Inventariar todas las herramientas IA/LLM desplegadas.
- Identificar cuáles son accesibles desde Internet.
- Eliminar exposición pública que no sea necesaria.
- Actualizar LiteLLM y otras aplicaciones.
- Revisar CVE aplicables a cada versión.
- Verificar procesos con alto consumo CPU/GPU.
- Revisar conexiones salientes.
- Buscar indicadores de compromiso de PoeLLM.
- Revisar logs históricos.
- Comprobar usuarios, SSH keys y tareas programadas.
- Rotar tokens potencialmente expuestos.
- Ejecutar servicios con mínimo privilegio.
- No utilizar contenedores privilegiados innecesariamente.
- Aplicar firewall y segmentación.
- Controlar tráfico de salida.
- Incorporar herramientas de IA al programa normal de gestión de vulnerabilidades.
¿Qué deberían revisar específicamente los equipos que usan LiteLLM?
Como mínimo:
| Control | Acción |
|---|---|
| Versión | Actualizar a una versión corregida y soportada |
| Internet | Evitar exposición directa cuando no sea necesaria |
| API | Aplicar autenticación y roles |
| MCP | Revisar endpoints y permisos |
| Host | Mínimo privilegio |
| Red | Filtrado inbound y outbound |
| Logs | Buscar actividad histórica anómala |
¿Qué deberían revisar quienes utilizan Ollama?
El hecho de que Ollama aparezca entre los sistemas identificados por Black Lotus Labs no significa que todos los compromisos se produjeran mediante una vulnerabilidad única de Ollama.
La prioridad debería ser:
- No exponer innecesariamente la API a Internet.
- Mantener la aplicación actualizada.
- Aplicar controles de red.
- Restringir quién puede acceder.
- Supervisar el uso de CPU/GPU.
La sombra de Shadow AI también aparece aquí
En muchas empresas los equipos instalan rápidamente:
Ollama LiteLLM Open WebUI MCP servers
sin que seguridad tenga necesariamente conocimiento del despliegue.
Eso crea:
Shadow AI.
El problema no es únicamente que el departamento de TI no conozca qué modelo utiliza la empresa.
Puede no saber siquiera:
- Qué puertos están abiertos.
- Qué dependencias están instaladas.
- Qué datos procesa.
- Quién lo actualiza.
El inventario de IA debería formar parte del inventario de activos
Una organización madura debería registrar:
| Campo | Ejemplo |
|---|---|
| Servicio | LiteLLM |
| Servidor | ai-gateway-01 |
| Versión | Versión instalada |
| Propietario | Equipo IA |
| Internet | Sí / No |
| Datos sensibles | Sí / No |
| Último parche | Fecha |
Las herramientas nuevas necesitan entrar inmediatamente al ciclo de parches
No debería existir:
servidores tradicionales
|
parches mensuales
servidores IA
|
nadie sabe
El programa de vulnerabilidades debe incluir:
- Frameworks IA.
- Gateways.
- Model servers.
- Vector databases.
- MCP servers.
- Interfaces web.
La historia del poema también es una advertencia para los SOC
Una regla convencional puede buscar:
dominio C2 conocido IP maliciosa archivo conocido
Pero PoeLLM obtiene dinámicamente su infraestructura desde contenido aparentemente inocente.
Esto demuestra la importancia de combinar:
- Indicadores.
- Análisis de comportamiento.
- Netflow.
- EDR.
- Contexto del activo.
Una petición a GitHub desde un servidor IA no siempre es normal
Tampoco es necesariamente maliciosa.
Pero un SOC puede aprender el patrón esperado de cada activo.
Si un servidor dedicado exclusivamente a inferencia comienza:
- Consultando repositorios desconocidos.
- Conectándose con pools de minería.
- Escaneando miles de IP.
la combinación resulta mucho más reveladora que cualquier indicador aislado.
Este ataque convierte poesía en infraestructura de comando y control
El detalle del poema puede parecer anecdótico.
Pero técnicamente representa una idea interesante.
El atacante separó:
malware
de:
ubicación actual del servidor C2
mediante una fuente externa modificable.
El poema funcionaba como una especie de:
configuración remota encubiertacapaz de sobrevivir a cambios de infraestructura.
Pero la sofisticación del C2 contrasta con un objetivo muy simple
PoeLLM dispone de una técnica original para localizar su infraestructura.
Pero su principal monetización continúa siendo algo conocido desde hace años:
robar CPU y GPU para mineríaEsto demuestra que los atacantes no necesitan una motivación extremadamente compleja para utilizar técnicas creativas.
Si existe beneficio económico, la innovación también aparece en el ciberdelito.
Recomendamos
- El lado oscuro de la inteligencia artificial: riesgos, dilemas y consecuencias
- OpenHands: la plataforma de desarrollo de software con IA de código abierto
- Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
- Las mejores herramientas de código abierto para proteger su servidor Linux
En resumen
La campaña Canto Incognito comprometió más de 3.400 servidores desde abril de 2026 mediante el malware PoeLLM, según Black Lotus Labs.
La mayor parte de los objetivos identificados estaba relacionada con servicios de inteligencia artificial y LLM expuestos a Internet, incluyendo LiteLLM y Ollama, aunque también aparecieron Gotenberg, Gitea y posible actividad relacionada con Ivanti Sentry.
PoeLLM integra mineros XMRig e Iron, una shell remota, funciones de escaneo y capacidad para convertir las propias víctimas en servidores utilizados para buscar nuevos objetivos.
La característica más original del malware está en su sistema de comando y control.
En lugar de almacenar directamente la IP del C2, consulta un poema titulado On the Nature of Connection alojado dentro de un repositorio GitHub.
Cuatro palabras del poema se convierten en cuatro números mediante una tabla integrada en PoeLLM y forman la dirección IPv4 del servidor.
El operador modificó el poema 11 veces, permitiendo cambiar la infraestructura C2 sin redistribuir el malware.
La campaña explotó servicios vulnerables conocidos, entre ellos una ruta asociada a CVE-2026-42271 en LiteLLM.
El incidente demuestra que los nuevos servidores de inteligencia artificial están heredando exactamente los mismos problemas de seguridad que históricamente afectaron a servidores web, Docker, Kubernetes y cloud: servicios desactualizados, puertos expuestos y configuraciones que llegan a producción sin controles suficientes.
Conclusión editorial
La parte más llamativa de PoeLLM es el poema, pero probablemente no sea la parte más importante de la historia.
El verdadero problema está en los miles de servidores que pudieron ser encontrados, alcanzados y utilizados por un atacante porque servicios de IA estaban expuestos a Internet con vulnerabilidades conocidas o configuraciones insuficientes.
La industria está invirtiendo enormes cantidades de dinero en modelos, GPU y agentes.
Pero un modelo de última generación sigue funcionando sobre un sistema operativo.
Ese sistema operativo ejecuta procesos.
Los procesos escuchan puertos.
Los puertos reciben peticiones.
Y el software necesita parches.
PoeLLM no necesitó engañar al modelo con prompt injection.
No necesitó robar sus pesos.
No necesitó desarrollar un nuevo ataque contra redes neuronales.
Simplemente atacó la infraestructura que estaba debajo de la inteligencia artificial.
Eso debería preocupar especialmente a las organizaciones que están desplegando rápidamente Ollama, LiteLLM, servidores MCP y plataformas de agentes sin incorporarlas simultáneamente a los procesos tradicionales de seguridad.
La otra gran enseñanza está en el método de comando y control.
Un poema dentro de GitHub parece completamente inocente.
Para un ser humano, es literatura.
Para PoeLLM, cuatro de sus palabras eran una dirección IP.
Esa simple diferencia permitió al atacante cambiar de infraestructura modificando unas pocas palabras sin necesitar actualizar miles de bots.
Es una técnica creativa.
Pero la defensa sigue necesitando principios bastante clásicos:
no exponer servicios innecesarios, actualizar rápidamente, segmentar la infraestructura, aplicar mínimo privilegio, controlar el tráfico saliente y saber exactamente qué herramientas de IA están funcionando dentro de la organización.
Porque la carrera por adoptar inteligencia artificial también está creando una nueva carrera para los atacantes.
Y mientras las empresas compiten por disponer de más GPU, más modelos y más agentes, los ciberdelincuentes ya han descubierto que esa misma infraestructura puede convertirse en una enorme granja de cómputo pagada por sus víctimas.
Fuentes: Black Lotus Labs / Lumen Technologies — Canto Incognito: Tracking the PoeLLM Malware, BleepingComputer — PoeLLM malware infects exposed AI servers, GitHub Security Advisory — CVE-2026-42271 en LiteLLM y The Hacker News — PoeLLM and Canto Incognito.
