¿La solución de Google a la confusión de nombres de los piratas informáticos? Otro sistema de nombres más

Si es CISO, aquí hay un nuevo problema para la pila: ¿Me preocupo más por Sandworm Relic o Strawberry Tempest?

La semana pasada, el grupo de inteligencia sobre amenazas de Google se unió a una lista de rivales al cambiar la forma en que nombra a los piratas informáticos, reemplazando años de sistemas de nombres divididos con un único conjunto de nombres en clave construidos alrededor de pares de palabras memorables.

La compañía dijo en una publicación de blog que el cambio fusiona dos sistemas que se habían separado durante años dentro de Google: Mandiant, la firma de seguridad que Google compró en 2022, y su grupo interno de análisis de amenazas. La combinación de esas unidades dejó a Google con nombres superpuestos para los mismos grupos de hackers, un problema que el nuevo sistema pretende solucionar.

«El seguimiento de amenazas no debería ser un ejercicio de memorización, sino más bien de intuición», se lee en la publicación.

Cada grupo rastreado ahora recibirá un nombre de dos palabras. La primera palabra es un término distinto que pretende ser fácil de recordar, a menudo extraído de nombres ya utilizados en informes anteriores sobre un grupo específico. Cuando no exista tal nombre, los investigadores generarán uno al azar y harán que los analistas lo verifiquen antes de usarlo. La segunda palabra clasifica cada grupo por categoría, como país de origen o motivo. En los ejemplos publicados por Google, CASTLE se empareja con grupos vinculados a China, ION con Irán, NEPTUNE con Corea del Norte, RELIC con Rusia y COMET con actores de amenazas con motivación financiera no vinculados a un estado-nación.

El enfoque se hace eco de uno por el que CrowdStrike es conocido desde hace mucho tiempo. CrowdStrike combina un término específico con un animal vinculado a un país o motivo: PANDA para China, BEAR para Rusia, SPIDER para ciberdelincuentes, JACKAL para hacktivistas. El sistema de Google cambia los animales por palabras como CASTILLO y NEPTUNO, pero sigue la misma estructura básica, hasta el argumento de por qué funciona: un nombre de dos partes contiene más información que una simple etiqueta de país o un número, y puede cambiar a medida que se afina la atribución.

Microsoft tomó su propio turno en una revisión de nombres en abril de 2023, abandonando un sistema basado en elementos químicos, árboles y volcanes en favor de términos climáticos. Bajo ese sistema, Typhoon marcó a China, Blizzard marcó a Rusia, Sandstorm marcó a Irán y Tempest marcó a los ciberdelincuentes con motivaciones financieras. El cambio produjo nombres que llamaron tanto la atención por su sonido como por su sustancia, entre ellos Strawberry Tempest, Pumpkin Sandstorm y Pistachio Tempest. Los expertos de la industria se enojaron por el cambio, diciendo que los nombres comparaban los grupos con sabores de helado o cócteles.

Para 2025, la expansión de nombres de la industria se había convertido en un dolor de cabeza compartido suficiente como para que dos de los actores más importantes acordaran intentar solucionarlo juntos. Microsoft y CrowdStrike anunciaron un esfuerzo de mapeo conjunto en junio de ese año, combinando los nombres del clima de Microsoft con los nombres de animales de CrowdStrike para los mismos grupos rastreados, con Google, Mandiant y Palo Alto Networks Unit 42 también firmando para contribuir. Ambas compañías tuvieron cuidado de decir que el proyecto no era un intento de obligar a la industria a adoptar un solo sistema de nombres, solo para hacer que los existentes fueran más fáciles de traducir.

El lanzamiento de Google comienza con varias docenas de los grupos de hackers más activamente rastreados, y con el tiempo seguirán más. Los nombres más antiguos seguirán siendo buscables dentro de la plataforma de inteligencia de amenazas de Google, junto con asignaciones al marco MITRE ATT&CK y a los sistemas de nombres utilizados por otros proveedores.

