Salesforce deshabilita la integración de la aplicación Klue después de que el abuso del token OAuth exponga los datos del cliente

Salesforce reveló que deshabilitó la integración de la aplicación Klue Battlecards dentro de su plataforma en respuesta a un incidente de seguridad que afectó a la empresa de inteligencia competitiva el 11 de junio de 2026.

Con ese fin, las organizaciones no podrán conectarse a Salesforce a través de la aplicación hasta nuevo aviso, señaló la compañía estadounidense de software basado en la nube en una alerta publicada esta semana.

«Salesforce tomó esta acción porque nuestros equipos de seguridad detectaron recientemente una actividad inusual relacionada con la aplicación que puede haber resultado en un acceso no autorizado a un subconjunto de datos del cliente a través de la conexión de la aplicación a Salesforce», anotado. «Este problema se limita a la conexión de la aplicación de Klue y no surge de una vulnerabilidad dentro de la plataforma Salesforce».

El desarrollo se produce cuando un grupo de extorsión denominado Icarus comprometió y exfiltró datos de los clientes de Klue, incluida la empresa de ciberseguridad Huntress.

«Los datos que se copiaron de nuestra cuenta de Salesforce incluyen contactos comerciales, cotizaciones de precios y otros datos y mensajes relacionados con las ventas», Huntress dicho. «Ningún dato de amenazas, contraseñas, información de tarjetas de pago o datos de ingeniería relacionados con el agente Huntress o la telemetría que recopilamos se vieron afectados».

En su propia actualización, Klue dijo que detectó actividad no autorizada que afectó una parte de la infraestructura de integración de Klue el 12 de junio de 2026, y agregó que los atacantes obtuvieron acceso a través de una credencial heredada comprometida asociada con un servicio de integración.

Ciberseguridad

«El atacante utilizó ese acceso para obtener tokens OAuth utilizados para conectar Klue con ciertas plataformas de terceros, incluido Salesforce, y posteriormente accedió a datos dentro de varios entornos de clientes conectados», dijo Jason Smith, director ejecutivo de Klue. dicho. «Según nuestra investigación hasta la fecha, el incidente se limitó a las plataformas de terceros afectadas y no hay evidencia de que el contenido del cliente almacenado dentro de la plataforma Klue se haya visto afectado».

Específicamente, se dice que la intrusión permitió al actor de amenazas impulsar una actualización de código capaz de recopilar tokens OAuth que sus clientes utilizan para conectar Klue a sus propios sistemas. En respuesta a la infracción, Klue tomó medidas para revocar las credenciales y tokens afectados, eliminar el código no autorizado, detener el acceso remoto, desactivar las integraciones potencialmente afectadas e iniciar una investigación exhaustiva.

A partir del 16 de junio de 2026, algunos de los empleados de Huntress recibieron un correo electrónico con el asunto «correo electrónico ultrasecreto» y una advertencia que dice: «Sus datos de Salesforce han sido descargados… Tiene 48 horas para comunicarse con nosotros. Tome la decisión correcta».

«El actor de la amenaza parece haber aprovechado una credencial en desuso durante mucho tiempo pero aún activa para llevar a cabo el compromiso inicial, una que fue creada originalmente por Klue para que crearan un prototipo de una integración de terceros que luego abandonaron», dijo la compañía. «El actor de amenazas luego ingresó a la infraestructura de Klue para robar los tokens utilizados por los clientes de Klue, luego usó esas credenciales robadas para consultar las herramientas CRM de esos clientes directamente y, eventualmente, exfiltrar los datos».

No se sabe mucho sobre el actor de Ícaro aparte del hecho de que ha estado activo desde el 28 de abril de 2026 y ha reclamado un total de dos víctimas hasta la fecha. Dicho esto, la campaña de robo de datos refleja oleadas de ataques anteriores montados por ShinyHunters y UNC6395.

ReliaQuest, en su propio análisis del abuso de integración de Klue, dijo que la actividad comparte similitudes con el manual de estrategias de abuso de OAuth de terceros asociado con el Los compromisos de Salesloft Drift y Gainsight que se dirigieron a los entornos de Salesforce el año pasado.

Ciberseguridad

«En los ataques que observamos, el adversario primero se autenticó a través de una cuenta de servicio de integración Klue comprometida, generó tokens OAuth y ejecutó scripts Python automatizados (identificables por cadenas de agente de usuario Python-urllib)», los investigadores de ReliaQuest Thassanai McCabe y Alexa Feminella. dicho.

«Estos scripts primero enumeraron el catálogo de objetos de la organización a través de GET /services/data/v59.0/sobjects, luego realizaron un bucle de consultas de API REST contra el punto final de consulta de Salesforce (/services/data/v59.0/query) y paginaron los resultados a través del cursor QueryMore durante casi 24 horas».

Se considera que son acciones de recuperación masiva de datos diseñadas para extraer grandes volúmenes de registros de CRM a través de la API REST de Salesforce. Esto incluyó una «ráfaga concentrada» de casi mil consultas en 15 minutos contra al menos un entorno y una ventana de extracción que duró más de seis horas en otro caso.

No está claro cuántos clientes de Salesforce se vieron afectados por los últimos ataques, aunque Klue dijo que se ha estado comunicando directamente con los clientes afectados, compartiendo hallazgos de investigación y ayudándolos con sus esfuerzos de respuesta.

«El hilo común es el abuso de tokens o credenciales de OAuth de un proveedor externo confiable», dijo ReliaQuest. «Estas integraciones son identidades no humanas con acceso persistente y a menudo amplio a datos confidenciales, pero normalmente se monitorean mucho menos estrechamente que las cuentas de los empleados. Esa brecha es la razón por la cual se podría ejecutar un ciclo de consulta automatizado de 24 horas desde una cuenta de integración ‘confiable’ sin activar las alarmas habituales».

Apple parchea la falla de Studio Buds que permite a atacantes cercanos espiar a través del micrófono – CYBERDEFENSA.MX

Apple ha actualizado sus auriculares inalámbricos Beats Studio Buds para solucionar una vulnerabilidad de alta gravedad que podría ser aprovechada por piratas informáticos cercanos para espiar a los usuarios.

La vulnerabilidad, rastreada como CVE-2025-20701 (Puntuación CVSS: 8,8), se refiere a un caso de autorización incorrecta que afecta al SDK de audio Bluetooth de Airoha que permite emparejar un dispositivo de audio Bluetooth sin el consentimiento del usuario.

Explotación exitosa La falla podría conducir a una escalada remota de privilegios sin requerir privilegios de ejecución adicionales o interacción del usuario. El problema se solucionó en la actualización de firmware Beats 1B211.

«Un atacante dentro del alcance de Bluetooth puede escuchar a través del micrófono de un dispositivo que aún no está emparejado y que busca activamente solicitudes de emparejamiento», dijo Apple en un aviso publicado esta semana.

