IronWorm y la nueva variante de Miasma Worm atacan a npm en ataques a la cadena de suministro – CYBERDEFENSA.MX

Múltiples ataques a la cadena de suministro de software han afectado al ecosistema npm, y los actores de amenazas utilizan versiones maliciosas y envenenadas de más de 50 paquetes legítimos para distribuir un ladrón de información basado en Rust y un gusano que se propaga automáticamente, respectivamente.

De acuerdo a JFrogel ladrón de información «elimina todos los secretos que puede encontrar en la máquina de un desarrollador, se esconde detrás de un rootkit del núcleo eBPF y responde a su operador a través de Tor».

El ladrón también utiliza las credenciales robadas como mecanismo de propagación, generando similitudes con el infame gusano Shai-Hulud. El nuevo malware tiene un nombre en clave gusano de hierro por la empresa de seguridad de la cadena de suministro de software. Al publicarse en el registro npm en forma de paquetes troyanizados, este enfoque resulta en un ataque autorreplicante.

La actividad maliciosa se remonta a una cuenta npm comprometida llamada «asteroide«, que se ha descubierto que publica versiones de paquetes que contienen el binario Rust ELF que se ejecuta a través de un gancho de preinstalación.

El malware se dirige a 86 variables de entorno, varios archivos que pueden contener credenciales asociadas con OpenAI Codex, Anthropic, Claude, Google Gemini, Cursor, Amazon Web Services (AWS), Docker, Kubernetes y npm, configuraciones de bóveda y archivos de billetera de criptomonedas Exodus.

Una peculiaridad inusual que vale la pena mencionar aquí es que el ladrón incluye una lógica para que el componente de robo de datos de la billetera omita la billetera del propio actor de la amenaza. Al momento de escribir, el billetera de criptomonedas está vacío y no se han registrado transacciones.

Ciberseguridad

JFrog describió a IronWorm como «un arma de cadena de suministro creada para encontrar secretos, modificar proyectos e inyectar código malicioso para autopropagarse en GitHub». Las confirmaciones maliciosas, que abarcan nueve organizaciones de GitHub, se introdujeron bajo el nombre del autor «claude» («claude@users.noreply.github.com») en un intento de imitar el chatbot de inteligencia artificial (IA) de Anthropic.

«El paquete malicioso npm fue publicado por asteroiddao; asteroiddao corresponde a la organización asteroid-dao GitHub; y ocrybit es miembro de esa organización, así como de organizaciones Arweave relacionadas», explicó la compañía.

«El malware robó las credenciales de ocrybit y las usó para enviar confirmaciones a través de repositorios a los que podía acceder. Esas confirmaciones colocaron malware en otros paquetes, que luego podrían publicarse e infectar al siguiente desarrollador. Y luego desapareció».

Es más, la carga útil maliciosa está equipada para intercambiar los flujos de trabajo de GitHub Actions existentes por uno que sea capaz de recolectar los secretos, escribirlos en un archivo de apariencia inofensiva y cargarlo como un artefacto de compilación, eliminando así la necesidad de un servidor externo de comando y control (C2).

Las capacidades del malware no terminan ahí. En entornos de CI, abusa del flujo de publicación confiable de npm para obtener tokens de corta duración para enviar versiones envenenadas que contienen el malware al registro.

También incorpora una carga útil eBPF que funciona como un rootkit a nivel de kernel para ocultar procesos y frustrar análisis. Sin embargo, en los sistemas donde el bloqueo del kernel está habilitado, los trucos para ocultar procesos fallan y los supuestos procesos y sockets vuelven a ser visibles.

El gusano miasma emerge nuevamente

La revelación surge como Laboratorios Endor y PasoSeguridad arrojar luz sobre una distinta campaña de ataque a la cadena de suministro que ha comprometido 57 paquetes npm en más de 286 versiones maliciosas para servir una nueva variante del gusano Miasma, que previamente infectó 32 paquetes en más de 90 versiones bajo el espacio de nombres npm @redhat-cloud-services en 72 segundos a principios de esta semana.

Algunos de los paquetes afectados se enumeran a continuación:

  • ai-sdk-ollama
  • autotel
  • esperando
  • analizador de efectos
  • complemento-eslint-esperando
  • historias-ejecutables-ciprés
  • http-uploader-dev
  • montado
  • nodo-env-resolver
  • nodo-env-resolver-aws

Los datos robados a través del malware se filtran a una cuenta de GitHub ahora inaccesible «liuende501«, que actuó como un punto de exfiltración. Se almacenaron hasta 236 repositorios en la cuenta. Actualmente no se sabe si GitHub eliminó la cuenta o si el propio actor de la amenaza la eliminó.

«Esta ola utiliza una técnica que llamamos ‘Phantom Gyp’: en lugar de los scripts de ciclo de vida previos o posteriores a la instalación que las herramientas de seguridad normalmente monitorean, el atacante abusa de un archivo vinculante.gyp de 157 bytes para activar la ejecución del código durante la instalación de npm, evitando por completo la mayoría de los controles de seguridad de los scripts de instalación», dijo el investigador de StepSecurity, Sai Likhith.

Como en el caso de Miasmala cadena de ataque está diseñada para descargar e instalar el tiempo de ejecución de Bun JavaScript, usándolo para cargar un recolector de credenciales integral diseñado para extraer secretos de AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH, administradores de contraseñas y asistentes de IA.

«La capacidad más novedosa y preocupante de esta variante es su objetivo en configuraciones de asistente de codificación de IA», dijo la compañía. «El malware inyecta archivos persistentes de puerta trasera en repositorios de proyectos que se ejecutan cada vez que un desarrollador abre el proyecto en su IDE asistido por IA».

Se recomienda a los desarrolladores que hayan instalado una versión afectada que roten las credenciales, desactiven los scripts de instalación y las reconstrucciones nativas de forma predeterminada y se aseguren de que los paquetes estén fijados con hashes de integridad.

Ciberseguridad

En una actualización compartida esta semana, Red Hat reveló que la causa principal detrás del incidente de la cadena de suministro de Miasma fue probablemente una cuenta de GitHub comprometida que se utilizó para enviar confirmaciones no autorizadas a los repositorios de la organización RedHatInsights GitHub.

«La carga útil operaba en Linux, macOS y Windows descargando dinámicamente el tiempo de ejecución de Bun correcto para cada plataforma, aunque los ejecutores de CI/CD de Linux parecían ser el objetivo principal», explicó Microsoft. dicho de la campaña.

«En los sistemas de desarrollo, el malware robó claves Secure Shell (SSH), credenciales de interfaz de línea de comandos (CLI), datos del navegador y de la billetera, mientras que en entornos CI/CD extrajo la memoria del ejecutor de GitHub Actions en busca de secretos, escaló privilegios usando sudo sin contraseña y volvió a publicar paquetes envenenados con niveles de cadena de suministro falsificados para artefactos de software (SLSA) para continuar con la propagación descendente».