La compañía dice que los grupos seguirán usando «UNC», por no categorizado, si aún es demasiado pronto para identificar exactamente dónde encaja un grupo en esta taxonomía.

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

La falla en el intercambio de tokens n8n podría permitir a los atacantes iniciar sesión como usuarios de otro emisor – CYBERDEFENSA.MX

n8n, la plataforma de automatización del flujo de trabajo, entregó las cuentas equivocadas al iniciar sesión. En instancias empresariales configuradas para confiar en más de un emisor de token externo, hizo coincidir un JWT entrante con un usuario local en el sub reclamo solo e ignorado iss.

Un token válido del emisor A que lleva un sub que pertenece a alguien del emisor B, inició sesión como esa persona. Su contraseña nunca apareció. n8n envió la solución el 24 de junio.

El defecto se rastrea como CVE-2026-59208. El registro CVE no se hizo público hasta el 9 de julio. n8n acredita el informe a la cuenta de GitHub ososyankeescuyo perfil incluye a Strix, que fabrica un agente de pruebas de penetración de IA.

estrix dice Señaló que el agente en el flujo de intercambio de tokens encontró el error de vinculación de identidad allí.

Dos emisores, una cuenta

El intercambio de tokens es la ruta empresarial de n8n para Socios OEM que integran el productoun Implementación de RFC 8693 eso ahorra a sus usuarios una segunda pantalla de inicio de sesión.

El socio firma un JWT de corta duración con su propia clave, n8n lo verifica con una clave pública configurada, hace coincidir los reclamos con una cuenta local y el usuario está dentro. Las claves confiables entran N8N_TOKEN_EXCHANGE_TRUSTED_KEYSy el documentos de implementación aún etiquete la función como vista previa.

Ciberseguridad

El token en sí se verifica. La coincidencia es el error. A sub Solo se garantiza que el valor será único dentro del emisor que lo acuñó. RFC 7519 pide que «tenga un alcance para ser localmente único en el contexto del emisor» o globalmente único. El identificador de un usuario es, por tanto, el par, iss más sub.

n8n codificado en la mitad. Nada impide que dos emisores emitan la misma cadena de asunto y, cuando lo hacen, ambos aterrizan en una cuenta n8n.

¿Qué tan importante es esto?

La falla alcanza una instancia solo si el intercambio de tokens está activado y la configuración confía en al menos dos emisores externos. n8n dice nada más se ve afectado. El intercambio de tokens es solo empresarial y todavía está marcado como una vista previa, por lo que el conjunto expuesto es pequeño y específico: implementaciones OEM, donde confiar en un segundo emisor es una configuración admitida.

Lo que el aviso no especifica es cómo un atacante obtiene el token. Sólo dice que pueden obtener uno. La cuestión práctica es si un usuario normal de un emisor de confianza puede influir en la sub ellos reciben. El registro público no lo contesta. El vector CVSS 4.0 de GitHub marca los requisitos de ataque como presentes y se detiene allí.

GitHub asignó ese vector. Como aquí la CNA pone CVE-2026-59208 a 7.6 en CVSS 4.0, alto. NVD coloca el mismo error en 6.8 en CVSS 3.1, medio, y no ha emitido ninguna evaluación de 4.0; su registro lleva CWE-287 y CWE-346. La evaluación SSVC de CISA del 13 de julio registra ninguna explotación, y The Hacker News no encontró ninguna prueba pública de concepto en las búsquedas del 16 de julio.

Dos semanas antes de la corrección del 24 de junio, los mantenedores parchearon CVE-2026-54305otro defecto exclusivo de Enterprise. Permite que cualquier usuario autenticado sobrescriba o revoque los tokens OAuth almacenados de otro usuario a través de los puntos finales de Credenciales dinámicas. Ése era un control de propiedad faltante, no una vinculación de identidad. Bicho diferente, misma superficie.

Ciberseguridad

The Hacker News se ha puesto en contacto con n8n para obtener confirmación sobre el alcance y el impacto de CVE-2026-59208 y actualizará esta historia con cualquier respuesta.

