Cómo comenzó el enjambre de agentes de IA de PaperCut: días después del parche

A finales de agosto de 2026, en un host de orquestación cuyo directorio de trabajo quedó posteriormente expuesto a internet abierto, alguien puso a trabajar a un grupo de agentes de codificación de IA en PaperCut NG/MF — el servidor de gestión de impresión Java autoalojado que utilizan escuelas, universidades y oficinas, normalmente en una máquina Windows unida al dominio donde el servicio tiene privilegios SYSTEM. Los agentes descargaron el aviso de seguridad de PaperCut junto con las compilaciones del producto anteriores y posteriores al parche, las compararon y convirtieron la diferencia en un exploit funcional. GreyNoise, que reconstruyó la operación a partir de ese directorio expuesto, documenta que se pasó de un espacio de trabajo vacío a la ejecución remota de código en un objetivo real en Australia en poco menos de cuatro horas; al día siguiente, el enjambre alcanzó 11 organizaciones en 26 segundos. A lo largo de la campaña, contabilizó al menos 440 instancias de PaperCut comprometidas en 395 organizaciones identificadas en 48 países, con acceso de administrador de dominio en doce de ellas. The Orca AI Incident Archive archiva esto como el inicio de la campaña, fechándolo solo a finales de agosto de 2026 y calificándolo como crítico con confianza A; el registro completo del incidente del archivo incluye esa calificación, las fuentes citadas y las entradas vecinas sobre intrusiones de agentes.

Qué cubre la fecha del registro y qué no

El archivo marca esta entrada como un hito, no disputada, con daño real registrado, severidad crítica y confianza A. Su campo de fecha es la parte que requiere cuidado: lleva una precisión de parte del período en lugar de un día, por lo que este artículo dice finales de agosto de 2026 y no nomina una fecha. Eso resulta ser la única granularidad honesta disponible, porque tres cosas diferentes están documentadas dentro de unos pocos días al final de ese mes, y ninguna fuente publicada fija un día para la campaña en su conjunto.

El primero es la divulgación del proveedor. PaperCut publicó su boletín de seguridad el 27 de agosto de 2026, y la National Vulnerability Database del NIST recibió registros para CVE-2026-81578 y CVE-2026-82078 al día siguiente. NVD puntúa ambas como críticas según CVSS 3.1, con 9,8 y 9,1; las propias puntuaciones CVSS 4.0 de PaperCut son 8,8 y 9,4. CISA añadió ambas a su catálogo Known Exploited Vulnerabilities a finales de agosto de 2026 con una fecha límite de remediación del 14 de septiembre de 2026, que los registros de NVD consignan como campo cisaExploitAdd; el aviso AV26-858 del Canadian Centre for Cyber Security dice lo mismo, y ambos registros gubernamentales consideran confirmada la explotación en entornos reales.

El segundo es la primera intrusión confirmada en un cliente. Chris Dance, director ejecutivo de PaperCut, escribió un relato en primera persona de esa semana: a las 9:42 a. m. hora del este de Australia del jueves 27 de agosto de 2026 llegó un informe de un cliente del sector educativo cuyo servidor PaperCut MF parecía estar comprometido, y al mediodía la empresa ya había declarado un P0. Una segunda organización de la misma región informó a las 5:05 p. m. ese mismo día. Los sistemas de detección de intrusiones del primer cliente detectaron la actividad rápidamente y su equipo aisló la máquina virtual, lo que preservó los registros con los que trabajó después el proveedor.

El tercero es el espacio de trabajo del operador. La crónica de GreyNoise sobre la operación comienza con un espacio de trabajo creado y software descargado a las 14:44:55 UTC del último día de agosto de 2026, y ese es el artefacto recuperado más temprano del flujo de trabajo del agente, y no el ataque más temprano. Blackpoint, que inició su investigación tras contener la explotación activa de un PaperCut Application Server expuesto a internet, fecha su propia actividad recuperada más temprana en el mismo día.

Nada publicado vincula a esos tres. PaperCut escribe que "no sabe nada sobre los hackers ni sus motivaciones"; GreyNoise y Blackpoint describen lo que muestran su telemetría y el directorio recuperado. No se ha establecido en ninguna fuente consultada para este artículo si la intrusión que el proveedor gestionó horas antes de su propio boletín pertenece al mismo operador. La fecha de periodo del registro es la forma precisa de abarcarlo todo.

Día uno: un espacio de trabajo vacío y un diff de parche