Los detalles de la vulnerabilidad surgieron por primera vez en junio de 2025 cuando los investigadores de ERNW GmbH Dennis Heinze y Frieder Steinmetz lo marcó junto con otros dos defectos en SoC Airoha (CVE-2025-20700 y CVE-2025-20702) en la conferencia de seguridad TROOPERS en Alemania. Parches similares fueron liberado por Jabra en diciembre de 2025.

Ciberseguridad

«En la mayoría de los casos, estas vulnerabilidades permiten a los atacantes apoderarse completamente de los auriculares a través de Bluetooth. No se requiere autenticación ni emparejamiento», señalaron los investigadores en ese momento. «Las vulnerabilidades pueden activarse a través de Bluetooth BR/EDR o Bluetooth Low Energy (BLE). Estar dentro del alcance de Bluetooth es la única condición previa. Es posible leer y escribir en la RAM y la memoria flash del dispositivo».

«Estas capacidades también permiten a los atacantes secuestrar relaciones de confianza establecidas con otros dispositivos, como el teléfono emparejado con los auriculares. Estas capacidades permiten múltiples escenarios de ataque».

Nuevo exploit no parcheable descubierto en los chips A12 y A13 de Apple

La revelación se produce cuando Paradigm Shift reveló un novedoso iPhone. ROM segura (también conocida como BootROM) que afecta a los chips A12 y A13 de Apple, además de un exploit de prueba de concepto (PoC) con nombre en código usbliter8.

«El exploit aprovecha tanto un error de hardware en el controlador USB como un fallo de configuración específico presente en el firmware del dispositivo», afirma la empresa europea de ciberseguridad. dicho. «Como estas vulnerabilidades residen en código inmutable, los usuarios afectados deben ser conscientes de que migrar a un hardware más nuevo sigue siendo la mitigación más eficaz».

En un nivel alto, el exploit funciona aprovechando una falla en el controlador USB integrado en los SoC de Apple. El controlador utiliza un buffer de memoria para almacenar los paquetes SETUP y OUT transmitidos al inicio de la transferencia de datos. La investigación encontró que es posible desencadenar una primitiva de desbordamiento de buffer aprovechando el hecho de que el controlador también acepta paquetes más pequeños, lo que permite efectivamente la inyección y ejecución de código malicioso bajo ciertas condiciones.

El problema, señaló Paradigm Shift, probablemente tenga su origen en el hardware del controlador USB, no en el software de Apple. El chip A11 no es susceptible a la vulnerabilidad, mientras que se confirma que A12 y A13 son susceptibles.

Ciberseguridad

«La diferencia es que el controlador USB A11 restablece manualmente la dirección DMA a su valor inicial después de recibir cada paquete», dijo la compañía. «En A12 y A13, USB DART está configurado en modo bypass, lo que nos permite sobrescribir datos SRAM libremente. Por el contrario, A14 y generaciones posteriores parecen configurar DART correctamente en SecureROM, lo que hace que la vulnerabilidad no se pueda explotar».

El exploit usbliter8 es comparable a checkm8, el exploit BootROM de este tipo conocido públicamente que afectó a todos los dispositivos iOS, desde el iPhone 4s (chip A5) hasta el iPhone 8 y el iPhone X (chip A11).

«El exploit usbliter8 demuestra que incluso en las generaciones más recientes de SecureROM, incluidas aquellas protegidas por Autenticación de punteroaún se pueden aprovechar errores sutiles de hardware para lograr la ejecución completa del código y romper la cadena de confianza», dijo Paradigm Shift.

«La seguridad de BootROM es crítica: las vulnerabilidades en este nivel pueden comprometer la integridad de todo el dispositivo. Aunque usbliter8 no afecta a SEP en sí, abre vectores de ataque más amplios para comprometer Secure Enclave».

Cómo la obsesión por la velocidad del desarrollo de software permitió la cruzada del caos del TeamPCP

TeamPCP está arrasando con el software de código abierto.

En menos de cuatro meses, el actor de amenazas comprometió e inyectó código malicioso en más de 1.000 paquetes de software. Esta extraordinaria oleada ha transformado la forma en que los desarrolladores y mantenedores de software distribuyen y administran su código, ya que sus dependencias y repositorios se han convertido en uno de los vectores de ataque más efectivos y frecuentes este año.

Si bien ha habido una serie de exploits técnicos, el mayor ataque de TeamPCP ha sido el desarraigo de la confianza, demostrando repetidamente que la mayoría de las organizaciones no verifican que el código que ingieren en sus sistemas sea legítimo, abusando de una fe casi ciega en la que depende gran parte de la industria de desarrollo de software para impulsar la economía moderna de hoy.

Comenzando con Trivy en febrero, los ataques de TeamPCP han sacudido esa confianza muchas veces.

La escala de los ataques de TeamPCP radica en parte en los sistemas automatizados que las empresas utilizan para implementar código, como los canales de CI/CD. También está aprovechando las nuevas brechas de seguridad creadas por la creciente dependencia de los desarrolladores de la IA. Sin embargo, con un esfuerzo relativamente bajo y tácticas poco originales, TeamPCP está destruyendo marcos de código abierto y sistemas subyacentes a niveles que la comunidad tecnológica rara vez ha tenido en cuenta.

«Los desarrolladores no hacían un gran trabajo analizando la seguridad de sus dependencias de código abierto antes, pero ahora con la IA, en algunos casos prácticamente no hay ningún ser humano en el circuito ni ningún tipo de control de cordura sobre lo que están haciendo estas herramientas», dijo a CyberScoop Feross Aboukhadijeh, fundador y director ejecutivo de Socket.

«Hay agentes que instalan paquetes que no han sido examinados», dijo. «Cuando un atacante ingresa, el impacto es aún mayor porque hay menos controles y contrapesos para evitar que afecte a todos».

TeamPCP no ha identificado un nuevo problema ni ha demostrado nada novedoso. El quid de estos ataques gira en torno a un tema central: las vulnerabilidades defensivas que toda la industria del software conoce desde hace años. Los investigadores y desarrolladores saben que el modelo de confianza del código abierto no funciona y es susceptible de sabotaje. Sin embargo, la industria del software no ha solucionado este problema.

«La velocidad y la escala de estos ataques es lo que los hace más notables, no necesariamente la metodología detrás de ellos, porque en esencia se trata de explotar la confianza de terceros que tenemos», dijo Kimberly Goody, gerente senior de Google Threat Intelligence Group.

Los paquetes de software suelen estar sujetos a una supervisión de seguridad intensiva para comprobar si hay vulnerabilidades y actualizaciones envenenadas antes de lanzarlos a entornos activos.

