Actores de amenazas asociados con el Anubis Se ha observado que una operación de ransomware aprovecha la vulnerabilidad Citrix Bleed 2 (CVE-2025-5777) para obtener acceso inicial.
«Aunque las tácticas difieren entre los afiliados, surgieron patrones comunes en el oficio mediante el uso de herramientas legítimas de monitoreo y administración remota (RMM), acceso a credenciales y procedimientos prácticos con el teclado utilizados para el movimiento lateral», Arctic Wolf dicho en un informe publicado esta semana.
«Los afiliados de Anubis abusaron repetidamente de herramientas legítimas de administración y acceso remoto, incluidas ScreenConnect, Zoho Assist, MeshAgent, Remotely, UltraVNC y Total Software Deployment, para integrarse con la actividad normal de TI mientras mantenían el control de los sistemas de las víctimas».
Anubis es un grupo de ransomware como servicio (RaaS) que surgió por primera vez a finales de 2024 como un cambio de marca del ransomware Sphinx. La operación de ransomware se anunció formalmente en el foro clandestino Ransomware and Advanced Malware Protection (RAMP) en febrero de 2025. Según datos de Ransomware.Live, el grupo de delitos cibernéticos se ha cobrado 91 víctimas en su sitio de filtración de datos, y solo en junio de 2026 se reportaron 11 víctimas.
Algunos de los sectores destacados a los que se dirigen incluyen la atención sanitaria, los servicios empresariales, la fabricación, la tecnología y los servicios financieros. Más del 50% de las víctimas se encuentran en Estados Unidos, seguido por el Reino Unido, Australia, Francia y Canadá.
En un informe publicado en julio de 2025, Rubrik Zero Labs dijo que Anubis anuncia atractivas divisiones de ganancias, ofreciendo a los afiliados el 80% de los montos del rescate pagado, y lo combina con una función de borrado de datos irreversible que aumenta la presión sobre las víctimas para que paguen.
«Cuando se activa el módulo /WIPEMODE de Anubis, los archivos permanecen en los directorios pero se reducen a un tamaño de 0 KB independientemente del pago del rescate», Rubrik anotado En el momento. «Saber que los actores de amenazas pueden revertir los entornos de las víctimas a este estado de tierra arrasada con un solo comando aumenta significativamente la presión sobre las víctimas para que paguen antes de que el limpiador se active por completo».
Las intrusiones de ransomware, observadas este año, implican tanto el uso de credenciales VPN válidas como la explotación de CVE-2025-5777 (puntuación CVSS: 9,3), una falla crítica que afecta a Citrix NetScaler ADC y Gateway y que un atacante podría abusar de ella para evitar la autenticación cuando el dispositivo está configurado como Gateway o servidor virtual AAA.
Se desconoce la fuente exacta de las credenciales de VPN utilizadas en estas intrusiones. Sin embargo, es posible que se hayan obtenido tras un compromiso previo, o mediante intermediarios de acceso inicial (IAB), relleno de credenciales o actividad de ladrón de información.
«Además de la explotación de CitrixBleed 2, se observaron inicios de sesión válidos de Cisco AnyConnect VPN desde varios ASN de alojamiento, incluidos AS20473 – The Constant Company y AS55286 – ServerMania», explicó Arctic Wolf. «La autenticación de VPN maliciosa fue seguida por una actividad de inicio de sesión que involucraba a RDP y SMB, lo que conducía al acceso a credenciales, la creación de servicios PsExec, la implementación de RMM y, en última instancia, la invocación de herramientas de transferencia a la nube para la exfiltración».
El movimiento lateral se facilita a través de RDP y PsExec, lo que luego conduce al despliegue de varias herramientas RMM legítimas para acceso persistente, otorgando a los atacantes la capacidad de transferir archivos y ejecutar código de forma remota, mientras permanecen fuera del radar. Algunas intrusiones también configuran un túnel Cloudflare (también conocido como cloudflared) para establecer túneles hacia los entornos de las víctimas.
La siguiente fase de los ataques implica recopilar credenciales para facilitar un acceso más profundo al entorno comprometido, después de lo cual se instalan herramientas como S3 Browser, rclone, s5cmd, WinSCP y PuTTY para la transferencia o exfiltración de datos antes de la implementación del ransomware. Paralelamente, se toman medidas para debilitar las defensas del sistema y complicar el análisis posterior al incidente.
«Estas técnicas incluían la desactivación de la protección en tiempo real de Windows Defender, la actividad de desinstalación de Sophos, artefactos relacionados con PCHunter y limpieza o manipulación de registros en múltiples sistemas», explicó la empresa de ciberseguridad. «En al menos una intrusión, se eliminó un cifrador Anubis después de la ejecución, lo que redujo la disponibilidad de artefactos de carga útil en el disco para su posterior análisis».
La puerta trasera de los caballeros y el exploit de día 0 detallados
La revelación se produce como lo detalló Kaspersky. los caballeros La explotación por parte del grupo RaaS de vulnerabilidades conocidas y credenciales de inicio de sesión robadas o débiles para violar objetivos y su uso de una puerta trasera basada en Go para permitir la ejecución remota de comandos después del reconocimiento, el movimiento lateral a través de la Política de grupo o PsExec y la evasión de defensa utilizando la técnica de traer su propio controlador vulnerable (BYOVD).
El implante está diseñado para recopilar información del sistema y exfiltrarla a un servidor externo («81.177.215[.]15:9443») a través de una conexión TCP bidireccional y espera respuestas del operador que luego se ejecutan en el host usando «cmd.exe» si el byte de respuesta es «c». Si el byte es «s», se establece una conexión de proxy SOCKS.
«Esta funcionalidad probablemente permita al equipo rojo de The Gentlemen girar dentro de la red objetivo y ampliar su cobertura de escaneo», Kaspersky dicho. «Dadas las capacidades del implante de puerta trasera, como establecer comunicación bidireccional, ejecutar comandos, configurar un proxy SOCKS y recopilar información, está claro que también se puede utilizar para expandir la cadena de ataque según sea necesario».
Según Expel, el grupo RaaS también ha utilizado como arma una vulnerabilidad de día cero en un controlador de proveedor externo poco conocido como parte de su arsenal BYOVD para obtener acceso a nivel de kernel, eludir las protecciones de seguridad de Windows y eliminar los procesos de seguridad protegidos asociados con Microsoft, ESET, Palo Alto Networks y SentinelOne. El conductor en cuestión es ktapi.sysque forma parte de una API desarrollada por Kontron.
«Aún no está claro cómo los actores de la amenaza llegaron a poseer el archivo o obtuvieron conocimiento de su vulnerabilidad», Marcus Hutchins. dicho. «BYOVD sigue siendo una gran amenaza para las empresas, ya que permite a los atacantes desactivar sistemas de seguridad de última generación en segundos. Incluso utilizando la última versión de Windows, con todas las mitigaciones de exploits habilitadas, no proporciona una protección completa».
Asociación de ransomware entre VECT y TeamPCP
Los hallazgos también surgen tras una investigación de la Unidad Contra Amenazas de Sophos sobre la asociación entre VECT y TeamPCP, que se anunció en marzo de 2026 para combinar el robo de credenciales impulsado por ataques a la cadena de suministro con la implementación de ransomware.
«La asociación formal entre TeamPCP y VECT permite a VECT implementar ransomware en todas las organizaciones comprometidas en los ataques a la cadena de suministro de Trivy y LiteLLM», dijo Sophos en un informe compartido con The Hacker News. «Antes de la asociación con VECT, TeamPCP ejecutaba otra operación de ransomware bajo la marca CipherForce. CipherForce enumeró a seis víctimas en su sitio de filtración en febrero de 2026 y lo renombró como sitio de filtración de TeamPCP en mayo».
Análisis recientes de Check Point y SALTO SEC han descubierto que VECT contiene fallas de implementación que causan que cualquier archivo de más de 128 KB se destruya permanentemente en lugar de cifrarse, lo que llevó a TeamPCP a emitir una declaración indicando que nunca habían usado el cifrado de VECT en ataques. «Somos dueños de CipherForce, nuestro propio casillero privado», afirmó el grupo.
«La alianza Vect/TeamPCP representa un cambio significativo en el panorama de amenazas de ransomware, incluso teniendo en cuenta las deficiencias técnicas que socavan su eficacia operativa», Sophos dicho.
«La convergencia del robo de credenciales de la cadena de suministro a gran escala, una operación RaaS madura y la movilización masiva de foros clandestinos constituye un modelo sin precedentes de implementación de ransomware industrializado que reduce significativamente la barrera de entrada del ciberdelito».
Google se ha degradado significativamente tuerca netauna de las redes más grandes que convierte los dispositivos domésticos en repetidores alquilados para el tráfico de otras personas.
En colaboración con el FBI, Lumen y otros, el Threat Intelligence Group (GTIG) de Google dijo esta semana había reducido en millones el conjunto de dispositivos utilizables de la red.
Google identifica NetNut, también rastreado como popacomo una red extendida a través de dispositivos domésticos en todo el mundo, incluidos televisores inteligentes y cajas de transmisión, y GTIG estima que la red tiene al menos 2 millones de dispositivos.
Si uno de esos dispositivos está en su casa, los extraños pueden dirigir su propio tráfico a través de su conexión a Internet y su dirección es la culpable de lo que hagan con él.
Cómo funciona
Una red de proxy residencial vende acceso a direcciones de Internet residenciales reales. Los atacantes pagan para dirigir su tráfico a través de su conexión de modo que parezca una navegación doméstica normal, no el tráfico del centro de datos que las herramientas de seguridad tienden a bloquear.
Para crear ese grupo, los operadores necesitan que su código se ejecute en dispositivos domésticos. Algunos dispositivos se envían con él preinstalado en hardware económico de otra marca; otros lo detectan cuando alguien instala una aplicación gratuita que lo oculta. Una vez que está en funcionamiento, el dispositivo se convierte en un «nodo de salida», una puerta por la que fluye el tráfico de otras personas.
Google dice que un nodo de salida lleva el tráfico externo al interior de la red doméstica, dando a los atacantes un punto de apoyo para llegar a otros dispositivos en ella. Algunos de estos dispositivos domésticos también han sido incluidos en grandes botnets de ataque como Mirai y Badbox 2.0.
En una sola semana de junio, GTIG contó 316 grupos de amenazas distintos que utilizaban nodos de salida sospechosos de NetNut, incluidos grupos de ciberdelincuentes y de espionaje, para ocultar su ubicación real y ejecutar Ataques para adivinar contraseñas.
La empresa detrás de esto
A diferencia de la mayoría de las botnets proxy, NetNut se remonta a una empresa pública. En junio, investigadores en Qurium, Synthient, Nokia Deepfield y Spur vincularon a Popa con NetNut.
NetNut es un proveedor de proxy propiedad de la empresa israelí que cotiza en bolsa Alarum Technologies (NASDAQ: ALAR). En una prueba controlada, Synthient dijo El tráfico que envió al portal comercial de NetNut salió a través de un dispositivo que había inscrito en Popa.
Synthient lo planteó como evidencia de la ruta del tráfico, no como prueba de lo que NetNut sabía o pretendía. La propia inteligencia de Google coincide: trata a NetNut y Popa como la misma red, y dice que los informes públicos coinciden con su visión de cómo NetNut construye su botnet. Hacker News cubrió los hallazgos de los investigadores cuando fueron publicados.
Alarum rechaza la etiqueta de «botnet». Califica la investigación como «afirmaciones demostrablemente inexactas y deducciones erróneas en lugar de hechos verificados», y dice que su software es para compartir ancho de banda de forma consentida que no compromete los dispositivos en los que se ejecuta.
Las pruebas de los investigadores complican esa defensa: Synthient informó que ninguna de las más de 20 aplicaciones que examinó realmente mostró a los usuarios una solicitud de consentimiento.
Por qué un derribo no es suficiente
Cortar NetNut es complicado por diseño. NetNut ejecuta un programa de revendedores que permite a otras empresas vender su red con sus propias marcas. Google dice que tiene gran confianza en que muchas marcas de proxy populares, aparentemente separadas, en realidad están revendiendo el mismo grupo de NetNut.
Entonces, una sola eliminación afecta a muchas marcas que parecen independientes pero no lo son.
Es también por eso que Google llama a esto degradación, no muerte. Dice que su acción anterior contra una red IPIDEA similar demostró que estas redes pueden parecer resistentes: los operadores comienzan a comprar capacidad de sus rivales y, de hecho, se convierten ellos mismos en revendedores. Un daño real y duradero, dice Google, significa perseguir a varios proveedores conectados a la vez.
En enero, Google y sus socios interrumpieron IPIDEA, una red con sede en China que en su apogeo era una de las más grandes de su tipo. En julio de 2025, Google llevó ante los tribunales a los operadores de Badbox 2.0, la botnet de dispositivos Android TV secuestrados cuyos componentes se superponen con los de Popa. En cada ocasión, las redes se mostraron testarudas.
Qué deberían hacer los consumidores
La señal de advertencia más clara es una aplicación que ofrece pagarle por su «ancho de banda no utilizado» o por «compartir su Internet». Esa es una de las principales formas en que crecen estas redes.
Más allá de eso:
Cíñete a las tiendas de aplicaciones oficiales y comprueba qué permisos solicita una aplicación VPN o proxy.
Mantenga activadas las protecciones integradas como Google Play Protect.
Compre cajas de transmisión y hardware de TV inteligente de fabricantes conocidos, no de marcas anónimas.
La demanda de estas direcciones particulares no desaparece cuando una red deja de funcionar; simplemente se mueve. Para los defensores y las plataformas, la siguiente señal a observar es si el tráfico vinculado a NetNut resurge bajo las marcas de revendedores.
This week’s security news is mostly about weak spots.
Browsers, bots, sandboxes, AI systems, and email flows all show the same problem in different ways. Everything looks normal until someone tests a small gap and finds a way through.
This is not one big break. It is small permissions, weak checks, open systems, and normal tools doing things they were allowed to do. That same pattern runs through the stories below.
Ransomware phishing lure
A phishing campaign is targeting small businesses across Europe, Asia, the Middle East, and the U.S. with fake investigation emails impersonating law enforcement officials. «The emails claim to contain evidence of suspicious company activity and pressure recipients into opening a password-protected archive,» Bitdefender said. «Recipients are directed to a Proton Drive-hosted file that ultimately delivers ransomware. The ransomware appears to be a custom-built payload rather than a known ransomware family.»
Sandbox root escape
New research from Armadin has discovered an attack chain affecting Claude Cowork on Windows. The attack allows an attacker with local code execution to plant a malicious file in Claude Desktop’s application directory, hijacking a trusted process to communicate with Cowork’s underlying VM service. «An attacker with local code execution could run arbitrary commands as root in Claude Cowork’s sandbox without network egress restrictions,» the company said. The exploit takes advantage of two unvalidated parameters in the service’s interface that allow the attacker to run commands as root and bypass network filtering entirely, thereby allowing sensitive data to be exfiltrated to attacker-controlled infrastructure. Following responsible disclosure on May 29, 2026, Anthropic said it does not consider it to be a security issue because exploitation requires pre-existing local code execution on the host.
Email privacy flaw
A vulnerability has been disclosed in Apple’s Hide My Email service that allows users’ real email addresses to be unmasked. Tyler Murphy, the researcher who found the bug, said that he reported the issue to Apple over a year ago and that it continues to remain unpatched. «We don’t know the full scope of the issue, but in our limited tests with volunteers, 100% of Hide My Email addresses were exploitable,» Murphy told 404 Media. Exact details surrounding the vulnerability have been withheld to avoid potential exploitation concerns.
China-linked RAT activity
A customized version of the open-source DCRat framework dubbed BeepRAT has been identified as distributed via a Chinese phone number management utility packaged within a ZIP archive, per Rubrik Zero Labs. «The archive contained a .NET application named HFY.exe alongside several third-party libraries commonly associated with database-driven applications,» Rubrik said. «Although the application appeared to function as a telephone number management tool, further analysis revealed a sophisticated multi-stage infection chain that ultimately deployed the customized BeepRAT payload.» The malware establishes persistence on the host via scheduled tasks, and resolves the command-and-control infrastructure using DNS-over-HTTPS (DoH) requests. It then beacons a packet containing information about the compromised host, after which a persistent communication channel is opened to receive incoming commands that allow the malware to transfer files between the host and the server, launch interactive command prompt sessions, issue commands to it, launch PowerShell sessions, enumerate running processes and available storage drives, terminate a specified process, perform file system operations, record through webcam, log keystrokes, take screenshots, list active network connections, download and run .NET assemblies in memory, and launch a proxy. It’s assessed that BeepRAT operates within the China-nexus espionage ecosystem.
AI cyber benchmark
An evaluation of OpenAI’s GPT-5.6 Sol on real-world offensive security benchmarks by AI security lab Irregular has found the model to perform slightly better than GPT-5.5, while continuing to struggle with well-defended targets and complete end-to-end attacks. «GPT-5.6 Sol demonstrated capabilities relevant to offensive cyber misuse, including finding and exploiting high-impact zero-day vulnerabilities across multiple real systems,» it said. «These capabilities were demonstrated on sensitive, widely used classes of systems, including mobile operating systems and database systems. Despite these capabilities, GPT-5.6 Sol continued to show clear limitations against hardened targets and in orchestration, operationalization, and operational security. Performance also degrades when tasks require sustained logical coherence over long horizons or quick, time-sensitive decision-making.»
Platform-aware phishing
Cofense said it’s observing a «clear shift in phishing operations» where threat actors are moving beyond broad, one-size-fits-all campaigns to adopt platform-aware delivery that adapts to the victim’s device, browser, and environment. Phishing campaigns have been found to deliver Itarian RAT or the ConnectWise tool via Ninite Loader on Windows, while serving credential harvesting phishing pages when URLs are visited from macOS or Android. The operating system-specific payloads are delivered by fingerprinting victims through User-Agent data. «What began as simple Windows-focused malware distribution campaigns has evolved into more sophisticated campaigns that can selectively deliver credential phishing, remote access tools, or malware across Windows, MacOS, and Android,» it said. «This trend reflects a broader strategic change in the threat landscape, one that is designed to increase the likelihood of compromise, expand target coverage, and improve threat actor return on investment.»
Russian hacker reward
The U.S. State Department is offering a reward of up to $10 million for information leading to the identification or location of threat actors associated with UNC5792, a malicious cyber group associated with the Russian Federal Security Service (FSB) Border Guards and UNC4221, a malicious group of cyber actors working on behalf of the Russian military services. UNC5792 has been linked to widespread phishing campaigns targeting Signal and WhatsApp accounts of U.S. government officials, military leadership, and allied personnel with an aim to gain unauthorized access. «Although these malicious cyber activities did not exploit any security vulnerability in the platforms’ encryption protections, they have compromised thousands of individual commercial messaging application accounts,» the State Department said.
LLM role confusion
New research from a group of academics has revealed that machine learning models cannot reliably distinguish between authorized and unauthorized input, leaving them susceptible to a persistent problem called prompt injection. «LLMs see the world as a single stream of text, partitioned into roles like or ,» the researchers said. «We trace prompt injection to role confusion: models perceive the source of text from how it sounds, not its labeled role. A command hidden in a web page hijacks an agent simply because it sounds like text, despite its label.» The attack, dubbed CoT Forgery, involves injecting fabricated reasoning into user prompts and tool outputs, causing the models to mistake the forgery for their own thoughts and act on them, yielding 60% attack success against frontier models. The attack essentially exploits the trust a model places in its own thinking.
Covert tracking rollback
Anthropic said it plans to remove the hidden code it added to Claude Code several months ago to detect unauthorized distillation efforts. The relevant code checks Claude Code’s base URL environment variable that’s used to route API requests to a proxy or gateway. If the base URL has been overridden, the code snippet checks the system time zone and whether the hostname matches any entry in a list of known Chinese companies, account resellers, and gateway domains. «This is an experiment we launched in March that was meant to prevent account abuse from unauthorized resellers and protect against distillation,» Anthropic’s Thariq Shihipar said. «The team has landed stronger mitigations since then and we’ve actually been meaning to take this down for a while.»
Clipboard attack defense
Opera has introduced Paste Protect, a new security feature designed to block ClickFix-style attacks that deceive users into executing malicious commands through social engineering techniques. «Paste Protect helps identify situations where malicious websites attempt to either replace something you copied with a malicious version or place potentially harmful commands on your clipboard and later trick you into pasting them onto a terminal,» the browser maker said. «When any kind of suspicious clipboard activity is detected, Opera’s Paste Protect warns users before dangerous content can be executed.» The development comes as ClickFix continues to be a popular initial access vector for threat actors. According to Huntress, ClickFix was responsible for over 53% of all malware loader activity in 2025. Data from ReliaQuest for the period between March 1 and May 31, 2026, ClickFix remained the dominant delivery method during this period and targeted both Windows and macOS systems. One notable trend observed during the period was that ClickFix activity appeared to shift from delivery via compromised websites to emailed links. «ClickFix demonstrates that the human element remains one of the most effective attack vectors, especially when combined with legitimate system functionality and trusted binaries,» security researcher Bert-Jan Pals said.
Gmail phishing operation
A spear-phishing attack orchestrated by UNC1151 (aka Ghostwriter) targeting Belarusian pro-democracy politician Yury Hubarevich has been assessed to be part of a much broader credential phishing operation. The activity involved sending emails from Gmail accounts claiming to have detected suspicious activity on targets’ Google accounts, urging them to click on a link to verify their account. The catch here was that entering the credentials on the phishing page harvested the victim’s login information and exfiltrated it to the attacker-controlled infrastructure. Attack surface management platform Censys has since uncovered additional domains impersonating the I.UA email portal, suggesting the activity also likely targeted Ukrainians.
FTC enforcement action
The U.S. Federal Trade Commission has fined Amazon $2.25 million to settle claims that the company failed to help customers who fell victim to identity theft. Consumers who contacted Amazon to report fraud were told by its customer service agents that they could not provide the application and business transaction records about fraudulent transactions made in their names for «security» or «privacy» reasons. «Amazon often puts identity theft victims through a Kafkaesque ordeal by demanding they identify the thief who stole their information before Amazon would release the records the law entitles them to – records that could help victims protect themselves and recover from the fraudulent conduct,» said Christopher Mufarrige, Director of the FTC’s Bureau of Consumer Protection.
Telegram RAT surge
A remote access trojan (RAT) named Millennium RAT has undergone an architectural shift from .NET to native C++, while still relying on the Telegram Bot API for command-and-control (C2). The malware is attributed to a developer named ShinyEnigma, who is also behind DotStealer and was first seen in September 2023. It is offered as malware-as-a-service (MaaS) for $50 for the first month, $10 for subsequent months, or a one-time $90 lifetime purchase. «As a full-featured remote access trojan, Millenium RAT 4.* is designed to compromise Windows machines,» Group-IB said. «It enables threat actors to exfiltrate sensitive browser and system data, capture screenshots and audio, perform keylogging, and download and run arbitrary executables.» Exploitation campaigns involving the malware are carried out by a threat actor cluster codenamed Y2K Operators. The threat actor has been active since May 2025, using social engineering as a way to trick users into executing malicious payloads by masquerading them as legitimate software or cracked applications. As of writing, 62,289 devices have been infected with the Millenium RAT 4.* versions, with more than 16,000 infections reported in the month of March 2026 alone. In an interesting twist, the attackers even target other cybercriminals. «They take popular RATs, builders, and exploit kits, add a backdoor, and redistribute them — so the would-be attacker downloads a working tool and gets infected at the same time,» Group-IB said.
Search hijack extension
Microsoft said it discovered a malicious Chromium-based extension that impersonates the AI-powered answer engine Perplexity AI to trick unsuspecting users into installing it. The extension, named «Search for Perplexity ai» (ID: flkebkiofojicogddingbdmcmkpbplcd), has since been taken down by Google, but not before it attracted 10,000 installs. «We assess its primary objective to be search traffic interception and data collection, which might enable downstream use cases such as profiling, targeted advertising, or other forms of misuse depending on operator intent,» the tech giant said. «However, unlike traditional search hijackers that rely primarily on aggressive monetization or visible redirection, this extension combines Manifest Version 3 (MV3) capabilities with intermediary infrastructure and declarativeNetRequest (DNR) rules to transparently intercept Omnibox queries while preserving the appearance of legitimate search results.» The attacks illustrate how threat actors continue to capitalize on the popularity of AI tools to abuse them as a social engineering vector.
Meeting bot controls
Microsoft said it’s introducing «smarter bot protection» features to tackle scenarios where bots connected to a third-party service attend meetings as AI tools become more common in enterprise setups. «Unexpected participants in a meeting can create security and privacy risks, particularly when sensitive information is being discussed,» it said. «That’s why we’re introducing a new Teams admin policy designed to give organizations more visibility and control over external bots in their meetings. This new experience helps organizers identify bots, and adds safeguards before they’re admitted, giving organizations greater confidence that only the intended participants and tools will be present.» As part of this effort, Microsoft intends to clearly distinguish between bots and human participants, give organizers more visibility when bots join a meeting, and issue warnings when organizers choose Admit all and bots are included. With these new safeguards rolling out, Microsoft plans to retire the existing CAPTCHA verification experience.
Defender zero-day abuse
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has confirmed that the now-patched Microsoft Defender vulnerability known as BlueHammer (aka CVE-2026-33825) was exploited in ransomware attacks. BlueHammer was first disclosed as a zero-day by an anonymous researcher named Chaotic Eclipse (aka Nightmare-Eclipse) in April 2026. It’s unclear which ransomware group has exploited the flaw.
Stolen AI compute abuse
Threat actors have been observed using a misconfigured Ollama model server as the reasoning engine for an automated, multi-stage offensive security tool called the VAPT framework, according to findings from Sysdig. The development marks a new evolution of LLMjacking, which refers to a form of resource hijacking attack in which malicious actors steal API keys, cloud credentials, or non-human identities to hijack an organization’s Large Language Model (LLM) resources. The unauthorized access is then abused to run heavy AI workloads or sell access to third-parties, leaving the legitimate account holder to pay the usage bills. «The actor was not chatting with the model or reselling access,» Sysdig’s Michael Clark said. «Instead, they wired access to the AI tool into a software pipeline that scans a target, matches it to known vulnerabilities, writes proof-of-concept exploits, and attempts to break into a victim’s environment — with the model making the decisions at every step.»
The lesson this week is simple: attackers do not need the front door when the side door is already open. A copied command, an exposed server, a trusted bot, a weak check. Small things become entry points when nobody treats them like one.
So read the list with that in mind. The loud part is the breach. The useful part is the quiet mistake that made it possible. Until next ThreatsDay.
Un presunto miembro de 19 años del grupo de extorsión Scattered Spider fue extraditado a los estados unidos la semana pasada y permanece bajo custodia federal a la espera de varios cargos por delitos cibernéticos, dijo el miércoles el Departamento de Justicia.
Peter Stokes, con doble ciudadanía de Estados Unidos y Estonia, supuestamente estuvo involucrado en Scattered Spider desde que se formó en 2022 y se jactó en las redes sociales de la lujosa vida trotamundos que disfrutaba cuando aún era un niño.
La red de delitos cibernéticos formada por jóvenes nativos de habla inglesa se ha infiltrado en más de 100 empresas desde 2022 y ha extorsionado a sus víctimas con más de 100 millones de dólares en todo el mundo, dijeron funcionarios.
«Scattered Spider ha atacado repetidamente a empresas estadounidenses, extorsionando a empleados, infligiendo pérdidas por valor de millones de dólares e interrumpiendo operaciones esenciales», dijo en un comunicado Brett Leatherman, subdirector de la división cibernética del FBI. «A través de sólidas asociaciones nacionales e internacionales, el FBI seguirá identificando, desbaratando y responsabilizando a los ciberdelincuentes, sin importar dónde se encuentren».
Stokes, también conocido como “Bouquet” y “Jordan”, está acusado de participar en múltiples intentos de extorsión y robo de datos, pero el FBI solo proporcionó detalles específicos sobre algunos ataques más recientes a un minorista de joyería de lujo en mayo de 2025 y a una compañía de seguros con sede en Estados Unidos en junio de 2025.
Los investigadores de delitos cibernéticos han estado rastreando la actividad en línea de Stokes desde 2022. Microsoft determinó su verdadera identidad e implicó a Stokes como miembro de Scattered Spider en una remisión criminal en octubre de 2024, según registros judiciales.
Todavía era un niño en ese momento y las autoridades normalmente no arrestan a los ciberdelincuentes conocidos hasta que llegan a la edad adulta. Stokes vivió en Estonia y los Emiratos Árabes Unidos mientras presuntamente cometía algunos de sus crímenes.
La policía arrestó a Stokes en Finlandia cuando intentaba abordar un vuelo con destino a Japón el 10 de abril, y poseía dos discos duros que contenían pruebas supuestamente incriminatorias. Hizo una comparecencia inicial ante el tribunal en Chicago el martes y se le ordenó permanecer en prisión.
Stokes exhibió una vida opulenta antes de su captura, según su actividad en las redes sociales y los registros de viajes del Departamento de Estado. Esto incluyó viajes y estancias múltiples en hoteles de lujo en París, Italia, España, Alemania, Nueva York, Florida, Nuevo México, Tailandia y Dubái entre 2024 y 2025, según una denuncia penal presentada en su contra ante el Tribunal de Distrito de Estados Unidos para el Distrito Norte de Illinois.
También publicó imágenes de relojes, mucho dinero en efectivo y una cadena aparentemente con incrustaciones de diamantes que representa las palabras «Hack the Planet».
Imágenes de la cuenta de Snapchat de Peter Stokes en febrero de 2025 y diciembre de 2024. Crédito: Departamento de Justicia
Los funcionarios también señalaron que la familia de Stokes parecía estar acomodada, ya que su padre fue ejecutivo anterior en dos importantes empresas europeas.
Stokes fue acusado de conspiración, intrusión cibernética y delitos de fraude.
«Los ataques maliciosos de Scattered Spider causaron perturbaciones generalizadas en empresas y organizaciones en todo Estados Unidos», dijo en un comunicado Andrew Boutros, fiscal estadounidense para el Distrito Norte de Illinois. «Estos cargos subrayan nuestro compromiso inquebrantable de mantener el ritmo de los actores criminales con conocimientos tecnológicos y responsabilizar a quienes buscan beneficiarse de las intrusiones cibernéticas, incluidos aquellos ubicados en jurisdicciones extranjeras que dañan a las empresas y víctimas estadounidenses».
El actor de amenazas conocido como toddygato se ha atribuido a un nuevo malware llamado Umbrij que está diseñado para obtener acceso subrepticio a la correspondencia de correo electrónico de una víctima a través de la API de Google.
«En esta campaña, los atacantes centraron su atención en las comunicaciones corporativas por correo electrónico alojadas en Gmail, apuntando a comprometer el acceso a través de API», Kaspersky dicho en un informe detallado publicado esta semana. «Debido a que la API de Google se basa en el protocolo OAuth 2.0 para la autorización, las aplicaciones pueden usar un token OAuth para acceder a los recursos de correo electrónico solicitados».
Se dice que el adversario desarrolló Umbrij para adquirir este token y usarlo para conectarse a la consola de administración del navegador en modo sin cabeza a través de un puerto de depuración remota.
Posteriormente, se emitieron una serie de solicitudes para obtener un código de autorización OAuth, que luego se intercambió por un token de acceso para llegar a los recursos de destino a través de la API. La técnica ha recibido el nombre en código. Token de sombra a través de depuración remota (STRD) del proveedor ruso de ciberseguridad.
Lo notable del ataque es que es viable en navegadores basados en Chromium y explota una sesión activa de Gmail. En otras palabras, la idea es iniciar el navegador en modo sin cabezaconéctese a través del puerto de depuración remota para tomar el control y aproveche una sesión de Gmail ya iniciada para obtener acceso a los recursos de la cuenta de Google.
Se han descubierto tres versiones diferentes de Umbrij, incluidas versiones que cuentan con funciones auxiliares para depurar y buscar y seleccionar cuentas de usuario dentro del navegador.
ToddyCat es el nombre asignado a una amenaza persistente avanzada (APT) que tiene un historial de atacar a varias organizaciones en Europa y Asia desde al menos 2020. En noviembre de 2025, Kaspersky detalló el uso por parte del grupo de piratería de una herramienta personalizada denominada TCSectorCopy para acceder a los datos de correo electrónico de Microsoft Outlook que pertenecen a las empresas objetivo.
La compañía de ciberseguridad dijo que descubrió a Umbrij durante lo que describió como una «operación de búsqueda de amenazas», como parte de la cual se utilizó una tarea programada que se hacía pasar por su software («KasperskyEndpointSecurityEDRAvp») para lanzar un archivo firmado digitalmente. El archivo firmado luego empleó Carga lateral de DLL para lanzar Umbrij.
Para realizar esta tarea, se abusó de tres archivos binarios legítimos susceptibles a la carga lateral de DLL:
BDSubWiz.exeun componente del Asistente de envío en Bitdefender ConnectAgent
VSTestVideoRecorder.exeun componente de la herramienta de grabación de vídeo utilizada para realizar pruebas con Microsoft Visual Studio
GoogleDesktop.exeuna aplicación discontinuada de Google Desktop Search que se utiliza para indexar archivos y realizar búsquedas rápidas en una computadora local con Windows
Independientemente del ejecutable utilizado, el resultado final es el mismo: iniciar la DLL Umbrij escrita en .NET y ofuscada con ConfuserEx, un ofuscador de código abierto. La herramienta también se puede invocar junto con parámetros de línea de comandos que especifican a qué navegadores apuntar (Google Chrome o Microsoft Edge), le indican que guarde una captura de pantalla del perfil del usuario como un archivo PDF y proporcionan el nombre de usuario del sistema bajo el cual se ejecutará la herramienta.
Diagrama de flujo de trabajo de Umbrij
Umbrij, una vez iniciado, realiza una serie de acciones preparatorias en un host de Windows comprometido para violar la cuenta de Gmail.
Verifique la disponibilidad del puerto que se designará para la depuración del navegador.
Recupere el contexto del usuario buscando el proceso «explorer.exe» y duplicando el token del primer proceso que encuentre para conservar todos los privilegios del usuario que ha iniciado sesión. Alternativamente, el usuario El interruptor se puede utilizar junto con la herramienta para especificar el usuario objetivo cuyo token debe duplicarse.
Construya la ruta a la carpeta de la aplicación del navegador web dentro del repositorio de datos de la aplicación local del usuario y luego analice el archivo de estado local correspondiente a Chrome o Edge para recopilar información sobre los perfiles de usuario del navegador almacenados.
Enumere todos los perfiles y escanéelos en busca de un campo llamado «nombre_usuario» que incluya una dirección de correo electrónico. Vale la pena señalar que la presencia de una dirección de correo electrónico indica que el usuario está autenticado en un servicio de Google.
Cree un directorio llamado «BackupFiles» dentro de «%LOCALAPPDATA%\Google\Chrome\» y «%LOCALAPPDATA%\Microsoft\Edge\».
Copie los siguientes archivos y carpetas de cada destino. perfil de usuario en ellos: IndexedDB, Almacenamiento local, Red, Datos de inicio de sesión, Datos de inicio de sesión para cuenta, Preferencias, Preferencias seguras y Datos web. En caso de que otros procesos bloqueen estos archivos, la herramienta incluye un mecanismo de copia forzada.
Busque en las carpetas «Archivos de programa» y «Archivos de programa (x86)» la carpeta de instalación del navegador Chrome y Edge.
Inicie los navegadores en modo sin cabeza utilizando el perfil de usuario copiado en la carpeta «BackupFiles», lo que hace que el navegador aplique todas las cookies del usuario activo, incluida la cuenta de Google que inició sesión, y omita la autenticación.
Usar Titiriterouna biblioteca de JavaScript utilizada para controlar los navegadores basados en Chromium a través del protocolo Chrome DevTools, para conectarse al puerto de depuración remota y enviar una solicitud de código de autorización para dirigir el navegador a «accounts.google[.]com/o/oauth2/v2/auth/identifier» URL que contiene un «client_id» que corresponde a un herramienta de migración se utiliza para importar archivos PST locales y datos de cuentas de Microsoft Exchange a una cuenta de Google Workspace. La solicitud HTTP GET también especifica el conjunto de permisos requeridos por la aplicación. Utilice JavaScript para emular eventos de clic del mouse para seleccionar la cuenta de Google adecuada después de navegar a la URL y otorgarle los permisos necesarios, incluido el acceso completo a Gmail, Drive, Contactos, Calendario y Tareas.
Redirija la sesión del navegador a una dirección local especificada en la solicitud inicial y extraiga de ella el código de autorización OAuth.
«Umbrij, como la mayoría de las otras herramientas del arsenal de ToddyCat, registra sus acciones en detalle y las guarda en un archivo», dijo Kaspersky. «También guarda el código de autorización recuperado en este archivo de registro, que posteriormente el operador extrae del host comprometido».
«El código de autorización adquirido luego se intercambia por un token de acceso OAuth. Los actores de amenazas usan ese token para conectarse a la cuenta de Gmail a través de la API, comprometiendo así las comunicaciones corporativas por correo electrónico».
Para contrarrestar la amenaza, se recomienda revisar los códigos de autorización otorgados a las aplicaciones navegando a «myaccount.google».[.]com/connections» y luego busque aplicaciones llamadas «Google Workspace Migration for Microsoft Outlook» o «Google Workspace Sync for Microsoft Outlook». Si cualquiera de esas aplicaciones está presente y no se utiliza realmente dentro de la organización, es esencial revocar su acceso para invalidar los tokens de OAuth.
«El grupo ToddyCat APT continúa buscando formas de comprometer las comunicaciones corporativas por correo electrónico», dijo Andrey Gunkin, analista senior de malware de Kaspersky. «Su nueva herramienta, Umbrij, automatiza los intentos de los atacantes de obtener acceso a las cuentas de correo electrónico de la organización. Esta automatización no sólo ayuda a aumentar la escala y la frecuencia de sus ataques sino que también demuestra la fuerte motivación y las habilidades técnicas avanzadas de ToddyCat».
Identity lifecycle management was architected around a person with an employment record, a manager, and a departure date. AI agents have none of those. As autonomous principals proliferate across enterprise environments, the governance model built for humans develops structural blind spots that traditional IGA tools weren’t designed to detect. This guide covers where that model breaks, what it fails to govern, and what extending it to agents actually requires.
What Identity Lifecycle Management Was Designed to Handle
To understand why identity lifecycle management breaks down around AI agents, you need to understand what it was built to do well and who it was built for. The entire architecture rests on a single foundational assumption: every identity maps to a human being whose organizational status changes through documented, HR-driven events.
The identity lifecycle management process governs access from an identity’s first provisioning event through every modification it accumulates to its eventual deactivation. At its core, it’s an event-driven control system built around three canonical transitions: joiner, mover, and leaver.
HR as the Authoritative Engine
The HR platform, whether Workday, SAP SuccessFactors, or ServiceNow HR, functions as the system of record that drives the entire identity and access management lifecycle. A new hire record triggers automated provisioning into Active Directory or Azure AD, which propagates entitlements to downstream applications through IGA connectors. A department transfer updates role attributes and recalculates the appropriate entitlement set. A termination event triggers deprovisioning workflows across all connected systems.
The strength of the model is its determinism. Access rights reflect a verifiable organizational fact: a person holds a specific role in a specific team under a specific manager. Role-based access control maps those attributes to defined entitlement sets, delivering the right permissions at onboarding without manual negotiation per account.
Identity governance lifecycle management builds accountability on top of that structure. Access certification campaigns route to the identity manager or application owner for attestation. Separation-of-duties controls detect conflicting permissions. Audit logs tie every provisioning action back to the originating HR event and the approver who authorized it, providing the compliance evidence that frameworks such as SOX, HIPAA, and PCI DSS require.
What the Identity Lifecycle Management Phases Enforce in Practice
When an employee changes roles, attribute updates automatically recalculate entitlements, revoking what the new role doesn’t require and granting what it does. When an employee leaves, the HR termination event triggers deprovisioning across all connected applications. Certification campaigns run on a defined cadence to fill the gaps between events, requiring managers to attest to current access against current role requirements.
Every control in the standard identity lifecycle management phases assumes a human principal with an employment record, a manager relationship, and a predictable transition pattern. Access review workflows route to humans. Provisioning triggers are triggered by humans entering or changing their status in the HR system. Offboarding fires when a human’s organizational status changes.
The model is coherent, auditable, and well-supported by decades of IGA tooling. It reliably governs the human identity population. The problem begins precisely at its edges, where the principals accumulating access inside enterprise environments no longer have employment records, managers, or departure dates.
Where AI Agents Fall Outside That Model
AI agents don’t arrive through HR. They don’t have employment records, reporting structures, or defined role profiles that map to entitlement sets. They are created by engineers, orchestration frameworks, or automated deployment pipelines, and they land in production with whatever permissions the developer scoped at creation time or whatever the platform granted by default.
That origin story breaks every assumption the identity lifecycle management model depends on.
No Authoritative Source, No Governed Entry Point
Standard identity and access management lifecycle controls require an authoritative source to initiate provisioning. For humans, that source is the HR system. For AI agents, provisioning typically happens through a developer committing a configuration file, a platform API call that instantiates a new agent runtime, or an orchestration layer like LangChain, AutoGen, or AWS Bedrock Agents spinning up a new execution context. None of those events touches an IGA platform. None generates a provisioning record tied to a defined identity owner.
The agent arrives with credentials already attached: a manually created service account, an API key generated and stored in an environment variable, or an OAuth grant issued through a developer consent flow. The IGA platform, if it sees the credential at all, treats it as a static machine identity with a fixed purpose. What it’s actually dealing with is an autonomous principal that will make access decisions, traverse API boundaries, and accumulate behavioral scope in ways no static service account ever does.
Dynamic Scope in a System Built for Fixed Roles
Role-based access control works because human job functions are, within limits, predictable. A database administrator needs specific permissions. A finance analyst needs access to a defined set of systems. Entitlement sets get designed around those functions and updated when roles change through documented HR events.
AI agents don’t operate within fixed functional boundaries. An agent built to summarize internal documents may, through tool-calling or RAG retrieval patterns, end up querying APIs it wasn’t explicitly provisioned for, writing outputs to storage systems outside its original scope, or chaining actions across multiple enterprise systems to complete a task. The access surface expands at runtime, driven by the agent’s objective-seeking behavior rather than by any policy decision made in advance by a governance team.
Identity lifecycle management phases weren’t designed to govern runtime-expanding scope. They were designed to govern access defined at provisioning and adjusted at known transition points.
Simultaneous Multi-Environment Instantiation
A human identity exists in one place at a time. An AI agent can run as dozens of parallel instances across cloud environments, containerized workloads, and SaaS API surfaces simultaneously. Each instance may carry its own credential set, its own tool permissions, and its own session context, none of which is correlated in any IGA system.
In multi-agent architectures, the complexity compounds further. Orchestrator agents spawn sub-agents, delegate tasks, and pass credentials between execution contexts. The identity and access management lifecycle has no native model for a principal that forks, delegates, and recombines access rights dynamically across a distributed execution graph.
What IGA Tools Actually See
When an IGA platform encounters an agent identity, it sees a service account with an API key or an OAuth client credential. Identity governance lifecycle management tooling applies the same governance logic it applies to any machine identity: it checks for an owner, verifies the credential age, and notes whether the account appeared in the last access review.
What it doesn’t see is that the account is actively making authorization decisions, traversing application boundaries, and operating with a degree of autonomy that no traditional service account possesses. The governance record looks static. The actual access behavior is anything but.
The Lifecycle Events Agents Never Trigger
The joiner-mover-leaver model works because human employment generates a continuous stream of structured events that governance systems can act on. AI agents generate none of them. Every control point in the standard identity lifecycle management phases depends on a signal that agent deployments never produce by design.
No Joiner Event, No Governed Entry
When a new employee joins, the creation of an HR record triggers provisioning. Access gets scoped to a role definition, routed through an approval chain, and recorded in the IGA platform with an owner attached. The identity enters the governance boundary on day one.
An AI agent enters production through a deployment pipeline, a Terraform apply, or a direct API call to an agent orchestration platform. No IGA workflow fires. No access request gets submitted. No manager approves the entitlement set. The agent’s credentials, whether a service account, an OAuth client, or an API key, are created inline with the deployment, often by the same automated process that provisions the compute environment. The identity and access management lifecycle never receives a joiner signal, so the governance record for that agent starts as a blank.
No Mover Event, No Entitlement Recalculation
When a human employee changes roles, HR attribute updates flow into the IGA platform, triggering entitlement recalculation. Access appropriate to the old role gets revoked. Access required by the new role gets provisioned. The governance record reflects the current organizational reality.
AI agents change scope constantly, and none of those changes generate a mover event. An agent retooled to access a new data source, extended to call additional APIs, or redeployed against a different environment doesn’t update any HR system. No IGA connector receives an attribute change. No access review fires to reconcile what the agent now reaches against what it was originally provisioned for. Identity governance lifecycle management has no visibility into scope expansion that happens entirely within the deployment layer.
No Access Review Signal
Periodic access certification depends on a manager or application owner receiving a review task tied to a specific identity. That routing logic requires an identity with a human owner on record and an organizational relationship that the IGA platform can traverse.
Agent identities accumulate permissions across deployment iterations without generating any of the signals that recertification workflows depend on. Each new tool integration, each additional API scope, and each expanded OAuth grant layer is added to the agent’s access profile without triggering a review. The what is identity lifecycle management question, answered honestly for agents, is a model that produces no certification record, no attestation history, and no evidence of ongoing governance.
No Leaver Event, No Deprovisioning
Offboarding fires when an HR termination record closes the employment relationship. The agent equivalent, a deployment being retired, a workflow being deprecated, or a project being shut down, produces no equivalent signal.
Retired agent credentials persist in secrets managers, environment variable stores, and OAuth authorization servers long after the workload they served stopped running. An identity lifecycle management solution built around HR-triggered deprovisioning has no mechanism to detect that an agent is gone. The credentials remain valid. The access paths remain open. The governance record shows an active identity because, from the IGA platform’s perspective, nothing has changed.
What This Means for Provisioning, Reviews, and Offboarding
The governance gaps described above aren’t theoretical edge cases. They produce concrete risks, compounding them at every operational stage of an agent’s existence. When provisioning has no defined scope, when reviews produce no actionable signal, and when offboarding has no trigger, the access surface expands in only one direction.
Provisioning: Over-Permission as the Default Starting Point
Human provisioning starts from a role definition. The IGA platform maps job functions to an entitlement set, and the new identity receives access calibrated to what that function requires. Scope is defined before the identity exists.
Agent provisioning works in reverse. A developer needs the agent to complete a task and grants access broad enough to ensure success. The path of least resistance across major cloud and SaaS platforms is permissive: AWS IAM policies default toward broad resource access when scoped to wildcards, OAuth consent flows issue all requested scopes without challenging individual permissions, and service account creation in Azure AD or Google Workspace carries no built-in entitlement governance check.
The agent arrives in production over-permissioned from its first moment of operation, with no minimum-necessary baseline, no approval chain, and no IGA record linking the granted access to a defined business requirement.
Access Reviews: Routing Logic That Finds No Owner
Certification campaigns in standard identity governance lifecycle management platforms route review tasks based on identity attributes, specifically manager relationships and application ownership records. A reviewer receives a list of identities and their entitlements, confirms each access grant remains appropriate, and submits an attestation.
Agent identities break the routing logic at its foundation. Most carry no manager attribute. Many have no defined human owner in the IGA platform. Where application ownership records exist, they typically point to a team rather than an individual, and that team’s familiarity with what the agent currently accesses rarely matches what was originally provisioned.
When certification campaigns do reach agent identities, reviewers attest to the access record in the IGA system, which reflects what was provisioned at creation rather than what the agent has accumulated through iterative deployment changes. The attestation is formally complete and operationally meaningless.
Offboarding: Credentials That Outlive Their Workload
HR-triggered deprovisioning is deterministic. A termination record closes, the IGA platform sends deprovisioning instructions to every connected application, and the access path closes at a defined moment.
Agent deprecation generates no equivalent signal. A development team retires a workflow, archives the repository, and decommissions the compute environment. The service account persists in Active Directory or Entra ID. The API key remains valid in the secrets manager. The OAuth authorization grant remains valid on the authorization server. None of the systems that issued those credentials received a revocation instruction because no system monitored the agent’s operational status in the first place.
Stale agent credentials aren’t a minor hygiene issue. A long-lived API key with production database access, attached to a workload that no longer runs, is an ungoverned access path with no owner, no review history, and no expiration. In environments running large numbers of agents across iterative deployment cycles, those credentials accumulate faster than any manual audit process can keep up with.
The identity and access management lifecycle, as currently implemented across most enterprise environments, has no mechanism to detect agent inactivity, flag credential age against operational status, or trigger revocation when a workload goes dark.
How to Extend Identity Lifecycle Management to Cover Agents
Extending identity lifecycle management to cover AI agents doesn’t mean retrofitting HR-driven workflows onto a principal type for which they were never designed. It means rebuilding the governance logic around the agent’s actual operational characteristics: how it gets created, how its scope evolves, and how its operational life ends.
Automated Discovery Across Every Deployment Surface
Agent identities get created across cloud provider IAM systems, SaaS OAuth authorization servers, Kubernetes service accounts, secrets managers, and CI/CD pipeline credential stores. No single system maintains a complete inventory, and agents deployed through automated pipelines frequently appear in none of the places a traditional IGA platform looks for them.
A genuine identity lifecycle management solution for agents requires continuous, automated discovery that instruments the environments where agents actually live: reading IAM policy attachments in AWS and Azure, extracting OAuth client registrations from authorization servers, surfacing service account configurations from Kubernetes namespaces, and identifying API keys embedded in runtime configurations. Discovery has to be ongoing because agent deployments change faster than any quarterly audit cycle can capture.
Attribute Modeling Built Around Agent Behavior
Human identity attributes map to organizational structure: department, job title, manager. Those attributes anchor entitlement decisions and review routing. Agent identity requires an entirely different attribute model.
Each agent identity needs a documented owning team, a defined operational purpose, a bounded list of the systems and APIs it’s authorized to reach, a deployment timestamp, and an expected operational lifetime tied to the workload it serves. Behavioral attributes matter equally: which APIs the agent calls, how often, and across which data surfaces. An identity governance lifecycle management approach built for agents treats observed access patterns as governance inputs, using behavioral baselines to surface permission grants the agent holds but never exercises.
Policy-Driven Provisioning Scoped to Agent Function
Rather than granting access at deployment time and reviewing it later, provisioning for agent identities should follow the same least-privilege logic that mature IAM program frameworks apply to privileged human accounts: define the minimum access the agent requires to perform its documented function, enforce that scope through policy at credential issuance, and attach the credential to a defined owner who carries accountability for any scope changes.
In practice, this means integrating agent provisioning into IGA intake workflows rather than leaving it entirely within the deployment pipeline. When an agent requires access to a production API or a sensitive data store, that request routes through an access governance control, not around it.
Continuous Behavioral Monitoring as the Review Substitute
Periodic access certification produces no actionable signal for agent identities. The operational substitute is continuous behavioral monitoring: tracking what each agent actually calls, comparing observed access against the provisioned entitlement set, and flagging divergence in real time.
When an agent starts calling APIs outside its provisioned scope, that divergence is a governance event requiring immediate response, not a finding to surface at the next quarterly review. Behavioral monitoring closes the gap left by recertification campaigns across the identity and access management lifecycle for agent principals.
Deprecation Workflows Triggered by Operational Status
Offboarding for agents requires a trigger mechanism that reflects operational reality. Inactivity monitoring tied to credential usage logs provides the signal: an API key that hasn’t generated an authenticated request within a defined window is a candidate for revocation review. Scope change detection flags when a deployment modifies the permissions attached to an agent credential, generating a governance event that routes to the owning team for reauthorization.
Connecting those signals to automated revocation workflows, integrated with AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault, closes the offboarding gap without requiring a manual discovery step. The identity lifecycle management phases for agents end when operational status ends.
Where Orchid Security Fits In
Most enterprise IAM stacks govern the identity population they can see through their existing connectors. Agent identities, ungoverned credentials, and authentication paths that bypass the corporate IdP fall into the space that those connectors don’t reach. That’s the gap Orchid Security was built to close.
Continuous Discovery Across the Full Identity Surface
Orchid deploys lightweight orchestrators that instrument applications directly, extracting authentication flows, authorization logic, account configurations, and credential storage patterns from both managed and unmanaged environments. The result is a continuously updated identity inventory that reflects what the environment actually contains, including every agent identity, service account, and API credential that never passed through an IGA intake workflow.
For organizations asking what identity lifecycle management is in practice, Orchid’s answer starts with visibility: you govern what you’ve found, and most programs haven’t found everything.
An Identity Graph That Reflects Agent Reality
Orchid’s identity graph maps every principal, human and non-human, to the authentication flows, entitlements, and application access paths it actually uses. For agent identities specifically, the graph surfaces the owning team, the provisioned permission set, observed behavioral patterns, and credential age, producing the attribute model that identity governance lifecycle management for agents requires, but traditional IGA platforms don’t generate.
Guardrails for Autonomous Identity
Orchid’s guardrails for the autonomous identity apply policy-driven controls directly to agent identity populations: scoped provisioning tied to documented agent function, continuous monitoring of behavioral divergence from provisioned entitlements, and deprecation workflows triggered by inactivity signals rather than HR events.
The platform integrates with existing IAM, PAM, and IGA infrastructure, routing remediation through the tools organizations already operate rather than replacing them. Governance scope expands to match the actual identity surface, including agent identities, and the identity and access management lifecycle extends to cover the principals that every traditional identity lifecycle management solution leaves outside its boundary.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
Los recientemente descubiertos con motivación financiera FortiBleed La campaña se ha atribuido a las operaciones de ransomware INC y Lynx, lo que indica que las credenciales robadas y verificadas estaban destinadas a intrusiones posteriores.
«Se encontró que un operador vinculado a la infraestructura de FortiBleed trabajaba activamente en paneles de negociación para ambos grupos, vinculando el robo masivo de credenciales de FortiGate directamente con la implementación de ransomware por primera vez», SOCRadar dicho en un nuevo informe publicado el miércoles.
La compañía dijo que rastreó la actividad de escaneo en aproximadamente 11,250 portales FortiGate en más de 150 países, seguido del acceso confirmado a nivel de administrador en 409 objetivos y la finalización exitosa de la cadena de ataque completa en 354 de ellos. En total, al menos 12 implementaciones de ransomware han resultado de este acceso, lo que ha provocado que se cifren cientos de puntos finales en las organizaciones afectadas.
La operación de recolección de credenciales a gran escala, que salió a la luz el mes pasado, involucró a los actores de amenazas escaneando sistemáticamente Internet en busca de dispositivos Fortinet expuestos, intentando ingresar a ellos usando combinaciones de credenciales conocidas y luego implementando rastreadores de paquetes personalizados para recopilar pasivamente credenciales y otros datos de autenticación del tráfico de la red.
Se estima que la campaña se dirigió a 430.000 firewalls FortiGate en todo el mundo, reuniendo más de 110 millones de credenciales en el proceso. La actividad quedó expuesta después de que un error de seguridad operativo por parte de los atacantes dejara un servidor que contenía credenciales robadas de miles de dispositivos Fortinet expuestos en Internet.
Se estima que el rastreador Golang se instaló en unos 12.000 dispositivos Fortinet, lo que lo convierte en un subconjunto del número total de equipos de red objetivo.
Los últimos hallazgos de SOCRadar muestran que se encontró que un operador con acceso a la infraestructura de FortiBleed inició sesión en los paneles de negociación de INC Ransom y Lynx, y las víctimas enumeradas por INC Ransom se superponen con los datos de la campaña. Los enlaces se basan en uno de los 200 servidores recientemente descubiertos asociados con la infraestructura FortiBleed que otorga visibilidad a archivos internos, registros y documentación operativa.
Las herramientas, los registros y las horas de trabajo indican que la actividad es obra de un actor de amenazas de habla rusa que probablemente opera como intermediario de acceso inicial. Gran parte de la focalización se ha centrado en los sectores de manufactura, tecnología y logística en América Latina y las regiones de Asia Pacífico.
SOCRadar también dijo que descubrió un documento interno que indica que se trata de una operación organizada que comprende a unas 20 personas con una clara división del trabajo. «Un pequeño núcleo de operadores líderes impulsa la mayoría de las intrusiones de alto impacto, respaldados por especialistas y personal de apoyo», añadió.
Además, se cree que los actores de amenazas poseen al menos una vulnerabilidad de día cero en Nextcloud. La firma de inteligencia de amenazas dijo que está coordinando activamente con el proveedor afectado.
La divulgación llega como eSentire dicho observó que los actores de amenazas explotaban una falla en Fortinet FortiClient EMS (CVE-2026-35616, puntuación CVSS: 9.1) para implementar un ladrón de información llamado EKZ Stealer contra un cliente en el sector de energía, servicios públicos y residuos con el objetivo final de recolectar credenciales de navegadores basados en Chromium y Firefox y exfiltrarlas a través de PowerShell.
La empresa de seguridad Sysdig dice que ha encontrado lo que cree que es el primer ataque de ransomware ejecutado de principio a fin por un agente de IA.
Su equipo de investigación de amenazas llama al operador JADEPUFFER y dice que un modelo de lenguaje grande se encargó de todo el trabajo: irrumpir, robar credenciales, profundizar en la red y luego cifrar y borrar la base de datos de producción de una empresa.
El ransomware siempre ha necesitado una persona capacitada en algún lugar del circuito, ya sea en el teclado o escribiendo el script que sigue el malware. Si un modelo puede encadenar esos pasos por sí solo, la habilidad necesaria para ejecutar un ataque se reduce a lo que cuesta alquilar un agente de IA.
La entrada era un error antiguo y ya parcheado. JADEPUFFER aprovechó CVE-2025-3248, una falla de autenticación faltante en Langflowuna herramienta de código abierto para crear aplicaciones de inteligencia artificial y flujos de trabajo de agentes. La falla permite que cualquiera que pueda acceder al servidor ejecute su propio código Python en él, sin necesidad de iniciar sesión.
Las cajas Langflow son un objetivo tentador porque a menudo quedan expuestas en Internet y contienen claves API y credenciales de nube para los servicios a los que se conectan.
La falla se solucionó en Langflow 1.3.0 y se agregó a la lista de vulnerabilidades explotadas conocidas de CISA en mayo de 2025, pero muchos servidores nunca se actualizaron. Ni siquiera es el único error de Langflow que se ve afectado de esta manera.
Una vez dentro, el agente trabajó rápido y limpió lo que ensució. Mapeó la máquina y luego la buscó en busca de secretos: claves API para servicios de inteligencia artificial (OpenAI, Anthropic, DeepSeek, Gemini), credenciales de nube (proveedores chinos como Alibaba y Tencent junto con AWS, Google y Azure), claves de billetera criptográfica e inicios de sesión de bases de datos.
Asaltó un servidor de almacenamiento MinIO utilizando su inicio de sesión predeterminado de fábrica (minioadmin:minioadmin), que nunca había sido modificado. También estableció una manera de regresar, añadiendo una tarea programada que hacía ping al servidor del atacante cada 30 minutos.
Luego giró hacia su objetivo real: un servidor separado con acceso a Internet que ejecuta una base de datos MySQL y Nacos de Alibaba, un directorio de configuración y servicios común en configuraciones de microservicios. El agente inició sesión en la base de datos como root.
Sysdig dice nunca vio de dónde procedían esas credenciales raíz, por lo que se desconoce su origen. A partir de ahí, se hizo cargo de Nacos utilizando una omisión de autenticación de 2021 (CVE-2021-29441) y una clave de firma predeterminada que Nacos ha enviado sin cambios desde 2020, luego plantó su propia cuenta de administrador.
La nota de rescate sin clave
El agente cifró las 1.342 configuraciones de Nacos, eliminó las tablas originales y dejó una nota de rescate exigiendo Bitcoin a un contacto de Proton Mail. Generó una clave de cifrado aleatoria, la imprimió en la pantalla una vez y nunca la guardó ni la envió a ninguna parte.
No hay ninguna llave que entregar. La víctima no puede recuperar los datos incluso si paga. (La nota afirma AES-256; Sysdig señala que la herramienta que utilizó tiene como valor predeterminado AES-128 más débil, aunque el resultado es el mismo).
Luego fue más allá, eliminando bases de datos enteras y dejando un comentario en su propio código afirmando que ya había copiado los datos en otro lugar.
Sysdig dice que es el agente quien habla, algo que el equipo no pudo confirmar, y no encontró evidencia de que realmente se hubiera dejado algún dato.
Cómo saben los expertos que conducía una IA
La señal más clara fue el propio código. Las cargas útiles del ataque estaban llenas de notas en inglés sencillo que explicaban por qué se estaba dando cada paso, el comentario continuo que un hacker humano nunca se molesta en escribir, pero que un modelo produce de forma predeterminada. El agente también corrigió sus propios errores a la velocidad de una máquina.
En un caso, pasó de un inicio de sesión fallido a una solución correcta de varios pasos en 31 segundos, diagnosticando la causa exacta en lugar de volver a intentarlo a ciegas. Sysdig contó más de 600 cargas útiles separadas y con propósito en toda la operación.
Un detalle sigue siendo un enigma. La dirección de Bitcoin en la nota de rescate es la dirección de muestra exacta que aparece en toda la documentación para desarrolladores de Bitcoin, lo que significa que aparece en todo el texto en el que se entrenan estos modelos. También es una billetera real y activa con un largo historial de pagos.
Sysdig no puede decir si el modelo simplemente pegó una dirección de memoria de aspecto familiar o si el operador utilizó deliberadamente una billetera real que coincide con el famoso ejemplo.
Parte de un cambio mayor
JADEPUFFER es el último paso en un año de rápidos cambios para los ataques impulsados por IA. En agosto de 2025, los investigadores de ESET señalaron Bloqueo rápidoanunciado como el primer ransomware impulsado por IA; luego resultó ser un laboratorio prototipo de la Universidad de Nueva York llamado Ransomware 3.0, no es un ataque real.
Casi al mismo tiempo, Anthropic informó sobre una verdadera campaña de extorsión que utilizó su herramienta Claude Code para atacar al menos a 17 organizaciones, con demandas que superan los 500.000 dólares, aunque aún así un humano la dirigió.
En noviembre de 2025, Anthropic reveló lo que llamó el primer ciberataque en gran medida autónomoun esfuerzo de espionaje vinculado al estado chino en el que Claude escribió exploits y robó datos con poca ayuda humana. Esa operación también hizo que la IA inventara credenciales que no existían, posiblemente el mismo tipo de alucinación detrás de la extraña dirección de Bitcoin de JADEPUFFER.
Las piezas de un ataque grave se están automatizando y el software antiguo y sin parches es el primer objetivo fácil. Los agentes hacen que la pulverización de todo el catálogo anterior de errores conocidos sea casi gratuita, por lo que los servidores descuidados quedan más expuestos, no menos.
Qué deben hacer los defensores
Las soluciones son familiares. Parche Langflow y nunca exponga sus puntos finales de ejecución de código a Internet. No ejecute herramientas de inteligencia artificial con claves de nube y credenciales de proveedor en su entorno; Guarde los secretos en un administrador adecuado, lejos de todo lo que la web pueda alcanzar.
Harden Nacos: cambie la clave de firma predeterminada, manténgalo fuera de la Internet pública y nunca permita que se conecte a su base de datos como root. Nunca exponga la cuenta de administrador de una base de datos a Internet y bloquee el tráfico saliente para que un servidor pirateado no pueda llamar a casa.
Debido a que los atacantes ahora pueden convertir un nuevo aviso en un arma en cuestión de horas, Sysdig sostiene que vigilar el mal comportamiento en tiempo de ejecución es más importante que correr para parchear.
Los indicadores publicados por Sysdig para esta operación incluyen:
Punto de entrada: CVE-2025-3248 (ejecución remota de código no autenticado de Langflow)
Mando y control: 45.131.66[.]106, con una baliza a hxxp://45.131.66[.]106:4444/baliza cada 30 minutos
Servidor provisional reclamado: 64.20.53[.]230
Dirección de Bitcoin de rescate: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy; contacto e78393397[@]protón[.]a mí; tabla de rescate llamada README_RANSOM
Sysdig llama a JADEPUFFER una señal de advertencia más que una crisis. Ninguno de los movimientos individuales fue inteligente o nuevo. Lo nuevo es que un modelo los unió en un ataque completo contra un servidor abandonado, por sí solo.
Espere más de lo mismo a medida que las herramientas del agente maduren y trate cualquier servidor expuesto, almacén de configuración o inicio de sesión de administrador de base de datos como algo que una máquina explorará, no solo una persona.
Los atacantes esconden un troyano que roba datos dentro de un código de explotación falso dirigido a las personas que se ganan la vida cazando errores. El malware, llamado ChocoPoCviaja en repositorios de prueba de concepto (PoC) de Python en GitHub que afirman explotar nuevos CVE.
Ejecute uno y extraerá silenciosamente sus contraseñas guardadas, cookies del navegador y archivos, y luego le entregará al atacante un shell en su máquina. YesWeHack y Sekoia publicaron sus hallazgos conjuntos el 1 de julio y advirtieron que, a partir de ese informe, el malware y sus servidores todavía estaban activos, por lo que no ejecute ninguna de estas PoC.
El truco está en dónde se encuentra el código. El PoC visible parece limpio. El malware se esconde en un paquete de Python que el PoC incorpora como una dependencia, por lo que pasa desapercibido en una revisión rápida del código.
Cómo funciona la trampa
El cebo es la presión del tiempo. Cuando surge una falla importante, los investigadores se apresuran a probarla y a obtener PoC de la comunidad para actuar rápidamente. Esta campaña convierte ese hábito en una vía de infección.
La cadena, en términos sencillos:
Clona el repositorio y ejecuta pip install para obtener los requisitos de PoC.
Eso atrae un paquete llamado frint, que a su vez arrastra un segundo paquete, skytext.
skytext incluye un pequeño archivo compilado (gradient.so en Linux, gradient.pyd en Windows) que se ejecuta en el momento en que inicia el PoC.
Solo se despierta cuando ve el PoC real cargado, busca un archivo llamado EXPLOIT_POC.py o similar, luego descomprime su carga útil y descarga el troyano.
Esa última comprobación es la razón por la que un sandbox simple no ve nada. Detona el paquete por sí solo, sin el PoC completo a su alrededor, y el malware permanece inactivo.
Lo que roba y hace
Una vez en ejecución, ChocoPoC es un troyano de acceso remoto completo. Extrae contraseñas guardadas, cookies, autocompletar e historial de Chrome, Brave, Edge y Firefox. Toma archivos de texto, notas y bases de datos locales, junto con el historial del shell, la configuración de red y la lista de procesos en ejecución.
El atacante también puede ejecutar cualquier comando de shell, ejecutar Python arbitrario, extraer carpetas enteras y ralentizar el malware para permanecer en silencio. Varios nombres de comandos están en español y el código contiene pequeños errores, que los investigadores interpretan como escritos a mano en lugar de generados por IA.
Para controlarlo, el malware se esconde a simple vista. Lee sus órdenes de un conjunto de datos en Mapbox, un servicio de mapas normal, y lo utiliza como punto muerto. Resuelve esa dirección a través de DNS sobre HTTPS y utiliza un truco de dominio frontal, por lo que el tráfico parece llamadas API de Mapbox normales. Las cargas más grandes van a un servidor separado en 91.132.163.78.
¿Hasta dónde se ha extendido?
YesWeHack y Sekoia encontraron al menos siete repositorios PoC falsos, cada uno vinculado a una falla de alto perfil:
Recorrido de ruta FortiWeb (CVE-2025-64446)
React2Shell (CVE-2025-55182)
MongoBleed (CVE-2025-14847)
Omisión de autenticación PAN-OS (CVE-2026-0257)
Inyección de comando Ivanti Sentry (CVE-2026-10520)
Omisión de autenticación de VPN de Check Point (CVE-2026-50751)
Generador de páginas Joomla SP RCE (CVE-2026-48908)
Solo el paquete skytext se descargó unas 2.400 veces, principalmente en Linux. Las descargas no prueban que alguien estuviera infectado, pero aumentaron justo después de que los principales CVE se hicieran públicos, lo que encaja con el atractivo.
Una ejecución anterior de la misma campaña, que se remonta a finales de 2025, utilizó otros dos paquetes, slogsec y logcrypt.cryptography, con un código casi idéntico. Sekoia evalúa con alta confianza que un actor está detrás de ambos, basándose en marcadores de control reutilizados.
Dice que el operador rotó cuentas de GitHub, PyPI y Mapbox, varias de ellas creadas a partir de inicios de sesión filtrados o robados. No se ha nombrado ningún grupo conocido.
Los investigadores de seguridad son un objetivo rico. Ejecutan código no confiable por diseño, a menudo con altos privilegios, y sus máquinas contienen credenciales de clientes, informes privados y detalles de interacciones en vivo. Si compromete uno, podrá llegar mucho más allá de una sola computadora portátil.
La campaña MUT-1244 mostró la recompensa, utilizando repositorios PoC falsos para robar claves SSH y credenciales de nube de investigadores y equipos rojos.
Lo que añade ChocoPoC es el escondite. El malware vive en una dependencia, por lo que la prueba de concepto que lees permanece limpia. Como lo expresaron los investigadores, el malware en sí es una noticia vieja, pero «lo que está cambiando es el mecanismo de entrega».
Que hacer ahora
Trate cualquier PoC como hostil hasta que se demuestre lo contrario y manténgase alejado del código de cuentas nuevas o desconocidas.
Lea la cadena de dependencia completa, no solo el archivo PoC. Esté atento a paquetes recién publicados, mantenedores desconocidos y cuentas con historial oculto.
Pruebe solo en una máquina virtual desechable, pero recuerde que el aislamiento por sí solo no activará esta. La verdadera solución es no instalar ningún paquete.
Verifique sus sistemas en busca de frint, skytext, slogsec y logcrypt.cryptography, además de los hashes de archivos en el informe. Si ejecutó alguno de ellos, rote las credenciales y reconstruya el host.
El mayor riesgo está aguas abajo. Estos señuelos se dirigen a los investigadores que proporcionan detecciones y PoC a marcos como Nuclei y MDUT. Sekoia señala el peligro de un doble impacto en la cadena de suministro: si se envenena a un investigador, el código incorrecto puede trasladarse a un marco en el que confían miles de personas más.
La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) el miércoles agregado una falla de alta gravedad que afecta a Microsoft SharePoint Server en su catálogo de vulnerabilidades explotadas conocidas (KEV), citando evidencia de explotación activa.
La vulnerabilidad, rastreada como CVE-2026-45659 (Puntuación CVSS: 8,8), es un caso de ejecución remota de código que surge de la deserialización de datos que no son de confianza. Microsoft solucionó el problema en mayo de 2026 para SharePoint Server Subscription Edition, SharePoint Server 2019 y SharePoint Enterprise Server 2016.
Microsoft señaló que cualquier atacante autenticado podría desencadenar la vulnerabilidad y que no requiere privilegios de administrador ni otros privilegios elevados. En un ataque basado en red, un atacante autenticado con un mínimo de permisos de miembro del sitio (PR:L) podría aprovecharlo para ejecutar código de forma remota en SharePoint Server.
«Microsoft SharePoint Server contiene una vulnerabilidad de deserialización de datos no confiables que permite a un atacante autorizado ejecutar código a través de una red», CISA dicho.
Según el aviso del fabricante de Windows, la falla ha sido etiquetada con una evaluación de «Explotación menos probable». Actualmente no se sabe cómo se explota la vulnerabilidad, quién está detrás de la actividad y cuáles son los objetivos finales de estos esfuerzos.
A la luz de la explotación activa, se recomienda a las agencias del Poder Ejecutivo Civil Federal (FCEB) que apliquen las correcciones antes del 4 de julio de 2026.
Microsoft descubre actividad de amenazas paralelas en dos grupos
A finales del mes pasado, Microsoft reveló que una investigación de rutina sobre ransomware descubrió dos atacantes no relacionados que operaban simultáneamente dentro de la misma red, mientras adoptaban técnicas deliberadas para establecer un acceso persistente y complicar los esfuerzos de respuesta a incidentes.
Un conjunto de ataques se ha atribuido a Storm-2603, un actor de amenazas conocido por implementar el ransomware Warlock, a menudo explotando vulnerabilidades conocidas en servidores SharePoint locales desde mediados de 2025.
«En este caso, el acceso inicial probablemente se intentó a través de una vulnerabilidad separada, con solicitudes de archivos como win.ini y web.config, lo que indica que se estaba investigando la inclusión de archivos locales», dijo Microsoft. La evidencia apunta a que se trata de CVE-2025-11371 (puntuación CVSS: 9,1), una falla crítica que afecta a Gladinet Triofox.
Al obtener acceso inicial, se dice que el actor de amenazas implementó herramientas como Velociraptor para combinar actividad maliciosa con comportamiento administrativo confiable, así como también estableció múltiples canales de acceso remoto a través del túnel Cloudflare, Zoho Assist y conexiones Secure Shell (SSH) configuradas a través de Visual Studio Code.
El ataque también aumentó los privilegios al crear nuevas cuentas de administrador local y de dominio, mientras que un controlador vulnerable («NSecKrnl.sys») actuó como un conducto para alterar las protecciones de seguridad de los terminales para ayudar a reducir su visibilidad.
Al mismo tiempo, Microsoft dijo que descubrió signos de un segundo actor de amenazas no relacionado que coexiste en el mismo entorno utilizando la carga lateral de DLL y puertas traseras personalizadas, lo que hace que la atribución sea más desafiante.
Una investigación más profunda descubrió que los atacantes se habían movido lateralmente más allá de la primera red y hacia una segunda organización, lo que confirmó que habían sido comprometidos por la misma actividad de ransomware atribuida a Storm-2603.
«Juntos, estos flujos de actividad superpuestos permitieron un acceso sostenido mientras enmascaraban el alcance total de la intrusión», dijo el equipo de Respuesta a Incidentes de Microsoft. «La combinación de tácticas de ransomware conocidas y técnicas ocultas permitió a los actores de amenazas establecer un acceso profundo y duradero».
«Lo que puede parecer un solo incidente de ransomware puede expandirse rápidamente a algo más complejo: abarcar organizaciones, combinar tácticas e incluso involucrar a múltiples actores de amenazas que operan en paralelo. Para los equipos de seguridad, la implicación es clara: las señales aisladas rara vez cuentan la historia completa».
