A los equipos de seguridad de hoy no les faltan herramientas ni datos. Están abrumados por ambos.

Sin embargo, dentro de los terabytes de alertas, exposiciones y configuraciones erróneas, los equipos de seguridad todavía tienen dificultades para comprender el contexto:

P: ¿Qué exposiciones, configuraciones erróneas y vulnerabilidades se encadenan para crear rutas de ataque viables hacia las joyas de la corona?

Incluso los equipos de seguridad más maduros no pueden responder tan fácilmente.

El problema no son las herramientas. Es que las herramientas no se comunican entre sí.

Este es precisamente el problema para el que se diseñó el marco Cybersecurity Mesh Architecture (CSMA) de Gartner, y es lo que Seguridad de malla ha puesto en funcionamiento la primera plataforma CSMA especialmente diseñada del mundo.

En este artículo, veremos qué es CSMA y cómo funciona Mesh CSMA:

• Descubre rutas de ataque hacia las joyas de la corona.
• Prioridades basadas en amenazas activas
• Elimina sistemáticamente las rutas de ataque.

¿Qué es CSMA y por qué es importante ahora?

Antes de sumergirnos en la plataforma, aclaremos qué es CSMA.

CSMAtal como lo define Gartner, es una capa de seguridad distribuida y componible que conecta su pila existente, brindándole la unificación del contexto de una plataforma sobre sus mejores herramientas. Con CSMA, el riesgo se puede entender de manera integral y no en silos.

El problema: las herramientas aisladas pierden la historia del ataque

Todos hemos visto hallazgos como estos en paneles separados:

• Un desarrollador ha instalado un asistente de codificación de IA de aspecto legítimo de VS Code Marketplace
• Esa extensión ha sido marcada como potencialmente troyanizada, pero la alerta se encuentra en una herramienta, desconectada de cualquier otra cosa.
• La estación de trabajo del desarrollador tiene largos tiempos de espera de sesión y no se aplica ninguna política de aislamiento de dispositivos.
• Las credenciales del desarrollador tienen amplio acceso a una cuenta de producción de AWS.
• Esa cuenta de AWS tiene acceso directo y sin restricciones a una base de datos RDS de producción que almacena la PII del cliente.

De forma aislada, cada señal parece manejable: un indicador de política de mercado aquí, una configuración incorrecta del tiempo de espera de sesión allí. Los equipos de seguridad los ven, los registran y les quitan prioridad. Ninguno de ellos parece P1 por sí solo.

Pero unidos, cuentan una historia muy diferente: una ruta de ataque clara y de múltiples saltos desde la estación de trabajo de un desarrollador directamente a los datos más confidenciales de sus clientes. No se ha producido ninguna brecha, pero el camino está abierto, es viable y está a la espera.

Si se añade inteligencia sobre amenazas, el riesgo se vuelve aún más difícil de ignorar: los actores de amenazas se dirigen activamente a los entornos de desarrollo y a los puntos de entrada de la cadena de suministro como su punto de apoyo preferido en la infraestructura de producción. ¿Encadenó sus herramientas marcadas por separado? Se corresponde casi exactamente con su libro de jugadas.

Exposición a amenazas en vivo en malla

Esta es una exposición a una amenaza viva. No es una brecha, sino una ruta explotable que existe en su entorno en este momento, invisible porque ninguna herramienta puede verla toda a la vez.

Eso es exactamente para lo que se creó Mesh CSMA. Al unificar el contexto en toda su pila, Mesh muestra estas rutas de ataque entre dominios antes de que sean explotadas, para que su equipo pueda romper la cadena antes de que un atacante la recorra.

Cómo funciona CSMA en malla

Mesh CSMA convierte señales fragmentadas en historias de amenazas significativas entre dominios. Para que los equipos de seguridad puedan centrarse en lo que importa.

Así es como funciona Mesh.

Paso 1: Conéctese: sin agentes, sin quitar y reemplazar