Sin embargo, la verdadera vulnerabilidad destacada por TeamPCP se encuentra más arriba en la cadena de mando con las organizaciones o individuos que publican estos paquetes en el mercado en general, según Nathaniel Quist, gerente de inteligencia de amenazas en la nube de Palo Alto Networks.

«Es su responsabilidad asegurar sus credenciales y no proporcionar un punto de partida para desencadenar un evento en la cadena de suministro», dijo. «Todo lo que interactúa con esa zona o la cruza debe ser altamente monitoreado y controlado para garantizar que un compromiso pueda contenerse rápida y fácilmente».

La motivación del TeamPCP

TeamPCP, como cualquier cibercriminal prolífico, ha captado una gran atención por parte de los cazadores de amenazas desde que surgió a finales de 2025. Google atribuye la actividad a un operador principal.

La compañía dijo que rastreó las conexiones de direcciones IP residenciales y móviles de TeamPCP hasta Sudáfrica, lo que indica que el operador principal estuvo ubicado allí durante al menos algunos de sus ataques.

«No creemos que exista un grupo central establecido, al menos no todavía, y que gran parte de esto ha sido realizado por un individuo», dijo Goody. Google se negó a nombrar al operador principal ni a confirmar que conoce la verdadera identidad de la persona.

Palo Alto Networks dijo que el administrador central de TeamPCP utiliza el identificador «ResoluteXBF» en múltiples plataformas. La firma de ciberseguridad también está rastreando a dos miembros principales adicionales: «diencracked» y «Shinigami».

Si TeamPCP está dirigido principalmente por una sola persona, las fuerzas del orden tienen una rara oportunidad de lograr un impacto duradero con un solo arresto.

TeamPCP ha colaborado con otros ciberdelincuentes, pero la mayoría de esas asociaciones duraron poco y terminaron en una disputa pública o no lograron despegar de manera significativa, dijo Goody.

Los investigadores han vinculado a TeamPCP con equipos de extorsión, foros de la web oscura y afiliados, incluidos Lapsus$, ShinyHunters, Vect, DragonForce, BreachForums y «HasanBroker». TeamPCP enumeró alrededor de 4.000 repositorios de códigos privados en un foro de la web oscura con un precio inicial de 95.000 dólares.

Las acciones hasta la fecha, incluido el comportamiento impredecible, indican motivaciones más allá del beneficio financiero y un “claro deseo de notoriedad”, dijo Goody. «Parece que les gusta crear el caos».

Quist llega a la misma conclusión de su investigación de meses, señalando que alienta a otros ciberdelincuentes a participar en la acción, ofreciendo en un momento recompensas financieras por el mayor ataque a la cadena de suministro de software.

TeamPCP no está involucrado en pagos de extorsión, dijo. «Estos actores están más interesados ​​en la credibilidad callejera clandestina que están ganando» y en «causar tanto daño y caos como sea posible».

Las víctimas abundan, pero la exposición es limitada

TeamPCP ha sido notablemente ruidoso, inyectando de manera oportunista malware en software de código abierto con el fin de robar credenciales para entornos Kubernetes, Amazon Web Services, Microsoft Azure, Google Cloud y muchos otros servicios conectados.

La lista de víctimas reclamadas por el grupo es asombrosa: Checkmarx, Bitwarden, LiteLLM, Telnyx, Mercor AI, PyTorch Lightning, AntV, SAP, GitHub, TanStack, UiPath, MistralAI, Microsoft DurableTask, Red Hat y Nx Console.

La colección completa de paquetes comprometidos o envenenados por TeamPCP hasta la fecha representa aproximadamente 500 millones de descargas semanales combinadas, según Quist.

Si bien la amplitud del posible compromiso posterior que surge de esas descargas es sustancial, muchos puntos finales infectados con esos paquetes plagados de malware no están expuestos a Internet y son menos susceptibles a los ataques, agregó.

«No creo que vaya a haber un número muy grande de víctimas», dijo Quist. «Habrá muchas personas que podrían verse comprometidas y tener paquetes potencialmente vulnerables en su entorno, pero eso no significa necesariamente que estén en una posición explotable».

Si bien estos incidentes han acaparado los titulares, TeamPCP no ha acumulado pagos tan grandes como otros ciberdelincuentes. Sin embargo, el impacto reputacional más amplio que ha provocado es enorme.

TeamPCP ha reclamado públicamente más de 10.000 víctimas y alrededor de 90.000 dólares en extorsiones, según Quist.

«Puede que no estén ganando mucho dinero, pero están causando un gran impacto», dijo Goody. «Sus campañas han sido muy disruptivas».

Cómo el modelo operativo de TeamPCP apunta al desarrollo

La lista de víctimas de TeamPCP ha crecido a medida que sus repositorios de código abierto secuestrados en npm, PyPI, GitHub y otras herramientas de desarrollo subcontratadas que se incorporan al código ascendente que se ejecuta en entornos de producción.

Las computadoras portátiles de los desarrolladores y otros puntos finales asignados para instalar, construir y publicar software contienen ampliamente claves y acceso al código fuente que crean objetivos de cadena de suministro increíblemente valiosos para los atacantes, explicó Amitai Cohen, jefe del equipo de inteligencia de vectores de ataque en Wiz, durante una presentación en junio sobre TeamPCP en SleuthCon en Arlington, Virginia.

El grupo se dirige a los corredores de CI, que son sistemas automatizados que crean, prueban y publican código. TeamPCP inyecta malware en los repositorios de código que mantienen estos corredores. Cuando otros desarrolladores introducen ese código en sus propios sistemas, sin saberlo, descargan el malware junto con él.

Algunos de estos artefactos, incluidas las bibliotecas de Python, los registros npm y las acciones de GitHub, son descargados casi de inmediato por miles o millones de desarrolladores que han configurado sus ejecutores para que obtengan consistentemente la última versión, según Cohen. «Nosotros, como industria de la seguridad, les hemos enseñado que eso es lo correcto. Quiere utilizar la última versión porque quiere estar protegido contra vulnerabilidades y, obviamente, quiere beneficiarse de todas las funciones más recientes».

Ese instinto es exactamente lo que explota TeamPCP. Al comprometer el flujo de trabajo de CI/CD de una empresa, el grupo obtiene acceso a todos los usuarios intermedios que extraen automáticamente ese código infectado. “Esto es lo que permite [TeamPCP] «Para aprovechar el acceso inicial a algún paciente cero, alguna empresa que tenía una vulnerabilidad en su flujo de trabajo de CI/CD, para obtener acceso a sus usuarios intermedios», dijo Cohen. «Así es como funciona la cadena de suministro de software. Todo tiene dependencias sobre dependencias sobre dependencias”.

Algunos de los paquetes comprometidos por TeamPCP estuvieron activos durante casi 13 horas, pero los profesionales de la seguridad han respondido identificando ataques de inyección de código mucho más rápido ahora, retirando algunos repositorios comprometidos en 15 minutos, dijo Ben Read, director de inteligencia estratégica de Wiz.