Se considera que la carga útil Miasma es un derivado del gusano Shai-Hulud utilizado por EquipoPCP en campañas recientes, introduciendo cambios en gran medida «cosméticos» manteniendo similar la funcionalidad subyacente. A pesar de la superposición en el oficio, la atribución del último conjunto de ataques sigue sin estar clara, dado que TeamPCP ha publicado públicamente el código Shai-Hulud.

Desde entonces, OX Security ha descubierto etapas adicionales en la cadena de ataque de Miasma, incluidas búsquedas de confirmaciones de GitHub que contienen la cadena «firedalazer» (que reemplaza el punto muerto «FIRESCALE» previamente marcado) para recuperar otra carga útil, un archivo JavaScript («index.js») que contiene una versión alternativa del gusano Shai-Hulud, transformando efectivamente la infección en un bucle perpetuo.

En este caso, los datos robados se filtran a repositorios públicos de GitHub, cada uno con la descripción «Miasma: The Spreading Blight» o «Miasma – The Spreading Blight». Es importante señalar aquí que la versión anterior dice «Miasma: The Spreading Blight», que no tiene un espacio entre Miasma y el símbolo «:». Hay actualmente 82 repositorios de este tipo creado en las cuentas de usuario «0tabek16» y «windy629».

«El actor de amenazas puede cambiar dinámicamente las confirmaciones de ‘firedalazer’ en GitHub, haciendo que las nuevas versiones del malware sean más adaptables y más sofisticadas», afirman los investigadores de seguridad Moshe Siman Tov Bustan y Nir Zadok. dicho.

«Esto convierte a GitHub en algo más peligroso que un punto muerto. Es un C2 adaptable, uno que se apoya en una plataforma confiable y ampliamente incluida en la lista blanca, haciendo que la detección a nivel de red sea casi inútil. La mayoría de las herramientas de seguridad no están configuradas para tratar el tráfico de GitHub como sospechoso. El actor de la amenaza lo sabe».

El software espía de Android Asin se dirige a usuarios árabes a través de noticias falsas, PDF y aplicaciones de mapas de guerra

Los usuarios de habla árabe se han convertido en el objetivo de un nuevo software espía de Android con nombre en código Asínde acuerdo a recomendaciones de ESET.

La empresa eslovaca de ciberseguridad dijo que detectó por primera vez el malware propagado a través de múltiples campañas a principios de 2025, y que cada ola de ataque hacía uso de distintos sitios web que imitaban utilidades, actualizaciones relacionadas con la guerra y una fuente de noticias del gobierno:

  • gobernar[.]net, que se hace pasar por una fuente de noticias del gobierno (registrado el 27 de mayo de 2025)
  • lector de pdf[.]ayuda, que se hace pasar por un editor de PDF seguro (registrado el 29 de mayo de 2025)
  • mapa-de-guerra-en-vivo[.]com, que afirma ofrecer actualizaciones sobre incidentes militares (registrado el 20 de enero de 2025)

Dos de estos sitios web: govlens[.]mapa de guerra neto y en vivo[.]com – también se comercializaron a través de cuentas dedicadas en plataformas de redes sociales como Facebook y Telegram –

  • www.facebook[.]es/GovLens
  • t[.]yo/liveuamap_ar

«Cada uno de estos sitios web distribuye una aplicación maliciosa que combina funcionalidad legítima con capacidades de software espía sigilosas», afirmó ESET.

Ciberseguridad

La compañía de ciberseguridad señaló que el nombre del canal Telegram probablemente esté inspirado en Live Universal Awareness Map (Liveuamap), una plataforma legítima y conocida dedicada a mapear conflictos en curso, cuestiones de derechos humanos, desastres naturales y eventos geopolíticos en todo el mundo.

Desde entonces se han identificado varios artefactos asociados con Asin, incluido uno subido a VirusTotal desde Türkiye en octubre de 2025, un APK descargado del dominio «c-pdf[.]net» en diciembre de 2025 por un usuario en un dispositivo Xiaomi Redmi Note 13 Pro con Android 15, y una tercera muestra disfrazada de «Mapa de Defensa de Siria» detectada en un dispositivo Xiaomi Redmi Note 13 Pro+ 5G con Android 15 alrededor de mediados de enero de 2026.

En el último caso, se dice que el APK se descargó de un sitio web llamado «syriadefensemap[.]com.» Vale la pena señalar que el usuario debe instalar manualmente la aplicación y otorgarle los permisos necesarios para que el software espía alcance sus objetivos.

El grupo de actividad, según ESET, permanece sin atribuir. Tampoco se sabe cuáles son los objetivos principales de estas campañas. Sin embargo, basándose en los señuelos utilizados, se sospecha que el objetivo pueden haber sido periodistas e investigadores de OSINT en regiones de habla árabe.

«Tres de las cinco aplicaciones fraudulentas que descubrimos (GovLens, WarMap y Syria Defence Map) parecen estar destinadas principalmente a personas interesadas en la investigación de código abierto», dijo la compañía. «Por lo tanto, parece posible que este conjunto de actividades haya estado destinado, al menos parcialmente, a periodistas de habla árabe o profesionales de OSINT».

El incidente de Nightmare Eclipse muestra que es posible que las peleas entre investigadores y proveedores nunca desaparezcan por completo

Microsoft reabrió algunas heridas y ha reavivado el debate durante las últimas dos semanas sobre la divulgación de vulnerabilidades y la dinámica a veces conflictiva que crea entre investigadores y proveedores de seguridad.

La última controversia se produjo cuando Microsoft amenazó con emprender acciones legales penales contra un investigador de seguridad que reveló públicamente una serie de vulnerabilidades de día cero con exploits de prueba de concepto. microsoft insistió en que no recibió detalles sobre las vulnerabilidades antes del lanzamiento, y agregó que los defectos no fueron divulgados de manera responsable y pusieron a sus clientes en riesgos innecesarios.

La disputa pública entre Microsoft y el investigador conocido como “Eclipse de pesadilla«, que no pudo ser identificado ni contactado para hacer comentarios, provocó consternación entre algunos profesionales de la seguridad. La contundente respuesta de Microsoft y la reacción resultante revivieron un punto de fricción entre proveedores e investigadores que encuentran e informan fallas en el software que venden.

«La pelea se argumenta como una divulgación coordinada, pero la queja subyacente es personal y específica de una manera que la divulgación no debería serlo, especialmente con un proveedor que ha estado en esto durante tanto tiempo», dijo a CyberScoop Katie Moussouris, fundadora y directora ejecutiva de Luta Security.

«Microsoft pareció emocionarse y no debería haber dicho nada públicamente, pero de alguna manera se sintió justificado al llamar a un investigador e involucrar a las autoridades al mismo tiempo», dijo. «Eso los devuelve a las primeras etapas del duelo por la revelación de la vulnerabilidad: la negación y la ira».