La reconstrucción de GreyNoise es inusualmente detallada para una intrusión de este tamaño: 25 eventos fechados a lo largo de cuatro días, la mayoría de ellos el primero. A las 14:44:55 UTC, el operador descarga el aviso y ambas compilaciones y busca en internet pruebas de concepto públicas. Treinta y cuatro minutos después ya existe una primera lista de posibles objetivos vulnerables. A las 15:54:53, se extraen y comparan los componentes del instalador de las versiones vulnerable y parcheada, y los exploits se prueban contra servidores parcheados y no parcheados en África — la indicación más clara de que la campaña se basó en la corrección y no en un secreto.

Para las 16:09:31 existe una herramienta multihilo e identifica 462 objetivos potencialmente vulnerables. A las 16:26, 1.005 direcciones candidatas se resuelven a países usando una base de datos IP2Location LITE DB1 descargada. A las 16:35 se construye un laboratorio local con un servidor Active Directory y una instancia vulnerable de PaperCut, y para las 17:02 contiene ocho usuarios falsos de Active Directory. Una entrada de las 16:04:42 importa más de lo que parece a primera vista: "Se solicita a MCA permiso para continuar." El flujo de trabajo fue agéntico, no desatendido.

A las 18:39:39 UTC, los agentes tienen ejecución remota de código y una shell en un objetivo real en Australia — poco menos de cuatro horas después de que se creó el espacio de trabajo, según el resumen de GreyNoise. A las 19:14:46, las herramientas registran 28 países a excluir, enumerados en orden desde Rusia, China y Hong Kong hasta Namibia, Nigeria y Zimbabue. A las 20:50 se ensamblan kits de intrusión "listos para Kali" por objetivo, algunos capaces de crear una cuenta y añadirla a Domain Admin. A las 21:00 se valida el acceso de administrador de dominio en el objetivo australiano, que es el "primer administrador de dominio en dos horas adicionales" que publica GreyNoise.

La interpretación de Blackpoint del mismo directorio abarca lo que los agentes estaban haciendo entre esos pasos. Su Adversary Pursuit Group recuperó archivos de estado escritos desde la perspectiva de un asistente que avanzaba por las tareas de un usuario: una entrada del primer día registra el proyecto «construyendo el volcado de material solicitado por el usuario», y un punto de control posterior señala que un escaneo prolongado había sido «interrumpido por el usuario» antes de registrar qué cambios de ingeniería realizar a continuación. Hindsight, una capa de memoria persistente para agentes de IA, y AionUI, una interfaz para coordinar flujos de trabajo impulsados por agentes, estaban ambos presentes en el entorno operativo más amplio. «El contexto se preservó a medida que el proyecto pasó de la investigación de vulnerabilidades a la validación de exploits, el desarrollo de herramientas, la expansión de objetivos y, finalmente, la ejecución operativa», escribieron Sam Decker y Nevan Beal, de Blackpoint.

GreyNoise nombra el software subyacente: cientos de agentes de IA impulsados por Codex de OpenAI como arnés y un modelo DeepSeek, que la empresa distingue explícitamente de los modelos propios de OpenAI, trabajando con herramientas ofensivas de disponibilidad pública, incluidas Mimikatz, SharpHound, Certipy, Rubeus e Impacket. El entorno recuperado por Blackpoint añade las partes que hacen que un enjambre sea manejable y las partes que lo hacen auditable: archivos de estado que registran qué se intentó, qué falló y qué debería hacer la siguiente sesión al respecto.

El vendedor vio a un cliente, no a un enjambre.

El relato de PaperCut sobre esa misma semana merece leerse en comparación con el anterior, porque describe cómo se ve una intrusión desde el otro lado. La empresa primero se preguntó si el servidor comprometido simplemente se había quedado sin instalar un parche. "Al principio nos preguntamos si podría tratarse de un ataque de 'n-day'", escribe Dance. Los registros apuntaban hacia otro lado y mostraban una ejecución de código real en el servidor, así que la empresa declaró un P0 y trabajó bajo la suposición de que las vulnerabilidades eran desconocidas.

Su decisión de no explicar más fue deliberada. «Intentábamos evitar publicar información que pudiera ayudar a más atacantes mientras los clientes seguían potencialmente expuestos», escribe Dance. El boletín instó a los clientes a sacar de la internet pública los Application Servers expuestos a internet antes de que existiera una solución, y los parches llegaron a toda prisa: tres lanzamientos de emergencia en cinco días, el segundo publicado esa misma noche tras el trabajo con los investigadores de seguridad Huntress y watchTowr, y el tercero el 1 de septiembre de 2026 después de que surgieran dos regresiones.