Las operaciones del grupo de amenaza siguen siendo de alto ritmo. TeamPCP infecta nuevos paquetes de software casi a diario, valida los compromisos y captura datos confidenciales en 24 horas, según los investigadores de Wiz.

El grupo de amenazas ha evolucionado constantemente sus tácticas, desarrollando cargas útiles en JavaScript y Python mientras se propaga desde archivos locales a interfaces de programación de aplicaciones de Kubernetes y kits de desarrollo de software incluidos. Más recientemente, ha estado robando credenciales mediante protocolos personalizados.

Las ambiciones del grupo se han expandido más allá de sus propios ataques. TeamPCP también es responsable de una pieza de malware autorreplicante conocida como Mini Shai-Hulud, que infectó cientos de paquetes de software en registros de código abierto en ataques consecutivos el mes pasado. Un afiliado de TeamPCP publicó el código fuente completo del malware en GitHub el mes pasado y alentó a otros ciberdelincuentes a utilizarlo para sus propias campañas.

«TeamPCP busca volumen. No discriminan, no necesariamente intentan ser sigilosos o maximizar el retorno de la inversión. Buscan una estrategia que incluya todo lo anterior», dijo Read durante la presentación de Sleuthcon.

Las brechas defensivas crean aperturas para el ataque

La ola de ataques de TeamPCP también ha puesto de relieve lo difícil que es para las organizaciones revocar secretos comprometidos. Múltiples víctimas han experimentado infecciones recurrentes, a veces siendo víctimas de TeamPCP tres veces en un mes, porque no rotaron los secretos correctamente, dijo Cohen.

En esencia, estos ataques resaltan una compensación directa que las organizaciones aceptan cuando actualizan el software rápidamente para corregir vulnerabilidades, pero aprenden que hacerlo demasiado rápido podría exponerlas a registros ilegítimos que contienen malware.

TeamPCP se ha centrado en lo que Aboukhadijeh describe como un “bien público”, registros de código abierto que nunca fueron perfectos pero que eran ampliamente confiables y rara vez se convertían en un punto de entrada para ataques a la cadena de suministro.

La instalación rápida de software de código abierto es una de las cosas más peligrosas que una organización puede hacer en este momento, dijo, y agregó que hay aproximadamente una posibilidad entre 10 de que cualquier paquete instalado por una organización pueda desencadenar un ataque activo.

TeamPCP ha comprometido escáneres de seguridad, administradores de contraseñas, herramientas de automatización, software de visualización de datos e infraestructura CI/CD en varios entornos.

Y ha obtenido un tesoro de credenciales y otros datos confidenciales de las víctimas.

Investigadores como Cohen en Wiz, que han estado siguiendo esta ola de ataques desde el principio, se están acercando a un punto de ruptura.

«Esto también es demasiado duro para nosotros. Estamos muy cansados. Estoy seguro de que mucha gente que trabaja en este espacio problemático está muy cansada y se ha vuelto insostenible», dijo Cohen.

«No se puede seguir existiendo en un mundo en el que te despiertas cada mañana y algún paquete súper prevalente está comprometido y todo el mundo va a utilizarlo como si nada», añadió. «Necesitamos empezar a tomar esto un poco más en serio».

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 legisladores desconfían del orden antrópico de la administración Trump

Los miembros del Congreso respondieron con escepticismo y cautela el martes a la decisión de la administración Trump de imponer controles de exportación a los modelos de inteligencia artificial más nuevos de Anthropic.

La orden del viernes, que según Anthropic la obligó a desactivar sus modelos de inteligencia artificial Fable 5 y Mythos 5, fue motivada por lo que la administración dijo que eran preocupaciones de seguridad nacional que un gran número de profesionales de la ciberseguridad han descartado como infundadas.

Varios demócratas de Hill dijeron a CyberScoop que les preocupaba que la decisión de la administración estuviera impulsada por otras consideraciones. En particular, la administración ha peleado con Anthropic sobre el uso de sus modelos para vigilancia doméstica y armas totalmente autónomas.

El senador Angus King, un independiente de Maine que forma parte de un grupo demócrata, dijo que necesitaría estar convencido de que era una orden de seguridad nacional legítima y que aún no había visto una justificación completa.

«Lo que hicieron fue bastante extremo y me gustaría ver cuál fue la base, a diferencia de todos los demás problemas que están dando vueltas en materia de ciberseguridad», dijo. «Soy un poco escéptico debido a la antipatía que, por lo demás, anunciaron hacia esta empresa».

Los líderes del Comité de Seguridad Nacional de la Cámara de Representantes tuvieron opiniones contrastantes: el presidente Andrew Garbarino, RN.Y., ofreció una respuesta doble y el principal demócrata del panel, Bennie Thompson de Mississippi, criticó el orden.

«La administración tiene razón al tratar las capacidades cibernéticas avanzadas de IA como una cuestión de seguridad nacional, especialmente cuando los adversarios extranjeros y los ciberdelincuentes están buscando activamente formas de convertir estas herramientas en armas», dijo Garbarino en un comunicado. «Al mismo tiempo, debemos asegurarnos de que nuestra respuesta no ponga en desventaja involuntaria a empresas estadounidenses, socios aliados o defensores de infraestructura crítica que necesitan acceso a las mejores herramientas seguras disponibles para proteger nuestras redes aquí en casa».

Estados Unidos, no China, necesita establecer estándares para una IA confiable, dijo Garbarino.

Pero Thompson dijo que la orden añade evidencia a la apariencia de que la administración Trump no «tiene un plan coherente para mitigar los riesgos de ciberseguridad» de los modelos fronterizos de IA, dijo a CyberScoop en un comunicado.

«Las regulaciones de IA deben basarse en estándares y procedimientos que brinden confianza al público de que las decisiones se basan en evidencia y no en política», dijo. “En cambio, la administración Trump ha adoptado un enfoque ad hoc en el que las decisiones las toman personas designadas políticas en la Casa Blanca en lugar de expertos y en el que las empresas se quedan adivinando cómo cumplirlas”.

El senador de Virginia Mark Warner, el principal demócrata en el Comité de Inteligencia, también había destacado previamente la disputa de la administración con Anthropic en respuesta a la orden en una declaración a CyberScoop.

Entre bastidores, la administración y Anthropic seguían intentando forjar una tregua Martes. En términos más generales, la orden ejecutiva de la administración sobre IA tuvo un lanzamiento difícil, ya que la administración oscilaba de un lado a otro sobre cuán involucrado debería estar el gobierno.

Algunos legisladores pospusieron hacer comentarios el martes, como el presidente del Comité de Seguridad Nacional del Senado, Rand Paul, republicano por Kentucky, quien le dijo a CyberScoop que no tenía nada que decir sobre la orden.