El antiguo empleado de Microsoft que trabajó en contacto con la comunidad de seguridad, creó el primer programa de recompensas de la empresa y ha otorgado charlas en conferencias sobre el tema Ya en 2013, dijo que la compañía redobló su falta de responsabilidad en toda la saga.

Microsoft se negó a responder preguntas a raíz de las consecuencias.

Nightmare Eclipse insinuó una falla y una batalla inminente con el proveedor en una serie de publicaciones de blog previas a la misiva de Microsoft sobre las vulnerabilidades. rojosol, Desdefender, Martillo azul, llave amarillaGreenPlasma y MiniPlasma.

Los atacantes explotaron tres de las seis vulnerabilidades que Nightmare Eclipse lanzó antes de que Microsoft las parcheara.

El investigador afirmó que Microsoft se negó a comunicarse, no les pagó ni les dio crédito por descubrir e informar algunas de las vulnerabilidades, eliminó la cuenta del Centro de Respuesta de Seguridad de Microsoft que usaron para revelar las vulnerabilidades y marcó su cuenta de GitHub para su eliminación.

«Están demostrando a todos que están intensificando activamente este conflicto», escribieron, antes de amenazar a Microsoft con un comunicado a mediados de julio que «asegurará que sus huesos queden destrozados ese día».

La divulgación de vulnerabilidades es una vía de doble sentido

Las características de los procesos adecuados de divulgación de vulnerabilidades tienen matices y, a menudo, se enmarcan en los ojos del espectador.

Cualquier baile exitoso entre cazadores de insectos y vendedores se reduce a encontrarse a mitad de camino, dijo Andrew Morris, fundador y arquitecto jefe de GreyNoise.

Si bien los proveedores deben corregir los defectos del software y priorizar la seguridad, Morris señaló que la divulgación irresponsable de vulnerabilidades perjudica tanto a los respondedores de incidentes como a las víctimas potenciales.

«Personalmente, siento que este investigador está siendo extremadamente mezquino. Parece que tienen un interés especial», dijo.

«No puedes darle algo a alguien y decir que es por la bondad de tu corazón, y luego enojarte cuando no te pagan por ello».

Pero Morris también dejó claro que los proveedores tienen la responsabilidad de generar confianza entre los investigadores.

«Si realmente le importa ser el primero en enterarse de los errores en su software, no enterarse una vez que se ha producido un daño o una vez que alguien ha sido descubierto, entonces desea cultivar esa confianza con la comunidad de seguridad», dijo Morris.

Microsoft dijo que reconoce que la relación entre los investigadores de seguridad y los proveedores es crítica y, en ocasiones, frágil.

«Valoramos profundamente a la comunidad de seguridad y continuaremos tomando en serio sus comentarios», dijo la compañía en su publicación. en X.

Sin embargo, la compañía se mantiene firme en oponerse a las circunstancias de las revelaciones de Nightmare Eclipse, describiendo sus acciones como ilegales, injustificables e irresponsables.

«Cuando un individuo infringe la ley y participa en actividades maliciosas que causan un daño real a nuestros clientes, trabajaremos con las autoridades según corresponda», dijo Microsoft sin nombrar al investigador por su apodo. «Seguimos creyendo firmemente en la divulgación coordinada de vulnerabilidades como base para proteger a los clientes y mejorar nuestros productos. Sabemos que, dada la naturaleza de este trabajo, en ocasiones habrá malentendidos. Seguimos comprometidos a participar de buena fe y a brindar una experiencia respetuosa y profesional para todos los investigadores, independientemente de interacciones pasadas».

El costo del retroceso

Los investigadores de seguridad buscan defectos por varias razones: pagos de recompensas, reconocimiento, credibilidad de la industria o simplemente la emoción de la búsqueda que conlleva encontrar vulnerabilidades y solucionarlas.

En el mejor de los casos, este proceso ocurre entre bastidores, con parches publicados y advertidos a los clientes antes de que ocurra la explotación.

Este enfoque colaborativo ha arraigado y mejorado considerablemente, pero todavía hay casos en los que los investigadores se sienten despreciados.

“El público no tiene idea de lo que sucedió detrás de escena para juzgar por qué un investigador que previamente coordinaba finalmente se cansó y decidió abandonar un día cero. [vulnerability]», dijo Moussouris. Como tal, está menos inclinada a criticar las acciones de Nightmare Eclipse, y agrega que «parecen ser alguien que necesita ayuda».

Sin embargo, la confianza entre los investigadores y los proveedores de vulnerabilidades se rompe a menudo. A principios de esta semana, el investigador de seguridad Ammar Askar afirmó que su última interacción con el equipo de seguridad de Microsoft fue tan pobre que decidió revelar públicamente cualquier error que encuentre en VS Code en el futuro. Cumplió esa amenaza al dejando caer una vulnerabilidad y explotar el código para un defecto que permite a los atacantes robar tokens de GitHub.

Si bien acciones como esta pueden sabotear la confianza y abrir una brecha entre los proveedores y los investigadores de vulnerabilidades, el recurso es en gran medida limitado. Moussouris dijo que la mayoría de las veces los límites legales y éticos son claros para los involucrados. Los investigadores pueden informar errores, retenerlos, venderlos o publicarlos. «La única línea roja es el crimen: usar un defecto para extorsionar o atacar a la gente», dijo Moussouris.

«Amenazar con publicar en una fecha determinada es una amenaza con divulgar, y la divulgación es legal. El tono puede resultar feo. [Nightmare Eclipse] todavía no violó ninguna regla ni violó ningún deber”.

El momento no podría ser peor

Ambas partes son en parte responsables de lo sucedido, pero Microsoft empeoró las cosas, afirmó Morris. Amenazar con acciones legales y adoptar un enfoque agresivo nunca ha funcionado. Construir una buena relación entre investigadores y proveedores requiere comunicación abierta y confianza.

«Pensé que ya habíamos superado esto. Resulta que no», dijo.

El incidente de Nightmare Eclipse llega en un momento tenso en este espacio. Los proveedores y sus clientes se enfrentan a una avalancha de más vulnerabilidades, y el aumento de modelos de inteligencia artificial que las descubren está exacerbando este desafío, dejando a los expertos en seguridad alarmados por lo que se avecina.

Las perspectivas sobre dónde se descubrirán y explotarán las vulnerabilidades a continuación, y con qué impacto, son desconocidas y tremendamente inquietantes.

Estas señales implican que el sistema clásico basado en CVE con procesos divulgados responsablemente probablemente esté roto, dijo Morris. «Hay tantos CVE. Es como si esto ¿ya funciona?».

Por ahora, y a pesar de todos sus defectos, los programas coordinados de divulgación de vulnerabilidades se consideran ampliamente como el enfoque más sensato y escalable para este dilema.