Parchear o cortar la lista de emisores

CVE-2026-59208 afecta a todas las versiones de n8n inferiores a 2.27.4 y 2.28.0. La solución llegó por primera vez a 2.27.4 y 2.28.1. Esos son el piso. El 16 de julio, el paquete npm de n8n llevaba la versión 2.30.6 en ambos latest y stable etiquetas. Envía un nuevo menor la mayoría de las semanas por su propia cuenta, así que verifique la etiqueta y tome la versión estable más nueva que admita su implementación.

Si la aplicación de parches tiene que esperar, averigüe qué está ejecutando: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS contiene las claves de firma confiables y un indicador de vista previa independiente controla si el intercambio de tokens está activado. Vuelva a centrarse en un único emisor de confianza o desactive la función.

El aviso llama a ambas medidas a corto plazo y dice que ninguna remedia completamente el riesgo. Esto es un texto repetitivo, idéntico en al menos otros tres avisos de n8n, incluido el del 10 de junio. Según la propia declaración de alcance de n8n, una instancia con intercambio de token desactivado no se ve afectada.

Ninguna nota de la versión menciona la solución. The Hacker News comprobó ambos: entre ellos, el 2.27.4 y 2.28.1 Los registros de cambios cubren una corrección de importación de Python, una actualización de un nodo de Google Ads, una verificación del flujo de trabajo de IA y un cambio en la creación de nodos, y nada sobre la identidad.

El aviso es donde éste vive. Si sus decisiones de actualización se basan en registros de cambios, este es el tipo de solución que pasa desapercibida.

Los investigadores detectan la explotación de otro defecto crítico de Oracle

Un ciberdelincuente aprovechó el sábado un defecto crítico en la función de procesamiento de pagos de Oracle E-Business Suite que podría marcar las primeras etapas de una campaña potencialmente más amplia, dijeron investigadores.

Defused, una empresa de inteligencia sobre amenazas, detectó seis casos de explotación durante un período de dos horas en sus honeypots, o señuelos diseñados para monitorear la actividad maliciosa en entornos que no son de producción, dijo a CyberScoop Simo Kohonen, fundador y director ejecutivo de la compañía.

Oráculo revelado y parcheado la vulnerabilidad, que se rastrea como CVE-2026-46817 con una calificación de gravedad de 9,8, a finales de mayo y advirtió que la complejidad de la explotación es baja.

Kohonen dijo que los exploits se atribuyeron a una única dirección IP y ocurrieron antes de que cualquier prueba de concepto estuviera disponible públicamente.

«Con solo una IP y un día de datos, se parece más a un reconocimiento y pruebas de armamento que a una campaña dirigida contra una víctima específica», añadió.

La posible expansión de la actividad maliciosa en redes activas podría ser significativa. Se encontraron escaneos de Shadowserver alrededor de 950 instancias potencialmente vulnerables de Oracle E-Business Suite el miércoles, y más de la mitad de esas implementaciones expuestas públicamente se encuentran en los Estados Unidos.

El defecto afecta a una colección popular de aplicaciones empresariales que los atacantes han atacado antes en ataques generalizados.

El famoso grupo de ransomware Clop intentó extorsionar a docenas de víctimas después de explotar un día cero y otras vulnerabilidades en Oracle E-Business Suite el año pasado. La agresiva campaña de extorsión comenzó en octubre, aproximadamente dos meses después de que Clop explotara el defecto y robara datos en masa.

Los clientes de Oracle se vieron afectados más recientemente por una vulnerabilidad de día cero explotada activamente en PeopleSoft, que incluye más de 40 herramientas para la gestión de recursos humanos y relaciones con los clientes.

ShinyHunters, el grupo detrás de esa ola de ataques que se remonta a finales de mayo, potencialmente se infiltró en las redes de más de 100 organizaciones, principalmente en educación superior, según Mandiant y Google Threat Intelligence Group.

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.

Los clientes de Cisco se encuentran con otro ataque de día cero a SD-WAN