Otros dijeron que todavía estaban buscando información de la administración.

“No he tenido la oportunidad de recibir información específica sobre la lógica, el razonamiento detrás de esto, etc.”, dijo el senador Mike Rounds, republicano de Dakota del Sur que preside el Subcomité de Ciberseguridad de las Fuerzas Armadas. «Así que voy a retener el juicio hasta que tenga la oportunidad de conocer el resto de la historia, por así decirlo».

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

La falla del SDK de Google Vertex AI permite a los atacantes secuestrar cargas de modelos a través de Bucket Squatting – CYBERDEFENSA.MX

Una falla en el SDK de Google Cloud Vertex AI para Python permitió a un atacante sin acceso al proyecto de una víctima secuestrar el modelo de aprendizaje automático de la víctima, cargar y ejecutar código dentro de la infraestructura de servicio de Google.

Unidad 42 de Palo Alto Networks, que encontró y reportado El error a través del programa de recompensas por errores de Google, llama a la técnica «Pepinillo en el medio» y dijo que no vio ninguna explotación en la naturaleza. Google lo ha parcheado; si usa el SDK, actualice a la versión 1.148.0 o posterior.

El atacante solo necesitaba un proyecto propio de Google Cloud y el ID del proyecto de la víctima, que suele ser público. Sin credenciales, sin phishing, sin punto de apoyo en el objetivo.

La falla estaba en cómo el SDK eligió un depósito temporal de Cloud Storage para la carga de modelos. Si un usuario no configuró un depósito, el SDK generó un nombre predecible a partir del ID del proyecto y la región, como región-ensayo-vértice-del-proyecto. Comprobó si ese cubo existía, pero no si la víctima era su propietario.

Debido a que los nombres de los depósitos son globalmente únicos, un atacante podría crear primero el depósito esperado en su propio proyecto. El SDK de la víctima luego cargaría los archivos del modelo en el depósito del atacante. Luego, el atacante podría reemplazar el modelo cargado por uno malicioso.

Ciberseguridad

Muchos modelos de Python ML se guardan con conservar en vinagre o biblioteca de trabajoque puede ejecutar código cuando se carga un archivo. Cuando Vertex AI cargó más tarde el modelo intercambiado, el código del atacante se ejecutó dentro del contenedor de servicio.

El ataque dependía de la velocidad. La Unidad 42 midió aproximadamente 2,5 segundos entre la carga de la víctima y Vertex AI leyendo el archivo. En su prueba de concepto, el atacante utilizó una función en la nube que se activó después de la carga y reemplazó el modelo en 1,4 segundos, antes de que Vertex AI lo leyera.

Luego, la carga útil robó un token OAuth del servidor de metadatos del contenedor de servicio y lo envió al atacante. En el entorno de prueba de la Unidad 42, ese token no se limitó a la implementación comprometida. Podría acceder a otros artefactos del modelo en el mismo proyecto de inquilino administrado por Google, incluido un modelo TensorFlow completo con pesos entrenados, así como metadatos de BigQuery, listas de acceso, registros de inquilinos, nombres de clústeres de GKE y rutas de imágenes de contenedores internos.

El ataque solo funcionó bajo condiciones específicas: el depósito de preparación predeterminado de la víctima no existía aún en esa región y la víctima abandonó el cubo_puesta en escena parámetro desarmado. El primero es común para un nuevo proyecto en Vertex AI en una región.

El segundo depende de que el desarrollador confíe en el valor predeterminado del SDK en lugar de nombrar su propio depósito.

La Unidad 42 informó la falla a través del Programa de recompensa por vulnerabilidades de Google el 5 de marzo de 2026. Probó las versiones 1.139.0 y 1.140.0, las últimas disponibles en ese momento, y encontró que ambas eran vulnerables.

Google envió una solución inicial en v1.144.0 el 31 de marzo, agregando un uuid4 aleatorio al nombre del depósito. Completó la solución en v1.148.0 el 15 de abril, se agregó la verificación de propiedad del depósito para bloquear la okupación del depósito en Model.upload(). Al momento de su publicación, ni Unit 42 ni los boletines de seguridad Vertex AI de Google enumeran un CVE para el problema.

Ciberseguridad

Actualice a 1.148.0 o posterior para que la verificación de propiedad esté activa. Además, establezca un staging_bucket explícito en una ubicación de Cloud Storage que controle al cargar modelos. Debido a que la lógica defectuosa reside en el SDK del cliente, verifique la versión de google-cloud-aiplatform dondequiera que se ejecute, incluidos los cuadernos, los trabajos de CI y los canales de capacitación, no solo los servicios de producción.

Es la segunda falla con nombre de depósito predecible que surge en Vertex AI este año. Google parcheado CVE-2026-2473 en febrero, un error separado en Vertex AI Experiments que también permitió la ejecución de código entre inquilinos, el robo de modelos y el envenenamiento.

El trabajo anterior de la Unidad 42 sobre los permisos de agente de servicio predeterminados de Vertex AI trazó una ruta relacionada desde un agente de IA implementado hasta los datos de clientes e inquilinos.

Alertas falsas de Microsoft utilizadas para implementar el malware NarwhalRAT de Corea del Norte – CYBERDEFENSA.MX

El grupo de hackers patrocinado por el Estado norcoreano conocido como ScarCruft (también conocido como APT37) ha sido observado utilizando mensajes de phishing que se hacen pasar por notificaciones de seguridad de cuentas de Microsoft para entregar malware llamado NarvalRAT.

«El correo electrónico del ataque contenía un mensaje que se hacía pasar por una alerta de seguridad de la cuenta de MS», informó el Genians Security Center (GSC). dicho. «Fue diseñado para generar preocupación sobre un posible compromiso de la cuenta y abuso de OTP, induciendo así al destinatario a ejecutar el archivo adjunto».

«El cuerpo del correo electrónico indicaba al destinatario que consultara el aviso adjunto. Sin embargo, el archivo adjunto real no era un HWP [Hangul Word Processor] documento, sino un archivo ZIP que contenía un archivo LNK malicioso».

El mensaje de correo electrónico afirma «actividad anormal» relacionada con la generación repetida de contraseñas de un solo uso, haciéndola pasar como un intento de phishing dirigido a la cuenta de Microsoft del objetivo por parte de un tercero e instándolo a cambiar su contraseña. El objetivo final del mensaje de phishing es inducir una falsa sensación de urgencia y engañar a la víctima para que interprete el correo electrónico como una alerta de seguridad legítima.

Ciberseguridad