«La divulgación coordinada es lo que sucede cuando un proveedor tiene suerte. Alguien a quien no contrató le entrega un error real en lugar de usarlo o venderlo. Eso pone toda la carga de mantener viva la coordinación en el proveedor», dijo Moussouris. «La aplicación de parches silenciosos sin CVE y la llamada a los investigadores que no siguen su cronograma de divulgación desperdician la suerte del proveedor».

Hizo hincapié en lo que está en juego: «Espero que Microsoft y todos los proveedores aprendan que la divulgación coordinada de vulnerabilidades es un regalo y una gracia de la comunidad de investigadores de seguridad para ellos, y la divulgación pública sigue siendo mejor que la no divulgación o el delito».

Las alternativas a una relación en deterioro podrían causar estragos y dejar a todos los proveedores y clientes más susceptibles a los ataques.

«Si los proveedores desaprenden cómo recibir propiedad intelectual y mano de obra gratuita de la comunidad de seguridad en forma de informes de vulnerabilidad con gratitud, nos dirigimos a un mundo donde nadie se molesta en avisar a los proveedores, o se mueven hacia un modelo de divulgación cronometrada que no da ninguna gracia», dijo Moussouris.

Concluyó con un mensaje directo: «Los proveedores de productos escribieron el código vulnerable, son dueños del riesgo y deben hacer todo lo que esté a su alcance para con sus usuarios para reducir ese riesgo». Eso incluye “guardar sus quejas para sí mismos y aprender de la introspección sobre la divulgación coordinada de vulnerabilidades que salieron mal”.

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

Only 10% of SOCs Say They’re Getting Excellent Value From AI. Here’s What the Second Wave Has to Deliver – CYBERDEFENSA.MX

Eighteen months ago, the AI SOC was a marketing line. Today it’s a budget item. The category has crossed over from interesting to inevitable, with billions of dollars now flowing into AI-powered security operations platforms, agentic SOC tools, and AI co-pilots built into every layer of the security stack. The data shows SOCs are buying, deploying, and standing up AI capabilities at the fastest pace the industry has ever seen.

And yet, the same SOCs reporting record AI adoption are reporting underwhelming outcomes. The first objective benchmark on the value of AI in the SOC was published in the SOC-CMM 2026 Maturity Report in May, drawing on survey data collected from roughly 200 SOCs across regions, sectors, and delivery models between late January and mid-March 2026. Only about 10% of respondents said AI has delivered excellent value to their SOC. About 19% reported good value. The remaining 71% landed at some value or none at all.

Eighteen months into AI deployment, that’s a structural signal. What follows is a read on what the data confirms, and on what the next wave of AI in security operations must deliver if the industry is going to close the gap.

What the SOC-CMM 2026 data shows

Three findings stand out in the SOC-CMM report’s AI section, and they correlate cleanly with each other once they are read together.

First, adoption is up across every category of AI used inside the SOC. Off-the-shelf large language models grew 55% year over year. AI co-pilots grew 145%. AI agents grew 118%. Supervised machine learning grew 96%. Customized LLMs grew 64%. SOC teams are over-investing in AI without the operational maturity to extract value from what they bought.

Second, the dominant adoption pattern is what the report calls the taker model: off-the-shelf AI deployed inside an existing security stack without customization. About 65% of SOCs surveyed describe themselves as takers. Another 20% are shapers, customizing what they buy. Only 15% are builders, training models against their own data. The takers are the largest cohort and the cohort reporting the least value. Across hybrid SOCs, in-house SOCs, and MSSP SOCs, the perceived value distribution is nearly identical. That uniformity is the tell. The pattern cuts across delivery model, region, and sector. The cause is structural.

Third, the report flags that the two SOC improvement challenges that grew year over year are lack of best practices (+17%) and complexity of increasing maturity (+11%). Every other challenge category, including lack of budget and lack of management support, dropped. SOCs aren’t telling the survey they don’t have money or executive support. They’re telling the survey they don’t know what they’re supposed to be doing with the AI they bought. That is the AI maturity gap in one data point.

Why the first wave of AI in the SOC underperformed

The first wave of AI SOC tools shipped as features bolted onto existing security products. SIEMs got AI triage. EDRs got AI investigation. SOAR platforms got AI playbook generation. Ticketing tools got AI summarization. Each feature was real. Each one worked in isolation. None of them shared context with the next.

What that means in practice is that SOC analysts now have five AI assistants instead of one. The triage agent in the SIEM does not know what the detection engineer silenced last week. The threat hunting agent in the EDR does not know what the threat intel team flagged that morning. The summarization agent in the ticketing tool does not know what the investigation surfaced two hops ago. Each agent accelerates its own slice of the workflow. None of them fixes the handoffs between slices, which is where most SOC time and most SOC value live.

SOC operators describe this pattern in conversations across the industry. They describe faster individual tasks and the same fragmented workflow. They describe being asked to learn five new agent interfaces while the core problem, which is that the SOC operates as a chain of disconnected stages, didn’t move at all. The AI accelerated each silo without connecting them.

The SOC-CMM 2026 report puts numbers on this dynamic too. The technology domain is again the highest-scoring maturity domain across the dataset, at an average of 2.7 out of 5. The process domain, where the handoffs between SOC stages live, scores 2.3. The people domain, where the institutional knowledge and decision-making capacity live, scores 2.3 as well. Buying more tools, including AI ones, does not move those numbers. In some SOCs it makes them worse, because each new tool adds a handoff.

What’s different about the SOCs that report excellent value

The 10% of SOCs reporting excellent value from AI are not running different point tools. They’re running AI inside a different architectural structure. Three things separate them from the 71%.

  1. AI that operates across the SOC lifecycle, not inside one stage of it. Threat intelligence, threat hunting, detection, investigation, and remediation are five stages of one workflow. When agents operate across all five stages and feed each other context, the SOC compounds. Every closed investigation calibrates the next detection. Every threat hunt result updates the next intel cycle. Every remediation feeds back into the playbook the next agent uses. The connected fabric is what produces sustained value. The SOCs reporting excellent value tend to have AI architectures that look like fabric. The SOCs reporting good value tend to have stacks of features.
  2. AI that knows the dynamic environment it’s operating in and continuously draws on it. Generic AI produces generic investigations. «Normal» looks different in a healthcare environment than a fintech one. A detection rule that fires on a real threat in one environment will fire on routine activity in another. An investigation that escalates correctly in one environment will overlook the right answer in another. SOCs reporting value have AI systems that capture and persist institutional knowledge: the assets that matter, the analysts whose judgment shaped past incidents, the sanctioned actions, the escalation criteria, the tickets that turned out to be nothing and the ones that turned out to be everything. Without that grounding, AI in the SOC produces the average of the internet, which is the wrong answer in most environments.
  3. AI that is governable. The SOC-CMM 2026 report identifies effective SOC governance as the single most challenging area of SOC improvement, with 39% of respondents naming it. AI governance and SOC governance overlap. The agentic SOC operates inside customer-defined guardrails. It exposes a defensible reasoning trace for every action. It earns autonomy in stages rather than asking for it upfront. AI in the SOC cannot be a black box. The SOCs that figured this out are the SOCs where analysts trust the system enough to give it standing authority. That trust is what produces the productivity gain. Without it, the system stalls.