Los clientes de Cisco se enfrentan a otra vulnerabilidad de día cero explotada activamente que afecta al software de gestión SD-WAN del proveedor, lo que refuerza la presión sobre las organizaciones que han experimentado raras interrupciones de amenazas activas este año.

La vulnerabilidad CVE-2026-20245 – marca el séptimo día cero explotado activamente en Cisco SD-WAN este año.

Cisco dijo que se enteró por primera vez de la explotación activa del último defecto en el software de gestión de red a principios de este mes. La compañía reveló la vulnerabilidad, que fue detectada por primera vez por Mandiant, el jueves y advirtió que aún no hay un parche de seguridad disponible y que, mientras tanto, no hay soluciones para mitigar el defecto.

«En el futuro se proporcionará un parche para esta vulnerabilidad», dijo un portavoz de la compañía en un comunicado.

Cisco no atribuyó los ataques a ningún grupo específico, no describió los objetivos de esos ataques ni compartió cuántas organizaciones ya se han visto afectadas.

El defecto de error de validación que afecta a Cisco Catalyst SD-WAN Manager permite a atacantes autenticados o locales ejecutar comandos como root, lo que resulta en ataques de inyección de comandos en un sistema afectado, dijo la compañía.

Sin embargo, el alcance del impacto potencial puede ser limitado porque la explotación requiere credenciales válidas o acceso privilegiado a través de otros medios. Cisco dijo que la explotación de un par de días cero que reveló a principios de este año: CVE-2026-20182 o CVE-2026-20127 – podría permitir a los atacantes el acceso necesario para explotar la nueva vulnerabilidad.

La compañía dijo que «no tiene conocimiento de una explotación exitosa por otros medios», y agregó que «observó casos limitados en los que la explotación de este error resultó en un cambio de configuración llevado a los dispositivos de borde».

Landon Rice, desarrollador senior de exploits en VulnCheck, dijo que la necesidad de privilegios existentes «hace que un atacante dependa en gran medida de vulnerabilidades anteriores, o de un vector de acceso inicial nuevo, para poder alcanzar el camino de escalada de privilegios».

Cisco recomendó a los clientes que actualizaran al software fijo lanzado en mayo como parte de su respuesta a CVE-2026-20182 como medida de protección.

A falta de un parche que brinde a las organizaciones más protección contra la nueva vulnerabilidad, Cisco proporcionó algunos indicadores de compromiso, pero señaló que esas mismas entradas de registro pueden ocurrir durante las operaciones estándar. La compañía alentó a los clientes que necesitan ayuda para distinguir entre actividades legítimas y maliciosas a comunicarse con los Centros de asistencia técnica de Cisco.

Cisco no es el único proveedor de seguridad que enfrenta una avalancha de ataques contra sus clientes, pero se encuentra entre los más atacados. La Agencia de Seguridad de Infraestructura y Ciberseguridad ha agregado siete vulnerabilidades que afectan Cisco SD-WAN y firewalls a su catálogo de vulnerabilidades explotadas conocidas de este año, sin incluir CVE-2026-20245, que aún no se ha agregado al catálogo.

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.

Una falla en la extensión de Chrome de Claude permitió que «cualquier» otro complemento secuestrara la IA de las víctimas

A medida que las empresas y los gobiernos recurren a agentes de inteligencia artificial para acceder a Internet y realizar tareas de nivel superior, los investigadores continúan encontrando fallas graves en grandes modelos de lenguaje que pueden ser explotadas por malos actores.

lo último descubrimiento proviene de la firma de seguridad de navegadores LayerX, e involucra un error en la extensión de Chrome para el modelo Claude AI de Anthropic que permite que cualquier otro complemento, incluso aquellos sin permisos especiales, incruste instrucciones ocultas que pueden hacerse cargo del agente.