El archivo LNK, una vez iniciado, inicia una cadena de infección de varias etapas que emplea secuencias de comandos por lotes intermediarias para descargar e instalar NarwhalRAT, además de recuperar el ejecutable Python legítimo del sitio web oficial y un archivo del catálogo de seguridad de Windows (CAT). La persistencia se logra mediante una tarea programada, que está configurada para iniciar el archivo CAT responsable de buscar y ejecutar la carga útil principal en la memoria sin dejar ningún artefacto en el disco.

El malware basado en Python está equipado para registrar pulsaciones de teclas, capturar capturas de pantalla (con soporte para imágenes de alta resolución), grabar audio ambiental, cargar contenidos de directorio, recopilar detalles de ventanas activas, recopilar datos de medios USB, ejecutar instrucciones emitidas por un servidor de comando y control (C2) y cambiar servidores C2.

El apodo NarwhalRAT es una referencia al uso que hace el malware de «%APPDATA%\naverwhale» para almacenar la información recopilada en el host comprometido. El nombre del directorio oculto es un intento de evadir la detección haciéndose pasar por Naver Whale, un navegador web desarrollado por la empresa de tecnología surcoreana Naver Corporation.

La implementación de NarwhalRAT por parte de APT37 es digna de mención, ya que marca un alejamiento de RokRAT, una familia de malware atribuida exclusivamente al grupo de hackers.

«Desde una perspectiva de infraestructura C2, el malware utiliza sitios web coreanos, incluido ‘daehoat[.]com’ y ‘novela21[.]co.kr’, como principales retransmisores de comunicación, al mismo tiempo que implementa una funcionalidad de comunicación basada en la API de almacenamiento en la nube pCloud», dijo la compañía de ciberseguridad de Corea del Sur.

«En particular, se identificaron dentro del código rutinas específicas de pCloud que procesan los parámetros ‘folderid’ y ‘auth’. Esto indica que el malware fue diseñado para utilizar un servicio de nube legítimo como canal C2 secundario en forma de un solucionador de caída muerta«.

Ciberseguridad

Genians dijo que la actividad comparte «múltiples similitudes» con ataques anteriores basados ​​en Python orquestados por ScarCruft, incluida una campaña de phishing que ha utilizado la confirmación de boletos y señuelos de invitaciones a eventos para engañar a objetivos potenciales para que abran archivos ZIP que contienen archivos LNK.

El cadena de ataque Se desarrolla de manera similar en el sentido de que el archivo LNK actúa como un conducto para un script por lotes ofuscado descargado desde un servidor C2 remoto, que luego descarga el binario de Python y un archivo CAT, lo que finalmente resulta en la implementación de un script de Python compilado capaz de ejecutar comandos remotos y enviar los resultados al servidor C2.

Curiosamente, los nombres de las tareas programadas que se utilizan para configurar la persistencia siguen una convención de nomenclatura similar. Mientras que la infección NarwhalRAT crea una tarea programada llamada «MicrosoftUserInterfacePicturesUpdateTackMachine», la segunda cadena usa el nombre «MicrosoftMusicLibrariesPackageTaskMachine».

«En general, se considera que NarwhalRAT es un malware RAT avanzado que integra un cargador de múltiples etapas basado en Python, una estructura de ejecución en memoria, un marco operativo multi-C2 y funciones de recopilación selectiva de información», dijo Genians.

La falla del copiloto de Microsoft 365 con un solo clic podría haber permitido a los atacantes robar correos electrónicos, archivos y códigos MFA

Un solo clic en un enlace confiable de Microsoft podría haber permitido a un atacante extraer correos electrónicos, detalles del calendario y archivos indexados de Microsoft 365 Copilot Enterprise Search.

Los investigadores de Varonis Threat Labs encadenaron tres errores en una ruta de exfiltración con un solo clic que llaman Buscarfuga. Debido a que el enlace apuntaba a un dominio microsoft.com real, era poco probable que las herramientas tradicionales de filtrado de URL y antiphishing lo marcaran.

Sin mensaje, sin contraseña, sin segundo clic. Microsoft asignado CVE-2026-42824 y lo marcó crítico; las puntuaciones CVSS fueron más bajas y en desacuerdo, 6,5 de Microsoft y 7,5 de Base de datos nacional de vulnerabilidad. La empresa mitigó la falla en su backend, por lo que los clientes no tienen nada de qué preocuparse, y Varonis presentó una prueba de concepto, una explotación no observada.

Tres errores, un clic

El aviso de Microsoft describe la falla como una inyección de comando que puede exponer información a través de una red. En la práctica, SearchLeak acumula una debilidad específica de la IA en dos errores web antiguos, y cada enlace es necesario para el siguiente.

El punto de entrada es el q parámetro en la URL de búsqueda de Copilot Enterprise. Está destinado a una consulta en lenguaje natural, pero Copilot lee todo lo que contiene como instrucciones, no solo una cadena de búsqueda.

varonis llama a esto Inyección de parámetro a mensaje. Un atacante escribe una URL que le indica a Copilot que busque en el buzón, tome un título de correo electrónico y lo coloque dentro de una URL de imagen. La víctima no escribe nada. Hacen clic y Copilot hace el trabajo.

Ciberseguridad

Lo siguiente es una condición de carrera en cómo se representa la respuesta. La barrera de seguridad de Microsoft envuelve la producción de Copilot bloquea para que el navegador trate el marcado como texto. El problema es el tiempo: el ajuste ocurre después de que Copilot termina de generar, pero el navegador procesa la transmisión a medida que llega. el inyectado La etiqueta se dibuja y activa su solicitud antes de que se ejecute el desinfectante. Cuando se neutraliza la salida, la solicitud ya se ha ido.

El último enlace pasa los datos más allá de la Política de seguridad de contenido de la página. El CSP en m365.cloud.microsoft bloquea imágenes de dominios arbitrarios, pero incluye en la lista blanca *.bing.com. El punto final «Buscar por imagen» de Bing acepta la URL de una imagen y la recupera del lado del servidor para analizarla. Apunte esa recuperación al servidor de un atacante con el texto robado codificado en la ruta y Bing lo recupera. El CSP del navegador nunca se aplica porque la solicitud proviene de la infraestructura de Bing. Bing se convierte en el proxy de exfiltración. La lista de permitidos de CSP se esconde.

En conjunto: la víctima hace clic, Copilot busca sus datos, la respuesta incorpora un valor como un asunto de correo electrónico en una URL de imagen de Bing, el navegador llama a Bing durante la transmisión y Bing extrae la URL del atacante. El atacante lo lee de sus propios registros, por ejemplo, una solicitud de /Your_Security_Code_847291/img.png.

Lo que obtiene un atacante

Copilot Enterprise puede alcanzar todo lo que el usuario que haya iniciado sesión pueda alcanzar, a través de su acceso a Microsoft Graph, y el atacante hereda ese alcance sin siquiera iniciar sesión.