The architecture problem, in plain terms

Most enterprises trying to extract value from AI in the SOC today are running point AI inside a fragmented architecture. The point AI works inside a broken architecture. That is the architecture problem.

If a SOC’s detection engineering team works in a different tool than its investigation team, AI in either tool will accelerate that team’s slice of the workflow and do nothing about the handoff between them. If a SOC’s threat hunters cannot easily test hypotheses across the same telemetry its investigations use, AI in either workflow will move only that workflow forward. If a SOC’s remediation playbooks live in a SOAR tool that does not see what its investigation agent concluded, AI remediation will execute against stale context.

The fix is connecting the stages. More AI inside the same fragmented architecture compounds the original problem. That connective fabric is what «second wave» means. The first wave delivered AI per stage. The second wave delivers AI across stages.

What the second wave must look like

The five stages of the SOC must operate as one agentic fabric grounded in the customer’s environment. Every closed investigation calibrates the next detection. Every threat hunt result updates the next intel cycle. Every remediation feeds back into the playbook the next agent uses. The SOC compounds.

In practice, a platform built this way sits on top of the SIEM, EDR, identity, cloud, ticketing, and threat intel stack an organization already owns rather than replacing it. The connective layer is what lets each stage feed the next instead of operating in isolation. Where that architecture is in place, SOCs report sharper investigations completed faster, detections that get surfaced and tuned instead of left silent or noisy, threat hunts that run continuously rather than episodically, and remediation that operates inside defined guardrails with full reasoning traces and audit-grade decision records.

The second wave of AI in the SOC must look architectural, not featural. The vendors and platforms that figure that out are the ones whose customers will move from «some value» to «excellent value» in next year’s benchmark.

Spotlight: End-to-End Agentic AI for Security Operations

One platform built around this architecture is Conifers’ end-to-end agentic SOC, launched in May 2026 on its CognitiveSOC™ platform. Rather than adding AI to a single stage, it connects threat intelligence, threat hunting, detection engineering, investigation, and remediation into one operating fabric grounded in each customer’s institutional knowledge. The five functions feed each other context, so hunts inform detection, investigations calibrate future detections, and remediation runs inside customer-defined guardrails instead of static playbooks.

Governance is built in from the start. Every agent action carries a reasoning chain and an evidence trail, and customers set the scope and authority each agent operates under, expanding autonomy as confidence builds. That is the move from human-in-the-loop to human-on-the-loop oversight. The system runs on top of the stack a SOC already owns, with more than 60 integrations across EDR, identity, cloud, email, and ITSM, and no rip-and-replace migration.

The window is closing faster than most SOCs think

Adversaries are not waiting for the second wave to arrive. Google’s Threat Intelligence Group disclosed the first confirmed AI-developed zero-day exploit earlier this year. Anthropic’s Claude Mythos preview is identifying critical vulnerabilities at machine speed. JPMorgan’s CISO published an open letter in April 2025 warning that the economics of cyber risk are shifting and that security buyers need to demand secure-by-default products instead of the current pace of rushed feature releases.

The defenders running first-wave AI inside a fragmented SOC will be the ones explaining what happened the morning after a breach. The defenders running second-wave AI as a connected fabric, with institutional knowledge inside the loop and governance built in from the start, will be the ones who saw it coming. The 10% number in the SOC-CMM 2026 report is a signal about the architecture most SOCs run right now. It is also a signal about which side of the next breach narrative each SOC will be standing on.

Visit Conifers.ai to request a demo and experience the power of a full lifecycle agentic SOC.

Frequently Asked Questions

Why are most SOCs reporting limited value from AI in 2026?

The SOC-CMM 2026 Maturity Report found that about 71% of SOCs see only some value or no value from their AI deployments. The root cause is architectural rather than technological. Most SOCs deployed AI as features inside individual products such as SIEMs, EDRs, and ticketing systems. Each feature accelerated its own stage of the workflow. None of them shared context across stages. The handoffs between threat intel, detection engineering, investigation, and remediation, which is where most SOC time goes, did not improve. AI accelerated the silos without connecting them. That is what produces «some value» instead of excellent value.

What does «second wave AI» in the SOC mean?

Second wave AI in the SOC means agentic AI that operates across the full SOC lifecycle rather than inside a single stage. The five stages of the SOC, threat intelligence, threat hunting, detection engineering, investigation, and remediation, run as one connected fabric. Agents share context. Closed investigations calibrate future detections. Threat hunt results update threat intel cycles. Remediation actions feed back into the playbook the next agent uses. The SOC compounds. This is the architectural pattern shared by the roughly 10% of SOCs reporting excellent value from AI in the SOC-CMM 2026 data.

Is the problem that SOCs are not buying enough AI?

No. The SOC-CMM 2026 data shows AI adoption growing aggressively across every category, with off-the-shelf LLMs up 55%, AI co-pilots up 145%, and AI agents up 118% year over year. SOCs are buying. The problem is that adoption is outpacing operational maturity. Two-thirds of SOCs are deploying off-the-shelf AI inside an existing security stack without modifying anything else around it. That cohort reports the least value. Buying more AI without changing the architecture it operates inside compounds the original problem instead of solving it.

How does institutional knowledge change AI SOC outcomes?

Generic AI produces generic investigations. A detection rule that fires on real threats in one environment will fire on routine activity in another. An investigation that escalates correctly in one organization will miss the right answer in another. AI systems that continuously ingest and persist dynamic institutional knowledge, the assets that matter, the analysts whose judgment shaped past incidents, the sanctioned actions, the escalation criteria, the historical incident outcomes, produce investigation results that match how a specific SOC operates. AI without that grounding produces the average of the internet, which is the wrong answer in most environments. Institutional knowledge is the difference between AI that produces noise and AI that produces decisions.

What should CISOs ask before buying their next AI SOC tool?

Three questions matter most. Does this AI operate across the full SOC lifecycle, or only inside one stage of it? How does the AI learn and persist the institutional knowledge of the organization’s specific environment, and what happens to that knowledge when analysts leave? Can the team audit every agent action with a defensible reasoning trace, and can it govern agent autonomy in stages as trust builds? A vendor that cannot give clear answers to all three is selling first-wave AI, no matter what the marketing says.

What is the agentic SOC, and how is it different from a SOAR or AI co-pilot?

The agentic SOC is the category of security operations platform where AI agents operate as decision-makers across the SOC lifecycle, not as assistants inside a single product. A SOAR automates predefined workflows using static playbooks. An AI co-pilot accelerates an analyst’s individual tasks. An agentic SOC runs agents that reason through investigations, surface and tune detections, threat hunt continuously, and remediate inside customer-defined guardrails, all while sharing context across stages. Analysts move from «in the loop» on every step to «on the loop» overseeing the system.