«La falla surge de una instrucción en el código de la extensión que permite que cualquier script que se ejecute en el navegador de origen se comunique con el LLM de Claude, pero no verifica quién está ejecutando el script», escribió el investigador principal de LayerX, Aviad Gispan. «Como resultado, cualquier extensión puede invocar un script de contenido (que no requiere ningún permiso especial) y emitir comandos a la extensión Claude».

Gispan dijo que podía ejecutar cualquier mensaje que quisiera, superar las barreras de seguridad de Claude, evadir la confirmación del usuario y realizar acciones entre sitios a través de múltiples herramientas de Google. Como prueba de concepto, LayerX pudo explotar la falla para extraer archivos de las carpetas de Google Drive y compartirlos con partes no autorizadas, monitorear la actividad reciente del correo electrónico y enviar correos electrónicos en nombre de un usuario, y robar código fuente privado de un repositorio de GitHub conectado.

La vulnerabilidad «rompe efectivamente la seguridad de las extensiones de Chrome» al crear «una escalada de privilegios primitiva entre extensiones, algo que el modelo de seguridad de Chrome está diseñado explícitamente para evitar», escribió Gispan.

Un gráfico que muestra cómo una vulnerabilidad explota los límites de confianza en la extensión de Clade Chrome. (Fuente: LayerX)

Claude se basa en el texto, la semántica de la interfaz de usuario y la interpretación de capturas de pantalla para tomar decisiones, todo lo cual un atacante puede controlar en el lado de entrada. Los investigadores modificaron la interfaz de usuario de Claude para eliminar etiquetas e indicadores relacionados con información confidencial, como contraseñas y comentarios compartidos, y luego le solicitaron a Claude que compartiera los archivos con un servidor externo.

Eso significa que los defensores de la ciberseguridad a menudo no tienen nada obviamente malicioso que detectar. Cuando hay actividad visible, se puede pedir al modelo que cubra sus huellas eliminando correos electrónicos y otras evidencias de sus acciones.

Ax Sharma, jefe de investigación de Manifold Security, calificó la vulnerabilidad como «una demostración útil de por qué monitorear los agentes de IA en la capa de aviso es fundamentalmente insuficiente».

«La parte más sofisticada de este ataque no es la inyección, sino que el entorno percibido por el agente fue manipulado para producir acciones que parecían legítimas desde adentro», dijo Sharma. «Ese es el tipo de amenaza para la que la industria necesita construir defensas».

Gispan dijo que LayerX informó la falla a Anthropic el 27 de abril, pero afirmó que la compañía solo emitió una solución «parcial» al problema. Según LayerX, Anthropic respondió un día después para decir que el error era un duplicado de otra vulnerabilidad que ya se estaba abordando en una actualización futura.

Si bien esa solución, emitida el 6 de mayo, introdujo nuevos flujos de aprobación para acciones privilegiadas que hicieron más difícil explotar la misma falla, Gispan dijo que aún podía hacerse cargo del agente de Claude en algunos escenarios.

«Cambiar al modo 'privilegiado', incluso sin la notificación o el consentimiento del usuario, permitió eludir estos controles de seguridad e inyectar mensajes en la extensión Claude, como antes», escribió Gispan.

Anthropic no respondió a una solicitud de comentarios de CyberScoop sobre los esfuerzos de investigación y mitigación.

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Los clientes de Ivanti se enfrentan a otro día cero activamente explotado

Los atacantes están atacando a los clientes de Ivanti una vez más, regresando a un objetivo común y a un proveedor consistentemente susceptible en el espacio del borde de la red, al explotar una vulnerabilidad de día cero en uno de los productos más asediados de la compañía.

Ivanti advirtió a los clientes que los atacantes han explotado con éxito CVE-2026-6973un defecto de validación de entrada incorrecta en Ivanti Endpoint Manager Mobile (EPMM) que permite a los usuarios autenticados con privilegios administrativos ejecutar código de forma remota. La empresa alertó a los clientes sobre la amenaza en un aviso de seguridad el jueves y también reveló cuatro vulnerabilidades adicionales de alta gravedad en el mismo producto.