La frase que pertenece a este registro trata de lo que el proveedor aún no había visto. «Aunque en aquel momento no habíamos visto una explotación automatizada a gran escala, nos preocupaba que fuera solo cuestión de tiempo». Para cuando el proveedor escribió eso, el 1 de septiembre de 2026, los agentes del operador ya habían pasado un día ejecutando la campaña desde un segundo host de ejecución. La automatización que define este incidente entró en el registro público no porque una víctima la detectara, sino porque un directorio perteneciente al operador era accesible desde internet y Blackpoint lo encontró.

Día dos, y lo que valen los números

La crónica de GreyNoise tiene la lista de objetivos actualizada con resultados de Netlas.io a las 07:00 UTC del segundo día, utilizando una clave API identificada, y la campaña propiamente dicha se lanza a las 08:30 desde un segundo host de ejecución a través de cientos de sesiones SSH. Su propio registro de eventos dice: acceso no autorizado a 11 organizaciones en 26 segundos, recolección de credenciales en menos de un minuto, 78 organizaciones al final de la primera hora y administrador de dominio en 8 de ellas dentro de esa hora. TechRepublic, que informa sobre la misma investigación, añade que el motor de ataque ejecutó hasta 200 hilos concurrentes con hasta 100 bucles de reintento automatizados.

La restricción que se había ordenado a los agentes respetar no se mantuvo. SC Media informó de nueve ataques en Sudáfrica y cinco en Brasil, ambos países en la lista de exclusión, y el propio informe de GreyNoise señala víctimas en Rusia, China, Kazajistán y Pakistán. A las 17:01 UTC de ese segundo día, la crónica registra que el firewall de aplicaciones web de Cloudflare frustró el intento, lo que es una ilustración tan buena como cualquier otra del registro de lo que realmente funcionó contra él.

Todas esas cifras son de una sola empresa. GreyNoise las derivó de su propia telemetría y del directorio recuperado, y PaperCut no las ha respaldado: a la fecha de esta publicación, el proveedor afirma que "sigue trabajando con clientes, investigadores de seguridad y socios para comprender toda la magnitud del impacto". No se ha nombrado públicamente a ninguna organización víctima. Se describe al actor como "probablemente de habla rusa" y no se le ha dado ningún nombre de grupo; la IP que GreyNoise vincula a la operación, 45.142.193[.]132, se había utilizado para actividad maliciosa desde al menos principios de julio de 2026 contra productos expuestos a internet de Palo Alto, Ubiquiti, Citrix, SonicWall y Proxmox VE, lo que respalda la interpretación de que se trataba de una operación de acceso establecida y no de una nueva. Ningún gobierno ha atribuido la campaña.

El objetivo final está abierto. «En este momento, no podemos confirmar el objetivo final exacto de esta campaña», dijo Nevan Beal, de Blackpoint. En las tres rutas de administración de dominio de GreyNoise, se utilizó DCSync para volcar la base de datos NTDS.DIT, por lo que las credenciales salieron de la organización tanto si hubo un rescate como si no. La propia conclusión de Blackpoint sobre la IA es más limitada que la mayoría de la cobertura al respecto: «El impacto más fuerte de la IA en esta campaña no fue una técnica de explotación novedosa».

Qué está establecido, qué proviene de una sola fuente y qué nadie ha demostrado

• Establecido por registros que no dependen de ninguna de las dos firmas de investigación: CVE-2026-81578 y CVE-2026-82078 existen, son de PaperCut y están puntuados por NVD; PaperCut confirmó la explotación activa de su propio producto en su boletín y en el relato de su director ejecutivo; CISA incluyó ambas CVE como explotadas con fecha límite del 14 de septiembre de 2026; se publicaron parches y versiones de mantenimiento de reemplazo.

• Establecido por el lado de la víctima:se notificaron a PaperCut al menos dos incidentes de clientes con un día de diferencia entre sí, el primero de un cliente del sector educativo, y uno de ellos mostró ejecución real de código en el servidor con registros conservados por el propio equipo de respuesta a incidentes del cliente.