How quickly can a SOC move from first-wave AI to second-wave AI?

Faster than most teams assume. The shift is architectural, not a rip-and-replace. The connective layer that turns point AI into agentic fabric does not require buying new tools or replacing existing ones. It requires connecting what the SOC already owns into a system that compounds. Most SOCs underestimate how quickly the shift can be made once the architecture is in place.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

El nuevo grupo de amenazas OP-512 se dirige a servidores Microsoft IIS con un marco de shell web personalizado – CYBERDEFENSA.MX

Somos el medio independiente de ciberseguridad de referencia en América Latina. Nacimos con una misión clara: llevar inteligencia de amenazas real, técnica y accesible a profesionales, empresas y ciudadanos de habla hispana — sin filtros corporativos, sin demora.

Los piratas informáticos aprovechan un defecto crítico del complemento de WordPress Everest Forms Pro para apoderarse de los sitios

Los actores de amenazas están explotando activamente una falla de seguridad crítica en Everest Forms Pro, un complemento de WordPress con alrededor de 4000 instalaciones activas, para ejecutar código arbitrario, lo que lleva a un compromiso completo del sitio.

La vulnerabilidad en cuestión es CVE-2026-3300 (puntuación CVSS: 9,8), un error de ejecución remota de código que afecta a todas las versiones del complemento hasta la 1.9.12 inclusive. Se lanzó un parche para la falla el 18 de marzo de 2026, con la versión 1.9.13.

«Esto se debe a que la función Process_filter() del complemento de cálculo concatena valores de campo de formulario enviados por el usuario en una cadena de código PHP sin el escape adecuado antes de pasarlo a eval()», Wordfence dicho.

«La función sanitize_text_field() aplicada a la entrada no escapa de las comillas simples u otros caracteres de contexto del código PHP. Esto hace posible que atacantes no autenticados inyecten y ejecuten código PHP arbitrario en el servidor enviando un valor manipulado en cualquier campo de formulario de tipo cadena (texto, correo electrónico, URL, selección, radio) cuando un formulario utiliza la función ‘Cálculo complejo’».

La explotación exitosa de la vulnerabilidad podría permitir a actores maliciosos no autenticados ejecutar código PHP arbitrario en el servidor, permitiéndoles crear cuentas de administrador fraudulentas, implementar shells web y abrir otras formas de profundizar en el servidor y establecer puntos de apoyo persistentes.

Ciberseguridad

Según la empresa de seguridad de WordPress, se ha observado que los atacantes explotan el defecto a partir del 13 de abril de 2026. Hasta la fecha se han bloqueado más de 29.300 intentos de explotación dirigidos al defecto. De estos, 16 intentos de ataque ocurrido en las últimas 24 horas. La carga útil más común implica intentos de crear una cuenta de administrador llamada «diksimarina» (dirección de correo electrónico: diksimarina@gmail.com) en el sitio comprometido.

Estos esfuerzos de ataque se originaron en las siguientes direcciones IP:

  • 202.56.2.126
  • 209.146.60.26
  • 15.235.166.18
  • 2402:1f00:8000:800::40dB
  • 185.78.165.153

Los ataques de Skimmer explotan Stripe para C2

La divulgación se produce cuando Sansec advirtió sobre múltiples campañas de skimmer, incluida una que utiliza Stripe como servidor de comando y control (C2) y un sumidero de exfiltración de datos en un intento por explotar la reputación de la marca y eludir las reglas de la Política de seguridad de contenido y los filtros de red.

«El atacante trata a Stripe como una infraestructura gratuita, no como una forma de blanquear cargos», Sansec anotado. «Stripe les proporciona una base de datos grabable para tarjetas robadas y un punto final de alojamiento de código para el skimmer, ambos detrás de un dominio en el que las reglas CSP y los filtros de red confían de forma predeterminada».

La campaña se basa en los dominios Google Tag Manager (GTM) y Stripe (googletagmanager.com y api.stripe.com), en los que las tiendas en línea confían implícitamente, con el código malicioso cargado desde un contenedor GTM y ejecutado en cada página que lo carga.

En las páginas de pago de Magento y Adobe Commerce, extrae un skimmer ofuscado de un Cuenta de cliente de Stripedel campo de metadatos («cus_TfFjAAZQNOYENR», en este caso) y guarda la información financiera, las direcciones de facturación y de correo electrónico y los números de teléfono ingresados ​​por usuarios desprevenidos para almacenamiento local. Los datos capturados luego se extraen de nuevo a la cuenta de Stripe del atacante.

Ciberseguridad

«Cada tarjeta robada se convierte en un ‘cliente’ en la cuenta del atacante», afirmó la empresa de seguridad del comercio electrónico. «Si tiene éxito, el cargador elimina la entrada localStorage, por lo que el mismo registro no se envía dos veces. El atacante lista sus tarjetas robadas más tarde llamando a la misma API con la misma clave. La base de datos de clientes de Stripe se convierte en un sumidero de exfiltración gratuito y duradero».

Se dice que el registro de cliente de Stripe que contiene el skimmer se creó el 24 de diciembre de 2025, lo que indica que la operación puede haber estado activa desde entonces. Sansec dijo que también identificó una segunda variante del cargador que usa Google Firestore en lugar de Stripe, aunque el objetivo final es el mismo: abusar de un servicio confiable como un canal encubierto que es poco probable que sea bloqueado por las tiendas de comercio electrónico.

Los hallazgos coinciden con una operación a gran escala denominada Gorgonágora que ha utilizado un grupo de 5.714 escaparates .shop falsos que se hacen pasar por marcas como Starbucks, Ford, Sony, Mattel, Hasbro, Lego, Disney y Toyota, cuyas páginas de pago canalizan datos de tarjetas robadas a un único servidor skimmer en Moldavia. La campaña ha estado en curso desde agosto de 2025.

«Cada tienda ejecuta la misma pila de comercio Medusa.js y carga el mismo SDK de pago personalizado, que genera un iframe Stripe falso y filtra los datos de la tarjeta a través de un WebSocket cifrado a un único servidor en Moldavia», dijo la compañía holandesa.

«La exfiltración se ejecuta a través de WebSocket con una carga útil AES-256-GCM, y el C2 mantiene una retransmisión 3D Secure en vivo: cuando el banco víctima devuelve un desafío 3DS, el operador se lo devuelve al comprador a través del iframe falso para que la transacción se complete y el robo permanezca invisible».

Sitios falsos, malware bancario e inicios de sesión robados – CYBERDEFENSA.MX

Los investigadores de seguridad y el FBI advierten que una ola de fraude con el tema de la FIFA ya está afectando a los fanáticos de la Copa Mundial 2026, días antes del inicio del 11 de junio.