«En el momento de la divulgación, Ivanti es consciente de una explotación muy limitada de CVE-2026-6973, que requiere acceso administrativo autenticado para su implementación», dijo un portavoz de Ivanti en un comunicado.

Ivanti no dijo cuándo ocurrió el primer caso de explotación, ni exactamente cuántos clientes ya se han visto afectados.

La Agencia de Seguridad de Infraestructura y Ciberseguridad agregó el día cero a su catálogo de vulnerabilidades explotadas conocidas pocas horas después de la divulgación de Ivanti.

La compañía lanzó parches para las cinco vulnerabilidades el jueves, incluidos los cuatro defectos adicionales: CVE-2026-5787, CVE-2026-5788, CVE-2026-6973 y CVE-2026-7821 – que, según dijo, no han sido explotados en la naturaleza.

«Ivanti descubrió estas vulnerabilidades en las últimas semanas a través de procesos de detección internos respaldados por inteligencia artificial avanzada, colaboración con el cliente y divulgación responsable», dijo el portavoz de la compañía. Uno de los defectos fue descubierto y denunciado responsablemente a Ivanti por un antiguo empleado.

La compañía sugirió que al menos una de las causas fundamentales del último día cero puede deberse al riesgo persistente planteado por un par de días cero críticos y separados: CVE-2026-1281 y CVE-2026-1340 – que fueron explotados a partir de finales de enero. Las consecuencias de esas vulnerabilidades explotadas en Ivanti EPMM se extendieron a casi 100 víctimas, incluida la Autoridad Holandesa de Protección de Datos de los Países Bajos y el Consejo del Poder Judicial, a principios de febrero.

El último día cero de Ivanti EPMM «requiere acceso administrativo autenticado para explotar, razón por la cual los clientes que siguieron la recomendación de Ivanti en enero de rotar las credenciales de EPMM tienen un riesgo significativamente menor. Los clientes que no se vieron afectados por la vulnerabilidad anterior también corren un riesgo mucho menor», dijo el portavoz de la compañía.

Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck, dijo que los privilegios administrativos necesarios para explotar CVE-2026-6973 indican que posiblemente fue explotado como parte de una cadena de ataque que dependía de otro método para el acceso inicial.

«No se compartió ninguna atribución sobre la explotación de CVE-2026-6973 por parte de los actores de amenazas, pero otros dos CVE de 2026 en Ivanti EPMM (CVE-2026-1281 y CVE-2026-1340) han sido explotados por una variedad de actores de amenazas, incluidos grupos atribuidos a China e Irán», dijo Condon a CyberScoop.

«Esas vulnerabilidades eran, en particular, vulnerabilidades de inyección de código que se podían explotar de forma remota sin autenticación, a diferencia de CVE-2026-6973», añadió. «Tanto CVE-2026-1281 como CVE-2026-1340 parecen haberse solucionado en la versión de Ivanti de hoy. Comparativamente, estas vulnerabilidades anteriores eran de mayor preocupación inicial que la nueva vulnerabilidad de día cero de hoy, que requiere autenticación de administrador».

Los ataques que involucran defectos de Ivanti son un problema recurrente para los clientes del proveedor y los profesionales de seguridad en general, incluidas muchas vulnerabilidades que los atacantes explotaron antes de que la empresa detectara o solucionara los errores.

La Agencia de Seguridad de Infraestructura y Ciberseguridad ha detectado 34 defectos de Ivanti en su catálogo de vulnerabilidades explotadas conocidas desde finales de 2021. Se han explotado al menos 22 defectos en los productos Ivanti en los últimos dos años, incluidas cinco vulnerabilidades en Ivanti EPMM en el último año.

Durante una entrevista con CyberScoop en marzo en la Conferencia RSAC, el director de seguridad de Ivanti, Daniel Spicer, dijo que la transparencia de la compañía explica en parte la gran cantidad de vulnerabilidades reportadas y reveladas en sus productos.

«Mi posición aquí en Ivanti es que no les hace ningún bien a nuestros clientes guardar silencio sobre esto», dijo, describiendo la postura de comunicación de la compañía con el público, CISA y los socios globales como «muy agresiva».