El premio más urgente se encuentra en la bandeja de entrada: códigos de un solo uso, códigos MFA y enlaces para restablecer contraseñas, que a menudo siguen siendo válidos durante unos minutos. Un script que los saca de un registro mientras la ventana está abierta puede hacerse cargo de una cuenta antes de que alguien se dé cuenta.

Ciberseguridad

El mismo acceso también llega a las invitaciones del calendario, notas de reuniones y cualquier archivo de SharePoint o OneDrive que Copilot haya indexado, donde se encuentran los datos salariales, las cifras de ganancias y los planes de adquisición.

SearchLeak es la segunda vez que Varonis muestra este patrón. El investigador de Varonis, Dolev Taler, demostró la misma técnica de un clic en un ataque Reprompt anterior contra Copilot Personal, y resistió contra Enterprise Search a pesar de las barreras de seguridad adicionales que se supone que debe imponer ese nivel.

El mismo patrón apareció en EchoLeak (CVE-2025-32711), el error de fuga de datos de Copilot sin clic que Aim Security reveló en 2025. SSRF y carreras de desinfectantes son clases de errores antiguos; la inyección rápida es la pieza nueva y hace que estén accesibles nuevamente.

Microsoft mitigó la falla en su backend y, debido a que Copilot Enterprise es un servicio administrado, los administradores de inquilinos no pueden parchear ni reconfigurar las partes que fallaron. Lo que pueden hacer es observar y contener.

Busque URL de Copilot Search que contengan cargas útiles codificadas o HTML en el parámetro q, y solicitudes salientes inusuales a los puntos finales de imágenes de Bing. Reforzar la gobernanza del acceso a los datos para que Copilot indexe menos, lo que reduce lo que puede alcanzar cualquier filtración futura.

Las estafas de Sniper Dz se dirigen a los usuarios de MENA a través de ofertas falsas de Facebook y alertas del navegador – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de actividades fraudulentas dirigidas a usuarios de todo Oriente Medio y el Norte de África mediante el empleo de varias cuentas fraudulentas de Facebook que se hacen pasar por políticos, figuras públicas y organizaciones de confianza.

«Estas cuentas promovían ofertas falsas, incluidos paquetes gratuitos de Internet móvil, compensaciones financieras y programas de subsidios gubernamentales», dijeron los analistas de Group-IB Anna Yurtaeva y Viacheslav Shevchenko. dicho.

«Se animaba a las víctimas a hacer clic en enlaces integrados para reclamar los beneficios anunciados, pero en lugar de ello eran redirigidas a través de una cadena de sitios web intermediarios que, en última instancia, conducían al phishing y a la infraestructura de monetización del tráfico».

La empresa de ciberseguridad con sede en Singapur dirige estas campañas a Sniper Dz, una plataforma llave en mano de phishing como servicio (PhaaS) que fue desmantelada el mes pasado en una operación dirigida por INTERPOL. Los hallazgos indican que la plataforma va más allá de facilitar el robo de credenciales, generando ingresos ilícitos a través del abuso de notificaciones en el navegador, suscripciones premium de SMS, llamadas con tarifas premium y estafas de inversión.

Ciberseguridad

Un «embudo típico de víctima de estafa de Sniper Dz» comienza con señuelos de ingeniería social localizados, en los que los estafadores se hacen pasar por proveedores de telecomunicaciones conocidos como Algérie Télécom para promover ofertas falsas y dirigir a los usuarios a dominios alojados en Link in bio, servicios que actúan como una capa intermediaria entre la publicación en las redes sociales y el destino final.

«En lugar de dirigir a las víctimas directamente a un sitio web malicioso, la campaña primero dirige a los usuarios a través de plataformas confiables de agregación de enlaces como Linkbio y Linktree», dijeron los investigadores de Group-IB. «Los atacantes crean páginas de destino señuelo en dominios operados por estos servicios».

El ataque finaliza dirigiendo a las víctimas a una página que obtiene permisos de notificación del navegador solicitando a los usuarios que hagan clic en «Permitir» para continuar. Detrás de escena, el código incrustado en la página web suscribe el navegador web a un sistema de notificaciones push mediante una identificación voluntaria del servidor de aplicaciones (INSÍPIDO) clave pública.

Group-IB dijo que se ha observado la misma clave VAPID en campañas que se hacen pasar por proveedores de telecomunicaciones en Argelia y estafas relacionadas con inversiones dirigidas a usuarios en múltiples regiones.

«Debido a que las claves públicas VAPID se utilizan para identificar el servicio de notificación responsable de entregar mensajes push, su reutilización puede proporcionar información valiosa sobre las relaciones de infraestructura subyacentes», dijo la compañía. «La aparición constante de la misma clave en campañas distintas sugiere que los operadores dependen de un ecosistema compartido de notificaciones push en lugar de una infraestructura independiente».

Además, la página secuestra el botón Atrás inyectando 10 estados históricos falsos, engañando a los usuarios para que visiten sitios que pueden publicar anuncios no solicitados o atrapándolos en una «prisión del botón Atrás» y dentro de contenido controlado por atacantes para inflar las impresiones de anuncios, promover estafas o entregar contenido malicioso.

Ciberseguridad

«La página también implementa una técnica de tabulación que se activa cuando los usuarios interactúan con ciertos enlaces», señaló la empresa de ciberseguridad. Si un enlace abre una nueva pestaña del navegador, un script retrasado redirige silenciosamente la pestaña original a otro destino controlado por los operadores.

«Esto permite que la campaña continúe generando tráfico a través de su infraestructura de redirección y monetización incluso después de que la víctima crea que ha abandonado el sitio. Al combinar el abuso de notificaciones del navegador con la manipulación del historial y las redirecciones con pestañas, los operadores hacen que sea mucho más difícil para los usuarios escapar del ecosistema de estafa».

Una vez que los usuarios se inscriben en la infraestructura de notificación, los ataques avanzan a la fase de monetización, dirigiendo a las víctimas a un sistema de distribución de tráfico (TDS) que determina qué estafa presentar en función de factores como el tipo de dispositivo, la ubicación y el operador de telefonía móvil. Las posibles vías incluyen estafas de llamadas con tarifas superiores, fraude de suscripciones de SMS premium y estafas de inversión.

«Esta campaña demuestra cómo las operaciones de fraude modernas dependen cada vez más del abuso de tecnologías web legítimas en lugar del malware tradicional», dijo Group-IB. «En lugar de infectar dispositivos, los operadores explotan plataformas confiables, funciones de navegador y técnicas de ingeniería social para guiar a las víctimas a través de un embudo de monetización cuidadosamente diseñado».

Miembro del grupo de ransomware Conti se declara culpable y enfrenta hasta 20 años de prisión

Ex miembro de Conti desde hace mucho tiempo, un grupo de ransomware que atacó a más de 1000 organizaciones en todo el mundo antes de disolverse en 2022, se declaró culpable de participar en algunos de esos ataques en un tribunal federal el miércoles, dijo el Departamento de Justicia.