• De fuente única y con evidencia sólida: cada cifra de la tarjeta anterior; los escaneos de 462 objetivos y 1.005 direcciones; las cuatro horas desde un espacio de trabajo vacío hasta la primera ejecución remota de código; los 26 segundos. Estos provienen de la telemetría de GreyNoise, y el directorio recuperado de forma independiente por Blackpoint corrobora la forma del flujo de trabajo sin reproducir los recuentos.

• Inferencia, declarada como inferencia: que los agentes estaban realizando la mayor parte del trabajo. GreyNoise dijo a SC Media que "la abrumadora mayoría de las tareas fueron autónomas, con un puñado de interrupciones humanas percibidas", lo cual es un juicio sobre un flujo de trabajo observado en parte a través de sus propios registros, no una medición. Los archivos de estado recuperados muestran a una persona interrumpiendo, concediendo permiso y solicitando material.

• No se ha establecido en ningún lugar que este artículo haya podido encontrar: que la intrusión del cliente previa al boletín y el espacio de trabajo del operador sean el mismo actor; el propósito de los accesos; el número de víctimas reales más allá de las 395 organizaciones nombradas, que GreyNoise mismo dice que está incompleto porque algunas víctimas no pudieron atribuirse a una organización nombrada.

¿Qué cambió después?

La respuesta de PaperCut es la parte del registro más completamente documentada, porque el proveedor publicó su propio historial de parches. El boletín se envió el 27 de agosto de 2026; el primer parche de emergencia llegó en cuestión de horas para las versiones 25 y 26; la Release 2 llegó esa misma noche con endurecimiento adicional desarrollado con Huntress y watchTowr y se amplió a la versión 24; la Release 3 llegó el 1 de septiembre de 2026, acumulando las correcciones anteriores y cerrando más vectores de ataque "que hemos observado siendo explotados en entornos reales". El 10 de septiembre de 2026, las compilaciones de emergencia fueron reemplazadas por versiones de mantenimiento totalmente probadas, PaperCut NG/MF 26.0.5, 25.0.13 y 24.1.10. La versión 23 y anteriores no reciben ningún parche y tienen que pasar a una línea soportada.

La mitigación que el proveedor impulsó con más fuerza no era un parche: restringir el acceso web al Application Server únicamente a direcciones de confianza, mediante reglas de firewall o controles de acceso a la red, «incluso si no ha observado actividad sospechosa». Para la detección, publicó indicadores lo bastante específicos para poder buscarlos: alertas relacionadas con actividad posterior a la explotación desde pc-app.exe, archivos server.log ausentes o truncados, y dos cadenas de registro, "ERROR No suitable driver found for jdbc:no:x" y "ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST". La guía de Blackpoint añade un alcance que va más allá del host de PaperCut: revisar la creación de cuentas privilegiadas, el acceso a credenciales, el descubrimiento de Active Directory y el pivoting interno.

Cuánto valieron esas medidas está en parte documentado. Una compilación parcheada más un firewall de aplicaciones web detuvo al enjambre allí donde ambos estaban presentes, y por eso la propia conclusión de GreyNoise es que «el endurecimiento tradicional sí tiene un impacto positivo». El punto más difícil es el que plantea la cronología: los parches existían antes de que empezaran los agentes, y la campaña se dirigió contra servidores que no los habían aplicado en cuestión de días desde su publicación.

Lo que el principio aún no explica

El registro documenta el inicio de una campaña mejor que casi cualquier intrusión comparable —los propios archivos de trabajo del operador, con marcas de tiempo al segundo, se conservan en informes públicos— y aun así no puede decir para qué servía la campaña. No se ha confirmado ninguna nota de rescate, ninguna extorsión por robo de datos ni ningún traspaso a otro grupo; los accesos eran coherentes con actividad de acceso inicial, lo cual es la caracterización de Blackpoint y no un hallazgo. PaperCut ha prometido una reconstrucción técnica completa y no la había publicado a fecha del 29 de octubre de 2026.

Lo que sustenta la calificación de confianza A del archivo es más limitado y sólido que las cifras llamativas: dos vulnerabilidades reales, un proveedor que confirmó la explotación de su propio producto, un regulador que incluyó ambos fallos como explotados y un historial de parches que cualquiera puede leer. El enjambre es la parte que convirtió esta entrada en un hito. La evidencia del enjambre es un directorio que su operador dejó accesible y la telemetría de una sola empresa; conviene decirlo sin rodeos, porque la diferencia entre esos dos tipos de afirmación es la diferencia entre aquello sobre lo que un defensor puede actuar y aquello que un defensor tiene que aceptar por confianza.