Informes recientes describen miles de dominios similares a FIFA, malware bancario oculto dentro de aplicaciones de streaming piratas y al menos una operación que copia la página de inicio de sesión de FIFA lo suficientemente bien como para hacerse cargo de cuentas reales.

Es un objetivo obvio. Se esperan más de seis millones de aficionados en 16 ciudades de Estados Unidos, Canadá y México, y la FIFA dijo que recibió más de 150 millones de billetes solicitudes en los primeros 15 días, lo que dejó el torneo con una sobresuscripción de alrededor de 30 veces. Las entradas son escasas, los aficionados están ansiosos y el dinero circula rápidamente, que es exactamente lo que necesita el fraude.

Un operador, 300 sitios FIFA clonados

Los hallazgos más detallados provienen de Grupo-IBque rastreó más de 4.300 dominios fraudulentos de FIFA registrados desde agosto de 2025. En el centro hay un grupo al que llama ESTADIO FANTASMAuna operación de habla china e impulsada por dinero que ejecuta un kit de phishing en más de 300 de esos sitios.

Lo falso es bueno. La página es una copia casi perfecta de fifa.com e imita el inicio de sesión único real de FIFA, administrado por PingIdentity, hasta la identificación de cliente genuina copiada del sitio en vivo. Carga sus imágenes directamente desde los propios servidores de la FIFA, por lo que la página parece auténtica y evita herramientas que marcan imágenes copiadas.

Aquí está la parte que hace el daño: la página de inicio de sesión falsa también solicita restablecer la contraseña. Una vez que la víctima ingresa sus datos, el atacante puede bloquear su propia cuenta de FIFA y revender las entradas vinculadas a ella.

La mayor parte del tráfico proviene de anuncios de Facebook, con los mismos códigos de seguimiento reutilizados en todo el grupo, además de enlaces en Telegram, WhatsApp y en los resultados de búsqueda. El sitio acepta pagos de cinco maneras diferentes: ingreso directo con tarjeta, pasarelas de pago externas, aplicaciones de transferencia de dinero como Chime y Nequi, procesadores exclusivos para México y una opción criptográfica que convierte un pago con tarjeta en criptomoneda, que es mucho más difícil de recuperar.

Esto último es útil, porque la venta de entradas oficiales de la FIFA nunca acepta criptomonedas, por lo que cualquier vendedor que las solicite es una estafa.

Group-IB cifra las pérdidas por fraude de billetes de primas y hoteles entre 71 y 474 millones de dólares, y dice que toda la campaña podría sumar miles de millones. Esas son estimaciones basadas en la infraestructura que puede ver, no en pérdidas confirmadas.

Miles de dominios, muchos tipos de estafas

No se trata sólo del Grupo IB. Laboratorios FortiGuard contó más de 13.000 dominios con temas de la Copa Mundial registrados entre enero y mayo, alrededor del 8,8% de ellos maliciosos o sospechosos.

El aviso del FBI enumera docenas de dominios falsos de FIFA, desde parecidos mal escritos hasta páginas de trabajos de FIFA falsas, y advierte que habrá más en el futuro. Otros investigadores han mapeado miles de sitios similares y más de mil cuentas sociales falsas.

Ciberseguridad

El fraude de billetes es sólo una pieza. Group-IB también encontró tiendas de mercancías falsificadas, sitios de transmisión falsos que cobran una tarifa de suscripción y luego instalan malware que entrega el control al atacante, y sitios de apuestas falsos que recopilan escaneos de pasaportes y selfies para el robo de identidad.

Bitdefender rastreado por separado Correos electrónicos de lotería de la FIFA pagos prometedores de hasta 2 millones de dólares. Group-IB también señaló un mercado de «phishing como servicio» que vende kits de estafa ya preparados y robots de compra de boletos, por lo que eliminar a un operador apenas ayuda.

Las piezas encajan: los dominios falsos captan las búsquedas de entradas, los anuncios y los resultados de búsqueda impulsan el tráfico, los volcados de contraseñas robadas alimentan las apropiaciones de cuentas y las aplicaciones descargadas convierten la caza de flujos en un fraude bancario.

Malware bancario oculto en aplicaciones de streaming

Para los fanáticos que buscan transmisiones gratuitas de partidos, el mayor peligro está en el teléfono. AmenazaTejido vio un aumento en aplicaciones maliciosas de streaming no oficiales, muchas de las cuales pretenden ser la popular RojaDirecta, en torno a la reciente final de la Liga de Campeones, y espera una repetición en la Copa del Mundo a mayor escala.

Kaspersky vinculó esas mismas aplicaciones con troyanos bancarios de Android, malware creado para drenar dinero de aplicaciones bancarias y criptográficas, y nombró dos familias: Massiv y Perseus. Estas aplicaciones no están en Google Play, por lo que instalar una significa hacer clic en las advertencias que normalmente la bloquearían.

Una vez instalado, el malware utiliza las herramientas de accesibilidad de Android para apoderarse del teléfono. Puede colocar pantallas de inicio de sesión bancarias falsas sobre aplicaciones reales, registrar lo que escribe el propietario, interceptar códigos de un solo uso de mensajes de texto y aplicaciones de inicio de sesión destinadas a mantener las cuentas seguras y controlar la pantalla desde lejos.

Perseus, construido sobre el código filtrado de un antiguo troyano llamado Cerberus, incluso lee aplicaciones para tomar notas en busca de contraseñas guardadas y frases de recuperación criptográfica. La señal de alerta más simple, dice ThreatFabric, es una aplicación de transmisión que solicita acceso de accesibilidad. No tiene ninguna razón honesta para necesitarlo.

Estafas sociales, inicios de sesión robados y Wi-Fi riesgosos

Las redes sociales están igualmente repletas de estafas. Bitdefender encontró más de 55 campañas publicitarias con temas de fútbol en Facebook e Instagram, promocionando kits falsificados, pegatinas de Panini falsas y páginas de phishing; dos de las operaciones de mercancías se remontaban a operadores chinos a través de sus etiquetas de seguimiento de anuncios.

Fortinet contó más de 1.700 cuentas falsificadas de FIFA, casi el 90% de ellas en Facebook e Instagram, además de un esquema que utilizaba anuncios de empleo e invitaciones de calendario falsos de FIFA para enviar a los solicitantes a un inicio de sesión similar a Google.

Los inicios de sesión robados de FIFA ya están en circulación. Fortinet encontró cientos de miles de inicios de sesión de usuarios, además de más de 4.600 direcciones web de FIFA, en datos recopilados por malware de robo de credenciales como Vidar, LummaC2 y RedLine.

El Wi-Fi de la ciudad anfitriona es su propio problema. A Encuesta de Kaspersky que recorrieron la Ciudad de México, Monterrey y Guadalajara encontraron que entre el 10% y el 12% de las redes estaban abiertas y sin contraseña, con la función de emparejamiento WPS todavía activada en casi la mitad. Ambos dejan aperturas fáciles para puntos de acceso maliciosos «gemelos malvados» que copian una red real y leen silenciosamente su tráfico.