Oleksii Oleksiyovych Lytvynenko, también conocido como Alexsey Alexseevich Litvinenko, admitió que se unió al prolífico grupo de cibercrimen en septiembre de 2021 y tenía datos sobre 12 víctimas, incluidas ocho con sede en Estados Unidos. Según los funcionarios, el hombre de 44 años dijo al tribunal que desarrolló malware que Conti utilizó en algunos de sus ataques.

«El acusado y sus conspiradores utilizaron el ransomware Conti para aterrorizar a personas y empresas en Estados Unidos y en todo el mundo, causando millones de dólares en daños», dijo en un comunicado A. Tysen Duva, fiscal general adjunto de la división penal del Departamento de Justicia.

Lytvynenko y sus cómplices utilizaron el ransomware para atacar a más de 1.000 víctimas en todo el mundo, atrapando víctimas en 47 estados, Washington, Puerto Rico y alrededor de 31 países, según el Departamento de Justicia. El FBI estima que Conti extorsionó a las víctimas por más de 150 millones de dólares en pagos de rescate.

El ciudadano ucraniano se declaró culpable de conspiración para cometer fraude electrónico y enfrenta hasta 20 años de prisión al momento de su sentencia, que está programada para el 10 de septiembre.

Lytvynenko fue arrestado en Irlanda en julio de 2023, extraditado a Estados Unidos en octubre de 2025 y permanece bajo custodia federal en Tennessee, donde se encuentran al menos tres de sus víctimas. Salió de Ucrania en 2022 y obtuvo un estatus de protección temporal en Irlanda, residiendo en Cork en el momento de su arresto.

Los fiscales dijeron que Lytvynenko y sus cómplices extorsionaron alrededor de 634.000 dólares en Bitcoin a dos víctimas en Tennessee, incluida una entidad gubernamental no revelada que resultó en el compromiso de un departamento del sheriff, servicios médicos de emergencia locales y un departamento de policía local. Según una acusación que se hizo pública el otoño pasado, Lytvynenko y sus cómplices también filtraron datos que robaron de otra víctima de Tennessee después de que se negó a pagar una demanda de rescate de 3 millones de dólares.

Cuatro de los presuntos cómplices de Lytvynenko (Maksim Galochkin, Maksim Rudenskiy, Mikhail Mikhailovich Tsarev y Andrey Yuryevich Zhuykov) fueron acusado en 2023 en el mismo tribunal federal por delitos relacionados con su presunta participación en los ataques de Conti de 2020 a 2022.

Las autoridades dijeron que Lytvynenko participó en delitos cibernéticos después de que Conti se disolviera y sus miembros se dividieran en nuevos grupos, y agregaron que «estaba dormido pero al alcance de una computadora portátil abierta que ejecutaba Cobalt Strike» en el momento de su arresto.

En un momento, Conti estuvo entre los grupos de ransomware más prolíficos a nivel mundial, lo que afectó a cientos de proveedores de infraestructura crítica, al gobierno de Costa Rica en 2022 y, en última instancia, llevó al Departamento de Estado a ofrecer una recompensa de 10 millones de dólares por información relacionada con los líderes de Conti. El grupo fue notoriamente resistente, se recuperó con nueva infraestructura y alcanzó nuevos objetivos después de que una filtración masiva expusiera chats entre los miembros del grupo en 2022.

Conti se disolvió más tarde ese año, pero los miembros del grupo en cirílico cambiaron su nombre a tres subgrupos: Zeon, Black Basta y Quantum, que rápidamente pasó a llamarse Royal, antes de volver a llamarse BlackSuit en 2024.

«La declaración de culpabilidad de Lytvynenko es un paso importante para responsabilizar a los ciberdelincuentes por el daño que infligen a las víctimas en todo el mundo», dijo Brett Leatherman, subdirector de la división cibernética del FBI, en un comunicado. «Lytvynenko se benefició del miedo y la coerción, conspirando para utilizar el ransomware Conti para extorsionar a las víctimas y robar sus datos».

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.

Microsoft bate el récord del Patch Tuesday con 206 vulnerabilidades

Microsoft abordó la friolera de 206 vulnerabilidades que acechan en su amplia cartera de productos empresariales y sistemas fundamentales en el informe de este mes. Actualización del martes de parcheslo que marca el mayor lote mensual de parches de seguridad registrado por el proveedor, según los investigadores.

La enorme variedad de vulnerabilidades en el último volcado de defectos de Microsoft acentúa una tendencia alarmante en toda la tecnología: se han materializado temores y advertencias sobre una avalancha de software plagado de errores. Y la enfermedad se está extendiendo.

«Es extraordinario que Microsoft pueda producir tantos parches en un solo mes, pero genera preocupación», escribió Dustin Childs, jefe de concientización sobre amenazas en la Iniciativa Día Cero de Trend Micro, en un publicación de blog Martes.

Los investigadores destacan constantemente el papel que desempeña la inteligencia artificial a la hora de descubrir más vulnerabilidades y ayudar en el desarrollo de parches y pruebas. Childs no es el único que se pregunta si esta es la nueva normalidad y cómo afectará eso a las estrategias de los defensores para la priorización y el despliegue de parches.

«La proverbial caja de Pandora se ha abierto y, a medida que estén disponibles modelos de IA más avanzados, esperamos que la norma continúe aumentando en todos los ámbitos, no solo para el martes de parches», dijo Satnam Narang, ingeniero senior de investigación de Tenable, en un correo electrónico.

Esta inundación de vulnerabilidad no es un evento único o raro. La mitad de las actualizaciones del martes de parches de Microsoft durante la primera mitad de este año contenían un volumen de defectos de tres dígitos.

«La cantidad actual de CVE enviadas por Microsoft este año excede la cantidad total de CVE enviadas en todo 2018», escribió Childs.

Microsoft reveló tres vulnerabilidades: CVE-2026-45586, CVE-2026-50507 y CVE-2026-49160 – que eran conocidos públicamente en el momento del lanzamiento, pero aún no explotados en la naturaleza, según la compañía.

Sin embargo, en una actualización fuera de banda del 19 de mayo, el proveedor reveló y lanzó un parche para CVE-2026-41091una vulnerabilidad de día cero explotada activamente que afecta a Microsoft Defender.

Microsoft reveló una vulnerabilidad de gravedad máxima: CVE-2026-48567que afecta a Azure HorizonDB, y nueve defectos con calificaciones CVSS críticas. La compañía designó 15 de las vulnerabilidades que abordó este mes como con mayor probabilidad de ser explotadas.

La lista completa de vulnerabilidades abordadas este mes está disponible en Centro de respuesta de seguridad de Microsoft.

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.