Mesh comienza integrándose con su pila existente: todas las herramientas, lagos de datos e infraestructura. (¿Con qué se integra Mesh? Ver Más de 150 integraciones aquí.

Integraciones de malla

Paso 2: Ver – The Mesh Context Graph™

A continuación, Mesh descubre automáticamente su Joyas de la Corona: bases de datos de producción, repositorios de datos de clientes, sistemas financieros, infraestructura de firma de código y ancla todo el modelo de riesgo en torno a ellos.

Este es el principio fundamental que hace que Mesh sea diferente: el riesgo se entiende en relación con lo que realmente importa para el negocio, no en relación con las alertas más ruidosas.

A partir de ahí, Mesh construye el Gráfico de contexto de malla™ – un gráfico centrado en la identidad y que se actualiza continuamente de cada entidad en su entorno: usuarios, máquinas, cargas de trabajo, servicios, almacenes de datos y las relaciones entre ellos.

A diferencia de los inventarios de activos, que le indican lo que existe, Mesh Context Graph™ le informa como todo se conecta. Mapea rutas de acceso, relaciones de confianza, cadenas de derechos y exposición de la red en un único modelo unificado, todo rastreado hasta sus Joyas de la Corona.

Gráfico de contexto de malla

Paso 3: Evaluar: descubrimiento de rutas de ataque viables

Aquí es donde Mesh se diferencia de las herramientas tradicionales de gestión de exposición.

Las plataformas CTEM y los escáneres de vulnerabilidades muestran CVE y configuraciones erróneas. Pero una vulnerabilidad CVSS 9.8 en un activo aislado con acceso a Internet sin acceso a nada sensible es un riesgo muy diferente a una mala configuración de CVSS 5.5 en una cuenta de servicio que tiene acceso directo a su base de datos de producción. Mesh entiende la diferencia.

La plataforma correlaciona los hallazgos entre dominios (configuraciones erróneas de la postura en la nube, extralimitación de los derechos de identidad, puntos ciegos de detección, vulnerabilidades sin parches) y los rastrea en el gráfico de contexto para determinar qué combinaciones crean cadenas de ataques viables de múltiples saltos hacia Crown Jewels. Luego, prioriza basándose en inteligencia sobre amenazas en vivo.

El resultado: una lista clasificada y procesable de rutas completas de ataque entre dominios, cada una de las cuales muestra:

• Punto de entrada: cómo un atacante obtendría acceso inicial
• Cadena de pivote: cada salto intermedio a través del entorno
• Objetivo: a qué joya de la corona se puede acceder
• ¿Por qué es viable?: las configuraciones erróneas específicas, las rutas de acceso o las brechas de detección que lo permiten
• Contexto de amenaza: si actores de amenazas activos conocidos están explotando esto actualmente

Exposiciones de la joya de la corona de malla

Con Mesh, puede hacer clic en cada exposición a amenazas en vivo y visualizar la ruta de ataque, convirtiendo señales aisladas en una hoja de ruta significativa para la solución de riesgos.

Visualización de la ruta de ataque de malla

Paso 4: Eliminar – Rompiendo la cadena

Descubrir rutas de ataque es solo la mitad del valor. La malla los cierra.

Para cada ruta de ataque identificada, Mesh genera acciones de remediación específicas y priorizadas asignadas a las herramientas existentes que ya están en su pila. En lugar de una guía genérica como «parchear este CVE», Mesh le indica: revocar este enlace de rol específico, aplicar MFA en esta cuenta de servicio, actualizar esta política CSPM, aislar esta carga de trabajo.

Fundamentalmente, Mesh organiza la corrección en todos los dominios: una única ruta de ataque puede requerir una solución en su herramienta CSPM, un cambio en su plataforma IGA y una actualización de políticas en su solución ZTNA. Mesh coordina esas acciones sin obligar a su equipo a cambiar manualmente de contexto entre consolas.

Paso 5: Defender: validación continua y cobertura de brechas de detección

La malla no se limita a la postura. También valida continuamente su capa de detección, identificando puntos ciegos donde las técnicas de ataque tendrían éxito pero no generarían alertas.

Esto cierra el círculo entre prevención y detección. Los equipos de seguridad pueden ver no sólo donde pueden ir los atacantes pero donde pasarían desapercibidos si lo intentaran. Las brechas de detección surgen junto con las brechas de postura dentro del mismo modelo de riesgo unificado, lo que permite una priorización que refleja el verdadero riesgo comercial.

Mesh reevalúa continuamente el entorno a medida que cambia la infraestructura, se incorporan nuevas herramientas y se actualiza la inteligencia sobre amenazas. El mapa de ruta de ataque nunca es una instantánea de un momento determinado: es un modelo en vivo.

Cronología de la investigación automática de malla

¿Qué lo diferencia de SIEM, XDR o CTEM?

SIEM y XDR detectar amenazas después de que se generan las señales. Se basan en eventos que ya sucedieron y requieren ajustes importantes para reducir los falsos positivos. No modelan rutas de ataque de manera proactiva.

Plataformas CTEM priorizan las vulnerabilidades en función de las puntuaciones de explotabilidad, pero la mayoría opera dentro de un único dominio (nube, punto final, identidad) y luchan por modelar cómo se encadenan los riesgos de diferentes dominios.

Grandes proveedores de plataformas lograr la unificación del contexto, pero a costa de la dependencia de un proveedor y el reemplazo forzoso de herramientas especializadas.

Mesh adopta un enfoque diferente. Alineándose precisamente con lo que Gartner imaginó para CSMA, Mesh unifica el contexto en todas las herramientas, lagos de datos e infraestructura existentes, lo que permite la eliminación continua de la exposición sin necesidad de extraer nada.

¿Para quién está diseñado Mesh?

Mesh CSMA está diseñado para equipos de seguridad que ya han invertido en las mejores herramientas y ahora están lidiando con las consecuencias de la seguridad fragmentada:

• Docenas de paneles, contexto cero
• Datos de seguridad inconexos, que generan ruido en lugar de información
• Correlación manual, conectando los puntos entre herramientas.

La plataforma cerró recientemente una Serie A de 12 millones de dólares liderada por Lobby Capital con la participación de Bright Pixel Capital y S1 (SentinelOne) Ventures.

Su próximo paso: obtenga más información sobre Mesh CSMA

Las herramientas de seguridad muestran riesgos aislados. Mesh muestra rutas de ataque hacia las Joyas de la Corona y las elimina.

¿Quiere ver exposiciones a amenazas en vivo en su entorno? Prueba Mesh gratis durante 7 días.

O regístrese para el seminario web en vivo: ¿Quién puede alcanzar las joyas de su corona? Modelado de rutas de ataque con Mesh CSMA para ver a Mesh identificar rutas de ataque reales en vivo.

La campaña de malware GlassWorm se está utilizando para impulsar un ataque continuo que aprovecha los tokens de GitHub robados para inyectar malware en cientos de repositorios de Python.

«El ataque se dirige a proyectos Python, incluidas aplicaciones Django, código de investigación de aprendizaje automático, paneles Streamlit y paquetes PyPI, agregando código ofuscado a archivos como setup.py, main.py y app.py», StepSecurity dicho. «Cualquiera que ejecute pip install desde un repositorio comprometido o clone y ejecute el código activará el malware».

Según la empresa de seguridad de la cadena de suministro de software, las primeras inyecciones se remontan al 8 de marzo de 2026. Los atacantes, al obtener acceso a las cuentas de los desarrolladores, rebase las últimas confirmaciones legítimas en la rama predeterminada de los repositorios de destino con código malicioso y luego forzar los cambios, manteniendo intactos el mensaje, el autor y la fecha del autor de la confirmación original.

Esta nueva rama de la campaña GlassWorm ha recibido el nombre en código ForceMemo. El ataque se desarrolla a través de los siguientes cuatro pasos:

• Comprometer los sistemas de los desarrolladores con el malware GlassWorm a través de extensiones maliciosas de VS Code y Cursor. El malware contiene un componente dedicado a robar secretos, como tokens de GitHub.
• Utilice las credenciales robadas para forzar la implementación de cambios maliciosos en cada repositorio administrado por la cuenta de GitHub violada al cambiar la base del malware ofuscado a archivos Python llamados «setup.py», «main.py» o «app.py».
• La carga útil codificada en Base64, adjunta al final del archivo Python, presenta comprobaciones similares a GlassWorm para determinar si el sistema tiene su configuración regional configurada en ruso. Si es así, omite la ejecución. En todos los demás casos, el malware consulta el Campo de nota de transacción asociado con una billetera Solana («BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC») previamente vinculado a GlassWorm para extraer la URL de carga útil.
• Descargue cargas útiles adicionales del servidor, incluido JavaScript cifrado diseñado para robar criptomonedas y datos.

«La primera transacción en la dirección C2 data del 27 de noviembre de 2025, más de tres meses antes de las primeras inyecciones de repositorio de GitHub el 8 de marzo de 2026», dijo StepSecurity. «La dirección tiene 50 transacciones en total, y el atacante actualiza periódicamente la URL de la carga útil, a veces varias veces al día».

La divulgación se produce cuando Socket marcó una nueva iteración de GlassWorm que técnicamente conserva el mismo oficio principal al tiempo que mejora la capacidad de supervivencia y la evasión al aprovechar extensionPack y extensionDependencies para entregar la carga útil maliciosa mediante un modelo de distribución transitiva.

Además, Aikido Security también atribuyó al autor de GlassWorm una campaña masiva que comprometió más de 151 repositorios de GitHub con código malicioso oculto mediante caracteres Unicode invisibles. Curiosamente, la carga útil decodificada está configurada para recuperar las instrucciones C2 de la misma billetera Solana, lo que indica que el actor de la amenaza ha estado apuntando a los repositorios de GitHub en múltiples oleadas.

El uso de diferentes métodos de entrega y métodos de ofuscación de código, pero la misma infraestructura de Solana, sugiere que ForceMemo es un nuevo vector de entrega mantenido y operado por el actor de amenazas GlassWorm, que ahora ha pasado de comprometer las extensiones de VS Code a una adquisición más amplia de cuentas de GitHub.

«El atacante inyecta malware forzando la rama predeterminada de los repositorios comprometidos», señaló StepSecurity. «Esta técnica reescribe el historial de git, conserva el mensaje de confirmación y el autor originales, y no deja ninguna solicitud de extracción ni rastro de confirmación en la interfaz de usuario de GitHub. Ninguna otra campaña documentada de la cadena de suministro utiliza este método de inyección».

Los investigadores de ciberseguridad han señalado una nueva iteración de la campaña GlassWorm que, según dicen, representa una «escalada significativa» en la forma en que se propaga a través del registro Open VSX.

«En lugar de requerir que cada listado malicioso incorpore el cargador directamente, el actor de amenazas ahora está abusando de extensionPack y extensionDependencies para convertir extensiones inicialmente independientes en vehículos de entrega transitivos en actualizaciones posteriores, permitiendo que un paquete de apariencia benigna comience a extraer una extensión separada vinculada a GlassWorm solo después de que ya se haya establecido la confianza», Socket dicho en un informe publicado el viernes.

La empresa de seguridad de la cadena de suministro de software dijo que descubrió al menos 72 extensiones maliciosas Open VSX adicionales desde el 31 de enero de 2026, dirigidas a desarrolladores. Estas extensiones imitan utilidades de desarrollo ampliamente utilizadas, incluidos linters y formateadores, ejecutores de código y herramientas para asistentes de codificación impulsados ​​por inteligencia artificial (IA), como Clade Code y Google Antigravity.

Los nombres de algunas de las extensiones se enumeran a continuación. Desde entonces, Open VSX ha tomado medidas para eliminarlos del registro.

• angular-studio.ng-extensión-angular
• crotoapp.vscode-xml-extensión
• extensión-de-código-gvotcha.claude
• mswincx.antigravity-cockpit
• tamokill12.foundry-pdf-extensión
• turbobase.sql-turbo-herramienta
• vce-brendan-studio-eich.js-depurador-vscode

GlassWorm es el nombre que se le da a un Campaña de malware en curso que se ha infiltrado repetidamente en Microsoft Visual Studio Marketplace y Open VSX con extensiones maliciosas diseñadas para robar secretos y vaciar carteras de criptomonedas, y abusar de los sistemas infectados como servidores proxy para otras actividades delictivas.

Aunque Koi Security detectó por primera vez la actividad en octubre de 2025, los paquetes npm que utilizaban las mismas tácticas, en particular el uso de caracteres Unicode invisibles para ocultar código malicioso, fueron detectados. identificado ya en marzo de 2025.

La última versión conserva muchas de las características asociadas con GlassWorm: ejecutar comprobaciones para evitar infectar sistemas con una configuración regional rusa y usar transacciones de Solana como un solucionador de caídas para recuperar el servidor de comando y control (C2) para mejorar la resiliencia.

Pero el nuevo conjunto de extensiones también presenta una mayor ofuscación y rota las billeteras de Solana para evadir la detección, además de abusar de las relaciones de extensión para implementar cargas útiles maliciosas, de manera similar a cómo los paquetes npm dependen de dependencias no autorizadas para pasar desapercibidas. Independientemente de si una extensión está declarada como «extensionPack» o «extensionDependencies» en el archivo «package.json» de la extensión, el editor procede a instalar todas las demás extensiones enumeradas en él.

Al hacerlo, la campaña GlassWorm utiliza una extensión como instalador de otra extensión maliciosa. Esto también abre nuevos escenarios de ataque a la cadena de suministro, ya que un atacante primero carga una extensión VS Code completamente inofensiva en el mercado para eludir la revisión, después de lo cual se actualiza para incluir un paquete vinculado a GlassWorm como una dependencia.

«Como resultado, una extensión que parecía no transitiva y comparativamente benigna en la publicación inicial puede convertirse más tarde en un vehículo de entrega transitivo de GlassWorm sin ningún cambio en su propósito aparente», dijo Socket.

En un aviso simultáneo, Aikido atribuyó al actor de amenazas GlassWorm a una campaña masiva que se está extendiendo a través de repositorios de código abierto, en la que los atacantes inyectan varios repositorios con caracteres Unicode invisibles para codificar una carga útil. Si bien el contenido no es visible cuando se carga en editores de código y terminales, se decodifica en un cargador que es responsable de buscar y ejecutar un script de segunda etapa para robar tokens, credenciales y secretos.

Se estima que no menos de 151 repositorios de GitHub se vieron afectados como parte de la campaña entre el 3 y el 9 de marzo de 2026. Además, la misma técnica Unicode se implementó en dos paquetes npm diferentes, lo que indica un impulso coordinado y multiplataforma:

• @aifabrix/miso-cliente
• @iflow-mcp/watercrawl-watercrawl-mcp

«Las inyecciones maliciosas no llegan en confirmaciones evidentemente sospechosas», afirma el investigador de seguridad Ilyas Makari dicho. «Los cambios circundantes son realistas: ajustes en la documentación, mejoras en la versión, pequeñas refactorizaciones y correcciones de errores que son estilísticamente consistentes con cada proyecto objetivo. Este nivel de adaptación específica del proyecto sugiere fuertemente que los atacantes están usando grandes modelos de lenguaje para generar compromisos de cobertura convincentes».

¿PhantomRaven o experimento de investigación?

El desarrollo surge como Endor Labs. dicho Descubrió 88 nuevos paquetes npm maliciosos cargados en tres oleadas entre noviembre de 2025 y febrero de 2026 a través de 50 cuentas desechables. Los paquetes vienen con funcionalidad para robar información confidencial de la máquina comprometida, incluidas variables de entorno, tokens CI/CD y metadatos del sistema.

La actividad se destaca por el uso de dependencias dinámicas remotas (RDD), donde el archivo de metadatos «package.json» especifica una dependencia en una URL HTTP personalizada, lo que permite a los operadores modificar el código malicioso sobre la marcha, así como evitar la inspección.

Si bien los paquetes fueron identificados inicialmente como parte del PhantomRaven campañala empresa de seguridad de aplicaciones señaló en una actualización que fueron producidas por un investigador de seguridad como parte de un experimento legítimo, afirmación que cuestionó, citando tres señales de alerta. Esto incluye el hecho de que las bibliotecas recopilan mucha más información de la necesaria, no brindan transparencia al usuario y se publican mediante nombres de cuentas y direcciones de correo electrónico rotados deliberadamente.

A partir del 12 de marzo de 2026, el propietario de los paquetes realizó cambios adicionales, intercambiando la carga útil de recolección de datos entregada a través de algunos de los paquetes npm publicados durante el período de tres meses con un simple «¡Hola, mundo!» Mensaje.

«Si bien la eliminación del código que recopilaba información extensa es ciertamente bienvenida, también resalta los riesgos asociados con las dependencias de URL», dijo Endor Labs. «Cuando los paquetes dependen de código alojado fuera del registro npm, los autores conservan el control total sobre la carga útil sin publicar una nueva versión del paquete. Al modificar un solo archivo en el servidor – o simplemente cerrarlo – pueden cambiar o deshabilitar silenciosamente el comportamiento de cada paquete dependiente a la vez».

Un ciberataque que afirmó un grupo de hackers iraní se llevó a cabo contra el fabricante de dispositivos médicos Stryker podría marcar la primera acción cibernética significativa de Teherán desde el inicio del conflicto conjunto entre Estados Unidos e Israel.

Pero incluso eso puede haber sido un feliz accidente para los piratas informáticos iraníes en lo que ha sido un bajo nivel de actividad durante ese período de tiempo, con los atacantes obteniendo ganancias por casualidad y no a propósito.

Las empresas de ciberseguridad, los rastreadores de inteligencia de amenazas y los propietarios de infraestructuras críticas han estado luchando para separar el ruido sobre los ataques proclamados desde Irán y las advertencias y amenazas relacionadas con el conflicto, de lo que realmente está sucediendo y representa un peligro significativo.

“Todo el mundo está luchando en este momento”, dijo Alex Orleans, analista de amenazas de Irán desde hace mucho tiempo y jefe de inteligencia de amenazas de Sublime Security. Otros dijeron que la naturaleza incipiente del conflicto dificulta las evaluaciones.

«Lo que vemos es bastante difícil de cuantificar o caracterizar sobre si ha habido un aumento o una disminución», dijo Saher Naumaan, investigador senior de amenazas en Proofpoint. «Creo que como solo llevamos un par de semanas en el conflicto y la cadencia regular de los actores iraníes no es muy consistente, necesariamente no tenemos suficientes datos ni suficiente tiempo para juzgar realmente».

Signos de actividad

En los primeros días del conflicto, hubo indicios de que ataques fisicos sobre Irán podría haber obstaculizado los esfuerzos de represalia iraníes u otras actividades cibernéticas, ya que aquellos que llevarían a cabo ataques cibernéticos probablemente estaban «escondidos en búnkeres», dijo Orleans, y como Irán sufrió cortes de internet.

Sin embargo, en los últimos días, el ataque Stryker y otros indicadores sugieren que la actividad cibernética iraní podría estar calentándose.

«Durante varios días después del estallido del conflicto, se notó una disminución en la actividad de amenazas cibernéticas provenientes de Irán», dijo un grupo de centros de análisis e intercambio de información de la industria. advirtió el miércoles. «Sin embargo, hay señales de vida en las operaciones cibernéticas ofensivas iraníes».

El ataque de Stryker destaca tanto por el tamaño como por la ubicación del objetivo, un fabricante de dispositivos médicos con sede en Michigan con más de 25 mil millones de dólares en ingresos en 2025.

Pero tanto Orleans como Sergey Shykevich, gerente del grupo de inteligencia de amenazas en Check Point Research, dijeron que el ataque tiene las características de ser oportunista en lugar de uno deliberado y enfocado. El grupo que se atribuye el mérito del ataque, Handala, un equipo vinculado al Ministerio de Inteligencia, es más conocido por aprovechar las debilidades que encuentra en lugar de hacerlo. persiguiendo obstinadamente objetivos particulares.

En particular, Stryker también es la clase de vehículo militar utilizado por las fuerzas estadounidenses. Esa conexión militar, incluso si se confunde con el fabricante de dispositivos médicos, posiblemente podría explicar por qué la empresa era un objetivo.

Aún así, “fue un ataque de mucho mayor perfil de lo que esperábamos de Handala”, dijo Shykevich. «Desafortunadamente, se puede definir como un éxito relativamente grande para ellos».

Ha habido informes de otras actividades cibernéticas que podrían estar relacionadas con el conflicto. Albania dijo el sistema de correo electrónico de su parlamento había sido atacado, y los piratas informáticos iraníes se habían atribuido el mérito. Estaba el orientación de cámaras de infraestructura vinculada a Irán en países a los que Irán luego lanzó misiles. Polonia dijo que era mirando hacia si Irán estuvo detrás de un intento de ciberataque a una instalación de investigación nuclear.

Algunas de las afirmaciones no coinciden con la realidad. «Hay muchos grupos hacktivistas que son muy activos en Telegram, pero en realidad no tienen ningún éxito significativo», dijo Shykevich.

También hay otros acontecimientos relacionados con la cibernética en el conflicto, como el espionajela proliferación de desinformación impulsada por la inteligencia artificial y la posibilidad de que Rusia o China ayudando en el ciberespacio en nombre de Irán, incluso si algunos expertos dudan de la probabilidad de que esto último ocurra.

Aún no está claro qué tan efectivo ha sido todo esto. Stryker, por ejemplo, dijo el ataque afectó principalmente a sus redes internas, aunque había señales También podría estar afectando las comunicaciones en los hospitales.

Pero el daño podría no venir al caso. Orleans dijo que los ataques podrían ser de naturaleza psicológica, destinados a producir miedo en el extranjero y afirmar la posición de los piratas informáticos ante los líderes nacionales en Irán durante el conflicto.

Incluso la desfiguración de bajo nivel o los ataques distribuidos de denegación de servicio pueden influir.

“Llegar al trabajo y encontrar una bandera iraní en su estación de trabajo sería un poco desconcertante, porque le hacen saber que 'puedo extender la mano y tocarlo'”, dijo Sarah Cleveland, directora senior de estrategia federal en ExtraHop y ex oficial cibernética de la Fuerza Aérea de EE. UU.

Posibles impactos posteriores

Si bien se la conoce principalmente como una empresa de suministros médicos, Stryker ha recibido contratos importantes con el ejército para equipos hospitalarios y suministros quirúrgicos, por ejemplo. No está claro si los piratas informáticos pretendían utilizar la conexión militar de Stryker para explotar los sistemas gubernamentales.

El Pentágono tiene advertido durante mucho tiempo de ciberataques cada vez mayores y complejos contra la base industrial de defensa, una vasta red de empresas -con niveles dispares de ciberseguridad- de las que depende el ejército para obtener desde armamento avanzado hasta camillas básicas. El DIB es a menudo visto por los adversarios como puerta trasera a los sistemas militares.

Si bien no abordó directamente el hackeo de Stryker, el principal asesor cibernético del Ejército, Brandon Pugh, describió algunos de los desafíos que enfrenta el DIB y la parte del servicio al tratar de protegerlo durante un seminario web el jueves en respuesta a una pregunta sobre el tema.

Dijo que los adversarios, «con razón o sin ella», ven a las empresas «como una extensión del ejército» y creen que un ataque a la industria privada tendría un impacto secundario en las fuerzas armadas.

«Algunas son empresas multinacionales muy grandes y sofisticadas», dijo, señalando que las necesidades de seguridad en todo el DIB no son universales. «Otras son empresas muy pequeñas que tienen suerte de tener un director de TI, y mucho menos un equipo cibernético sofisticado, y creo que ahí es donde es realmente importante apoyarse».

Pugh dijo que agencias de todo el gobierno federal han estado trabajando con el DIB para aumentar su resistencia a los ataques, y que el esfuerzo cibernético del Ejército enfatiza afianzar la ciberseguridad desde el comienzo del proceso de adquisición.

«Lo cibernético no puede ser una ocurrencia tardía, no digo que lo sea», añadió Pugh. “Yo diría que el Ejército hace un gran trabajo aquí, pero asegurándose de que nunca se olvide y siempre se lo considere de esa manera”.

Matt Tait, director ejecutivo y presidente de MANTECH, dijo en respuesta a una pregunta sobre el ataque Stryker y las protecciones DIB que defenderse contra tales incidentes incluye aprovechar los acuerdos y el acceso gubernamentales, como con la NSA, y compartir información rápidamente después de un ataque.

«Para mí, se trata de compartir información en tiempo real», dijo. “Cuando te atacan, necesitas compartir información en tiempo real para poder compartir esa información con el resto de la industria, así como con el gobierno, porque ellos pueden compartir esa información entre” entidades federales de ciberseguridad.

«Si quieres realizar un trabajo tecnológico centrado en una misión, este es el mundo en el que tienes que vivir y deberías compartir esta información en tiempo real», añadió. «24 horas después, 48 ​​horas después, llamo a esa ambulancia que me persigue. Eso es demasiado posterior al hecho desde una perspectiva cibernética».

Los cazadores de amenazas y un grupo de víctimas no confirmadas están respondiendo a una serie de ataques dirigidos a clientes de Salesforce, que el proveedor reveló en un aviso de seguridad Sábado.

«Salesforce está monitoreando activamente la actividad de amenazas dirigida a sitios públicos de Experience Cloud, incluidos los intentos de aprovechar configuraciones de usuarios invitados demasiado permisivas», dijo la compañía en la alerta.

La campaña marca el tercer ataque generalizado dirigido a clientes de Salesforce en aproximadamente seis meses.

El número de víctimas atrapadas por los últimos ataques no está verificado, pero ShinyHunters, el grupo de amenazas que se atribuye la responsabilidad de los ataques, afirma que unas 100 empresas ya se han visto afectadas.

Los investigadores dijeron a CyberScoop que confían en que el grupo de amenazas detrás de la campaña está asociado con ShinyHunters, un equipo que anteriormente robó datos de instancias de Salesforce para intentos de extorsión.

Salesforce no atribuyó los ataques, pero culpó a un «grupo conocido de actores de amenazas», y agregó que el problema es no debido a una vulnerabilidad en la plataforma de la empresa.

La compañía dijo que la actividad de amenazas refleja una tendencia más amplia de ataques basados ​​en identidad, en este caso configuraciones de usuario invitado configuradas por el cliente que exponen los sitios de Experience Cloud de acceso público a posibles ataques.

«Somos conscientes de un actor de amenazas que intenta identificar configuraciones erróneas dentro de las instancias de Salesforce Experience Cloud», dijo en un comunicado Charles Carmakal, director de tecnología de Mandiant Consulting. «Estamos trabajando estrechamente con Salesforce y nuestros clientes para proporcionar las reglas de detección y telemetría necesarias para mitigar el riesgo potencial».

Salesforce dijo que el actor de amenazas está utilizando una versión modificada de la herramienta de código abierto desarrollada por Mandiant. AuraInspector para buscar sitios públicos de Experience Cloud y robar datos de instancias con un perfil de usuario invitado.

Esta configuración está diseñada para proporcionar a los usuarios no autenticados acceso a datos destinados al consumo público. Sin embargo, los perfiles de invitados con permisos excesivos permiten a los atacantes ver datos adicionales consultando directamente los objetos de Salesforce CRM sin iniciar sesión, explicó la compañía.

Salesforce no dijo cuándo ni cómo se enteró de la última campaña dirigida a sus clientes, ni cuántas empresas ya se han visto afectadas. «No tenemos nada más que agregar en este momento», dijo Nicole Aranda, gerente senior de comunicaciones corporativas de Salesforce.

La empresa recomendó a los clientes que se aseguren de que las configuraciones de los usuarios invitados estén restringidas adecuadamente.

«Cualquier sistema expuesto a Internet debe configurarse con la expectativa de que será escaneado continuamente», dijo en un correo electrónico Shane Barney, director de seguridad de la información de Keeper Security.

“En esencia, se trata de una cuestión de gobernanza del acceso”, añadió. «Las cuentas de invitado, las cuentas de servicio y las integraciones de API deben tratarse con la misma disciplina que los usuarios privilegiados. Aplicar privilegios mínimos, restringir el acceso a la API y auditar continuamente los permisos son controles de seguridad fundamentales».

Los clientes de Salesforce se enfrentaron a un par de ataques que involucraron a proveedores externos el año pasado. Google Threat Intelligence Group dijo en ese momento que tenía conocimiento de más de 200 instancias de Salesforce potencialmente afectadas vinculadas a actividad maliciosa en aplicaciones Gainsight conectadas a entornos de clientes de Salesforce en noviembre.

Una ola de ataques posteriores más extensa descubierta en agosto afectó a más de 700 empresas que integraron el agente de chat de IA Salesloft Drift en sus entornos de Salesforce. ShinyHunters o grupos de amenazas afiliados al grupo de extorsión también participaron en ambas campañas.

Un actor de amenazas conocido como UNC6426 claves apalancadas robadas tras el compromiso de la cadena de suministro del paquete nx npm el año pasado para violar completamente el entorno de nube de una víctima en un lapso de 72 horas.

El ataque comenzó con el robo del token GitHub de un desarrollador, que luego el actor de la amenaza utilizó para obtener acceso no autorizado a la nube y robar datos.

«El actor de amenazas, UNC6426, luego utilizó este acceso para abusar de la confianza de GitHub-to-AWS OpenID Connect (OIDC) y crear una nueva función de administrador en el entorno de la nube», Google dicho en su Informe Cloud Threat Horizons para el primer semestre de 2026. «Abusaron de esta función para exfiltrar archivos de los depósitos del Servicio de almacenamiento simple (S3) de Amazon Web Services (AWS) del cliente y realizaron la destrucción de datos en sus entornos de producción en la nube».

El ataque a la cadena de suministro dirigido al paquete nx npm tuvo lugar en agosto de 2025, cuando actores de amenazas desconocidos explotaron un flujo de trabajo vulnerable pull_request_target, un ataque tipo referido como Solicitud de Pwn – para obtener privilegios elevados y acceder a datos confidenciales, incluido un GITHUB_TOKEN, y, en última instancia, enviar versiones troyanizadas del paquete al registro npm.

Se descubrió que los paquetes incorporaban un script de postinstalación que, a su vez, lanzaba un Ladrón de credenciales de JavaScript llamado QUIETVAULT para desviar variables de entorno, información del sistema y tokens valiosos, incluidos los tokens de acceso personal (PAT) de GitHub, utilizando como arma una herramienta de modelo de lenguaje grande (LLM) ya instalada en el punto final para realizar la búsqueda. Los datos se cargaron en un repositorio público de GitHub llamado «/s1ngularity-repository-1».

Google dijo que un empleado de la organización víctima ejecutó una aplicación de edición de código que usaba el complemento Nx Console, lo que provocó una actualización en el proceso y resultó en la ejecución de QUIETVAULT.

Se dice que UNC6426 inició actividades de reconocimiento dentro del entorno GitHub del cliente utilizando el PAT robado dos días después del compromiso inicial utilizando una herramienta legítima de código abierto llamada Corriente del Norte para extraer secretos de entornos CI/CD, filtrando las credenciales de una cuenta de servicio de GitHub.

Posteriormente, los atacantes aprovecharon esta cuenta de servicio y utilizaron el parámetro «–aws-role» de la utilidad para generar tokens temporales de AWS Security Token Service (STS) para el rol «Actions-CloudFormation» y, en última instancia, permitirles obtener un punto de apoyo en el entorno AWS de la víctima.

«La función comprometida Github-Actions-CloudFormation era demasiado permisiva», dijo Google. «UNC6426 utilizó este permiso para implementar una nueva pila de AWS con capacidades [«CAPABILITY_NAMED_IAM»,»CAPABILITY_IAM»]. El único propósito de esta pila era crear una nueva función de IAM y adjuntarle la política arn:aws:iam::aws:policy/AdministratorAccess. UNC6426 pasó con éxito de un token robado a permisos completos de administrador de AWS en menos de 72 horas».

Armado con los nuevos roles de administrador, el actor de amenazas llevó a cabo una serie de acciones, incluida la enumeración y el acceso a objetos dentro de los depósitos de S3, la finalización de instancias de producción de Elastic Compute Cloud (EC2) y Relational Database Service (RDS), y descifrado de claves de aplicaciones. En la etapa final, todos los repositorios internos de GitHub de la víctima pasaron a llamarse «/s1ngularity-repository-[randomcharacters]» y hecho público.

Para contrarrestar tales amenazas, se recomienda utilizar administradores de paquetes que impidan scripts posteriores a la instalación o herramientas de sandboxing, aplicar el principio de privilegio mínimo (PoLP) a las cuentas de servicio de CI/CD y roles vinculados a OIDC, aplicar PAT detalladas con ventanas de vencimiento cortas y permisos de repositorio específicos, eliminar privilegios permanentes para acciones de alto riesgo como la creación de roles de administrador, monitorear actividades anómalas de IAM e implementar controles sólidos para detectar riesgos de Shadow AI.

El incidente destaca un caso de lo que Socket ha descrito como un abuso de la cadena de suministro asistido por IA, donde la ejecución se descarga a agentes de IA que ya tienen acceso privilegiado al sistema de archivos, las credenciales y las herramientas autenticadas del desarrollador.

«La intención maliciosa se expresa en mensajes en lenguaje natural en lugar de devoluciones de llamadas de red explícitas o puntos finales codificados, lo que complica los enfoques de detección convencionales», dijo la firma de seguridad de la cadena de suministro de software. dicho. «A medida que los asistentes de IA se integran más en los flujos de trabajo de los desarrolladores, también amplían la superficie de ataque. Cualquier herramienta capaz de invocarlos hereda su alcance».

No se puede controlar cuándo cae la próxima vulnerabilidad crítica. Puede controlar qué parte de su entorno está expuesto cuando lo hace. El problema es que la mayoría de los equipos tienen más exposición a Internet de lo que creen. del intruso El Jefe de Seguridad profundiza en por qué sucede esto y cómo los equipos pueden gestionarlo deliberadamente.

El tiempo de explotación se está reduciendo

Cuanto mayor y menos controlada sea su superficie de ataque, más oportunidades existirán de explotación. Y la ventana para actuar en consecuencia se está reduciendo rápidamente. Para las vulnerabilidades más graves, la divulgación para la explotación puede durar tan solo 24 a 48 horas. Reloj de día cero proyectos cuyo tiempo de explotación será de solo unos minutos para 2028.

No es mucho tiempo si se considera lo que debe suceder antes de implementar un parche: ejecutar análisis, esperar resultados, generar tickets, acordar prioridades, implementar y verificar la solución. Si la divulgación llega fuera de horario, lleva aún más tiempo.

En muchos casos, los sistemas vulnerables no necesitan estar conectados a Internet en primer lugar. Con visibilidad de la superficie de ataque, los equipos pueden reducir la exposición innecesaria desde el principio y evitar la confusión cuando surge una nueva vulnerabilidad.

Cuando un día cero cae en sábado

Shell de herramientas era una vulnerabilidad de ejecución remota de código no autenticado en Microsoft SharePoint. Si un atacante pudiera alcanzarlo, podría ejecutar código en su servidor y, como SharePoint está conectado a Active Directory, comenzaría en una parte altamente confidencial de su entorno.

Se trataba de un día cero, lo que significa que los atacantes lo estaban explotando antes de que estuviera disponible un parche. Microsoft lo reveló un sábado y confirmó que grupos patrocinados por el estado chino lo habían estado explotando durante hasta dos semanas antes. Cuando la mayoría de los equipos se enteraron, los atacantes oportunistas buscaban instancias expuestas y las explotaban a escala.

La investigación de Intruder encontró miles de instancias de SharePoint de acceso público en el momento de la divulgación, a pesar de que SharePoint no necesita estar conectado a Internet. Cada una de esas exposiciones fue innecesaria y cada servidor sin parches fue una puerta abierta.

Por qué se pasan por alto las exposiciones

Entonces, ¿por qué los equipos de seguridad suelen pasar por alto las exposiciones?

En un análisis externo típico, los hallazgos informativos se encuentran debajo de cientos de críticas, altibajos y altibajos. Pero esa información puede incluir detecciones que representen un riesgo de exposición real, como:

• Un servidor SharePoint expuesto
• Una base de datos expuesta a Internet, como MySQL o Postgres.
• Otros protocolos, que normalmente deberían reservarse para la red interna, como RDP y SNMP

Aquí hay un ejemplo real de cómo se ve:

En términos de escaneo de vulnerabilidades, a veces tiene sentido clasificarlos como informativos. Si el escáner se encuentra en la misma subred privada que los objetivos, un servicio expuesto podría realmente ser de bajo riesgo. Pero cuando ese mismo servicio está expuesto a Internet, conlleva un riesgo real incluso sin una vulnerabilidad conocida asociada. Todavía.

El peligro es que los informes de análisis tradicionales tratan ambos casos de la misma manera, por lo que los riesgos reales se escapan de las lagunas.

¿Qué implica realmente la reducción proactiva de la superficie de ataque?

Hay tres elementos clave para que la reducción de la superficie de ataque funcione en la práctica.

1. Descubrimiento de activos: defina su superficie de ataque

Antes de poder reducir su superficie de ataque, necesita una imagen clara de lo que posee y de lo que es accesible externamente. Eso comienza con la identificación de la TI en la sombra: sistemas que su organización posee u opera pero que actualmente no está escaneando ni monitoreando.

Cerrar esa brecha es importante y hay tres elementos clave que recomendamos implementar:

1. Integración con sus proveedores de nube y DNS para que cuando se cree una nueva infraestructura, se recoja y analice automáticamente. Esta es un área donde los defensores tienen una ventaja genuina: puedes integrarte directamente con tus propios entornos, los atacantes no.
2. Usando la enumeración de subdominios para mostrar hosts accesibles externamente que no están en su inventario. Esto es importante especialmente después de adquisiciones, en las que es posible que esté heredando una infraestructura de la que aún no tiene visibilidad.
3. Identificación de infraestructura alojada con proveedores de nube más pequeños y desconocidos. Es posible que tenga una política de seguridad que obligue a los equipos de desarrollo a utilizar solo su proveedor de nube principal, pero debe verificar que se sigan las prácticas.

Vea una inmersión profunda en estas técnicas:

. Trate la exposición como riesgo

El siguiente paso es tratar la exposición de la superficie de ataque como una categoría de riesgo en sí misma.

Eso requiere un capacidad de detección que identifica qué hallazgos informativos representan una exposición y asigna la gravedad adecuada. Una instancia de SharePoint expuesta, por ejemplo, podría razonablemente tratarse como un problema de riesgo medio.

También significa crear espacio para este trabajo en como priorizas. Si los esfuerzos estratégicos como la reducción de la superficie de ataque siempre compiten con los parches urgentes, siempre perderán. Eso podría significar reservar tiempo cada trimestre para revisar y reducir la exposición, o asignar una propiedad clara para que alguien sea responsable de ello, no sólo cuando ocurre una crisis, sino de forma rutinaria.

3. Monitoreo continuo

La reducción de la superficie de ataque no es un ejercicio de una sola vez. La exposición cambia constantemente (se edita una regla de firewall, se implementa un nuevo servicio, se olvida un subdominio) y su equipo necesita detectar esos cambios rápidamente.

Los análisis de vulnerabilidades tardan en completarse y, por lo general, no es posible ejecutar análisis completos diariamente. Escaneo diario de puertos es una mejor opción. Es liviano, rápido y significa que puede detectar servicios recientemente expuestos a medida que aparecen. Si alguien edita una regla de firewall y accidentalmente expone Escritorio remoto, usted se enterará el día en que sucede, no en el siguiente análisis programado, que podría realizarse hasta un mes después.

Menos servicios expuestos, menos sorpresas

Cuando los servicios innecesarios no se exponen en primer lugar, es mucho menos probable que queden atrapados en la explotación masiva que sigue a una divulgación crítica. Eso significa menos sorpresas, menos luchas urgentes y más tiempo para responder deliberadamente cuando surgen nuevas vulnerabilidades.

Intruder automatiza este proceso, desde descubrir TI en la sombra y monitorear nuevas exposiciones, hasta alertar a su equipo en el momento en que algo cambia, para que su equipo de seguridad pueda anticiparse a la exposición en lugar de reaccionar ante ella.

Si quieres ver lo que está expuesto en tu entorno, reservar una demostración de Intruder.

Un kit de explotación que puede haberse originado a partir de un marco de trabajo filtrado del gobierno de EE. UU. está detrás de lo que los investigadores llaman el primer ataque a gran escala contra iOS, el sistema operativo de los iPhone de Apple.

Rastros de los exploits, encontrados en el trabajo de ciberdelincuentes chinos, también han sido detectados en ataques rusos a Ucrania y utilizados por un cliente de un proveedor de software espía.

Esas conclusiones provienen de dos investigaciones que Grupo de inteligencia sobre amenazas de Google y iVerificar publicado por separado el martes. Rocky Cole, cofundador de iVerify, dijo que representaba un potencial “momento EternalBlue”, con ecos de ese software de explotación que escapó de la Agencia de Seguridad Nacional para alimentar el ransomware global WannaCry y los ataques NotPetya en 2017.

Google dijo que el llamado kit de exploits Coruña que es el tema de la investigación del martes «proporciona otro ejemplo de cómo proliferan las capacidades sofisticadas», como escribió en una publicación de blog sobre los exploits de día cero, o no divulgados ni parcheados previamente.

«No está claro cómo se produjo esta proliferación, pero sugiere un mercado activo para exploits de día cero de 'segunda mano'», escribió Google. «Más allá de estos exploits identificados, múltiples actores de amenazas han adquirido técnicas de explotación avanzadas que pueden reutilizarse y modificarse con vulnerabilidades recientemente identificadas».

Dijo iVerify: «Si bien iVerify tiene alguna evidencia de que esta herramienta es un marco del gobierno de EE. UU. filtrado, eso no debería eclipsar el conocimiento de que estas herramientas encontrarán su camino hacia la naturaleza y serán utilizadas sin escrúpulos por malos actores».

La semana pasada, un tribunal estadounidense condenó a prisión a un ex ejecutivo de L3 Harris por vender exploits de día cero a un corredor ruso.

Tanto Google como iVerify conectaron el kit de exploits a la Operación Triangulación, que según la firma rusa de ciberseguridad Kaspersky en 2023 había apuntado a la compañía y al gobierno ruso atribuido al gobierno de Estados Unidos. La NSA se negó a comentar sobre esa acusación.

Un portavoz de Apple no respondió a una solicitud de comentarios el martes por la tarde. Apple emitió varios parches en respuesta a la Operación Triangulación y trabajó con Google en la investigación más reciente.

Spencer Parker, director de productos de iVerify, dijo que el ataque afectó al menos a 42.000 dispositivos, una «cifra enorme» para iOS, aunque parezca pequeña para otras plataformas. Ese número tiene el potencial de expandirse a medida que los investigadores profundicen en los detalles técnicos, dijo Cole.

Otras señales apuntan al desarrollo del kit de exploits en Estados Unidos, dijo Cole.

«La base del código para el marco y los exploits fue excelente», dijo. «Estaba escrito con elegancia. Es fluido y se mantiene muy bien. Había comentarios en el código que, como alguien que ha estado en la base industrial de defensa de EE. UU. durante años, realmente recuerdan el tipo de bromas y comentarios internos que podrías ver de un codificador con sede en EE. UU. Sin duda, eran hablantes nativos de inglés».

Google dijo que rastreó el uso del kit de explotación a lo largo del año pasado en operaciones desde un cliente anónimo de un proveedor de vigilancia hasta ataques a usuarios ucranianos por parte de un presunto grupo de espionaje ruso, antes de recuperar el kit de explotación completo de un grupo con motivación financiera que opera desde China.

El investigador de seguridad de Apple, Patrick Wardle, observó en el sitio de redes sociales X sobre la investigación de Coruña: «Resulta que incluso los ciberdelincuentes más humildes estaban (ab)usando 0days para piratear dispositivos Apple».

Investigadores de ciberseguridad han revelado detalles de un nuevo cargador de botnet llamado Aeternum C2 que utiliza una infraestructura de comando y control (C2) basada en blockchain para hacerlo resistente a los esfuerzos de eliminación.

«En lugar de depender de servidores o dominios tradicionales para el comando y control, Aeternum almacena sus instrucciones en la cadena de bloques pública Polygon», Qrator Labs dicho en un informe compartido con The Hacker News.

«Esta red es ampliamente utilizada por aplicaciones descentralizadas, incluido Polymarket, el mercado de predicción más grande del mundo. Este enfoque hace que la infraestructura C2 de Aeternum sea efectivamente permanente y resistente a los métodos tradicionales de eliminación».

Esta no es la primera vez que se descubre que botnets dependen de blockchain para C2. En 2021, Google dijo que tomó medidas para interrumpir una botnet conocida como Glupteba que utiliza la cadena de bloques de Bitcoin como mecanismo C2 de respaldo para recuperar la dirección real del servidor C2.

Los detalles de Aeternum C2 surgieron por primera vez en diciembre de 2025, cuando KrakenLabs de Outpost24 reveló que un actor de amenazas llamado LenAI estaba anunciando el malware en foros clandestinos por 200 dólares que otorga a los clientes acceso a un panel y una compilación configurada. Por 4.000 dólares, supuestamente a los clientes se les prometió todo el código base de C++ junto con las actualizaciones.

El malware, un cargador nativo de C++ disponible en versiones x32 y x64, funciona escribiendo comandos que se emiten al host infectado en contratos inteligentes en la cadena de bloques Polygon. Luego, los bots leen esos comandos consultando puntos finales públicos de llamada a procedimiento remoto (RPC).

Todo esto se gestiona a través del panel web, desde donde los clientes pueden seleccionar un contrato inteligente, elegir un tipo de comando, especificar una URL de carga útil y actualizarla. El comando, que puede apuntar a todos los puntos finales o a uno específico, se escribe en la cadena de bloques como una transacción, después de lo cual queda disponible para todos los dispositivos comprometidos que estén sondeando la red.

«Una vez que se confirma un comando, nadie más que el titular de la billetera no puede modificarlo ni eliminarlo», dijo Qrator Labs. «El operador puede gestionar múltiples contratos inteligentes simultáneamente, cada uno de los cuales potencialmente cumple una carga útil o función diferente, como un clipper, un ladrón, un RAT o un minero».

Según un investigación en dos partes publicado por Ctrl Alt Intel A principios de este mes, el panel C2 se implementó como una aplicación web Next.js que permite a los operadores implementar contratos inteligentes en la cadena de bloques Polygon. Los contratos inteligentes contienen una función que, cuando el malware la llama a través de Polygon RPC, hace que devuelva el comando cifrado que posteriormente se decodifica y se ejecuta en las máquinas víctimas.

Además de utilizar blockchain para convertirla en una botnet resistente a la eliminación, el malware incluye varias funciones antianálisis para extender la vida útil de las infecciones. Esto incluye comprobaciones para detectar entornos virtualizados, además de equipar a los clientes con la capacidad de escanear sus compilaciones a través de Kleenscan para garantizar que no sean marcados por los proveedores de antivirus.

«Los costes operativos son insignificantes: 1 dólar en MATIC, el token nativo de la red Polygon, es suficiente para entre 100 y 150 transacciones de comando», dijo el proveedor checo de ciberseguridad. «El operador no necesita alquilar servidores, registrar dominios ni mantener ninguna infraestructura más allá de una billetera criptográfica y una copia local del panel».

El actor de amenazas ha desde entonces intentó vender todo el kit de herramientas por un precio inicial de 10.000 dólares, alegando falta de tiempo para recibir apoyo y su participación en otro proyecto. «Venderé todo el proyecto a una persona con permiso para reventa y uso comercial, con todos los ‘derechos’», dijo LenAI. «También daré consejos/notas útiles sobre el desarrollo que no tuve tiempo de implementar».

Vale la pena señalar que LenAI también está detrás de una segunda solución de crimeware llamada ErrTraffic que permite a los actores de amenazas automatizar los ataques ClickFix generando fallos falsos en sitios web comprometidos para inducir una falsa sensación de urgencia y engañar a los usuarios para que sigan instrucciones maliciosas.

La divulgación se produce cuando Infrawatch publicó detalles de un servicio clandestino que implementa hardware de computadoras portátiles dedicado en hogares estadounidenses para incorporar los dispositivos a una red proxy residencial llamada DSLRoot que redirige el tráfico malicioso a través de ellos.

El hardware está diseñado para ejecutar un programa basado en Delphi llamado DSLPylon que está equipado con capacidades para enumerar módems compatibles en la red, así como para controlar de forma remota el equipo de red residencial y los dispositivos Android a través de una integración de Android Debug Bridge (ADB).

«El análisis de atribución identifica al operador como un ciudadano bielorruso con presencia residencial en Minsk y Moscú», Infrawatch dicho. «Se estima que DSLRoot opera aproximadamente 300 dispositivos de hardware activos en más de 20 estados de EE. UU.».

El operador ha sido identificado como Andrei Holas (también conocido como Andre Holas y Andrei Golas), con el servicio promocionado en BlackHatWorld por un usuario que opera bajo el alias GlobalSolutions, afirmando ofrecer proxies ADSL residenciales físicos a la venta por $190 por mes para acceso sin restricciones. También está disponible por $990 por seis meses y $1,750 por suscripciones anuales.

«El software personalizado de DSLRoot proporciona gestión remota automatizada de módems de consumo (ARRIS/Motorola, Belkin, D-Link, ASUS) y dispositivos Android a través de ADB, lo que permite la rotación de direcciones IP y el control de la conectividad», señaló la empresa. «La red opera sin autenticación, lo que permite a los clientes enrutar el tráfico de forma anónima a través de IP residenciales de EE. UU.».