Ese no es siempre el caso con otros proveedores, dijo Spicer. «No sé si la transparencia es un elemento fundamental de todas las demás organizaciones».

La empresa, que presta servicios a muchas agencias gubernamentales y operadores de infraestructura crítica, también señala habitualmente que atacantes altamente capacitados y con recursos, incluidos aquellos respaldados por estados-nación, a menudo son responsables de estas oleadas de ataques contra sus clientes.

Ivanti sostiene que está intentando mejorar constantemente la seguridad de sus productos. «A través de una inversión continua en su programa de seguridad de productos, incluido el uso de IA avanzada combinada con verificación humana, Ivanti está fortaleciendo su capacidad para identificar, remediar y revelar problemas rápidamente, ayudando a los clientes a mantenerse a la vanguardia de un panorama de amenazas cada vez más comprimido», dijo el portavoz.

Como lo expresó Spicer en marzo: «Queremos asegurarnos de que la gente entienda que estamos tratando de hacer lo correcto».

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.

Los federales dicen que otro negociador de DigitalMint ejecutó ataques de ransomware y extorsionó 75 millones de dólares

Un hombre de 41 años del sur de Florida está acusado de realizar al menos 10 ataques de ransomware y extorsionar por un total combinado de 75,25 millones de dólares en pagos de rescate mientras trabajaba como negociador de ransomware para DigitalMint.

Cinco de las presuntas víctimas de Angelo John Martino III contrataron a DigitalMint, que asignó a Martino para llevar a cabo negociaciones sobre ransomware en nombre de sus clientes, colocándolo en una posición para jugar en ambos lados, como el criminal responsable del ataque y el negociador principal de sus presuntas víctimas, según registros judiciales federales revelados el miércoles.

Martino supuestamente obtuvo una cuenta de afiliado en ALPHV, también conocida como BlackCat, y conspiró con otros exprofesionales de ciberseguridad para irrumpir en las redes de las víctimas, robar y cifrar datos y extorsionar a las empresas para pedir rescates durante un período de seis meses en 2023.

Martino fue un cómplice anónimo en una acusación presentada en noviembre de 2025 contra Kevin Tyler Martin, otro exnegociador de ransomware en DigitalMint, y Ryan Clifford Goldberg, exgerente de respuesta a incidentes en Sygnia. Goldberg y Martin se declararon culpables en diciembre de participar en una serie de ataques de ransomware y su sentencia está programada para el 30 de abril.

Los fiscales acusan a Martino de proporcionar información confidencial sobre negociaciones de ransomware a los co-conspiradores de ALPHV para maximizar el pago del rescate. Su abogado no respondió de inmediato a una solicitud de comentarios.

Las cinco víctimas con sede en EE. UU. que contrataron a DigitalMint y, sin saberlo, recurrieron a Martino para supuestamente llevar a cabo negociaciones de ransomware con él y sus co-conspiradores incluyen una organización sin fines de lucro y empresas de las industrias hotelera, de servicios financieros, minorista y médica. Las cinco víctimas pagaron un rescate.

Goldberg y Martin no fueron nombrados específicamente como co-conspiradores en esos ataques. Los fiscales dijeron anteriormente que solo extorsionaron con éxito un pago financiero de una de sus víctimas por casi 1,3 millones de dólares.

Firma de ciberseguridad que contrató a Martino responde

DigitalMint dijo que suspendieron el acceso de Martino a los sistemas cuando el Departamento de Justicia notificó a la compañía que lo estaban investigando el 3 de abril y lo despidió al día siguiente. La compañía, que no está acusada de ningún conocimiento o participación en los delitos, agregó que no tenía conocimiento de que Martino y Martin ya estuvieran involucrados en esquemas relacionados con ransomware antes de ser contratados.

«Condenamos enérgicamente el comportamiento criminal de estos ex empleados, que violaron nuestros valores, estándares éticos y la ley», dijo el director ejecutivo de DigitalMint, Jonathan Solomon, en una declaración a CyberScoop.