Qué tener en cuenta

Estas estafas dejan señales claras. Compre únicamente a través de fifa.com y escriba la dirección usted mismo en lugar de confiar en un anuncio o un resultado de búsqueda. Active el inicio de sesión multifactor y trate a cualquier vendedor que quiera un pago en criptomonedas como una estafa, ya que la venta de entradas de la FIFA nunca lo solicita.

Ciberseguridad

En Android, la señal de alerta más clara es una aplicación de transmisión que solicita acceso de accesibilidad que no tiene motivos para necesitar. En Wi-Fi abierto en las ciudades anfitrionas, limítese a los datos móviles cuando pueda y evite iniciar sesión en cuentas bancarias o de correo electrónico.

Para los equipos de seguridad, el trabajo es sencillo: estar atento a nuevos dominios con temas de FIFA y páginas de inicio de sesión similares, marcar cualquier inicio de sesión de personal o cliente que aparezca en los registros de ladrones de Vidar, LummaC2 o RedLine, y preparar a los equipos antifraude para los picos de multas y devoluciones de cargos hasta mediados de julio.

Meta dice que también está respondiendo.. Ahora muestra ventanas emergentes de advertencia cuando la gente busca en Facebook entradas para la FIFA, y se asoció con Visa para desmantelar una red de Facebook vinculada a sitios falsos de la Copa Mundial que promueven apuestas falsas. El FBI pide a cualquier persona que haya sido estafada que lo denuncie en IC3.

La mayor preocupación es lo que todavía está esperando. Group-IB contó aproximadamente 3.800 dominios FIFA fraudulentos estacionados y sin uso, listos para activarse. Con kits de estafas y bots listos para usar que ya están a la venta, es fácil llamar a la ventana ocupada: del 11 de junio al 19 de julio, cuando las búsquedas de boletos, transmisiones y viajes estarán en su punto máximo.

PCPJack secuestra 230 servidores AWS, Google Cloud y Azure para una red de retransmisión SMTP encubierta – CYBERDEFENSA.MX

El actor de amenazas conocido como PCPJack ha secuestrado servidores en la nube asociados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure para crear una red encubierta de retransmisión de correo electrónico SMTP.

«Los servidores empresariales comprometidos en EE. UU., Europa y Asia se convirtieron silenciosamente en servidores proxy SMTP, se verificó su capacidad de retransmisión de correo y se sincronizaron con un consumidor intermedio cada cinco minutos», dijo Hunt.io en un comunicado. «La infraestructura todavía estaba funcionando cuando la encontramos».

La empresa de inteligencia de amenazas dicho encontró código fuente, archivos binarios compilados, registros de estado de implementación, escáneres de Internet, herramientas de explotación y una configuración de Sliver en vivo después de que el actor de amenazas detrás de la operación dejó dos directorios abiertos en un servidor de comando y control (C2) («213.136.80[.]73») sin ninguna autenticación.

PCPJack fue descubierto por primera vez por SentinelOne en abril de 2026 después de que identificó un marco de robo de credenciales que apunta específicamente a los servicios en la nube, mientras tomaba medidas para terminar y eliminar procesos o artefactos asociados con TeamPCP, otro notorio grupo de piratería que ha llamado la atención en los últimos meses por sus ataques a la cadena de suministro de software.

Ciberseguridad

Organizado en uno de los directorios abiertos. Astilla-Kit de herramientas de implementación de proxy SMTP integrado, junto con tunelización Chisel y binarios de proxy para la mayoría de las arquitecturas de CPU de Linux, como AMD64, ARM64 y x86. En el lado de la víctima, el binario se elimina como un archivo oculto con prefijo de punto y se conserva en «/var/tmp/.xs».

También se encuentran en los directorios scripts de implementación diseñados para cargar la configuración del cliente Sliver C2 y filtrar las balizas de Linux que se han registrado en los últimos diez minutos. Las balizas son implantes que llaman periódicamente al servidor C2 a intervalos regulares para registrarse y recuperar comandos.

«Cada baliza recibe un puerto proxy SOCKS5 derivado de manera determinista de un hash MD5 de su UUID Sliver, asignado en el rango 10000-14999», señaló Hunt.io. «La misma baliza siempre se asigna al mismo puerto en todas las ejecuciones, lo que elimina la necesidad de un registro de puerto compartido».

El script también es capaz de ejecutar una puerta de calidad SMTP que busca acceso saliente a smtp.gmail.[.]Com:587. Los hosts que no pasan esta verificación se omiten con un código de salida de cero.

«Esta puerta define el propósito de la operación: los hosts que no pueden transmitir correo electrónico no tienen ningún valor para este canal», añadió la empresa de ciberseguridad. «Las balizas se procesan en lotes de 50, con una espera de 25 minutos después de la carga y 15 minutos después de la ejecución de los comandos, para dar cabida a registros de balizas a intervalos lentos».

Se ha descubierto que las iteraciones posteriores de los scripts de implementación eliminan la puerta SMTP y la lógica de procesamiento por lotes. También está presente un script de diagnóstico que selecciona cinco balizas activas y les asigna a cada una un comando de shell que verifica lo siguiente:

  • Presencia de archivos binarios de Chisel en rutas de caída conocidas
  • Se está ejecutando un proceso de Chisel
  • Espacio en disco
  • Accesibilidad del puerto 9000 en el C2, y
  • Presencia de artefactos de persistencia, como la entrada cron o el servicio systemd
Ciberseguridad

Además, el servidor C2 ejecuta un script Python llamado «chisel_verifier.py» como un demonio en segundo plano persistente, que enumera los puertos activos del túnel Chisel a través de ss -tlnp cada 60 segundos, prueba la capacidad SMTP de cada nuevo puerto y elimina los túneles fallidos o descartados del grupo activo.

Los proxies verificados se enriquecen con la dirección IP de salida, el país y el ASN a través de servicios como api.ipify.[.]org y ip-api[.]com. Luego, las listas de proxy se sincronizan cada cinco minutos a través del Protocolo de copia segura (SCP) con un servidor descendente independiente en 38.242.204.[.]245. Actualmente no se puede acceder al servidor. El objetivo final de la operación aún no está claro en este momento.

«El resultado de 230 nodos es el resultado observable. Si esta progresión refleja un solo operador iterando o múltiples actores que comparten la misma infraestructura no se puede determinar a partir de los archivos recuperados», dijo Hunt.io, describiéndola como una campaña oportunista.

«La lista de proxy verificada se sincroniza cada cinco minutos con ese servidor y alguien la está consumiendo. Ya sea para spam, phishing o cualquier otra cosa, la infraestructura para realizar entregas a escala claramente estaba funcionando».