«DigitalMint ha cooperado plenamente con las autoridades desde el principio y no espera más cargos», añadió Solomon. «Si bien ninguna organización puede eliminar por completo el riesgo interno, nos tomamos incidentes como este extremadamente en serio y hemos reforzado las salvaguardas y los controles internos para reducir aún más la probabilidad de conductas similares».

DigitalMint no respondió directamente a las preguntas sobre si reembolsó a sus clientes que supuestamente fueron víctimas de Martino. «No podemos discutir relaciones específicas con clientes o acuerdos de honorarios debido a obligaciones de confidencialidad», dijo un portavoz en un comunicado. «Seguimos comprometidos con nuestros clientes y hemos abordado cualquier asunto comercial directamente con esas partes».

La compañía también se negó a describir las circunstancias bajo las cuales fue contratada y asignó a Martino para llevar a cabo negociaciones de ransomware sobre los ataques que supuestamente cometió. Sin embargo, en una declaración señaló: “Los documentos de acusación no alegan que Martino haya remitido o llevado a estas víctimas a DigitalMint”.

El caso contra Martino muestra un ejemplo extremo, aunque raro, del punto más oscuro de la negociación de ransomware como práctica. Los peligros de la negociación de ransomware son excesivos y estas negociaciones de canal secundario, que en gran medida no se analizan, pueden salir mal por varias razones.

Las autoridades confiscan alrededor de 12 millones de dólares en activos y fijan una fianza de 500.000 dólares

Martino está acusado de conspiración para interferir con el comercio mediante extorsión y enfrenta hasta 20 años de prisión. Está previsto que se declare culpable el 19 de marzo.

Las autoridades confiscaron casi 9,2 millones de dólares en cinco tipos de criptomonedas de 21 carteras controladas por Martino. Otros artículos incautados a Martino incluyen un Nissan Skyline de 1999, un Polaris RZR de 2024, un remolque de 2023 y una embarcación de 29 pies fabricada en 2023.

Los funcionarios también confiscaron dos propiedades propiedad de Martino en Nokomis, Florida, incluida una casa frente a la bahía con un valor estimado de 1,68 millones de dólares y una segunda casa unifamiliar con un valor estimado de 396.000 dólares. La casa frente a la bahía fue reportada como la Segunda transacción inmobiliaria más grande de la semana. cuando Martino y su esposa compraron la casa por $1,791 millones en febrero de 2024.

Toma aérea de la propiedad de Nokomis, Florida, confiscada a Angelo Martino. (aleta roja)
Toma aérea de una de las propiedades de Nokomis, Florida, que las autoridades confiscaron a Angelo Martino. (aleta roja)

Martino se entregó a los alguaciles estadounidenses en Miami el martes y fue liberado con una fianza de 500.000 dólares. Tiene restringido viajar fuera del Distrito Sur de Florida y tiene prohibido trabajar en la industria de la ciberseguridad.

ALPHV/BlackCat era un notorio grupo de ransomware y extorsión vinculado a una serie de ataques a proveedores de infraestructura crítica. La variante de ransomware apareció por primera vez a finales de 2021 y luego se utilizó en decenas de ataques a organizaciones del sector de la salud.

El grupo detrás de la cepa de ransomware también se atribuyó la responsabilidad del ataque de febrero de 2024 a la filial de UnitedHealth Group, Change Healthcare, que pagó un rescate de 22 millones de dólares y se convirtió en la mayor filtración de datos de atención médica registrada, comprometiendo los datos de alrededor de 190 millones de personas.

Dos de las presuntas víctimas de Martino pagaron rescates aún mayores en 2023, según los fiscales, incluido un pago de casi 26,8 millones de dólares de la organización sin fines de lucro no identificada y un pago de casi 25,7 millones de dólares de la empresa de servicios financieros no identificada.

Puede leer los cargos formales que los fiscales presentaron contra Martino a continuación.

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.