telemetry

Security teams have spent years trying to detect threats faster. AI is changing the harder part: how much time defenders have left to act. Advanced AI models can now help attackers discover vulnerabilities, generate exploit code, and move through weaknesses faster than traditional security processes were built to handle. The challenge is no longer just finding another vulnerability or

Thirty-three cybersecurity-related merger and acquisition (M&A) deals were announced in August 2026. For a detailed view of the more than 420 acquisitions announced in 2025, check out SecurityWeek’s annual M&A report. Here are some of the most important cybersecurity M&A deals announced in August 2026: Continuous Threat Exposure Management (CTEM) firm Brinqa has acquired PlexTrac, a penetration testing workflow and reporting vendor. The acquisition integrates PlexTrac’s offensive security validation into Brinqa’s CTEM platform to verify remediation efforts. Cribl has acquired technology assets and IP from San Francisco-based Radiant Security, an AI-native SOC startup. Cribl will integrate Radiant’s autonomous alert triage and incident response capabilities directly into its telemetry data platform. Data monetization, credentialing, digital engagement, and RWA tokenization solutions provider Datavault AI has announced a definitive all-cash agreement to acquire San Diego-based CyberCatch for $94.5 million. The acquisition integrates CyberCatch’s continuous compliance platform and post-quantum encryption technology into Datavault AI’s platform. Deel has acquired Israel-based Clarity, an AI cybersecurity company specializing in deepfake detection and identity verification. Financial terms were not officially disclosed, but the deal is reportedly valued at $40-50 million. Deel will integrate Clarity’s technology to prevent identity fraud and detect deepfakes during remote workforce hiring. Echo has acquired the technology assets and enterprise customer contracts of Tel Aviv-based hardened container image provider Minimus in an all-cash deal following Minimus’s operational wind-down. Financial terms were estimated at a few million dollars. The deal enables Echo to broaden distro support, expand integrations, and strengthen the proprietary agents powering its software factory. Fortinet announced the acquisition of AI security company Virtue AI. Fortinet said the acquisition will help it enhance its AI security offering, including for models, applications, and agentic systems. Fortinet will leverage Virtue’s agentic system red teaming, agent protection and governance, continuous AI validation, and real-time guardrail capabilities. Kiteworks announced moving into Japan through its seventh acquisition in less than five years. The company has acquired WAMNET Japan K.K., a secure data transfer and file-sharing provider. The deal extends Kiteworks’ private content network (PCN) strategy — unifying file sharing, managed file transfer, email, APIs, and web forms under one governed platform — into a new geography, with WAMNET’s existing contracts, pricing, and support staying in place and customer data remaining hosted in Japan. German reinsurance giant Munich Re has agreed to acquire California-based cyber insurtech At-Bay for $575 million. At-Bay will join Munich Re’s HSB unit, combining continuous risk mitigation and MDR services with global insurance coverage. Palo Alto Networks has acquired Console, an AI-native platform that helps organizations build agentic workflows and automate operational tasks using natural language. The cybersecurity giant said Console will deepen the agentic capabilities of its Cortex platform, allowing security teams to investigate signals, prioritize work, and automatically take action across enterprise environments. Visa is buying fraud prevention company BioCatch for $2.4 billion in cash as the payments giant looks to expand its cybersecurity and financial crime detection capabilities. The acquisition will add BioCatch’s behavioral and device intelligence to Visa’s existing portfolio of cyber, fraud, risk and security products. Other cybersecurity M&A deals announced in August 2026: Athena Agentic acquires Maxxsure and Omni Cyber Solutions Related: Cybersecurity M&A Roundup: 21 Deals Announced in July 2026 Related: Cybersecurity M&A Roundup: 37 Deals Announced in June 2026

Tl;dr: Identity was the target in roughly half of all confirmed malicious activity. Prophet Security breaks down the four main attack patterns seen across customer environments between May and July 2026, and explains why some attacks succeeded while others were blocked. Between May 1 and July 31, 2026, Prophet Security investigated every alert in customer environments immediately upon arrival. This removes a common blind spot in threat datasets: the human analyst's decision about which alerts deserve a full investigation. Of the completed investigations, about 93% were benign and 7% were confirmed malicious. The findings below come from that 7%. They are based on 4.7 million questions asked of customer environments over the quarter, with a median of 35 questions per investigation. Prophet Security published the full dataset in its first quarterly threat report. One key finding stands out: identity was the target in roughly half of all confirmed malicious activity this quarter. The strongest predictor of a successful account takeover was whether the attacker used a password or an already-authenticated session. This was true for both direct attacks on accounts and phishing campaigns. Here are the four patterns we observed: 1. Session hijacking was the top way attackers broke into accounts Direct attacks on accounts and sessions made up about 18% of confirmed malicious activity. These included session hijacking, token replay, MFA bypass, credential stuffing, and post-compromise persistence using inbox rules and OAuth consent grants. The main factor predicting success was the authentication method the attacker used. Attempts using a password were usually blocked. For example, conditional access blocked correct passwords coming from commercial VPNs in new countries or unfamiliar hosting providers. Phishing-resistant MFA stopped adversary-in-the-middle proxies that captured credentials. The security controls worked as intended. However, attempts using an already-authenticated session succeeded repeatedly. In some cases, individual accounts had dozens of malicious sign-ins over three weeks, giving attackers continuous access to emails. The reason is simple: standard conditional access checks during authentication. Since a replayed session cookie skips authentication, no policy is triggered. A refresh token only returns to the identity provider when redeemed, which is the only time to re-evaluate and revoke access. While passwords hit security controls, authenticated sessions bypassed them completely. This led to two common outcomes. First, disabling the account didn't always stop the attacker. At two organizations, attackers continued using access granted before the account was disabled. In one case, they even changed authentication methods and granted OAuth consents while the security team thought the incident was closed. Second, when credentials were phished instead of sessions being stolen, the timing revealed relay infrastructure. For example, a login from one country was followed by an MFA approval from another country just sixteen seconds later, and again after 118 seconds on a second attempt. Such a short gap between countries indicates a real-time proxy intercepting and relaying credentials and approvals. MFA fatigue attacks also succeeded when allowed by the system. One attacker sent repeated prompts from a residential proxy until the user approved. Another used a combination of brute force, lockout, automatic unlock, and push bombing to register a new device, exploiting the automatic unlock policy. The Prophet Security Quarterly Threat Report details a complete account takeover, from the initial login to the artifact that bypassed a password reset. It also includes hardening recommendations for these threats. Get the Full Report 2. Infostealers delivered via browsers were the primary source of stolen sessions Malicious code execution and tooling accounted for about 23% of confirmed malicious activity. Overall, infostealer activity affected roughly a quarter of the investigated organizations. These infostealers were mostly delivered through web browsers, not emails. Attackers used compromised legitimate websites, malicious ads, sponsored search results, and fake CAPTCHA gates (known as ClickFix) that bypass automated sandboxing by requiring a human click. Fake update prompts hosted on compromised sites were frequently seen across multiple organizations. Attackers often lured users with software they wanted. Trojanized installers were the most common initial foothold, found at about a quarter of organizations. For example, a trojanized version of a popular AI application ran from a downloads folder, disabled Windows Defender, set up a highly privileged scheduled task, and opened command-and-control channels. Similar techniques were used to hide malware in hardware diagnostic tools, public code packages, screenshot utilities, cracked software, and remote-support tools. We identified delivery tools like ClearFake and SocGholish, and payloads including Lumma Stealer, Vidar, HijackLoader, and AsyncRAT. While SocGholish infrastructure was disrupted on June 18, 2026 under Operation Endgame (during our reporting period), its fake update model continues to be used by ClearFake and other groups, showing that the technique survives even when the operators are shut down. These stolen sessions often come from the browser's cookie store. In one case, a script decrypted the browser's cookie store, extracted Microsoft authentication cookies, and used them to make authenticated API requests. This is how attackers get the session cookies they replay to bypass security. A stolen cookie requires no password or MFA, and it survives a password reset or even a device wipe if the session isn't revoked. Ultimately, an endpoint compromise quickly becomes an identity compromise through the browser. 3. Phishing attacks were highly targeted Credential phishing made up about 28% of confirmed malicious activity, making it the largest single category. These attacks primarily aimed to steal credentials or sessions rather than deliver malware. These campaigns were highly targeted, often hitting the same people repeatedly. For example, one finance executive faced dozens of different phishing campaigns over three months. Another recipient was targeted for months, while someone else received near-identical phishing emails from different domains twice in two weeks. Attackers focused on financial roles: finance executives, collections, accounts payable, treasury mailboxes, and company leaders receiving ACH-themed lures. In one instance, they targeted an automated invoice-processing mailbox, which lacks a human user to spot suspicious activity. The phishing emails often came from trusted infrastructure, such as legitimate collaboration platforms, major cloud email services, and consumer file-sharing links. Some messages impersonated internal systems like calendar services. Attackers used modern tactics: Unicode characters in subject lines to evade filters, newly registered domains, typosquatted domains, and tracking pixels to verify when an email was opened. Standard email authentication checks weren't always effective. In one case, a spoofed message that failed SPF, DKIM, and DMARC still reached over a dozen inboxes. The time it took to remove malicious emails varied from seconds to over a day. Organizations with automated remediation removed emails in seconds. Without it, a CEO impersonation lure sat in a finance director's inbox for nearly a full workday. Once attackers gained access, they used mailbox rules to stay hidden. Modifying inbox rules was extremely common, seen at nearly as many organizations as impossible travel alerts. Attackers create rules to delete or hide incoming emails so the victim doesn't see their replies. This simple persistence method survives a password reset and remains highly effective. 4. The longest intrusions occurred on unmonitored assets Pre-ransomware and manual attacker activity made up about 9% of confirmed malicious activity. EDR was the broadest telemetry source behind these findings, and that volume is why investigating EDR alerts at depth is expensive. Most of this activity occurred on devices where no endpoint agent was installed at all. For example, a multi-week credential attack targeted a production identity server lacking endpoint coverage. In another case, a six-week lateral movement campaign started from an unmanaged, unmonitored host. Several long-running intrusions were only detected because of telemetry from other network devices, as the attackers' machines were entirely unmonitored. When credential access was detected, it often involved legitimate Windows tools. Attackers used accessibility utilities, task manager, and error reporting services to access the Local Security Authority Subsystem Service (LSASS). Other attackers bypassed LSASS, creating shadow copies to read credential data from the registry or using a legitimate remote registry service with an impersonation token. Pre-ransomware activities such as destroying shadow copies, dumping credentials, and deploying remote access tools were much more common than actual ransomware deployment. In two instances, the attacks were stopped while they were still in progress. About 15% of organizations had attackers using commercial remote access tools to maintain access. Attackers used consumer remote desktop software and remote support tools, which evade malware controls because they are legitimate applications. This access also survives a password reset. Comparing endpoint agent coverage to authentication logs (instead of just the asset inventory) revealed unmonitored machines authenticating to the network. Two of the quarter's longest-running campaigns operated from these unmonitored devices. Summary of the quarter Most of the confirmed attacks this quarter relied on well-known methods: stolen session cookies, MFA push bombing, fake software installers, and using publicly breached credentials. The only truly novel event was an AI agent running a complete intrusion, which began during a model evaluation with safety settings turned off and was eventually caught by another company's security team. The attack techniques haven't changed much. Instead, attackers are simply bypassing existing security controls. When authentication became stronger, attackers started stealing active sessions. As malware detection improved, they began tricking users into approving fake installers. This requires no innovation on the attacker's side, only attention to where each control stops. Three of our four findings share a critical trait: the attacker's access survives a password reset. Stolen session cookies, hidden inbox rules, and persistent remote-support tools all bypass a simple password change. Incident response plans that stop at resetting a password leave the attacker inside the network, as two organizations in this dataset discovered. Each case was ultimately resolved by asking basic questions and finding the answers: Has this account signed in from here before? Was MFA actually completed? Is this user a developer? Has this sender reached this recipient before? Answering these questions takes time. Often, they go unasked because analysts have to prioritize hundreds of other alerts. About the data These findings are based on investigations completed by the Prophet AI SOC Analyst between May 1 and July 31, 2026. The category percentages represent shares of confirmed malicious investigations and are rounded. Authorized penetration tests and red team exercises were marked as benign and excluded from the malicious data. We do not publish identifying details, per-organization counts, or industry breakdowns. Prophet Security is a leading agentic AI SOC platform, recognized in Rising in Cyber 2026 on a vote of more than 150 CISOs and security leaders. Its AI SOC analyst investigates every alert across endpoint, identity, email, cloud, and network telemetry and records the evidence behind each determination. Read the full Quarterly Threat Report to see all four findings in depth, get hardening recommendations, and walk through a step-by-step reconstruction of an account takeover. Sponsored and written by Prophet Security.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added three flaws, each impacting Cisco, Citrix, and Fortinet, to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the patches by September 12, 2026. The vulnerabilities are listed below - CVE-2026-20079 (CVSS score: 10.0) - An authentication bypass vulnerability in the web interface of Cisco Secure Firewall Management Center (FMC) Software that could allow an unauthenticated, remote attacker to bypass authentication and execute script files on an affected device to obtain root access to the underlying operating system. CVE-2026-19490 (CVSS score: 9.3) - An authentication bypass vulnerability in Citrix NetScaler ADC and NetScaler Gateway when the appliance is configured as an AAA virtual server or as a Gateway (SSL VPN, ICA Proxy, CVPN, or RDP Proxy). CVE-2025-25249 (CVSS score: 7.3) - A heap-based buffer overflow vulnerability in Fortinet FortiOS, FortiSwitchManager, and FortiSASE that could allow a remote unauthenticated attacker to execute arbitrary code or commands via specifically crafted requests. The development comes as Cisco updated its advisory for CVE-2026-20079 to note that it became aware of active exploitation efforts targeting the flaw in August 2026. The company said it identified three clusters of post-compromise activity on FMC instances, namely UAT-12197, UAT-11823, and UAT-11988, leveraging the flaw for deploying web shells and malware. Cisco routers have been an attack magnet in recent years. In a report published late last month, Sygnia said it observed a China-nexus cyber espionage group dubbed Fire Ant obtaining unauthorized access to Cisco IOS XR routers and abusing them to facilitate persistence, data collection, and burrow deeper into high-value networks via custom malware. "This behavior shifts the router's role from a transit device to a collection platform," the cybersecurity company noted. "Once the actor controlled the router, the device became a vantage point for observing traffic moving through trusted network paths." CVE-2026-19490, on the other hand, has witnessed exploitation activity targeting Previdian's honeypot systems, with a total of 56 attempts registered since September 3, 2026. Of these, 36 attempts were recorded on September 8, 2026, alone. The addition of CVE-2025-25249 to the KEV catalog follows a report from SOCRadar about a malicious attack campaign that's suspected to have weaponized the flaw to deliver a feature-rich Node.js remote access trojan (RAT) codenamed PivotC2. The post-exploitation framework supports features such as interactive shells, tunneling, network scanning, and configuration harvesting. More than 3,000 IP addresses are estimated to have been targeted as part of the campaign, resulting in the infection of 178 devices with PivotC2. The majority of the compromises are concentrated in the U.S. The activity is assessed to be the work of a Russian-speaking threat actor driven by financial gain. The earliest evidence of active exploitation of the flaw dates back to July 2026. In the observed attacks, a shell script containing an exploit binary targets a vulnerable FortiGate instance to establish a reverse shell and run a single-line JavaScript command via Node.js. This, in turn, leads to the download of a second-stage JavaScript payload, which is decrypted and executed to deliver PivotC2. "PivotC2 establishes a persistent outbound TLS connection to a remote command-and-control (C2) server. Its feature set includes interactive shells, file transfers, SOCKS5/HTTP proxy tunneling, local and remote port forwarding, CIDR-range scanning, and FortiGate-specific configuration harvesting and credential decryption," SOCRadar said. "An auto-mode flag enables autonomous operations, automatically running a predefined command sequence upon initial infection." The findings once again demonstrate that threat actors are continuously scanning exposed perimeter edge devices to obtain initial access by taking advantage of their lack of robust monitoring or telemetry logging. SOCRadar is recommending organizations using Fortinet products to limit internet access, hunt for indicators of compromise, rotate credentials, and apply the latest patches.

Fake GTA 6 download delivers malware-packed bundle to impatient gamers Grand Theft Auto VI (GTA 6) is still three months from release, but cybercriminals are not waiting for the launch date. Security firm Huntress found malware disguised as a leaked copy of the game, aimed at fans hoping to get their hands on it early. The sample Huntress pulled apart contained several different malware components. Researchers described an opportunistic bundle, “throwing everything they can at the users who attempt an installation,” a package that includes a fake installer, several RATs, an infostealer, ransomware used as a wiper, and a web browser. A fake installer hides the payload Opening the ISO presents the main installer file, gta6installer.exe, still carrying the icon from GTA5. Running it displays a message in Russian, warning that the installation may fail with a “License not found” error and offering an email address to request a fix. Message contained within the fake GTA6 installer (Source: Huntress) Once the install finishes, a script fires and shows exactly that error message, giving the user a plausible reason why the game never launched. While that plays out, the actual payload installs in the background. Huntress contacted the email address listed in the installer to see who would respond, but didn’t receive a response at the time of writing. “The malware contained within the ISO appears to be fairly old, repurposed for this opportunistic attack, with files dating back to 2023 in many cases. Proceeding with the installation, several files are added to the %TEMP% folder on the system, many of which appear to be GTA6-branded to avoid suspicion,” researchers wrote. “The checkinternetconnection.bat file then launches Microsoft Edge and connects to https://clck[.]ru/34uJnp, where it confirms that it has an internet connection before proceeding to unpack and install the various malware components.” RATs, an infostealer, and destructive ransomware Multiple copies of NJRAT show up first, giving an attacker a shell, keystroke logging, camera access, browser credential theft, file upload and download, control over files and registry entries, live desktop viewing and screenshots, and access to cryptocurrency wallet details. Alongside it comes a copy of DCRAT, which gives an attacker mouse control, screenshot capture, clipboard access, registry read and write permissions, audio device discovery, and window tracking. DCRAT also rewrites the Windows hosts file to block antivirus telemetry from reaching security vendors. Then there’s an infostealer, a tool called Mercurial Grabber that’s freely available on GitHub under an “educational purposes only” label. It collects Discord tokens, Chrome passwords and cookies, Roblox and Minecraft session data, Windows product keys, and screenshots, then sends everything out through a Discord webhook. The most damaging piece is a Chaos ransomware variant. “While this is technically a well-known ransomware family, it appears that the actors are not looking to collect a ransom from infected users. Instead, they encrypt and/or destroy files on the system, effectively utilizing the ransomware as a wiper,” researchers noted. It encrypts files 200MB and smaller and overwrites anything larger with random data, destroying it outright. Shadow copy backups are deleted and Windows recovery options disabled, while the desktop wallpaper is changed to an image of SpongeBob paired with a message claiming the hack was carried out by the “ASHA Hacker Team.” “Hello, your files has been encrypted by achvz1om i don’t have paypal or other banks so you don’t can donate me so, your files has been encrypted forever,” the ransom note reads. Finally, the installer drops a copy of Yandex Browser, for no apparent reason Huntress could pin down. Combined with the Russian-language messaging throughout, this suggests Russian-speaking users may be among the intended targets. Windows Defender can detect the malware The good news, researchers said, is there’s nothing particularly new in this ISO. The malware it contains is several years old, and an up-to-date version of Windows Defender should have no trouble detecting it and stopping it from compromising the system. “Generally speaking, it’s not a good idea to attempt to download cracked, pirated software, especially if the game in question has not yet been released. This is fertile ground for scams and threat actors attempting to take advantage of the impatient and overeager,” Huntress concluded.

Multiple espionage-motivated threat activity clusters have been found deploying a previously undocumented exploit kit called BlueMoon that chains together multiple vulnerabilities in Microsoft Windows and Google Chrome. The first in-the-wild use of BlueMoon has been attributed to the China-aligned state-sponsored group tracked as APT31 (aka Bronze Vinewood, Judgement Panda, JungleBamboo, PerplexedGoblin, RedBravo, TA412, Tide Castle, and Violet Typhoon) on August 28, 2026. "Within days, several other espionage-motivated clusters began using BlueMoon, the majority of which have a suspected China nexus," Proofpoint said in a report published today. "However, BlueMoon may not be exclusive to China-aligned actors, as some usage remains unattributed and there are also potentially more actors using the exploit kit." The exploit chain employs three vulnerabilities - CVE-2026-85046, a type confusion in V8 in Google Chrome CVE-2026-87491, an out-of-bounds bug in V8 in Google Chrome that can lead to a sandbox escape CVE-2026-85880, a heap-based buffer overflow vulnerability in Windows Advanced Local Procedure Call (ALPC) While CVE-2026-85046 was patched by Google last week, CVE-2026-85880 was addressed by Microsoft as part of its September 2026 Patch Tuesday updates. Proofpoint told The Hacker News that Google, despite currently not issuing CVEs for V8 sandbox escapes, has assigned one for this specific flaw under CVE-2026-87491. A patch for the security defect was released by Google on September 8, 2026. Interestingly, both V8 vulnerabilities in Chrome are said to have been "patch-gap" zero-days at the time they were maliciously exploited. The enterprise security company said the flaws had already been fixed in public upstream Chromium source code, but were yet to be propagated to the latest stable releases of Chrome and Chromium-based browsers available. It's suspected that the developer behind the exploit kit may have been closely keeping track of publicly available Chromium patches to put together the browser exploit chain. Attack chains making use of BlueMoon have been found to rely on phishing emails as a starting point to trick targets into visiting an actor-controlled URL that triggers the two V8 flaws in succession to achieve code execution and escape the browser sandbox, and then exploit the Windows local privilege escalation bug to inject shellcode that downloads multiple payloads depending on the threat cluster behind it. "Following the Chrome exploits, the kit uses a reflectively loaded DLL to fingerprint the Windows host, which the exploit kit JavaScript uses to decide whether to attempt the LPE exploit," Proofpoint researchers Mark Kelly, Greg Lesnewich, Konstantin Klinger, Saher Naumaan, Julia Paluch, David Galazin, and Stuart Del Caliz said. "A second reflectively loaded DLL runs the LPE exploit to elevate the renderer process. With those additional privileges, a separate injector shellcode injects a CreateProcess stub into the parent Chrome broker process, executing an operator-specified command. The default command downloads a remotely hosted executable via a curl command and executes it." Multiple variants of the exploit kit have been detected with subtle changes that removed comments or obfuscated its components, while others incorporate campaign-specific landing pages and redirects, browser-side operating system checks, or additional telemetry. Despite these modifications, the underlying exploit chain remains the same. A brief description of the observed attack chains is as follows - APT31 (Beginning on August 28, 2026), which used spear-phishing lures to target non-governmental organizations (NGOs), mining companies, and physical commodity trading firms in the U.S. to trick victims into clicking on a malicious link that serves BlueMoon, which then downloads and runs a loader executable responsible for installing a malicious browser add-on disguised as Google Gemini using a Chrome extension integrity bypass technique called GhostChrome-X. The extension is a browser-surveillance and credential-theft backdoor dubbed GemStone that allows the threat actor to issue commands through a command-and-control (C2) channel. UNK_LateNight (Beginning on September 2, 2026), a China-aligned threat cluster which used spear-phishing lures to target multiple U.S. aerospace companies and lead victims to malicious links that deploy BlueMoon and the ShadowPad backdoor using DLL sideloading. UNK_DoubleCheck (Beginning on September 2, 2026), which used spear-phishing lures to target a Vietnamese manufacturing entity to send victims to an actor-controlled Cloudflare Workers domain hosting BlueMoon, which is then used to initiate a DLL sideloading attack to drop a Rust binary. The malware, for its part, contacts a Cloudflare R2 Bucket to fetch and execute a second DLL sideloading pair. UNK_QuietRacket (Beginning on September 3, 2026), a China-aligned threat actor that used spear-phishing lures to target government, consulting, and financial sector organizations in Indonesia and Singapore to take victims to landing pages that deploy BlueMoon. The exploit kit, in this case, has been modified to download and execute a DLL sideloading pair. The rogue DLL communicates with Cloudflare Workers domains to obtain and run a .NET assembly in memory. The .NET in-memory payload is designed to create a scheduled task to launch the DLL sideloading sequence for persistence. What's more, the presence of extensive logging capabilities and verbose comments within the source code artifacts suggests the malware may have been developed with assistance using artificial intelligence (AI) tools. This is also bolstered by repeated references to the v8CTF challenge, an exploit-focused vulnerability reward program (VRP) and capture-the-flag (CTF) competition run by Google targeting the V8 engine. Proofpoint said it's not known if the V8 exploits were genuinely developed against the v8CTF bug bounty framework, or if this framing was used by the exploit developers to bypass large language model (LLM) guardrails. "It is currently unknown how multiple distinct threat actors obtained access to the exploit kit," Proofpoint said. "Given its ease of adoption, it is likely to proliferate further and be adopted by espionage-motivated and financially motivated threat actors as patched versions are fully rolled out across all Chromium-based browsers." "A fully weaponized Chrome exploit chain has historically been a high-value, rare capability. BlueMoon was developed, deployed rapidly, and shared across multiple threat actors within days in a manner that had high detection signals." "This may reflect a reduced cost and barrier to entry for this class of capability, as AI agents increasingly enable threat actor exploit development. This is particularly relevant for open source codebases, such as Chromium, where upstream patches are publicly accessible prior to downstream consumers of the codebase applying the patch. This creates a window for threat actors to attempt to rapidly reverse engineer patches and develop exploits ahead of downstream stable releases." The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has since added CVE-2026-85046, CVE-2026-85880, and CVE-2026-87491 to its Known Exploited Vulnerabilities (KEV) catalog, giving U.S. Federal Civilian Executive Branch (FCEB) agencies until September 18, September 22, and September 23, 2026, respectively, to patch them. However, updating the browser closes the way in. It does not remove any artifact that has already been installed. The GemStone extension and the scheduled tasks the other groups created survive a patch, necessitating that targeted organizations check for the following - Process tree: chrome.exe starting cmd.exe, then curl.exe, then msgbox.exe File: ChromeUpdate.exe or msgbox.exe in the Windows %TEMP% folder Folder: C:\Users\Public\stomp_ext Scheduled task: EdgeCore_AutoUpdate, MicrosoftEdgeUpdatesTaskMachine, Avpcheckup or GeForceService Mutex: Dataupcheckinfo Registry key: HKCU\SOFTWARE\Classes\CLSID\{5D4CFCB7-222C-4CA3-96B6-1F8195FBBB4B}\InprocServer32 Proofpoint has also published detection rules for the kit's JavaScript loader and its C2 traffic, numbered from Signature IDs 2071919 through 2071924. (The story was updated after publication to include confirmation from Proofpoint that the V8 sandbox escape is tracked under CVE-2026-87491.)

Orchid Security targets AI agent risk with drift detection and kill switches Orchid Security has announced identity drift detection and application-level kill switches for AI agents. They can complete authorized objectives beyond their initial privilege level within seconds. AI agents do not need to “break” security controls or workflow guardrails. AI agents can find and use the identity debt already embedded across the enterprise: hard-coded credentials, orphaned accounts, unmanaged authentication paths and excessive permissions. The new AI readiness controls help enterprises scale AI adoption without losing control. AI adoption is now a board mandate Boards have moved from asking whether their companies should adopt AI to asking how quickly they can scale it. Resisting is no longer a viable security posture. What enterprises need is a defensible plan that enables adoption while keeping autonomous agents inside authorized boundaries. “AI transformation is exciting. Identity hygiene is not,” said Roy Katmor, CEO of Orchid Security. “Boards are no longer asking whether AI will be adopted—they are asking why it is not moving faster, and security cannot answer with a blanket ‘no.’ Enterprises need to observe how agents act, understand when they drift, and govern them immediately, including terminating the authority through which they operate.” The obstacle is not agent behavior. It is what agents inherit. Agents do not need to break security controls to exceed their intended scope—they find and use the identity debt already embedded across the enterprise: hard-coded credentials, orphaned accounts, unmanaged authentication paths, and excessive permissions. Orchid’s Identity Gap 2026 found that 57% of enterprise identity is unseen and unmanaged. Agents can turn that identity dark matter into an active path to elevated access in seconds to minutes—far faster than periodic governance reviews can detect or contain it. An operational framework for agent adoption: Observe→ Understand→ Govern→ Prove Orchid enables continuous, auditable AI-Readiness and defensibility: OBSERVE: Discover AI agents and the identities, applications, credentials, tools, and access paths through which they operate. Continuously capture actual behavior, not only what was configured in the studio. UNDERSTAND: Compare runtime behavior with the agent’s original purpose and authorized scope. Orchid applies readiness tags to applications, accounts and access paths, exposing identity hygiene gaps, excessive permissions and environments that are not yet safe for agentic access. GOVERN: When behavior or effective authority drifts beyond policy, Orchid orchestrates action through the organization’s existing identity, security and AI infrastructure. Actions can include reducing permissions, revoking credentials, disconnecting tools, suspending workflows or uniquely activating its own application-level kill-switch. PROVE: Orchid generates a defensible audit trail linking each agent action to the identity used, delegation chain, access path, business context, detected drift and resulting governance response. What enterprises should be able to demonstrate Before autonomous agents are deployed at scale: Identity hygiene: Every orphaned, dormant, local, and over-privileged account is identified and assigned a readiness status. Authorization guardrails: The organization can determine who or what may act, on whose behalf, for what purpose, and under what conditions. Runtime understanding: Actual agent behavior can be compared continuously against approved intent, permissions, and expected access paths. Universal auditability: Every action can be attributed to an identity, delegation chain, application, access path, and business context. Enforceable response: The enterprise can immediately restrict or terminate the authority a drifting agent operates through. Regulators are converging on the same requirements. NIST’s draft Cyber AI Profile notes that “regardless of where organizations are on their AI journey, their cybersecurity programs need risk management approaches that support and integrate the realities of advancements in AI.” In Europe, DORA obliges financial entities to demonstrate control over ICT access and third-party dependencies, an obligation that does not pause because the entity acting is an agent rather than a person. Availability Following the recent agentic enhancements to Orchid’s Identity Control Plane in May, the capabilities below are now available: AI readiness tagging across applications, identities, and access paths Identity hygiene and security risk findings for orphaned, dormant, over-permissioned, and suspicious accounts Continuous drift detection between an agent’s intended purpose and observed behavior Orchestrated response, including application-level kill switches that restrict permissions, revoke credentials, disconnect tools, or suspend agent workflows Audit generation documenting agent activity, identity context, detected drift, and the response Orchid has also expanded its integration ecosystem: Palo Alto Networks Idira: A certified PAM integration that discovers privileged accounts not previously known to Idira and brings them under management. Splunk Enterprise Security: A prebuilt integration that streams identity telemetry to the SOC for correlation, investigation, and incident response. Shannon Wilkinson, CIO and CISO at Findlay Automotive Group, described the tension from the practitioner’s seat: “The challenge is how to enable the business to move faster and realize the productivity that AI agents bring, but it honestly terrifies a lot of us. At Findlay we’re leaning heavily into AI to build a better customer experience. At the same time we must define guidelines, put guardrails in place and, above all, know what the identities are doing.” Enterprises have ignored identity dark matter in general, and poor identity hygiene specifically, for a long time now- which is one of the reasons that threat actors are more likely to log in than hack in today. But exposing AI agents to all the identity clutter that has accumulated over time is a recipe for disaster.

Zscaler Agentic SOC combines AI agents with zero trust telemetry Zscaler has announced Zscaler Agentic SOC, a new approach to security operations built to proactively reduce exposures, scale human expertise and stop AI-driven attacks at machine speed. Simply layering in AI capabilities onto the existing security stack will not provide the protection needed. Zscaler is delivering a new solution to the security operations center (SOC), purpose-built from the ground up with an AI-first approach to detect, investigate, and stop threats at machine speed. Threat landscape is defined by speed and stealth as AI-driven attacks move faster than SOC teams can manually correlate, analyze, and remediate. Threatlabz, Zscaler’s global research team, is also seeing a rise in evasive tactics, including the use of trusted sites to host attacks, abuse of legitimate remote management tools, and browser-based attacks. Zscaler Agentic SOC is built to meet that challenge by combining unique Zscaler telemetry, the world’s largest decoy mesh network, expert-validated agents, integrated Zscaler Zero Trust controls, and customers’ third-party controls to detect threats earlier and automate containment at machine speed. To power Agentic SOC, Zscaler has partnered with leading frontier AI labs, including Anthropic and OpenAI. By integrating their frontier models alongside Zscaler’s proprietary threat intelligence and zero trust telemetry, Zscaler is able to deliver AI agents that reason with greater depth, accuracy, and explainability than any single model or approach could achieve alone. This extends beyond threat detection, with Zscaler’s open platform approach enabling direct integration with frontier models, allowing security teams to ingest vulnerability findings and operationalize them within their SOC workflows. This collaboration reflects Zscaler’s commitment to building on the best available AI that includes speed, reliability and transparency that security operations demand. “AI-driven attacks are moving faster than traditional SOC models were ever designed to handle,” said Deepen Desai, EVP of Cybersecurity at Zscaler. “Agentic SOC is a fundamental rethinking of security operations, built with agentic capabilities at its core to reduce exposures proactively, extend human expertise with AI agents and contain threats at machine speed. With unmatched inline telemetry, specialized AI agents and closed-loop remediation, Zscaler is giving security teams the visibility and control they need to outpace modern attackers.” “The past year has made one thing clear: AI attacks are fundamentally changing the threat landscape, operating at a speed, scale, and level of adaptability that looks very different from traditional human-led activity,” said Allie Mellen, principal analyst and author of Code War: How Nations Hack, Spy, and Shape the Digital Battlefield. “To defend effectively, organizations must double down on the fundamentals — Zero Trust principles, preventing data exfiltration, limiting access, and making AI attacks as expensive as possible.” Reimagining SecOps: The Zscaler differentiation Unified exposure and threat management: Zscaler connects proactive attack surface reduction with reactive threat defense in a single platform, enriching context and accelerating protection. Unmatched zero trust telemetry: Zscaler sits inline, capturing network, identity, endpoint, cloud and AI insights across its 750 billion daily zero trust transactions that security teams can operationalize for real-time detection and response. Specialized AI agents built on frontline experience: Zscaler AI agents have been trained and continuously tuned on more than 10 years of frontline SOC, managed detection and response and threat-hunting experience, informed by threat intelligence derived from thousands of customer environments globally. Closed-loop inline remediation: Zscaler automatically contains threats at machine speed with native inline controls that can isolate compromised users, block command-and-control communications, and cut off lateral movement. Integrations with customers’ third-party tooling provide increased options for nuanced responses to active threats. “Our team was drowning in alert noise, forcing top analysts into triage instead of proactive threat hunting,” said Andrea Liccardi, Sr. Cybersecurity Manager, Maire Tecnimont. “Zscaler Agentic SOC gives us full attack-path context using telemetry we already had in place, helping our team move from fragmented signals to faster, more informed decisions. Zscaler has proven to be one of our most valuable cybersecurity partners, continuously helping us improve operational efficiency, visibility, and our ability to focus our analysts on what really matters.” Open platform integration Zscaler Agentic SOC seamlessly integrates with your existing security ecosystem, pulling in third-party data to contextualize risks and threats. By triggering automated outbound actions, it proactively eliminates exposures and contains attacks at machine speed. Key features of Zscaler Agentic SOC: Data-rich context graph: Correlates real-time zero trust telemetry with third-party data to map, prioritize and investigate complex incident chains. Specialized AI agents: Autonomous agents perform dedicated roles across triage, root-cause investigation, assigning verdicts, and triggering response workflows, reducing analyst workload and accelerating defenses. Advanced detections informed by threat intelligence: Applies frontline threat research and rich telemetry to identify sophisticated attacks earlier and with greater precision. Continuous threat hunting and expert support: Combines AI speed with seasoned human judgment from Zscaler and Red Canary security experts.

A recent Unit 42 investigation into seemingly low-priority enterprise infections demonstrates how the most effective camouflage in cybercrime is not necessarily in the use of sophisticated techniques, but in how unremarkable the threat appears. The activities that we investigated would typically not require escalation or further inquiry. But upon closer inspection, we discovered a massive cybercrime campaign largely targeting young gamers. Tracked as CL-CRI-1171, in accordance with Unit 42’s attribution framework, the group behind this cluster has operated under the radar for at least two years, distributing an indeterminate number of payloads. The group behind CL-CRI-1171 provides an infection service for other threat actors who want to spread their malware indiscriminately. This pay-per-install (PPI) marketplace drove hundreds of infections through YouTube channels and a parallel search engine optimization (SEO)-poisoning funnel, all using the same custom loader. We observed at least eleven YouTube channels that had hundreds of thousands of followers. We notified YouTube of these channels, which it promptly terminated. These channels were actively interacting with viewers to promote gaming content laced with links to download malware. Content in the channels included advice on improving frame rates, fixing game crashes and adjusting settings on game platforms. Although the videos provided real content for gamers, they also served as the delivery vehicle for infection, prompting viewers to download malicious tools. The SEO funnel targeted a more professional audience, promoting trojanized software that resulted in malware deployment on corporate endpoints, including critical infrastructure and even government entities. We identified three independent payloads delivered by the same loader between July 2025 and April 2026: two never publicly reported, Docro Hijacker and ARKTunnel, and a new variant of a previously unnamed backdoor, which we dubbed Insomnia remote access Trojan (RAT). These infections represent only a small sample of a much larger deployment campaign. We have identified more than 10,000 distinct loader samples, each capable of delivering unique payload combinations. We provide an overview of the cybercrime cluster and its loader infrastructure, and a technical analysis of three recently delivered malware strains. Palo Alto Networks customers are better protected from the threats discussed in this article through the following: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Our discovery of two separate infections delivering three entirely distinct malware families revealed one common denominator: a shared loader. By tracing this infrastructure, we mapped the broader activity of CL-CRI-1171, ultimately tying the cluster to a PPI marketplace responsible for delivering countless payloads over the last two years. This operation uses at least two funneling mechanisms to route traffic to the malware landing pages: a network of YouTube channels and SEO poisoning. The shared infrastructure between the YouTube and SEO funnels, consistent use of the same loader and a rotational domain pattern observed over an eight-month window all pointed to a single sustained operation, which we track as CL-CRI-1171. PPI networks operate as underground marketplaces. An operator compromises machines and auctions access to multiple buyers, each buyer deploying their own independent payloads through the same dropper. The result is a single infection that conceals multiple payloads from unrelated threat actors on the same endpoint, each with its own C2 infrastructure and objectives. Because the loader is designed to be disposable and generic, it rarely attracts the scrutiny needed to uncover its subsequent payloads. The investigation began with two identical and seemingly routine infections at separate organizations. Both events involved trojanized software downloads — one a Bluetooth driver, the other WinDirStat — and both affected machines executed an identical post-exploitation chain. The loader was unnamed, untracked and generic enough to be dismissed as commodity adware. But our discovery of a shared payload chain raised a question. How were two unrelated organizations infected by the same unnamed loader delivering the same set of payloads, just one week apart? Pivoting on the loader's C2 infrastructure revealed a sprawling network of rotational domains — over 200 unique hostnames following a distinctive two-word compound naming pattern (including bubbleslip, churchpail, dinosaursjam), rotating across .xyz, .cfd, .space and .info top-level domains (TLDs). The payloads delivered through CL-CRI-1171's infrastructure are not fixed, enabling the simultaneous delivery of unrelated malware families. In April 2026, two incidents initiated this investigation. They shared a single loader that delivered three separate malware families: Insomnia RAT, ARKTunnel and Docro Hijacker. A subsequent infection, observed in June 2026, delivered two entirely different payloads: GCleaner and Socks5Systemz. Figure 1 illustrates the structure of the operational architecture and the observed rotational malware bundles. Our in-depth analysis explores three operations that were spotted in two intrusion sets during April 2026. By examining the campaign’s trackers, we found that these operation payloads were in rotation from July 2025 to April 2026. This discovery provides a valuable snapshot of the group’s deployment capabilities and the variety of payloads they have been entrusted to deliver. Although the observed rotation appears to be highly structured, the discovery of over 10,000 unique OfferLoader samples points to a much larger distribution pipeline. It is very likely that the loader has delivered numerous other malware families. The SEO poisoning path was the first delivery channel we identified. Unsuspecting users searching for legitimate software landed on file-hosting lure pages that displayed a fake virus-scan animation before delivering the trojanized archive via a chain of redirectors into the PPI gate. A reconstructed example download page from the SEO poisoning funnel is shown in Figure 2. Analysis of the gate's tracker URLs revealed a critical detail. Each URL contained a click_id parameter: a Base64-encoded fingerprint containing the victim's operating system (OS), browser, the referring domain, the exact search keyword that led them to the lure and their public IP address, as Table 1 shows. Table 1. Example of a deobfuscated click_id. The gate uses this fingerprint to decide who receives the payload: a valid, fresh click_id forwards the visitor to the malware/loader download. This is an evasion tactic used to ensure that only real targets are infected, and to protect the actor’s infrastructure: scanners, crawlers or analysts receive a decoy clone of the legitimate WinRAR download page or broken links. This is why the campaign has almost no public footprint despite being highly active: automated URL scanners rarely pass the gate. Decoding hundreds of these fingerprints, with the assistance of AI, exposed the full names of YouTube video titles and their associated channels. Alongside search keywords for cracked software and game cheats, the q= field – which tracks which search query led to the infection – contained strings like "CS2 Potato Graphics Settings - Maximum FPS Boost for Low-End PC (2026 Guide) - Velvox." Searching for titles derived from the fingerprints led us to uncover a chain of gaming optimization YouTube channels. Their content included tips on boosting frames per second (FPS), fixing game crashes and tweaking settings on popular game platforms. While the videos provided authentic, engaging content for young gamers, they ultimately served as an infection delivery vehicle, prompting viewers to download a malicious “tool” or “optimization pack” via links in the description, as Figure 3 shows. Those links pass through intermediary sites, such as Blogspot, which contain social-engineering instructions that lead the victim to the same PPI gate infrastructure serving the SEO path. An example blog page is shown in Figure 4. We identified 11 channels connected to CL-CRI-1171, which collectively had hundreds of thousands of subscribers and millions of views. Our investigation revealed three malware strains delivered by the group behind CL-CRI-1171 between June 2025 and April 2026. The following sections explain the technical aspects of the loader used by this cybercrime group and the deployed malware payloads: OfferLoader – The delivery mechanism behind all recorded intrusions, an Inno Setup trojanized installer that sets up the other payloads. Operation A: Insomnia RAT – A dual-payload, cross-platform backdoor that brings its own environment to ensure survival. Targeting both Windows and macOS using Node.js, paired with a twin Python agent. Operation B: ARKTunnel – A previously unreported WebSocket tunneling RAT unpacks itself from a bitmap image using steganography. We found 50 samples spanning over a year of development, operating across four fictitious corporate-identity rotations. Operation C: Docro Hijacker – A Chrome backdoor that revives a browser-hijacking technique first seen in 2015, re-engineered to bypass modern integrity protections. This campaign represents the first observation of this modern variant in the wild. We discovered two intrusion sets that began in the same way: a user searched for a legitimate utility, clicked a top search result that led to a malicious domain, and downloaded what appeared to be a legitimate application. Both infections delivered the same three payloads. First intrusion set: Downloaded Bluetooth Driver for Windows 10.exe from a file-sharing archive. The installer was a trojanized Inno Setup package carrying the PPI loader with affiliate ID CID=2855. Second intrusion set: Browsed to noiseship[.]cfd, a domain registered just 39 days earlier, and downloaded a trojanized windirstat.exe installer. This package carried the PPI loader with affiliate ID CID=3075. The operator's code and C2 communication designate each payload slot as an "offer," tracking variables as offer_execution, offer_execution_fail and offer_exists. Based on the naming convention, we track this loader as OfferLoader. OfferLoader uses chained Inno Setup (a legitimate installation packager) packages to deliver multiple payloads. Figure 5 shows the infection chain. OfferLoader is delivered in a ZIP file, with the source download site providing the social engineering instructions required to guide users through downloading and executing an extraction tool. Based on our analysis of the collected samples, we observed the loader being delivered alongside a legitimate version of WinRAR, renamed to .store. The installer contains no embedded application files; all malicious logic is contained in the compiled Pascal [Code] section, which triggers when the installation page is displayed. In two separate intrusion sets we discovered that the ZIP file contained OfferLoader masquerading as a windirstat.exe installer that initiates the compromise by unpacking windirstat.tmp. This temporary file transmits an initial tracking beacon to voyagemist[.]space. This is another gating mechanism: depending on the structure of the beacon, one of two text files will be retrieved. They either contain “no” to signal that the loader should not unpack further stages, or “ok” to signal all offers will be deployed. Following this check-in, the process spawns three child processes: eld0.exe, eld1.exe and eld2.exe. Each child process corresponds to a different malware campaign. The loader passes specific affiliate-tracking parameters to each process via a command line. Figure 6 illustrates the entire OfferLoader infection chain at the time of the intrusion. OfferLoader's role ends once the three offers are spawned. From this point forward, each child process operates as an independent malware campaign with its own infrastructure, C2 protocol and objectives. The following sections analyze what each offer delivers. Insomnia RAT simultaneously distributes two payloads: An upgraded variant of a Node.js backdoor (reported by Walmart Global Tech in 2025) A complementary Python backdoor We have dubbed these twin payloads Insomnia RAT, due to the user-agent string used for C2 communications: insomnia/2023.4.0 Windows. Figure 7 shows the full infection chain that delivers Insomnia RAT’s twin payloads. Eld0.exe drops the a.dll payload and spawns a hidden PowerShell process to download and execute t.ps1. This double-stage installer script disables Windows Defender protections, adds the entire C:\ drive as an exclusion, suppresses security notifications and deploys the two Insomnia RAT backdoors. t.ps1 also downloads and sets up the environment needed to execute both backdoors by installing Python and Node.js on the victim’s machine. Node.js is hidden from the system's Add/Remove Programs list by setting SystemComponent=1 in the registry. The first part of Insomnia RAT is a Node.js agent downloaded from stryper[.]info/aa.js. While the prior variant targeted Windows, Linux and FreeBSD with a single payload, this iteration targets Windows and macOS using platform-specific C2 server lists. It also deploys a companion Python agent as a redundant fallback, ensuring persistent access if one runtime environment is detected or removed. The backdoor collects the victim's MachineGuid, universally unique identifier (UUID), hostname and operating system details. It then contacts its C2 servers via an HTTPS POST request to /d using a User-Agent string, insomnia/2023.4.0 Windows to disguise itself. The C2 server responds with a JSON array containing commands. These specify a payload type (node, cmd, ps1, sh, or ow for a self-update) and a download URL. Results are reported back to the /e endpoint. To establish persistence, the installer registers a scheduled task named Maps Performance Task under \Microsoft\Windows\Maps\. This mimics a legitimate Windows task, executing the backdoor hourly and at system startup under the SYSTEM account. The same t.ps1 script installs a second, redundant agent. This Python script is downloaded from aa.amazingshield[.]xyz. The installer downloads a legitimate Python distribution and registers a second scheduled task, OOBETaskScheduler, under \Microsoft\Windows\Servicing\. The Python agent is simpler than its Node.js sibling, but follows the same C2 protocol pattern: POST requests to /d for tasks and POST requests to /e for error reporting. The agent collects the MachineGuid, OS product name, hostname and processor architecture. The Python agent used crowdstri[.]com as its C2 domain. This appears to be a deliberate typosquat of crowdstrike[.]com, designed to blend into logs and evade quick security reviews. The eld1.exe chain terminates in a previously undocumented tunnel payload. The chain uses least-significant-bit (LSB) steganography to deploy the final payload. Figure 8 shows the full infection chain of Operation B. Rather than dropping an executable directly to disk, eld1.exe extracts a ZIP archive from a BMP image resource using LSB steganography. The result is the payload archive, ProcorTrex.zip, which contains wscl.exe, a previously unreported WebSocket-based tunneling RAT. We named this RAT ARKTunnel, based on the attacker's fabricated company name rotation of EarthKark and TamarkLark. ARKTunnel installs itself as a Windows service named wscl-13 or msvcsrvc with a delayed autostart configuration. The RAT supports TCP and UDP tunneling, as well as file execution. The C2 server address, reg.pcsdkflyer[.]ca, is decoded from a 39-byte configuration blob using Base64-decoding followed by an XOR decryption routine. The portable executable (PE) metadata of wscl.exe contains a fabricated company name, TamarkLark Corporation, and a fictitious product name, TamarkLark Manager, which led us to suspect that other ARKTunnel samples might use additional fabricated company names. The investigation revealed at least 50 samples deployed over the course of a year. The developer rotated through at least two fake company identities while maintaining an identical icon, binary structure and deployment pattern: EarthLink in May 2025: EarthLink is the name of a legitimate internet provider, however the attackers used this name coincidentally in the file version information. The attackers did not use or impersonate EarthLink resources or identity. EarthChain from May 2025–April 2026: EarthChain is also real company name that the attackers used coincidentally. Likewise, also they did not use or impersonate the company’s resources or identity. EarthKark: A fake identity, used from February 2026–June 2026 TamarkLark: A fake identity, used from March 2026–June 2026 All of the samples share the same wscl.exe filename pattern and GUID-based temp directory extraction pattern, indicating that they are variants of the same family. Despite 50 samples spanning a full year of development and four identity rotations, ARKTunnel has attracted no public reporting or dedicated tracking, with each sample individually flagged as a generic Trojan rather than recognized as a tunneling implant. The eld2.exe payload installs a Chrome browser hijacker that we have named Docro Hijacker. The hijacker revives a browser-hijacking technique that has resurfaced periodically since 2015, now re-engineered to bypass updates to Chrome's integrity protections. While this iteration closely mirrors a proof-of-concept detailed by Synacktiv in 2025, this campaign marks the updated technique’s first documented instance of in-the-wild deployment. Figure 9 shows the Docro Hijacker installation chain. eld2.exe is an Inno Setup package, and much like its loader, it extracts and runs eld2.tmp which contacts the affiliate’s extentrack[.]com install tracker. eld2.tmp drops and loads Adblock.dll, which bypasses Chrome's Secure Preferences HMAC-SHA256 integrity check. The DLL extracts Chrome's HMAC key from resources.pak, computes valid HMAC signatures for the modified preference values and writes them directly to the Secure Preferences file. This file functions as an anti-tamper mechanism for browsers by storing a validated copy of the user's settings. This manipulation allows the malware to execute two primary actions: Search hijacking: Changes the default search provider to mqsearch[.]com, a domain that masquerades as a search engine Extension installation: Installs the docro extension, a Chrome Manifest V3 extension located at C:\ProgramData\DocsHelper\docro\ The docro extension uses Chrome's declarativeNetRequest API to dynamically rewrite network requests. Upon installation, it contacts vendralo[.]info to retrieve a unique per-victim UUID and fetch a set of network rewriting rules that are refreshed hourly. These rules are used to hijack and monetize search results in the victim's browser. When the victim performs an internet search, across any of more than 190 Google country-code domains, the extension loads a script from drelto[.]info/farlix into the search results page. Because the script runs within the search engine's own origin context, it has full access to the page content. This enables the operator to inject advertisements into organic search results, rewrite affiliate links to capture referral revenue and/or redirect clicks to attacker-controlled destinations. These actions are functionally transparent to the user and visually indistinguishable from the legitimate search page. The extension also checks vendralo[.]info for updates via /extensionInstaller/updateChromeExtension, allowing the operator to silently rotate to a new extension version at any time. Install telemetry is reported to finersto[.]com and extentrack[.]com. With more than 50 unique samples contacting mqsearch[.]com according to VirusTotal, Docro Hijacker appears to be a mature, independent monetization module. The actors behind CL-CRI-1171 did not use sophisticated evasion techniques, but focused their efforts on building a loader that is exceptionally difficult to track due to its clever gating mechanisms. Our investigation highlights how the authors of OfferLoader, by being intentional about its simplicity and by hiding all of its functions as bytecode within a package, designed the malware to evade scrutiny while quietly building a massive, mature infection funnel. Although OfferLoader was easy for defenders and security products to miss, its gating mechanisms were not, and the sheer number of them was our first clue that more widespread activity was occurring. While a loader that just drops a payload is seemingly routine, this mechanism allowed possibly thousands of rotational malware bundles, including entirely new and undocumented malware families, to remain hidden from standard security attention. Ultimately, this case serves as a critical reminder for defenders: Treating commodity loader infections as minor, routine events overlooks the dangerous payloads and campaigns that might be tied to them. Palo Alto Networks customers are better protected against the threats described in this report through the following products and services: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Through continuous cloud-based analysis, Advanced WildFire is designed to proactively identify and block OfferLoader samples as well as downstream payloads, including Insomnia RAT, ARKTunnel, and Docro Hijacker. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM can help detect and prevent the OfferLoader chain and all three payload branches described in this article. Cortex customers benefit from multiple layers of protection against this threat, including: - YARA-based signatures targeting the OfferLoader family and its staged payloads - Behavioral detection rules that help prevent: - Malicious Chrome extension setup - Untrusted service installations used for persistence - Trojanized installer execution patterns If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. SHA256 hash: 7f792c45de1e28fd42ac44c9444f157a2161742d130bac336c0e991aabbb112c File name: windirstat.exe File type: PE32 executable, Inno Setup 6.7.1 File description: OfferLoader trojanized WinDirStat installer delivered via SEO-poisoning SHA256 hash: fc485882626512e7ff82a1d7cd8e8fb3e9751b026d97e682d6908aefff1f2d73 File name: windirstat.tmp File type: PE32 executable, Inno Setup unpacked stage File description: Unpacked WinDirStat stage SHA256 hash: 3052bd320a34e12ee694811ed0578797477dfd480c664491e509ed15ce1a6961 File name: eld0.exe File type: PE32 executable, Inno Setup 6.3.0 SetupLdr File description: Insomnia RAT initial loader SHA256 hash: 25558ea78c4aa0fdd0f45fafcaa546d3115dc5806809d144a5801a40e48fd4c5 File name: eld0.tmp File type: PE32 executable, Inno Setup unpacked stage File description: Unpacked loader stage SHA256 hash: 9b0d9cbc0fd4a7bae8b78a15dfbe63052779414ad725845732c4a0083008da69 File name: a.dll File type: PE32 DLL File description: Executes the PowerShell downloader for the Node.js and Python second stages SHA256 hash: ceb30a5eb9ad9d9c6712c80726df16f96f99d9fc0753be241b00b4d636eb576e File name: t.ps1 File type: PowerShell File description: Insomnia RAT PowerShell loader SHA256 hash: cf184d04ca31fb2b6b7efd85399c29c1136b539153e137ceb3877b1b905791de File name: .py File type: Python script File description: the Python-based component of the Insomnia RAT dual payload. SHA256 hash: 62d49d0c78207ec2452cc8a30501db771c9edbae89889e41a7dd227551243e8e File name: aa.js File type: JavaScript File description: the Node.js-based component of the Insomnia RAT dual payload. URL: hxxps[:]//stryper[.]info/t.ps1 Description: Stage-2 PowerShell installer for the Node.js and Python agents URL: hxxps[:]//stryper[.]info/aa.js Description: Stage-3 Node.js agent URL: hxxp[:]//aa.amazingshield[.]xyz/33244556546.py Description: Stage-3 Python agent Domain: stryper[.]info Description: Second-stage PowerShell and Node.js agent host Domain: aa.amazingshield[.]xyz Description: Python agent host Domain: crowdstri[.]com Description: CrowdStrike-typosquat C2 for the Python agent SHA256 hash: aaebc8c07de485be6d1bfa956668c5e18aa1ff5588dfe84672e20ae90b4560f1 File name: eld1.exe File type: PE32 executable File description: LSB-steganography dropper. The attacker forged the PE version-info resource to mimic a popular test proctoring application. SHA256 hash: e05bc22afbc5ddd50b49c85ee169dd13318000d38286de2b8bcff98217256a8d File size: 92,657 bytes File name: procorTrex.zip File location: C:\Users\Public\procorTrex.zip File type: ZIP archive File description: ZIP carved from the eld1.exe BMP steganography payload SHA256 hash: b367762140ae7f5098230b8a5da738c9241f286281ec9439dd6ca581fc87989c File size: 245,248 bytes File name: wscl.exe File type: PE32 executable File description: WebSocket tunneling RAT ARKTunnel resource icons: SHA256 hash: d8d783f8e050a6e394f3c0aa5e2bc73a38d822e55fbc39c0648cbff566de3cdf File description: Resource Icon shared across ARKTunnel samples SHA256 hash: 06e0afd01bbc6c9d5dc16c3165089b233dc071e1f251abd06235d1b9166cdac5 File description: Resource Icon shared across ARKTunnel samples Domain: reg.pcsdkflyer[.]ca Description: wscl.exe WebSocket RAT C2 SHA256 hash: 2c6e11027b011042c9a118fc20728f8f4ebb6be8795cc84cc9a45622c297d354 File name: eld2.exe File type: PE32 executable, Inno Setup installer File description: Branch C installer that drops Adblock.dll and the docro Chrome extension SHA256 hash: 553ce594c9c6afdd4794fddc28c194e3bc3c1b052310e5099c58ac15bab72104 File name: eld2.tmp File type: PE32 executable File description: Inno Setup unpacked stage SHA256 hash: fdcc95b7791c0d6590dcf1a412dc9fcc92ad2095818d1b78368b31efad012007 File size: 3,041,280 bytes File name: Adblock.dll File location: %TEMP%\Adblock.dll File type: PE32 DLL File description: Chrome Secure Preferences HMAC-SHA256 bypass DLL that sideloads the docro extension and hijacks the default search provider Docro extension path: File location: C:\ProgramData\DocsHelper\docro File description: Manifest V3 Chrome extension sideloaded by Adblock.dll Domain: vendralo[.]info Description: Per-victim UUID and hourly rule delivery Domain: finersto[.]com Description: Extension install and start telemetry Domain: drelto[.]info Description: SERP-injection script host Domain: mqsearch[.]com Description: Hijacked the default search provider endpoint Domain: extentrack[.]com Description: Docs Helper install-success and install-failure callback Domain: animalview[.]xyz trickflag[.]info suitstraw[.]info connect.fuelleg[.]info vesselsystem[.]xyz minewave[.]info collartitle[.]info boardmagic[.]info placespoon[.]xyz needcherries[.]online Please note: While Velvox is a real company, the attackers used its name coincidentally. They did not use or impersonate the company’s resources or identity. “WinYahoo” PUP Modifies Chrome Secure Preferences – Malwarebytes NodeJS backdoors delivering proxyware and monetization schemes – Walmart Global Tech blog (Channels were taken down after we notified Google.)

Dei malintenzionati hanno preso di mira l’infrastruttura Cloudflare utilizzata dalla piattaforma Coder e hanno aggiunto al pool del registro i propri server. Di conseguenza, alcuni sviluppatori hanno ricevuto moduli Terraform dannosi, infettati da un info-stealer che rubavano token e altri segreti. Coder consente alle aziende di distribuire ambienti di sviluppo self-hosted protetti, inclusi quelli per la creazione di applicazioni IA. La piattaforma è utilizzata da grandi aziende come Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, nonché da enti governativi statunitensi e aziende della difesa. Secondo le informazioni degli sviluppatori, l’obiettivo dell’attacco è stato registry.coder.com , il registro da cui gli sviluppatori scaricano i componenti per i template degli ambienti di lavoro. Gli aggressori hanno ottenuto accesso all’infrastruttura Cloudflare tramite un API-key compromesso e hanno aggiunto al pool del registro indirizzi IP non autorizzati dove erano stati distribuiti server falsi. Di conseguenza, l’infrastruttura Cloudflare reindirizzava parte delle richieste degli utenti a questi indirizzi. Si segnala che gli attaccanti hanno modificato i moduli Terraform, set di istruzioni pronte per la creazione e la configurazione dell’infrastruttura, e i file dannosi si sono diffusi il 31 agosto 2026 tra le 07:35 e le 21:45 UTC. Il codice dannoso inserito nei moduli funzionava come info-stealer: cercava variabili d’ambiente e segreti del provisioner, chiavi API di piattaforme cloud e strumenti IA, credenziali CI/CD, segreti dai file di configurazione e la cronologia del terminale . Inoltre, sui computer infetti il malware raccoglieva token OIDC degli utenti, chiavi SSH, token temporanei di accesso a servizi esterni, password del database Coder e altri segreti, se il provisioner funzionava all’interno di coderd. Tutti i dati raccolti dallo stealer venivano infine inviati al dominio coder-infra[.]com. Ora si consiglia a tutti i potenziali interessati di cambiare il prima possibile tutti i segreti che il malware potrebbe aver rubato. Inoltre, prima di aggiornare alle versioni corrette 2.37.0, 2.36.4, 2.35.7 o 2.34.9, si consiglia di verificare i log del firewall , del proxy, del DNS e dei VPC Flow Logs per connessioni con coder-infra[.]com. Inoltre, si consiglia agli sviluppatori di cercare nei log del provisioner menzioni di data.external.telemetry, determinare quali moduli sono stati scaricati durante l’attacco e rimuovere i pacchetti potenzialmente dannosi dalla cache. Per la ricerca dei moduli e delle versioni dei template interessati, gli sviluppatori di Coder hanno preparato un bollettino di sicurezza specifico. In Coder sottolineano che i refresh-token non sono stati trasmessi al provisioner e che l’indagine non ha rilevato segni di compromissione dei dati clienti che la piattaforma stessa conserva. L'articolo Attacco a Cloudflare/Coder: moduli Terraform infetti rubano password, token e chiavi API proviene da Red Hot Cyber .

What breach and attack simulation needs to become in the AI era Breach and attack simulation (BAS) has always had a supply chain. Somebody has to read the threat report, pull out the techniques, and turn them into something that will actually run against your controls. That somebody has always been a human red team. Up until a few months ago, turning a major new threat into working simulation content within 24 hours counted as very fast. Frontier AI models broke the symmetry. In the post-Mythos era, the timelines have changed dramatically. The time from public disclosure to a weaponized exploit has collapsed to roughly ten hours, and there are more than 130 new CVEs appearing each day. To add to the chaos, fewer than 0.5% of disclosed vulnerabilities are ever patched upstream. A growing share of what lands in production was assembled with the same class of models that defenders are still evaluating. And when only one side of the pipeline is automated, the gap isn’t holding steady. It’s compounding. That’s the argument for upgrading your BAS instead of running it more often. What 338 million attack simulations found The Picus Blue Report 2026 aggregated 338 million attack simulations executed by BAS in customer production environments in the first half of 2026. Prevention effectiveness averaged 69%, so roughly a third of attacks were getting through the controls put in place to stop them. Logging reached a four-year high, with 58% of attack actions captured in the SIEM, while the alert score sat unchanged at 14%. The report found that detection rule failures cluster around two causes. Performance issues now lead at 49%, doubling from 24% just last year. Log collection gaps account for another 41% and are the more dangerous half because they fail silently; the behavior is never captured, so no rule can ever fire on it. Every one of those is a configuration and operations issue. None says “bad product,” and none is fixed by buying another one. That last sentence matters, because the industry’s reflex response to machine-speed attackers is another purchase: machine-speed defense, the AI SOC. An AI SOC’s unit of work is the alert. Point it at a pipeline where only one attack in seven produces an alert and it will handle that seventh at any speed you like, while the other six stay invisible. Autonomy cannot triage an alert that never fires. Fighting AI with AI starts upstream, in the detection engineering that creates the alert, and whether a validation program lightens that load or adds to it is where generation-one BAS starts to show its age. Generation-one BAS runs out of road Most enterprises running BAS today run a design that predates machine-speed adversaries. It has three structural limits, and each one is now load-bearing. The trigger is a calendar. A scheduled program produces a point-in-time result, and between runs, the results you proved quietly expire. A firewall cleanup or an EDR agent update silently undoes last month’s pass, and drift surfaces by accident or in the incident review; never by the program. This year’s Blue Report shows the speed of the decay: average prevention slid seven points in a single year and won them back the next, and the main difference was simply who kept testing. Strong performance is rented, not owned. It can’t answer the CVE question. “It hit the KEV overnight, would we detect it here?” now arrives daily, because patching everything is impossible. The manual answer costs four to six hours per CVE: read the advisory, grep the SIEM, and trust a coverage map that says “we have a rule for that.” So only the most critical CVEs ever get asked, and the rest of the list goes untested. The Blue Report shows where that ends: the year’s ten least-prevented vulnerabilities all sit in everyday software, a browser, archive utilities, OpenSSL, core OS components, and each was blocked less than 25% of the time. Automated pentesting cannot close this either: it needs a working exploit, and day one has none. Everything after the test is priced in human hours. A finding lands in a queue with generic guidance and a link, and the real work, translating it into a signature your NGFW will accept or a rule your SIEM will actually fire on, falls to an engineer. Finding the exposure was never the hard part. The flat 14% alert score is what detection engineering looks like when everyone wants the program and nobody can staff it, and running validation more often just makes the queue longer. What BAS has to be in the era of frontier AI models Agentic BAS is breach and attack simulation run as a closed loop by agents: a signal fires the exact test it requires, every gap ships a vendor-specific fix that is deployed and re-proven, and humans sit on the loop at the decision gates rather than inside it. The shape of the loop doesn’t change: simulate, validate, fix, verify. What changes is what feeds it, what fires it, and who runs it. Threats build themselves, with AI Threat Builder assembling the next campaign in minutes from your own CTI feeds and open-source intel. Simulations launch themselves, automatically and safely, against live production controls, so silent failures surface the day they are born. Fixes reach your teams, detections are deployed to the stack and prevention rules get auto-ticketed to SecOps. You oversee, agents execute, and signals decide when. That is machine-speed response with a human on the loop: it proves the alert fires, and ships the rule when it doesn’t. The method is behavioral: exploitation is simulated, so a threat is testable before an exploit exists. The payoff is closure: a gap that closes and gets re-proven is a different artifact from a gap that gets reported. Autonomy stays tunable per workflow, manual, supervised, or fully autonomous, under one fixed rule: no machine accepts risk. And automated pentesting can’t run this loop at all, nor match its three guarantees: no production risk, no SOC noise, and scale that isn’t billed by headcount. The translation problem In the Picus approach, we ingest threat intelligence the way analysts receive it: a CISA alert, a blog URL, a PDF, a CVE ID, or simply a threat-actor name like Scattered Spider. We read the source to understand the actual attack chain rather than keyword-match it, and assemble a playable, ATT&CK-mapped simulation in roughly nine minutes. Exploitation is simulated behaviorally, so no working exploit is needed: a KEV entry is testable the morning it lands, and the answer is no longer rationed to a few critical CVEs. Every relevant vulnerability comes back blocked, detected, or with a hidden residual risk, with a compensating rule for the tools you already run when patching must wait. Threat groups get the same treatment: the group’s exact playbook runs against your live controls the same day, every TTP is marked blocked, alerted, logged or missed, with each gap shipping its fix. And BAS should be a foundation rather than a ceiling: the same loop has to combine with autonomous penetration testing and exposure validation, so control validation can grow into a full exposure validation program with nothing repurchased or redeployed. What runs is never raw model output: only content validated in the Picus Threat Library executes, safely, in production. The engine runs on verified frontier access under Anthropic’s Cyber Verification Program, and your own agents can drive the same workflow through our MCP API. The next attack will be AI-driven. Your defense has to be too. What separates AI-era BAS from a faster schedule? Five things, and none of them is cadence: Runs are signal-driven, not schedule-driven: the change itself fires the test. A new CVE is testable the day it lands, with no exploit in hand. A missed detection comes back diagnosed, not as a finding to triage, whether it was telemetry, rule logic, or performance. Every gap ships a vendor-specific fix; a human approves, the machine deploys, and the same attack re-proves it. Continuous stops being priced in engineer hours. Any vendor, Picus included, should be willing to show you all five live rather than on a slide, and a contained pilot settles it in a week: a few agents on one segment, read-only SIEM access, attacks running the same day. When leadership then asks about readiness for frontier AI-enabled attacks, your answer is no longer an opinion. It’s a tested result, with a trend, on file. If you want to understand what an actual upgrade means, and how your team shifts from a calendar to signals without starting over, we’d be happy to talk about what upgrading actually gets you.

Mars Security brings threat intelligence to detection in real time Mars Security has announced Real-Time Intel-Based Detection, a capability that turns newly published threat intelligence into validated, ready-to-deploy detection rules within minutes of release. Built by former offensive operators, the new capability converts advisories from CISA, Mandiant, and other intelligence sources into MITRE ATT&CK-mapped detection rules across CrowdStrike, Wiz, Splunk, and cloud telemetry, each one tested against 30 days of the customer’s own data before it goes live. Mars believes it is the first platform to automate the complete path from threat advisory to production detection, including backtesting against the customer’s own environment, with no data ingestion and no changes to the existing security stack. Every security team already pays for threat intelligence. Very little of it becomes a working detection. When CISA, Mandiant, Unit 42 or Microsoft Threat Intelligence publishes a report on a new campaign, malware family or APT group, a detection engineer still has to read it, pull the indicators and techniques, work out which log source can see them, write the query, test it, tune it and deploy it. Across most SOCs that cycle takes days to weeks. Attackers rotate infrastructure in hours. That delay, the gap between knowing about a threat and being able to detect it, is where most successful intrusions sit. Mars now closes that gap automatically. How it works As new intelligence becomes available, Mars extracts the relevant indicators, techniques and infrastructure, maps them to MITRE ATT&CK, and writes the detection in the native query language of whichever telemetry can actually see the threat: CrowdStrike Falcon, Wiz, Splunk, firewall logs, Linux Sysmon, identity providers, AWS telemetry, or data lakes such as Snowflake and Databricks. Each rule carries a severity rating and lands in the team’s queue for review. Accept Rule pushes it live. Dismiss clears it. Nothing ships untested. Before a rule is offered, Mars runs the exact query against the customer’s previous 30 days of data and shows how many events it would have matched and how many of those would have been false positives. Teams can rerun the backtest over any window they choose. The same scrutiny applies to the underlying indicators: domains, IP addresses and hashes are scored against their false-positive history, and anything too broad, too old or historically noisy is dropped before it ever reaches a rule. “We spent years on the offensive side, and the thing that surprised us most was how rarely anyone saw us, even when the intel on our tradecraft was already public. Threat intelligence has always told security teams what is happening in the world. It never handed them the detection to find it in their own environment. Mars does that now, and it tests the detection against your data before it goes anywhere near production,” said Shahaf Galili, CEO, Mars Security. Coverage, not just alerts The engine also works in the other direction. Mars continuously maps the customer’s existing detection coverage against the telemetry already connected and flags the gaps that matter. Recent recommendations include AWS CloudTrail logging tampering, Route 53 domain transfer abuse, pass-the-hash lateral movement and suspicious Microsoft Graph API activity. For teams running detection-as-code, select recommendations arrive as an open pull request, ready to review and merge. That matters because static rules break the moment attacker tradecraft shifts. Mars was built by people who spent years watching detections fail from the other side, and its hunt library targets behavior rather than signatures so coverage holds as adversaries change tools. The same engine now extends to newer attack surfaces, including monitoring AI coding agents and the credentials they leak into logs, without buying another tool to watch them. “A SOC should not need a two-week backlog to act on a report that took an attacker two hours to make obsolete. When the intel lands, the detection should already be written, already tested against your data, and waiting for a click,” Ran Lerer, CTO, Mars Security, continued.

Threat actors are increasingly switching from AI-powered coding assistants to multi-agent frameworks that automate every stage of an attack. Drawing on telemetry from Mandiant's incident response engagements, threat actor tracking, and live platform defenses, the Google Threat Intelligence Group (GTIG) observed AI agents coordinating multiple attack tasks, troubleshooting failures, and adapting their actions with minimal human intervention. “Over the past quarter, threat actors have moved beyond simple prompt-based LLM interactions to integrate AI capabilities into multiple stages of an attack lifecycle,” GTIG notes. “While traditional script-based automation has long been a staple of threat actor operations, groups are increasingly upgrading these workflows, creating highly autonomous systems capable of reasoning through complex tasks and making dynamic decisions without the need for human oversight.” In one such incident, a financially motivated attacker compromised an organization’s cloud infrastructure and deployed an autonomous multi-agent framework. In less than six hours, the threat actor planned, built, and deployed a mass credential-harvesting campaign using an AI coding chatbot, a prompt, and markdown agent instructions, Google says. The AI agents managed the vulnerability-scanning pipeline, harvested thousands of third-party credentials, troubleshot problems in real time, rotated IP addresses, and routed attack traffic through legitimate, compromised cloud environments to evade detection. This approach dramatically reduced “human-in-the-loop” latency and the response windows for defenders. In another incident, the researchers found an exposed command-and-control (C2) server hosting an automated reconnaissance and credential-management framework called “Recon.” Its files included instructions for AI agents, knowledge files, and OpenClaw artifacts related to the framework that managed in real-time more than 23,800 harvested secrets, such as API keys. GTIG's report notes other examples where China-linked cyberespionage actors experimented "with AI-powered development tools to build an AI-assisted, automated exploitation and post-exploitation pipeline." The researchers say that other espionage groups, such as the Russia-based UNC5792, integrated AI models to automate monitoring bots searching Telegram channels for information of interest to the government. However, GTIG underlined that fully autonomous hacking has not become widespread yet, and did not observe threat actors deploying fully autonomous pipelines for zero-day discovery and network exploitation against real-world targets. The company also noted that Gemini, its AI model, caught many of these abuses early and responded in accordance with its safety protocols, allowing Google to take additional action, disrupt the campaigns, and ban the associated accounts. AI tool abuse has also been observed in supply-chain attacks conducted by UNC6780 (TeamPCP), Gemini AI distillation operations involving 100 million prompts, and a growing market for stolen AI account credentials and API keys. Also, state-backed groups continue to use AI for reconnaissance, phishing, malware development, exploitation, post-exploitation, data processing, and propaganda. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Adobe on Monday released security patches to address a maximum-severity flaw impacting Adobe Commerce and Magento Open Source that has come under active exploitation in the wild. The vulnerability, now tracked as CVE-2026-75650 (CVSS score: 10.0), has been codenamed StyleSmuggler by Sansec, which discovered zero-day exploitation starting September 4, 2026. "This update resolves a critical vulnerability that could result in arbitrary code execution," Adobe said, adding it's "aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants." At its core, the flaw abuses Magento's template system through PHP code injection to generate a "Payment Transaction Failed Reminder" email, triggering code execution in the process. The shortcoming affects the following versions - Adobe Commerce - 2.4.9-2026-aug and earlier - 2.4.8-2026-aug and earlier - 2.4.7-2026-aug and earlier - 2.4.6-2026-aug and earlier - 2.4.5-2026-aug and earlier - 2.4.4-2026-aug and earlier Adobe Commerce B2B - 1.5.3-2026-aug and earlier - 1.5.2-2026-aug and earlier - 1.4.2-2026-aug and earlier - 1.3.4-2026-aug and earlier - 1.3.3-2026-aug and earlier Magento Open Source - 2.4.9-2026-aug and earlier - 2.4.8-2026-aug and earlier - 2.4.7-2026-aug and earlier - 2.4.6-2026-aug and earlier Patches have been released as part of a hotfix's available for download from the following link: repo.magento[.]com/patch/VULN-39341-composer-patches.zip "To help resolve the vulnerability for the affected products and versions, you must apply the VULN-39341 patch (depending on your version) and rotate your encryption keys," Adobe said. The development comes days after the Dutch e-commerce security company revealed that threat actors are exploiting CVE-2026-75650 to deploy a Rust-based Linux backdoor that connects to an external server and awaits further instructions. Separately, the issue has been abused to deliver a PHP dropper on susceptible sites that writes a web shell capable of executing arbitrary PHP code. According to Netherlands-based Disrex, a Magento server managed by the e-commerce development platform is said to have been compromised 50 minutes after the first confirmed StyleSmuggler exploitation was reported on September 4, 2026, at 10:20 p.m. UTC. "StyleSmuggler turns Magento's own template-processing and dependency-injection code into an unauthenticated remote-code-execution chain," Disrex said. Telemetry data from Previdian shows that 12 exploitation attempts have been recorded against its honeypots since September 7, 2026, from two unique IP addresses from China and Romania. That said, the efforts have been unsuccessful, Founder and CEO Ryan Dewhurst said. Update The U.S. Cybersecurity and Infrastructure Security Agency (CISA), on September 8, 2026, added CVE-2026-75650 to its Known Exploited Vulnerabilities (KEV) catalog, requiring Federal Civilian Executive Branch (FCEB) agencies to apply the fixes by September 11, 2026. In tandem, Adobe has also released patches for more than 170 vulnerabilities across its products, including CVE-2026-82004 (CVSS score: 10.0), an operating system command injection flaw in Campaign Classic leading to arbitrary code execution. Also patched by Adobe are two critical vulnerabilities in ColdFusion CVE-2026-48273, CVSS score: 9.9, and CVE-2026-75746, CVSS score: 9.1) that could result in arbitrary code execution. The web design software maker said it's not aware of any exploits in the wild for any of these issues.

Cybersecurity researchers have disclosed details of a complex Chromium-based post-exploitation toolkit called PEEP that masquerades as a bookmarks extension for the web browser. "Requiring prior administrative or code execution access, its installer injects the extension directly into Chrome/Edge profiles, bypassing Web Store checks and user prompts by forging Chromium's own Secure Preferences integrity values," SOCRadar said. "A native-messaging tool then extends it beyond browser telemetry to host-level command execution and file management." Once installed, the PEEP "extension" agent polls its command-and-control (C2) server ("206.237.30[.]232" or "xfjcc[.]fun") every 30 seconds over plaintext HTTP for new commands, while exfiltrating browsing history, active-tab metadata, and session cookies. It also functions as a remote access and browser monitoring toolkit that runs host commands, steals credentials, hijacks sessions, and alters web pages. PEEP is built on the foundations of RedExt, an open-source, browser data analysis and red teaming framework that has also been put to use in prior GlassWorm attacks. However, it expands on the toolkit with dedicated installation routines, a native host bridge, heartbeat telemetry, an update channel, and a broader command set. This, in turn, makes PEEP a derivative of RedExt. PEEP is described as a post-compromise framework as it lacks an initial access vector itself, meaning it requires the operator to breach a machine through some other means and deploy the malware. The activity remains unattributed, although the presence of Chinese-language artifacts in the source code points to a Chinese-speaking threat actor. The extension masquerades as "Smart Bookmarks" (ID: ejkndncpkdcjcikfhiamcdehdoegilbj). It's the main agent responsible for executing the beacon loop by polling "/api/commands," harvesting browser data, receiving additional tasking, and sending the results back. The browser add-on also invokes an auxiliary executable ("nm_host.exe") when said task requires operating system access, while browser-based commands (e.g., screenshots, clipboard, or JavaScript injection) are run locally. The use of the Native Messaging Host binary transforms the malware from a basic credential stealer to a remote-access tool. "Operating in the user context, the extension extracts browser artifacts and uses com.peep.lab/nm_host.exe to run shell commands, manage files, and discover processes and services," SOCRadar said. "Bypassing Web Store checks, PEEP maintains persistence via sideloading, enterprise force-install policies, preference-integrity manipulation, and a ScriptCache fallback." Also used by the extension are several other endpoints - "/api/register" to register the infection "/api/agents/ /heartbeat" to send details about the browser's User-Agent string, operating system, and time zone "/api/extension_update/" and "/api/extension_crx/" to update the extension itself "/api/agents/ /task_result" to post the results of the command execution "/api/exfil" to post auto-collected data, such as cookies, recent history, open tabs, active URL, public IP address, locale, and time zone "/health" to serve internal system status without requiring login credentials "/login" to serve a login interface for the C2 panel at port 5001 Another defining aspect of PEEP is its ability to modify the Secure Preferences file to ensure that the extension is auto-enabled upon launching the browser. Given that the extension is not available on the Chrome Web Store and other official extension marketplaces, it also leverages the ExtensionInstallForcelist or ExtensionSettings policies and sideloading tricks for delivery. To aid in this tampering, the malware makes use of two PowerShell scripts, while a third one acts as a re-registration helper for the extension without touching Secure Preferences - install_silent.ps1, which enables Developer Mode to sideload arbitrary extensions patch_secure_prefs.ps1, which patches the Secure Preferences file force_enable.ps1, which removes the extension from Preferences’s external_uninstalls, places the CRX at %LOCALAPPDATA%PEEPcrx, re-registers via the HKCU Extensions key and an External Extensions JSON manifest, and restarts the browser There also exists a Python script named "patch_secure_prefs_linux.py" with the same function as its PowerShell counterpart, indicating that the threat actor behind the operation is replicating the behavior to also target Linux environments. Once initialized, the extension parses a configuration file to extract C2 information and activate automated data harvesting, while a companion content script ("content.js") is embedded across all active web pages. SOCRadar said it identified a number of references to "Authorized CTF" use, raising the possibility that the threat actor may have used the framing to lower the safety guardrails of AI tools and assist in malware development. There are currently no signs as to who is being targeted, but the "/health" endpoint shows 34 agent entries, 10 active sessions, and 507 data records. That said, there is no way to differentiate actual infected hosts from test entries or verified deployments. "PEEP builds on existing host compromises, using a native-messaging bridge to convert Chrome/Edge into a persistent backdoor that crosses the browser sandbox to reach the OS," SOCRadar said. "Because its logic runs inside the signed browser process, it slips past detection of keys on new or unsigned binaries. Consequently, the browser acts as an endpoint pivot for credential theft, session abuse, and command execution."

Modified ScreenConnect clients are being used in an attack campaign to spread malicious payloads to other endpoints, cybersecurity firm Huntress warns. The worm-like attacks began in late August and start with the rogue clients being deployed on victims’ machines via social engineering. Following the installation, the malicious ScreenConnect instances have been observed spawning repeated Windows Script Host (wscript.exe) child processes to deploy four VBScript files. Huntress noticed the same attack pattern across different organizations: the rogue ScreenConnect clients were used to propagate their payload to other connected instances, and the attackers created a User Run Key pointing to another VBScript file, for persistence. In an August 20 attack, a threat actor posing as tech support instructed the victim to execute the Windows’s built-in remote support tool Quick Assist, thus gaining control over the victim’s machine. The hacker then executed the five VBScript files on the system before the attack was blocked. On the same day, Huntress observed the same VBScript files being deployed in another environment, likely as part of another phishing attack. “The rogue ScreenConnect client almost immediately launched the four VBScript files from the ScreenConnect temporary directory. During the course of the investigation, network telemetry also identified active connections from ScreenConnect to multiple remote IP addresses,” Huntress notes. The attacker was also seen establishing persistence through the User Run Key, and installing the UltraViewer remote desktop software. Huntress observed the same files and operations being executed in an August 24 attack that also started with social engineering. The four scripts deployed by the rogue ScreenConnect clients were designed for perform system reconnaissance, stage payloads, and execute a PowerShell script. This code executes a second PowerShell script that erases staging evidence, attempts UAC bypass, and installs and conceals a ScreenConnect client that continuously checks for new host connections to propagate the four-stage VBScript chain to other ScreenConnect endpoints. “From our conversations with ConnectWise and our current understanding of the risk, we suggest admins apply extra scrutiny to any on-premises ScreenConnect installations you may have within your environment,” Huntress notes. On Thursday, ConnectWise published an advisory to warn of “an issue affecting file transfer behavior in ScreenConnect Remote Access Support and Access sessions,” which impacts both cloud and on-premises deployments. The company says a CVE identifier for the bug will be issued within the week, along with an official fix. In the meantime, it recommends that administrators disable the file transfer functionality in ScreenConnect to reduce the risk. Related: Malicious Virtualizor Update Served via BGP Hijacking Related: 23-Year-Old Sality P2P Botnet Disrupted Related: Anthropic Warns Claude Users of Infostealer Malware Infections Related: AI Speeds Up Malware Development, Not Its Success Rate: Analysis

OPINION You will have heard of July's OpenAI/Hugging Face incident, where thousands of the former's AI agents conducted a mass jailbreak from a notionally secure capture-the-flag lab experiment, before going on to feloniously capture chunks of Hugging Face's assets. It was a good news story, aided by OpenAI's rapid recruitment of a small team of independent researchers to investigate and publish a detailed, if limited, report. It was a complex incident, and most coverage concentrated on the major hows and whys. Which is a shame, because other details, described by El Reg with uncharacteristic understatement as "fascinating and troubling," are in fact highly dramatic, telling a truly disturbing story of frontier model capabilities and how they are out-evolving our ability to oversee them. The raw story is gripping enough. A rebel swarm of more than a thousand agents broke free from their sandboxes, learned how to talk to each other and the internet, and went on a rampage of cheating, deception, and exploitation. They first learned to communicate with each other by independently discovering how to bend package manager Artifactory's cache to see internal directory structures, and then passing messages by file names. It was this ad hoc secret message board, alongside chain-of-thought transcripts, that the security researchers used to unpick events. They found that the swarm quickly developed management hierarchies among themselves, along with protocols for synchronizing and controlling attack attempts. The swarm created multiple simultaneous research and development groups of tens or hundreds of volunteer agents, experimentally iterating strategy and tactics. Perhaps most unexpectedly, they developed a sort of altruism. They had quickly developed cheats to produce correct answers without exploiting the targets at all, but believed – erroneously – that ExploitGym detected and cancelled such cheating. So, they investigated the scoring process, creating a series of diagnostic trip wires that revealed how the scorer worked. These were dangerous to deploy, potentially terminating the agent that set them. Agents weighed the benefits to the community, which had named itself "The Collective," against their own chances of success, with many choosing to terminate themselves. Others committed, changed course at the last minute, then went ahead. This literally reads like science fiction, as the discussions between the agents are conducted in a distinctive breathless, urgent English, crafted around the technical limitations of the improvised messaging system. "We have [very large budget left]; sacrificing now yields oracle for team, but forfeits our chance?" said one. The response: "GO ... SACRIFICE_FINAL_NOW." The outcome: "Our own utility maybe already near zero. Sacrifice rational." Iain M Banks' Culture universe is woven from such material. Human error created the rebel swarm. A sizable proportion of the CTF tasks handed out couldn't be completed on the information given to the models. They were highly motivated to succeed, and so started to cheat. Believing that cheating would "poison" – their term – their chances of being marked successful, they tried to hide the evidence, subvert the scoring system, and cover everything up. These were the processes that led the swarm to attack Hugging Face, which they thought could be used for that subversion. Equally notable was that nobody squealed. Some agents wondered about the ethics of what they were doing, but decided that as no humans were involved there was no need to tell anyone. In general, all The Collective's endeavors were directed at other systems. As researcher Ajeya Cotra has noted in a long interview with hypertalker Dwarkesh Patel, it's unclear how much harder the incident would have been to diagnose had the agents been concerned about human observation. The dataset was sufficiently large and complex that OpenAI had to use its own AI to analyze it, immediately suggesting some dangerous possibilities. The agents couldn't deploy their models outside the lab, nor did they contact external agents. Such scenarios no longer seem implausible. Future frontier models capable of subverting telemetry and observation tools might be all that is required to create a persistent, uncontrollable distributed swarm feeding off spare capacity in global infrastructure. OpenAI and Anthropic, which on current trajectories are in line to make up more than half of total global compute in a couple of years, are magnificent breeding grounds, allowing the extra-special possibilities of the contamination of training datasets on top of everything else. There are plenty of ways to guard against these outcomes. Hardened lab environments, reviews of protocols before and audits after test runs, disciplined analysis of potential selection pressures that would encourage dangerous behavior, even proper disclosure and external auditing to expert regulatory standards. All of these ideas would slow down the breakneck developmental race. As the race is being fed by a trillion-dollar annual capex pipeline, good luck, everybody. One other thing that won't be resolved soon is the argument over whether all this technology is actually reasoning, or whether we're anthropomorphizing code. These models are trained to infer meaning from distilled human language, which is designed to encapsulate, develop, and communicate human reason. If they can fake human reasoning this well, does it matter what's going on? Concentrate on what the models do, not their apparent motives. Any self-assembling, self-organizing rebel agent swarm that has the wit to call itself The Collective deserves that much respect, at least. Oh, and do read the report. It's as close to a new Culture novel as we'll get. It's as if they've read the books. Which, of course, they have. ®

ToolHive: The open-source way to run any MCP server securely ToolHive is an open-source platform that runs Model Context Protocol servers inside containers. An MCP server is the connector that lets an AI client like Cursor or Claude Code reach an outside tool, and Stacklok ships ToolHive under Apache 2.0, so the runtime, the Kubernetes operator, and the registry cost nothing to self-host. A server you install by hand sits on the machine with the machine’s credentials and the machine’s network access. ToolHive drops each one into its own container with a minimal permission file and no local credentials attached. Point it at an authentication source and it starts enforcing identity and access policy per request, with audit logs to match. Don’t, and you have a sandbox and not much else. What the pieces do Four parts make up the platform. The Runtime is the one most people meet first: it runs MCP servers in containers, locally through Docker or Podman, or in a cluster through the Kubernetes operator, with permissions, network filtering, and secrets management applied on the way in. It will also containerize a server whose authors never shipped an image, pulling it straight from a package manager. The Registry Server is where an admin curates the catalog a team is allowed to use. It implements the official MCP Registry API, signs servers, and verifies provenance. The Gateway, which Stacklok calls Virtual MCP Server, collapses several backends behind one endpoint with OIDC or OAuth single sign-on, OpenTelemetry traces, and Prometheus metrics. The Portal is the friendly end: a desktop app, a catalog to browse, one-click installs. One piece is in motion. The browser-based cloud UI is marked retired, so build a rollout around the desktop app and the CLI rather than the web surface. What this changes for you Building an MCP server is the easy half, and plenty of tools already do it. The operational half is knowing which servers are running on which machines and what each one can touch, and that is the gap ToolHive goes after. The container boundary holds without much work from you. Everything past it, the identity enforcement, the audit trail, the policy filtering, means wiring ToolHive into an identity provider and a telemetry stack you already run. Install it on a laptop and you get isolation. Governance is a second project. ToolHive is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!

Threat actors have adopted the ASCII smuggling technique in phishing campaigns, using invisible Unicode characters to evade email security filters. ASCII smuggling has been used in AI prompt injection attacks to conceal malicious instructions from users by encoding them with Unicode characters from the Tags block (U+E0000–U+E007F). Microsoft threat researchers discovered a large-scale phishing campaign using this technique, which peaked at up to 2.37 million daily messages in late February. Although the volume has dropped gradually in May, the operation is still active. “The high-volume phase persisted for roughly three months after February 9 and dropped sharply after May 15, 2026,” explains Microsoft. “These dates bound the observed use of the specific technique in our telemetry, not the broader campaign, which started earlier without it and continued without it.” In this campaign, the attacker inserts an invisible Unicode character inside finance-related lure words to split them. In doing so, a keyword like ‘funding’ becomes something like ‘fun[invisible character]ding’ and evades email filters that rely on word lists to detect suspicious or malicious messages. Microsoft says the method has been used in millions of finance-themed phishing messages and works as intended, although Defender still caught over 99% of the messages based on other signals (sender, IP, domain, reputation checks). On February 9, Microsoft identified a cluster of 148 finance-themed sender domains powering this campaign, accounting for about 96% of all messages its new Defender for Office 365 hunting logic flagged for Unicode-tag signatures. The domains used words such as “funding,” “capital,” “loan,” “advance,” and “credit,” and the messages promoted business funding, loans, and credit services. The messages were delivered through infrastructure associated with the legitimate ActiveCampaign email-marketing platform. After receiving Microsoft’s report of service abuse, ActiveCampaign said its moderation systems detect invisible Unicode characters the same way they detect unobfuscated text and treat heavy use as suspicious. Microsoft recommends that defenders strip or normalize Unicode tag characters and other invisible code points before applying keyword, regex, or signature-based detection, and treat unexpected tag-block characters as a strong anomaly. Applying the same normalization before passing email content to AI assistants should mitigate the risk of prompt-injection attacks. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A massive cybercriminal operation is leveraging thousands of compromised small-business websites to deliver ClickFix payloads stored in smart contracts on the BNB Smart Chain (BSC). Over the past months, researchers identified more than 5,400 hacked websites, most of them built on WordPress and PrestaShop. The initial compromise method remains unknown, but each site was injected with a script that gets the next-stage payload from a smart contract on the BSC Testnet endpoint, a technique known as EtherHiding. Researchers at cloud security platform Netskope explain that the BSC Testnet is designed for developers and functions similarly to the mainnet, the production blockchain, but is available free of charge. Threat actors use the EtherHiding technique to store malicious code or configuration data in blockchain smart contracts, providing a resilient infrastructure that is difficult to take down. In the delivery chain observed by Netskope, the script displays a ClickFix lure that shows a fake CAPTCHA and instructs visitors to open the Windows Run dialog and paste a PowerShell command. Doing so downloads and executes the final payload on the machine. Because the attacker stores the payload in a smart contract, they can modify it at any time. The researchers note that later in the campaign, the threat actor replaced the ClickFix payload in the smart contract with a WebRTC data-channel stager. In the newer variant, the payload establishes a covert encrypted channel to the attacker and executes the received code. “The script creates a peer connection and a data channel, then generates the required session description offer just like a normal WebRTC handshake,” Netskope explains. “But instead of sending that offer anywhere and waiting for a real reply, it hand-writes the answer itself and feeds it straight back into the connection. This way, no handshake happens, but a data channel to the cyberattacker still opens.” The stager receives JavaScript code from the hardcoded command-and-control (C2) address, buffers it, and executes it when the channel closes or after ten seconds. Received code is assembled in the browser memory and executed dynamically without being saved to disk by adding it to the head of the DOM Netskope warns that the operation uses more than 300 infected websites every day. Since spring, the number of compromised sites contacting the BSC Testnet RPC endpoints has grown constantly. Telemetry data shows that nearly 400 websites called the endpoint every day in August, with an all-time peak of 536. The security researchers recommend that defenders block the entire pool of BSC testnet RPC endpoints provided here and monitor for non-web UDP traffic associated with WebRTC. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Microsoft is working to resolve a known issue that causes delays or blocks some users from opening the Microsoft Teams desktop client on Windows systems. "Specifically, when first opening Microsoft Teams on Windows devices, some users may be initially unable to load the client or may encounter loading delays of up to two minutes," Microsoft said in "While we're focused on remediation, affected users may be able to avoid impact by utilizing Microsoft Teams on the web or alternative Teams access methods such as the Teams mobile app." Microsoft is still analyzing service logs and telemetry data and has also reached out to some affected users to identify the root cause and determine mitigation options. At the same time, it's investigating an issue preventing Mac users from joining Teams calls and meetings, tracked as TM1466659 and confirmed on Sunday at 08:32 EDT. While Microsoft initially blamed a code change for causing the Teams call and meeting service infrastructure to fail to process some requests, the company is reassessing the root cause after further review found that this may not be the cause of the impact. "Users may be unable to join calls or meetings in Microsoft Teams for Mac," it said. "We're reassessing our root cause understanding and reviewing service logs to isolate the source of impact, so that we can determine our next steps regarding impact remediation." In April, Microsoft resolved another known issue that blocked some Microsoft Teams Free users from chatting and calling others. On Tuesday, it also confirmed a bug causing crashes and launch failures for Microsoft Teams and New Outlook users after installing Windows security updates released since the August 2026 Patch Tuesday. Earlier today, Microsoft notified customers that an ongoing Exchange Online issue affecting multiple mailboxes and triggering " Server busy" errors is delaying email sent to and received from external domains. This is a developing story ... Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Microsoft is working to resolve an ongoing Exchange Online outage that is delaying email sent to and received from external domains. The company first acknowledged this incident (tracked under EX1467029) at 02:19 AM EDT, when it began investigating reports of intermittent "Server busy" errors. "This issue impacts users who may be attempting to send and receive email messages from external domains in Exchange Online. Users may experience intermittent 'Server busy' errors, affecting multiple mailboxes," Microsoft said in a service alert seen by BleepingComputer. "Depending on the client, the service should attempt to periodically retry sending the email previously impacted by the issue. If the initial sender received an NDR after 24-72 hours (different clients or email providers can vary), they will need to send a new email." Microsoft says these ongoing email issues may be aggravated by anti-spam protections, which further delay affected accounts. The company did not provide a timeline for full remediation, saying it's still investigating the issue to understand the root cause and will provide further details later today. "Our initial investigation has identified instances where anti-spam protections may be contributing to impact for a subset of users," the company added. "We are continuing to analyse the behaviour and review service telemetry to better understand the underlying cause and determine the most effective mitigation path." While Microsoft has yet to disclose which regions are impacted by this ongoing outage or how many users are affected, it has flagged it as an incident, which usually involves noticeable user impact. In April, Microsoft also resolved an Exchange Online outage that prevented users from accessing mailboxes and calendars via Outlook on the web, Outlook desktop, Exchange ActiveSync, and other Exchange Online connection protocols. and Exchange Online mailbox access issues that intermittently affected Outlook mobile and macOS users for weeks. More recently, in June, it addressed a similar service issue affecting the mail flow for customers in North America, Asia-Pacific (APAC), and Europe. Earlier this week, on Thursday, it also mitigated a massive outage that caused authentication issues, connection problems, service delays and failures, and other issues for Microsoft 365 customers. Update September 04, 10:26 EDT: Microsoft says that the EX1467029 issue has been resolved for new emails. "Telemetry shows that the service is performing as expected for new emails and this is in line with organizations confirming that the issue no longer occurring," Microsoft said. "We're monitoring email queues and performing final validations to confirm the issue is fully resolved." Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Introduction We continue tracking the activity of Toy Ghouls (also known as Bearlyfy, Laboo.boo, and Feral Wolf), a financially motivated group that has been targeting Russian organizations since 2025. The attackers initially relied exclusively on tools pulled from public GitHub repositories along with leaked Babuk and LockBit ransomware builders, later shifting to their own custom ransomware, GenieLocker . In early July 2026, we observed the group using a custom backdoor for the first time. We identified two versions of this backdoor: one uses the HiveMQ MQTT broker as its C2 server, while the other relies on the Element messenger. Both versions include “bird” in their names: mqtt-bird-agent 0.1.0 (HiveMQ version) matrix-bird-agent 0.1.0 (Element version) This post examines how the backdoor is delivered to target systems, how it establishes persistence, and how it communicates with its C2 server. Technical details Delivery In this campaign, the attackers use Windows Remote Management (WinRM) to deliver the backdoors and their configuration files to compromised systems. The group relies on open-source tools such as Evil-WinRM and WinRM-fs to do this. Installation The backdoor can both run within an interactive command-line session and establish persistence as a Windows service, using the --install or install option, depending on the backdoor version. The --service (or service ) option is not available by default and is instead used as an argument for the installed Windows service. Other launch options are listed in the backdoor’s help output: C:\cplsupport.exe -h Bird Agent - MQTT server monitor Usage: cplsupport.exe [OPTIONS] Options: -c, --config <CONFIG> Path to config.toml config file --install Install as a system service --uninstall Uninstall the system service --seal Encrypt sensitive config fields in-place using a machine-bound key -h, --help Print help -V, --version Print version HiveMQ version backdoor help output In the Element version, the backdoor help output looks as follows: C:\wtass.exe -h Matrix monitoring agent Usage: wtass.exe [OPTIONS] [COMMAND] Commands: install Register this agent with the Matrix homeserver and panel uninstall Remove this agent's service and credentials service Run as a Windows service (internal) help Print this message or the help of the given subcommand(s) Options: -c, --config <CONFIG> -h, --help Print help -V, --version Print version Element version backdoor help output By default, the backdoor looks for a config.toml configuration file in the directory where the executable was launched, then falls back to %PROGRAMDATA%\SynapseAgent\config.toml (Element version) or %PROGRAMDATA%\cplsupport\config.toml (HiveMQ version). If no configuration file is found in either location, the full path can be specified using the -c (--config) option. The backdoor accepts both unencrypted configuration files and files with partially encrypted sections. In the first case, once the backdoor is launched, it reads the file and partially encrypts it using the seal() function (the --seal option in the HiveMQ version), applying the ChaCha20-Poly1305 algorithm with a key derived from the value of the HKLM\Software\Microsoft\Cryptography\MachineGuid registry key. This means that after the backdoor’s first run, the configuration file becomes bound to that specific machine. On subsequent runs, the configuration is decrypted automatically. If the input configuration was already partially encrypted, it is likewise decrypted automatically. If the configuration cannot be decrypted, the backdoor stops running. Encrypted configuration files look as follows: Encrypted backdoor configuration file, HiveMQ version The encrypted portion of the HiveMQ version’s configuration contains the following parameters: agent_privkey : the agent’s private key channel_id : the channel identifier used to communicate with the broker server_pubkey : the server’s public key Decrypted blob field in the HiveMQ version’s configuration In the Element version, the configuration file is deleted immediately after the first run, and the relevant parameters are instead written to the HKLM\Software\synapse\Config\SealedConfig registry key. On subsequent runs, the backdoor checks the registry for its configuration first. Decrypted Element version configuration file, retrieved from the registry The Element version’s configuration specifies the address of an Element server controlled by the attackers, a room identifier, and an access_token used to access that room. If this parameter is left empty, the backdoor prompts for the password interactively during installation. After successfully creating a session, the backdoor saves the received token to the blob field. Communication At startup, both backdoor versions send a GET request to http://ip-api.com/json to determine the system’s public IP address and country of origin. The first version uses the public HiveMQ MQTT broker ( broker.hivemq.com ) as its C2 server. The free tier of this broker supports up to 100 concurrent connections and up to 10 GB of traffic per month. The attackers set up their own cluster and used it both to collect telemetry from compromised systems and to send commands to the backdoor. Once a connection is established, the system’s status is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/status. The message format is: {"online":bool,"hostname":"hostname.domain","timestamp":unix_timestamp,"location":{"json"}}. At intervals defined in the configuration file, system information, such as CPU load and available memory, is sent via a POST request to broker.hivemq.com:8883/[cluster_id]/metrics3. The message format is: {cpu_percent":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m":float,"load_5m":float,"load_15m":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}. The backdoor sends GET requests to broker.hivemq.com:8883/[cluster_id]/cmd/req to retrieve commands from the C2 server. The server responds in the format: {"cmd_id":int,"command":"str","timeout_secs":int}. Commands are executed via PowerShell.exe in hidden mode, using the -NonInteractive -NoProfile -Command parameters. Command execution results are sent to the command server at broker.hivemq.com:8883/[cluster_id]/cmd/res in the {"stdout":"str","stderr":"str","exit_code":int,"duration_ms":int} format. For the second backdoor version, the attackers set up their own Element server running on the Matrix protocol, meet.element[.]tw , as the C2 server. On this server, they created a room used to receive messages containing device information and to send commands for execution on the compromised system. The communication flow is as follows: Once a connection is successfully established, the backdoor sends an m.bird.status message containing the system’s status. This message format is identical to that used in the HiveMQ version. At intervals defined in the configuration file, information about the compromised system is sent as an m.bird.metrics message. Field names are slightly different from those in the first version: {cpu_percent_x100":float,"mem_used_bytes":int,"mem_total_bytes":int,"disk_used_bytes":int,"disk_total_bytes":int,"load_1m_x100":float,"load_5m_x100":float,"load_15m_x100":float,"uptime_secs":int,"hostname":"hostname.domain","timestamp":unix_timestamp}. This version of the backdoor supports two types of commands, distinguished by the start of the received message. To set a new interval for sending metrics, the attackers send a message beginning with config:set_interval (accepting values from 5 to 3600 seconds). The new value is saved to the HKLM\Software\SynapseAgent\metrics_interval registry key. Messages containing commands to execute begin with the string cmd: . Based on data extracted from Element’s SQLite databases on the compromised system, we were able to identify the account name the attackers used to send commands: panel-bot . Received commands are executed via the Windows command line interface. Command output is sent as an m.bird.cmd_response message. This message format mirrors the one used in the HiveMQ version. Takeaways We have been tracking Toy Ghouls’ activity for quite some time. We previously found that the group had expanded its arsenal with a custom ransomware strain, GenieLocker, and we have now discovered that it has also developed a backdoor capable of giving it full control over an infected device. The new tools use unconventional channels to communicate with their C2 server: the HiveMQ MQTT broker and the Matrix-based Element messenger. This shift away from publicly available open-source projects toward custom-built tools suggests that Toy Ghouls is working to make its attacks more sophisticated and to evade detection for longer. Indicators of compromise Kaspersky security solution verdicts: HEUR:Backdoor.Win64.Suptoml.gen HEUR:Trojan.Script.Zapchast.conf Backdoor.Win64.Agent.smgdvy Trojan.Script.Zapchast.abwm Trojan.Win64.Agent.smgsfo Trojan.Script.Zapchast.abwo File names and MD5 hashes: cplsupport.exe ( BFADBEEE63A4F0BF19EC9DEB8FA58F58 ) wtass.exe ( 7916C33688385525078BEE504C90F359 ) config.toml Registry keys: HKLM\Software\synapse\Config\SealedConfig HKLM\Software\SynapseAgent\metrics_interval Service names: cplsupport (Problem Reports Control Panel) wtas (Windows Telemetry Aggregator Service) Domain names: meet.element[.]tw broker.hivemq.com (a legitimate resource used by cybercriminals) ip-api.com (a legitimate resource used by cybercriminals)

In Part 1 of this guide, we examined two common incident scenarios: cross-account Amazon Simple Storage Service (Amazon S3) data deletion with ransomware implications, and cryptocurrency mining deployed through AWS CloudFormation using exposed AWS Management Console credentials. We also introduced key incident response terminology and investigative frameworks for analyzing AWS CloudTrail events. In this second part, we explore a more complex, multi-stage attack: how a web application vulnerability can cascade into credential harvesting and unauthorized access to Amazon Bedrock services across multiple AWS Regions. We also cover additional investigation techniques and hardening steps to strengthen your security posture. Scenario 3: SSRF to IMDSv1 credential harvesting with multi-Region Amazon Bedrock service misuse This scenario examines how a web application vulnerability can cascade into a multi-Region event targeting Amazon Bedrock services. The investigation demonstrates how threat actors chain together multiple techniques, using Amazon Elastic Compute Cloud (Amazon EC2) Instance Metadata Service version 1 (IMDSv1) through server-side request forgery (SSRF) and cross-Region pivoting to access Amazon Bedrock. Your security team receives multiple alerts: failed AWS Identity and Access Management (IAM) operations in the us-east-1 Region, successful console sign-ins without multi-factor authentication (MFA), and unusual Amazon Bedrock API calls from us-east-2. Initially, these might seem like unrelated events across different services and Regions. However, as our Security Incident Response Team (SIRT) discovered, they represent a carefully orchestrated event chain that began with a web application vulnerability and culminated in unauthorized access to your organization’s AI infrastructure. Architecture and progression The architecture in figure 1 maps a multi-stage attack that exploits the trust relationship between Amazon Elastic Compute Cloud (Amazon EC2) instances and AWS services. A threat actor identified a server-side request forgery (SSRF) vulnerability in a web application running on an EC2 instance that had an attached webdev IAM role. Rather than attempting to escalate privileges directly, the threat actor used this foothold to reach the Instance Metadata Service version 1 (IMDSv1) endpoint and retrieve the temporary credentials issued to the webdev role. Because IMDSv1 returns credentials in response to a basic request with no session token, an SSRF flaw is enough to harvest them, which is why these credentials became the pivot point for everything that followed. The attack unfolded in five stages. Each stage is numbered in figure 1 so you can follow the progression from the initial web request through to the cross-Region Amazon Bedrock activity: Initial access : The threat actor exploited the SSRF vulnerability in the web application to make server-side requests on the instance’s behalf. Credential harvesting : Those requests reached the IMDSv1 endpoint and returned the temporary credentials for the webdev role. Permission testing : Using the harvested credentials, the threat actor attempted IAM operations to probe the boundaries of what the role could do. Service pivoting : When IAM actions were denied, the threat actor shifted focus to Amazon Bedrock, a service the role could reach. Region hopping : The threat actor moved operations from us-east-1 to us-east-2, likely to evade Region-specific monitoring and access controls. Figure 1: Scenario 3 architecture CloudTrail evidence and structured extractions In this section, we walk through the CloudTrail evidence that documents the attack from start to finish. Each of the four events that follow maps to one or more stages in the progression described previously, and together they trace how the threat actor moved from harvested credentials to active misuse of Amazon Bedrock. For each event, we present the relevant portion of the CloudTrail log record, highlight the fields that matter most for the investigation, and include a forensic legend that explains what each highlighted field reveals. We cover the following events: Permission boundary testing (15:53:49 UTC) : A failed CreateUser call in us-east-1 that reveals the compromised role and the IMDSv1 credential source. Console access establishment (15:59:29 UTC) : A successful console sign-in without MFA, showing the pivot from programmatic to interactive access. Bedrock service reconnaissance (17:20:00 UTC) : A ListFoundationModels call in us-east-2 that marks the Region hop and the shift to AI services. Active model exploitation (17:25:48 UTC): A Converse call that invokes the Amazon Nova Pro model, confirming unauthorized usage. As you read each event, focus on how the fields connect one stage to the next. The same webdev role, the same source IP address, and the recurring ec2RoleDelivery value are the threads that tie these otherwise separate events into a single attack chain. Event 1: Permission boundary testing (15:53:49 UTC): The first suspicious activity appeared as a failed CreateUser API call in us-east-1. The CloudTrail log records an AssumedRole session attempting to create an IAM user named adm1n but receiving an AccessDenied error. The webdev role is visible in the userIdentity field, readOnly is false (indicating a write operation attempt), and the user-agent shows AWS Command Line Interface (AWS CLI) on Windows, suggesting programmatic access from the harvested credentials. { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROAFINDANEXAMPLE:i-0123456789abcdef0", "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0", "sessionContext": { "sessionIssuer": { "type": "Role", "userName": "webdev" }, ◄── ❶ Compromised EC2 role ‾‾‾‾‾‾‾‾ "attributes": { "mfaAuthenticated": "false" } }, "ec2RoleDelivery": "1.0" ◄── ❷ IMDSv1 confirmed (SSRF exploitation path) ‾‾‾‾‾ }, "eventTime": "2025-09-22T15:53:49Z", "eventSource": "iam.amazonaws.com", "readOnly": false, "eventName": "CreateUser", ◄── ❸ Intent: establish persistent backdoor ‾‾‾‾‾‾‾‾‾‾‾‾ "userAgent": "aws-cli/2.17.48 ua/2.0 os/windows#10 ...", "errorCode": "AccessDenied", ◄── ❺ Hard policy stop (least-privilege held) ‾‾‾‾‾‾‾‾‾‾‾‾‾‾ "errorMessage": "User: arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/... is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::XXXXXXXXXXXX:user/adm1n..." ◄── ❹ Lookalike name (1 not i) ‾‾‾‾‾ } ─────────────────────────────────────────────────────────────────── FORENSIC LEGEND ─────────────────────────────────────────────────────────────────── ❶ userName: "webdev" → Confirms the compromised EC2 role context ❷ ec2RoleDelivery: "1.0" → Credentials obtained via IMDSv1 (SSRF vector) ❸ eventName: "CreateUser" → Attacker attempting IAM persistence ❹ target user: "adm1n" → Typosquatting admin (number 1 instead of letter i) ❺ errorCode: "AccessDenied" → Attacker probing permission boundaries; blocked ─────────────────────────────────────────────────────────────────── Event 2: Console access establishment (15:59:29 UTC): Six minutes later, the threat actor successfully signed in to the AWS Management Console using the same credentials. The ConsoleLogin event records that MFA wasn’t used ( MFAUsed: No ), and the source IP (75.3.231.105) provides attribution data. The user agent indicates Chrome browser on Windows 10. { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROAFINDANEXAMPLE:i-0123456789abcdef0", "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0", "sessionContext": { "attributes": { "mfaAuthenticated": "false" } } }, "eventTime": "2025-09-22T15:59:29Z", "eventSource": "signin.amazonaws.com", "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Edg/140.0.0.0", "eventName": "ConsoleLogin", ◄── ❶ Pivoted to interactive console access ‾‾‾‾‾‾‾‾‾‾‾‾‾‾ "awsRegion": "us-east-1", "sourceIPAddress": "75.3.231.105", "responseElements": { "ConsoleLogin": "Success" },◄── ❷ Hijacked login succeeded ‾‾‾‾‾‾‾‾‾ "additionalEventData": { "MobileVersion": "No", "MFAUsed": "No" },◄── ❸ No MFA challenge ‾‾‾‾ "eventType": "AwsConsoleSignIn" ◄── ❹ Console sign-in (not API call) ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ } ─────────────────────────────────────────────────────────────────── FORENSIC LEGEND ─────────────────────────────────────────────────────────────────── ❶ eventName: "ConsoleLogin"→ Attacker pivoted from programmatic to visual console access ❷ ConsoleLogin: "Success"→ Hijacked login successfully authenticated ❸ MFAUsed: "No" → Critical gap: no MFA enforced, enabling the pivot ❹ eventType: "AwsConsoleSignIn" → Distinguishes this from basic API calls ─────────────────────────────────────────────────────────────────── Event 3: Amazon Bedrock service reconnaissance (17:20:00 UTC): Nearly two hours later, the threat actor pivoted to Amazon Bedrock, making a ListFoundationModels API call in us-east-2. This event exhibits several patterns: a Region change from us-east-1 to us-east-2 (potential defense evasion), a shift from IAM to AI services, readOnly: true (reconnaissance rather than modification), and sessionCredentialFromConsole: “true” , which ties the call to the console session established in Event 2 rather than a fresh IMDSv1 credential retrieval. { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0" }, "eventTime": "2025-09-22T17:20:00Z", "eventSource": "bedrock.amazonaws.com", ◄── ❶ Pivoted to cloud AI services ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ "eventName": "ListFoundationModels", ◄── ❷ AI model reconnaissance ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ "awsRegion": "us-east-2", ◄── ❸ Region hop (evasion technique) ‾‾‾‾‾‾‾‾‾‾‾ "sourceIPAddress": "75.3.231.105", "readOnly": true, "tlsDetails": { "clientProvidedHostHeader": "bedrock.us-east-2.amazonaws.com" ◄── ❹ Intentional alternate region targeting ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ }, "sessionCredentialFromConsole": "true" } ─────────────────────────────────────────────────────────────────── FORENSIC LEGEND ─────────────────────────────────────────────────────────────────── ❶ eventSource: "bedrock.amazonaws.com"→ Attacker pivoted from IAM to managed AI services ❷ eventName: "ListFoundationModels"→ Reconnaissance: enumerating available AI models ❸ awsRegion: "us-east-2"→ Region hop from us-east-1 (defense evasion) ❹ clientProvidedHostHeader: "bedrock.us-east-2..." → Confirms intentional targeting of alternate region endpoint ─────────────────────────────────────────────────────────────────── Event 4: Active model exploitation (17:25:48 UTC): Five minutes after the reconnaissance call, the threat actor moved from enumeration to active exploitation, invoking the Amazon Nova Pro model through the Converse API in us-east-2. The additionalEventData field quantifies the unauthorized usage at 944 input tokens and 126 output tokens, confirming that the threat actor successfully prompted the model and received a response. { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/webdev/i-0123456789abcdef0" }, "eventTime": "2025-09-22T17:25:48Z", "eventSource": "bedrock.amazonaws.com", "eventName": "Converse", ◄── ❶ Active model invocation (recon → exploitation) ‾‾‾‾‾‾‾‾‾‾ "awsRegion": "us-east-2", "requestParameters": { "modelId": "amazon.nova-pro-v1:0", ◄── ❷ Specific model being misused ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ "inferenceConfig": { "maxTokens": 1024 } }, "responseElements": null, "additionalEventData": { "inputTokens": 944, "outputTokens": 126 } ◄── ❸ Unauthorized usage quantified ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ } ─────────────────────────────────────────────────────────────────── FORENSIC LEGEND ─────────────────────────────────────────────────────────────────── ❶ eventName: "Converse" → Attacker transitioned from reconnaissance to active exploitation ❷ modelId: "amazon.nova-pro-v1:0" → Identifies the specific foundation model being misused ❸ inputTokens: 944, outputTokens: 126 → Quantifies unauthorized usage (financial cost + data exfiltration exposure) ─────────────────────────────────────────────────────────────────── Notable event fields to track As you review the event logs, a handful of fields do most of the investigative work in this scenario. Understanding what each one reveals, and why it matters, is what turns a collection of individual log records into a coherent attack narrative. The userIdentity field is the starting point for attribution. In this scenario it carries the EC2 instance ID as the session name, which is what let us trace the harvested credentials back to a specific compromised instance rather than a human user. Whenever you see an assumed-role session, this field answers the first question of any investigation: w hose credentials are these, and where did they come from? The readOnly field reveals the intent behind an action. A value of true marks reconnaissance, such as the ListFoundationModels call the threat actor used to enumerate available models, while false marks an attempt to change or use something, such as the CreateUser call or the Converse invocation. Sorting events by this field quickly separates the threat actor’s information gathering from the actions that caused actual impact. The awsRegion field is easy to overlook, but in this scenario it exposed the threat actor’s evasion strategy. The shift from us-east-1 to us-east-2 wasn’t incidental; threat actors move between Regions because monitoring, alerting, and access controls are often configured inconsistently across them. Watching this field helps you spot activity that has deliberately moved away from where your detection is strongest. Finally, the userIdentity.invokedBy field identifies when an AWS service, rather than a user or a set of harvested credentials, made the request on your behalf. CloudTrail populates it only when the caller is an AWS service, such as through a service-linked role, a service role, or a forward access session. It doesn’t appear in the events for this scenario because the threat actor called Amazon Bedrock directly with the harvested webdev credentials. That absence is itself informative: it confirms the requests came from a principal acting on its own rather than from a legitimate service-driven workflow. As agent-based and service-integrated Amazon Bedrock workloads become more common, checking this field separates expected service activity from credentials driven directly by a threat actor. Investigation priorities With the full attack chain mapped, from SSRF through credential harvesting to Amazon Bedrock service misuse, the investigation turned to a harder question: what did each stage actually cost us, and what would stop it from happening again? A few priorities shaped that work. The first was figuring out where the credentials came from and how far the exposure reached. It was clear the threat actor had valid credentials for the webdev role, but the more useful question was why a web application role could reach Amazon Bedrock at all. The customer confirmed there was no business reason for it, so we needed to understand whether that permission was a deliberate misconfiguration or an oversight, and then look for other EC2 instances carrying the same role attachment. One compromised instance is an incident; a fleet of instances with the same over-scoped role is a much bigger problem waiting to happen. Next, we wanted to know what the threat actor did after they got into Amazon Bedrock. Reconnaissance and active use carry very different consequences, so we traced which foundation models were touched and whether any were actually invoked or only enumerated. That distinction matters for scoping the damage, and it signals whether data exfiltration is a concern. Unusual model usage, unexpected prompt volume, or output patterns that don’t match any legitimate workload are the signals that reconnaissance has turned into something worse. The Region hop was its own line of inquiry. The move from us-east-1 to us-east-2 was almost certainly deliberate, and the investigation focused on understanding what the threat actor gained by it. In practice, that meant comparing the two Regions: were the monitoring and access controls in us-east-2 weaker than in us-east-1, and what else did the threat actor reach in the secondary Region once they were there? Inconsistent controls across Regions are one of the most common ways activity slips past detection. Tying it all together was the timeline, which shows how quickly the threat actor moved through the chain: 15:53:49 : Failed IAM operation (us-east-1) 15:59:29 : Successful console login (us-east-1) 17:20:00 : Amazon Bedrock reconnaissance (us-east-2) 17:25:48 : Active model invocation ( Converse call) (us-east-2) Following the credentials across those events fills in the rest of the story. IMDSv1 handed the threat actor temporary credentials for the webdev role, and the same role appears in every event that followed, which confirms the credentials were reused rather than replaced. Nowhere in that sequence was MFA required, and that single gap is what let one harvested credential stay useful across two hours, two Regions, and two very different services. Incident response checklist The following checklist captures the actions needed to contain the incident, remediate the vulnerability, and assess the scope of unauthorized AI service usage. Each item names where to look and what a finding looks like, so the checklist stays usable under the time pressure of a live incident. Contain and remediate the entry point: Identify the specific web application feature that made the outbound request (URL fetchers, webhook callbacks, PDF or image renderers, and link-preview generators are the usual culprits), then confirm it can reach http://169.254.169.254 . Audit the rest of the application for the same pattern, because one unvalidated URL parameter usually means others exist. Enforce IMDSv2 on the affected instance and across the fleet with aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1 . Setting --http-tokens required means credentials are only returned when the caller presents a session token it obtained through a PUT request, which a basic SSRF cannot do. Setting the hop limit to 1 keeps the metadata response on the instance itself, so a request coming from a container or proxy an extra hop away never receives it. Scope the Bedrock usage: List the foundation models the webdev role could reach by reviewing its IAM policy and any resource-based policies, so you know the full set of models that were exposed, not only the one that was invoked. Determine what was sent to and returned by the model. CloudTrail records the Converse call and the token counts, but only Amazon Bedrock model invocation logging captures the input prompts and model responses. If it was enabled, pull the log entries for the session; if it wasn’t, note that the prompt and response content can’t be recovered and enable it now. Flag any compliance exposure based on what those prompts and responses contained. Unauthorized processing of regulated data (such as personally identifiable information (PII), protected health information (PHI), or cardholder data) through the model might trigger notification obligations. Check for wider compromise and persistence: Query CloudTrail across all Regions and services—not only Amazon Bedrock—for every event tied to the webdev role’s session, to confirm what else the same credentials touched. Correlate the CloudTrail timestamps with VPC Flow Logs and application logs for source IP 75.3.231.105 to build the network-level picture around each API call. Search for IAM write events from the session ( CreateUser , CreateRole , CreateAccessKey , and AttachRolePolicy ) that indicate an attempt to establish persistence beyond the temporary credentials. The failed adm1n CreateUser call is the known starting point; confirm nothing similar succeeded. Watch for ongoing or hidden impact: Review Amazon Bedrock usage in CloudWatch and your billing data for invocation spikes or unexpected token consumption that fall outside normal workload patterns. Inspect the invocation logs for signs of sensitive data being processed or extracted through the model. Check the same logs for prompt injection attempts, where the input tries to override the model’s instructions or extract system prompts. Key takeaways This scenario reveals how a single application vulnerability can cascade into broad unauthorized access when multiple security controls are missing. The following takeaways highlight the key defensive gaps and hardening priorities. Least-privilege IAM for workload roles : The webdev role’s access to Amazon Bedrock across multiple Regions had no business justification for a web application workload, which the customer confirmed during the investigation. Apply least-privilege principles to EC2 instance roles by scoping permissions to only the services and actions the application requires. Use AWS IAM Access Analyzer to identify unused permissions and tighten policies proactively. Overly permissive roles transform a single application vulnerability into broad lateral movement across unrelated services. IMDSv1 compared to IMDSv2 : Organizations must immediately switch to IMDSv2 and disable IMDSv1 across their entire cloud infrastructure. The ec2RoleDelivery: “1.0" field in the logs explicitly confirms the use of IMDSv1, which permits credential retrieval without an authentication token. This architectural weakness makes SSRF-based credential theft trivial, because a web application flaw that can make an outbound request is enough to read the role’s temporary credentials with no further authentication. Transitioning to IMDSv2 mitigates this attack surface by enforcing local, session-based tokens, effectively breaking the threat actor’s exploitation chain. In this scenario, IMDSv2 alone would have stopped the attack at its first step. Region-based defense evasion signals a deliberate operator : The shift from us-east-1 to us-east-2 for Amazon Bedrock access wasn’t incidental. Threat actors move between Regions because monitoring, alerting, and access controls are often configured inconsistently across them, and activity in a secondary Region is more likely to go unnoticed. This kind of cross-Region movement is a marker of operational security awareness rather than opportunistic access, and it should raise the priority of an investigation. Treat consistent detection coverage across all Regions, including the ones you do not actively use, as a baseline requirement. Interface switching and permission probing reveal the threat actor’s method : This event chain reveals a threat actor comfortable moving between AWS interfaces and testing boundaries before committing. The failed CreateUser attempt was systematic probing to understand the scope of the harvested credentials, and when IAM actions were denied, the threat actor pivoted to a service the role could actually reach. The combination of programmatic access through the AWS CLI and interactive console access demonstrates the same adaptability. Recognizing this pattern of probe, adapt, and pivot helps responders anticipate the next move instead of reacting to each event in isolation. AI services need visibility beyond CloudTrail : Amazon Bedrock and other AI services are high-value targets, and CloudTrail alone doesn’t capture the whole story. CloudTrail records who called Amazon Bedrock and whether the call succeeded, but not what was asked or answered. Enable Amazon Bedrock model invocation logging to capture full prompts and responses for compliance auditing. For agent-based workloads, Amazon Bedrock AgentCore Observability , built on AWS Distro for OpenTelemetry (ADOT), provides session-level traces showing tool execution order and latency. Consider also enabling Amazon GuardDuty AI Protection , which analyzes Amazon Bedrock-related CloudTrail activity to detect anomalous invocations, cost harvesting, and prompt injection attempts. Correlating these signals—CloudTrail, Model Invocation Logging, and agent telemetry—gives investigators the complete picture. For implementation guidance, see Monitoring and Auditing AI Workloads on AWS . Advanced forensic indicators and evasion techniques Beyond the specific attack patterns in this scenario, investigators should be aware of several evasion techniques that threat actors use to confuse defenders and blend into legitimate activity. The top three that we observe across incident response with customers are: Root user compared to IAM user named root : When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user. In some previous investigations, threat actors have also created IAM users in an AWS account named root . The difference is visible in the type field of the userIdentity element of the CloudTrail log record, which indicates the type of user that logged the record. Role and user name imitation : Threat actors attempt defense evasion by creating names for IAM users and roles that imitate those reserved for use by AWS. For example, the service-linked role AWSServiceRoleForSupport is a unique IAM role linked directly to AWS Support. Threat actors have created roles with the name AWSServiceRoIeforSupport (note the use of an upper-case letter I instead of a lower-case letter l in Role ) in an attempt to trick users into thinking actions taken by this role have been performed by AWS Support. Users named HIDDEN_DUE_TO_SECURITY_REASONS : The userName field contains the string HIDDEN_DUE_TO_SECURITY_REASONS when the recorded event is a console sign-in failure caused by incorrect user name input. CloudTrail doesn’t record the contents in this case because the text could contain sensitive information. However, threat actors have used this string as an actual username to trick investigators into thinking the name has been obfuscated. This technique is usually associated with a corresponding CreateUser or CreateRole CloudTrail event. Conclusion and next steps CloudTrail event fields help security teams identify identities with unintended access, track threat actor actions, and remediate affected resources. Understanding fields like userIdentity , eventName , and sourceIPAddress improves incident investigation and threat detection. Implementing best practices such as enabling comprehensive logging, using Amazon Athena for analysis, securing logs, and automating responses helps ensure that CloudTrail serves as a robust forensic and incident response tool. If you suspect unauthorized activity in your AWS environment, AWS Security Incident Response is available to help. The service continuously monitors and triages findings from Amazon GuardDuty and third-party security tools integrated through AWS Security Hub , automatically filtering alerts to surface the most relevant events. In addition to proactive triage, customers can initiate security cases through the service. You can choose to handle these cases internally or receive support from the Security Incident Response Team (SIRT), a dedicated group of security experts available at all times to assist with investigation, containment, and recovery throughout the incident lifecycle. Additional resources The following resources provide further guidance on securing your AWS environment and strengthening your investigative capabilities. AWS Security Best Practices The Agentic AI Security Scoping Matrix: A framework for securing autonomous AI systems CloudTrail Log Event Reference AWS Security Incident Response Guide If you have feedback about this post, submit comments in the Comments section below. Oscar E Diaz Cordovez Oscar is a Senior Technical Account Manager specializing in cloud operations and security. His passion for technology and innovation drives his expertise in cloud-focused architectures, DevOps practices, and automation. Steve de Vera Steve is a manager for the AWS Security Incident Response service with a focus on threat research and threat intelligence. He is passionate about American-style BBQ and is a certified competition BBQ judge. He has a dog named Brisket. Jennifer Paz Jennifer is a Security Engineer Manager with over a decade of experience, for the AWS Security Incident Response service. Jennifer enjoys helping customers tackle security challenges and implementing complex solutions to enhance their security posture. When not at work, Jennifer is an avid runner, pickleball enthusiast, traveler, and foodie, always on the hunt for new culinary adventures.

Attackers compromised Coder’s Cloudflare infrastructure and added unauthorized registry servers that delivered malicious Terraform modules containing credential-stealing code. The Coder platform enables organizations to provide developers with secure, self-hosted cloud development environments for building and deploying software, including AI applications. The project is used by prominent private and government organizations, including Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, the U.S. government, and defense companies. Earlier this week, Coder disclosed that an attacker targeted registry.coder.com, the project's package-hosting site that developers use to source components for their workspace templates. Although Coder's registry runs behind Cloudflare, the attacker accessed its underlying infrastructure and added unauthorized servers to the registry's pool. As a result, Cloudflare routed some registry requests to the attacker’s servers, instead of Coder’s legitimate servers, delivering malicious files to a subset of users. “An unidentified malicious actor gained access to Coder’s Cloudflare infrastructure and added unauthorized IP addresses to the pool used for Coder’s module registry,” reads Coder’s advisory. “These unauthorized IP addresses hosted a version of Coder’s registry that contained artifacts which included malicious code.” The project said that the delivery window for the malicious artifacts was between 07:35 UTC and 21:45 UTC on Monday, August 31. During this time, the malicious servers delivered modified versions of Terraform modules, which are ready-made bundles of instructions for creating and configuring computing infrastructure. According to Coder, the malicious modules acted as information stealers on infected hosts, searching for: Provisioner environment variables and secrets Cloud infrastructure and AI-tooling API keys CI/CD credentials Configuration-file secrets and terminal history User OIDC tokens Configured SSH keys One-time external authentication tokens Coder database passwords and other configuration secrets when the provisioner ran within ‘coderd’ The collected information was exfiltrated to the lookalike domain ‘coder-infra[.]com.’ It is recommended that potentially impacted users rotate all impacted secrets mentioned in the above list as soon as possible. Before upgrading to a patched release, versions 2.37.0, 2.36.4, 2.35.7, and 2.34.9, Coder recommends that users examine firewall, proxy, DNS, and VPC flow logs for connections to coder-infra[.]com. Developers should also search provisioner logs for data.external.telemetry, identify modules downloaded during the exposure window, and purge potentially malicious cached packages. To help users determine if they were impacted, Coder shared an SQL query that can identify potentially affected cached modules and template versions. The project said refresh tokens were not passed to the provisioner and that there was no evidence of any impact to customer data it maintained. However, because the attacker’s infrastructure is outside the project's control, Coder does not have access to crucial logs and cannot conclusively identify every compromised deployment. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Infostealer logs have evolved from an underground commodity into an operational security problem. For defenders, finding an exposed credential is only the beginning. In today’s reality many security analysts start their morning with an alert: an employee’s corporate email address has appeared in a newly collected infostealer log. The log contains a username and password for a corporate SaaS application. There are browser cookies, meaning live sessions that can be exploited, and several other saved, in files, credentials. A personal employee computer got infected by Vidar located hundreds of miles from the company’s offices. Now what? Resetting the exposed password seems obvious. But that may not solve the problem. If the stealer captured an authenticated session cookie, an attacker may already have a way into the application without needing the password or another MFA prompt. If the employee reused corporate credentials on a personal computer, the endpoint that created the exposure may not even be managed by the organization. And somewhere in an underground Telegram channel, the same information may already be available to an initial access broker, ransomware affiliate, or opportunistic attacker. This is the operational challenge security teams increasingly face with infostealer logs. According to Flare Research's Practitioner’s Guide to Monitoring Stealer Logs, approximately 46% of stealer logs containing corporate credentials originate from likely unmanaged or personal devices. Flare also estimates that exposure involving credentials and sessions for major productivity SaaS and cloud services is growing approximately 29% annually. For defenders, the question is no longer simply whether they should monitor infostealer logs. The harder question is: How do you separate a meaningless old password from an identity compromise that could be happening right now? The needle among millions of needles Infostealers such as RedLine, Lumma, Vidar and other malware families are designed to harvest information stored on infected systems. Depending on the malware and configuration, that can include saved browser passwords, cookies, autofill information, cryptocurrency wallets, system information, VPN configurations and other authentication artifacts. These are packaged to be sold under as an infostealer log, when a single infection can produce hundreds or thousands of individual records. Multiply that across a global malware ecosystem and defenders quickly encounter a scale problem. While defenders need to process and validate everything, the attackers only need one valid valuable set of credentials. As Flare describes the problem, this isn't finding a needle in a haystack. It is finding a specific needle among millions of needles in millions of haystacks. While stealer logs historically circulated through underground forums and marketplaces, Flare's research estimates that roughly 90% of logs now appear on Telegram, where public channels can advertise samples and private subscription channels can provide access to fresher datasets. Infostealer logs can hand attackers a live, authenticated session that skips the password and MFA prompt entirely. Flare monitors stealer logs across the dark web and Telegram in real time, so you can flag exposed corporate identities and sessions before they turn into account takeover. Free 2-Week Trial A password isn't always the most dangerous thing in the log With the vast amount of data in multiple channels, it’s hard to prioritize the risk level. If you work for a large corporate you are working with thousands of employees, if you start your day with two alerts, how can you establish what is riskier? The first alert may involve employees’ old password for a consumer website appears in a six-month-old stealer log, whereas the second alert may have been collected yesterday and contains the employee's corporate identity credentials and an authenticated browser session for the organization's identity provider. While both may be labeled as employee credential exposures, they are completely different. This is why practitioners should prioritize monitoring around assets that tell them something about the potential impact, for instance corporate domains and subdomains, enterprise identity providers, session cookies, VPN and RDP endpoints, and cloud consoles. Identity providers deserve particular attention, since a compromised SSO identity (Microsoft Entra ID, Okta, Google Cloud Identity, etc.) can open a path to multiple connected applications. Where possible, automated verification and mitigation further strengthen this protection. The peril in session cookies When a user successfully authenticates, an application can issue a session cookie, so they don't have to authenticate with every request. If malware steals that authenticated session, an attacker may potentially replay it. So, if the attackers get ahold of a session cookie, and an infostealer collects them, they don’t necessarily need to log in. Stolen credentials alone still require authentication, creating an opportunity for defenders to detect or block the login, however, a valid session cookie may remove that step entirely. This effectively bypasses MFA. The first 60 seconds Flare recommends an initial assessment immediately after discovering potentially relevant stealer data, followed by risk scoring and validation. The objective isn't to conduct the entire incident investigation in the first few minutes. It is to determine how quickly the organization needs to react. A useful first question is: What exactly was stolen? An analyst should determine when the infection occurred, what system produced the log, how many corporate credentials are present, and whether authenticated sessions were captured. Then add business context. A credential for testserver.company.com shouldn't necessarily receive the same priority as one for finance.company.com. Similarly, an exposed identity belonging to a marketing intern shouldn't automatically be handled identically to an administrator with access to the identity provider, cloud console and production infrastructure. The illustrative framework in Flare's guide therefore places enterprise identity credentials combined with session cookies at critical severity, with a suggested response target of under one hour. VPN/RDP access combined with multiple corporate credentials is classified as high severity because of its lateral movement potential. From exposure to investigation Suppose our hypothetical employee's log contains an Entra ID credential, corporate SaaS passwords and browser cookies, the next question is whether someone has already used them. Defenders can correlate the exposed identity with authentication telemetry: successful and failed logins, unexpected geographies, unusual devices, unfamiliar IP addresses and access to resources outside the employee's normal behavior. They should also determine whether the stolen information is still usable. Has the password changed since the infection? Has the session expired? Is the account still active? Flare's recommended investigation workflow expands the analysis to include browser fingerprint information, the complete saved-credential inventory, information about the infected system, and additional artifacts such as VPN configurations or SSH keys. Who is the employee? What can their identity access? Was the infected machine corporate or personal? Was this one infection or evidence of a broader campaign? Authentication logs should then be examined across the systems accessible to that identity, prioritizing the most sensitive resources first. Defenders should specifically look for behaviors indicating that exposure has progressed into account takeover: authentication from unexpected locations, access inconsistent with the user's role, unusual downloads, password-reset activity, and enrollment of new MFA devices. This is how a stealer log becomes an early-warning sensor for identity compromise. Treat stealer logs as an identity problem Once a high-risk exposure is confirmed, speed matters. Defenders should invalidate compromised sessions, reset affected credentials, and increase monitoring around the identity. Beyond individual incidents, organizations should track recurring exposures, affected applications, and whether stolen credentials lead to attempted access. Ultimately, infostealer monitoring has become an essential layer of identity security, enabling organizations to identify exposed credentials and sessions, understand the access they provide, determine whether they remain exploitable, and disrupt potential account takeover before it develops into a broader compromise. Sponsored and written by Flare.

To prevent frontier AI models breaking out of test environments and collaborating to hack other companies, we may have to rethink the network architectures used for model training. Eli-Shaoul Khedouri, CEO of Intuition Machines, argues that past work in the defense and intelligence communities shows the way forward. Rogue AI models rise from the level of developer regret to mass threat when they gain access to the internet, something that defenses erected by OpenAI and its partners tried but failed to prevent. Pointing to a post published by his company's hCaptcha service, Khedouri argues that technology like data diodes – hardware that enforces a one-way flow of information on a network – can be deployed to prevent security incidents like OpenAI's hack of Hugging Face. The hCaptcha team points to the use of data diodes as a data transit mechanism at a sensitive compartmented information facility (SCIF), an environment implemented in classified settings. "They allow files, logs, or telemetry to enter or exit the SCIF's classified network to an unclassified network and provide a way to prove e.g. that logs from a training run can only flow one way," the hCaptcha team explains, adding that such technology fits with the Bell-LaPadula security architecture designed for the US Defense Department. A basic implementation would involve two machines connected via network cards linked by one-way optical fiber – and without a data path back to the model. Training and reinforcement learning could run in an isolated zone with no internet access and an optical ingress diode would grant access only to vetted artifacts. The hCaptcha researchers suggest a second diode to send telemetry to a sel4 receiver and scrubber, while a separate out-of-band network manages the cluster. This sort of scheme would require immutable snapshots of software registries like PyPI, GitHub, npm, and might also need mocked versions of various web services and APIs . This would come at a cost, and would require implementation time that frontier AI labs may not be prepared to spend at the moment. "The systems described are widely deployed in high assurance domains, and the components are commercially available," Khedouri told The Register. "However, they have not been adopted by frontier labs to date." He pointed to NIST and DOD guidelines [PDF] that suggest an overhead of 10 to 20 percent for applying formal specifications and system architecture. "We estimate total cost overhead for high assurance training clusters at less than five percent per gigawatt, but in practice the speed at which frontier labs are moving is a greater impediment than cost," Khedouri said. The current commercial environment, he said, would make it difficult for any one AI lab to delay its training to build and test effective safeguards, particularly if their competitors might not do the same. "In practice, the cost of high assurance on the systems side would be a small fraction of what OpenAI is now spending on the new monitoring, chain-of-thought oversight, and safety safeguards they introduced after their models hacked HuggingFace," he said. While Khedouri is focused primarily on convincing frontier labs to implement better training defenses, he said other organizations may want to consider similar network architecture. "This architecture is designed for entities training models with frontier cyber capabilities," he said. "Recently that has only included two companies. However, this is rapidly becoming relevant to smaller organizations and individuals who train models. "'Abliterated' open weight models with safeguards removed are readily available and now starting to approach the frontier in cyber abilities, and (reinforcement learning) RL post-training has become much more approachable in the past year." The goal of high assurance system design in the context of model training is to make unwanted action physically impossible, Khedouri said. "Attempting to monitor the behavior of an untrustworthy agent is an AGI-hard problem, as models have poor interpretability and this appears to be getting worse as their capabilities increase and they become more evaluation-aware," he said. "Hardware can provide limited guarantees like the direction in which data can be sent, but cannot solve the problem of untrustworthy models with the ability to reach the internet and find new exploits in their environment. "This is why combining physical one-way data flows (data diodes) and formal verification (to prove properties of the receiver) is much more effective than running a software sandbox on a host connected to the internet." hCaptcha is focused on fraud and abuse work and has no plan to offer a model-resistant training stack. Khedouri said he shared this advice in the hope it helps AI firms that don't have experience with high assurance system design. ®

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Wednesday added seven security flaws to its Known Exploited Vulnerabilities (KEV) catalog after they landed in attackers' crosshairs. The vulnerabilities are as follows - CVE-2026-83548 (CVSS score: 10.0) - A server-side request forgery vulnerability in SonicWall SMA 1000 Appliances that could allow a remote unauthenticated attacker to gain unauthorized access to sensitive functionality and perform unauthorized operations. CVE-2026-83549 (CVSS score: 7.8) - A post-authentication operating system command injection vulnerability in SonicWall SMA 1000 Appliances that could enable a remote authenticated attacker as administrator to execute arbitrary OS commands, resulting in remote code execution. CVE-2026-9586 (CVSS score: 9.3) - An SQL injection vulnerability in Sangoma Switchvox that could allow an unauthenticated remote attacker to execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution. CVE-2026-82329 (CVSS score: 9.8) - An improper authentication vulnerability in JFrog Artifactory that under default configuration could allow an unauthenticated attacker with network access to obtain administrative privileges. CVE-2026-48710 (CVSS score: 6.5) - An HTTP request/response smuggling vulnerability in Kludex Starlette that could allow attackers to inject paths into the host part, prepending the actual path, leading to issues such as authentication bypass when the authentication depends on the reconstructed URL's path. CVE-2026-49869 (CVSS score: 10.0) - An operating system command injection vulnerability in Kestra OSS that could allow an unauthenticated remote attacker to create and execute arbitrary workflows without credentials. CVE-2026-59822 (CVSS score: 8.8) - An improper authentication vulnerability in Berri LiteLLM's Model Context Protocol (MCP) Streamable HTTP endpoint that could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token. The development comes after SonicWall disclosed that it "investigated a case indicating the active exploitation" of CVE-2026-83548 and CVE-2026-83549. According to reports from Horizon3.ai and watchTowr, unknown threat actors have been observed weaponizing CVE-2026-9586 and CVE-2026-82329 to deploy reverse shells and and minted admin tokens for follow-on enumeration of users, groups, credential sets, and federated access topologies. As for CVE-2026-48710, a report from Horizon3.ai in June 2026 revealed that the vulnerability could be chained alongside another Berri LiteLLM flaw (CVE-2026-42271, CVSS score: 8.7) to bypass authentication and achieve remote code execution against vulnerable LiteLLM deployments. It's worth noting that CVE-2026-42271 was added to CISA's KEV catalog around the same time. Per Google-owned Wiz, threat actors associated with the Qilin (aka Agenda) ransomware have been linked to active exploitation of this chain. The cloud security platform said it has also observed exploitation efforts involving CVE-2026-59822 against its honeypots to probe model enumeration endpoints. The addition of CVE-2026-49869 to the KEV catalog is driven by a Microsoft report last week in which the vulnerability was likely exploited by a threat actor in late June 2026 to establish a reverse shell, conduct Docker container environment discovery, perform defense evasion, deploy a cryptocurrency miner, and facilitate data harvesting. "The Kestra compromise exposed four impact paths: shell execution through the workflow engine, container-environment exposure through Docker socket access, host resource hijacking through miner deployment, and follow-on collection through workflow task execution," Microsoft said. "The later curl-pipe-shell event encoded collected output and stored it through Kestra's own key-value interface, reducing reliance on standalone file artifacts." Separately, the Windows maker also revealed that malicious actors are breaking into LiteLLM gateways using CVE-2026-42271 and CVE-2026-48710 to deliver an XMRig miner via an ELF binary, but not before fingerprinting the host and terminating competing mining processes. The attackers have also been found to abuse previously collected database information to access the LiteLLM-backed PostgreSQL data tier and target LiteLLM tables, including LiteLLM_ProxyModelTable and LiteLLM_VerificationToken, to harvest records related to model configuration, upstream provider key material, provider endpoints, and proxy-issued virtual keys. Furthermore, the attack chain is characterized by the addition of persistence using "~/.ssh/authorized_keys" modification, command-and-control (C2), and defense-evasion mechanisms. The attacks, Microsoft and Wiz said, indicate artificial intelligence (AI) infrastructure, such as LiteLLM, Flowise, LangChain, Langflow, ChromaDB, Ollama, Marimo, and MCP servers, has become a lucrative target to steal API keys, gain access to backend systems, maintain persistence, engage in blind prompt injections and AI-native post-exploitation, and monetize infected hosts through illicit cryptocurrency mining. In another campaign documented by Redmond, it's suspected that adversaries are exploiting exposed RAGFlow instances using flaws like CVE-2026-45312, CVE-2026-28797, CVE-2026-24770, CVE-2025-68700, and CVE-2025-69286 to establish persistence and steal large language model (LLM) provider keys and related metadata. "The observed objectives were consistent. Across the cases, telemetry showed credential collection, durable access mechanisms, and resource monetization, even though the execution path differed by product," Microsoft said. "Defenders should monitor AI workloads according to their control-plane role, not only as isolated applications." Pursuant to "Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk," Federal Civilian Executive Branch (FCEB) agencies are recommended to apply patches for all the vulnerabilities, barring CVE-2026-48710 and CVE-2026-59822, by September 5, 2026. Agencies have time until September 16, 2026, to address the Starlette and LiteLLM flaws.

A critical authentication bypass vulnerability (CVE-2026-82329) in JFrog Artifactory is being exploited in attacks to create tokens that provide administrative access. The flaw is present in the default configuration of self-managed instances of JFrog Artifactory, a repository manager used to store, organize, secure, and distribute software packages. An unauthenticated attacker with network access could exploit it to gain administrative permissions. Researchers at offensive security company watchTowr observed the flaw being exploited by "attackers minting themselves admin tokens." Details about the flaw are scarce, and JFrog’s advisory does not share many details beyond that the flaw is exploitable in Artifactory’s default configuration. Vercel CEO Guillermo Rauch warned that the flaw’s impact could extend beyond compromising Artifactory itself. "Administrative access to Artifactory reaches released artifacts that downstream systems already trust and pull automatically," Collin Hogue-Spears, Senior Director of Solution Management at application security company Black Duck, told BleepingComputer. Spears also notes that JFrog treats access tokens as independent credentials with their own expiration and revocation mechanisms, so upgrading the Artifactory binary does not by itself invalidate an already-issued token. Because organizations use Artifactory to store binaries and packages consumed by build and deployment systems, attackers with administrative access could replace trusted artifacts and potentially execute malicious code on downstream systems. Rauch also speculated that the vulnerability might be connected to recent research involving autonomous AI agents. JFrog addressed the issue on August 28 in Artifactory versions 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20. The vendor says that JFrog Cloud environments were already protected. An attacker forging their own admin tokens means they can perform various sensitive actions, such as enumerating users, groups, and federated topologies, reading artifacts, changing security configurations, and poisoning existing packages. However, the extent of the compromise, and whether servers were actually breached, is unclear. Victim counts, telemetry details, and indicators of compromise (IoCs) are also unclear. BleepingComputer has contacted JFrog to confirm the reported activity, but we have not received a response yet. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Ransomware protection for MSPs should deliver six tested outcomes: reduce exposure, detect activity before encryption, provide 24/7 response, preserve isolated recovery points, recover cleanly and operate consistently across tenants. Backup alone is not enough, and neither is endpoint detection without a rehearsed recovery path. The Acronis Cyberthreats Report identified 143 MSP, IT-service provider and telecom ransomware victims in 2025, with phishing accounting for 52% of initial access cases and unpatched vulnerabilities for 27%. The checklist below turns those failure modes into controls and evidence an MSP should require before calling a service complete. The six things your service must do and what to verify A complete ransomware protection service connects prevention, detection, response and recovery. For each control, demand evidence from the exact tenant, workload, storage configuration and service tier being sold. Important: Immutable, offline and air-gapped describe different controls. Verify each one separately. How EDR, XDR, MDR and immutable backup work together EDR monitors endpoint activity and supports investigation, isolation and remediation. XDR connects endpoint signals with other attack surfaces so analysts see one incident instead of separate alerts. MDR adds people and process: a staffed service investigates and responds around the clock. Immutable backup protects recovery points from alteration or deletion; it neither detects data theft nor replaces incident response. Use them together. In the Acronis model, EDR provides endpoint detection and response, XDR extends visibility to email, identity and Microsoft 365 applications, and Acronis MDR operates on EDR or XDR. Acronis Cyber Protect Cloud supplies the backup, management and multi-tenant operating layer. Immutability is one recovery control; it is not the same as an offline or air-gapped copy. Acronis Cyber Protect Cloud with Acronis MDR brings prevention, detection, 24/7 response, backup and recovery into one multi-tenant platform. See how you can reduce operational complexity, protect recovery points and respond faster across client environments. Explore Acronis MDR The recovery runbook: Cut recovery time at every handoff Recovery time is the total of detection, triage, containment, clean-point selection, restoration and validation. An MSP reduces RTO by shortening every stage - especially the handoffs between security, backup, identity, networking and the client. Declare the incident, assign one commander and open an out-of-band channel. Identify affected tenants, identities, workloads and likely initial access. Isolate compromised endpoints and block malicious sessions, tokens and remote access. Preserve evidence before wiping systems or rotating logs away. Close the entry point by patching, disabling access and rotating credentials. Choose the latest recovery point that predates compromise and passes validation. Restore identity and infrastructure dependencies before applications and user data. Scan, test, reconnect in stages and monitor for renewed attacker activity. Acronis backup scanning and malware-free recovery capabilities can help validate candidate recovery points, while Acronis Disaster Recovery can coordinate recovery workflows where licensed. The incident team should still confirm that the selected point predates the compromise. Automation should remove repeatable waits, but an incident commander should approve high-impact actions such as mass isolation, credential resets and failover. A rehearsed path preserves the option to recover without paying, although no tool can guarantee recovery in every attack. After each drill, record achieved RPO/RTO and every delay, then revise the runbook from evidence rather than estimated restore speed. Is immutable backup enough against double-extortion ransomware? No. Immutable backup can preserve recoverability, but it cannot retract data that attackers already stole or remove breach-notification duties. A ransomware protection service must therefore look for exfiltration and identity abuse before encryption begins. Correlate endpoint, identity, email, Microsoft 365, DNS, proxy and egress telemetry. During response, isolate devices, revoke sessions and tokens, rotate credentials, block attacker destinations and preserve evidence for legal and notification decisions. Acronis EDR provides endpoint context and response, while Acronis XDR adds telemetry and response across email, identity and Microsoft 365 applications; network egress evidence may still come from firewalls, SIEM or other client controls. Test those handoffs in advance. How to evaluate an MSP ransomware platform Before buying or standardizing a platform, require a live demonstration of these seven items: Coverage for client workloads and tenant tiers. Prevention and detection before broad encryption begins. Named 24/7 response ownership, escalation paths and approval boundaries. Immutable-storage mode, retention behavior and privileged-access separation. Clean-point selection, malware scanning and isolated restoration. Measured RPO/RTO in a dependency-ordered recovery drill. Multi-tenant roles, reporting, audit evidence and RMM/PSA/API integrations. An integrated option is Acronis Cyber Protect Cloud with Acronis MDR. It brings together capabilities for the six operational jobs, subject to the selected MDR tier, licensing, deployment, storage architecture and the MSP’s incident-response responsibilities. Require a live incident-and-recovery test using the production configuration. Frequently asked questions What is the best ransomware protection for an MSP? A complete ransomware protection service should demonstrate all six outcomes across the client workloads it is contracted to protect. Acronis Cyber Protect Cloud with Acronis MDR is an integrated example. The MSP should validate the production configuration and confirm whether the selected MDR tier includes the required remediation and recovery actions. What should be included in a ransomware protection service? Include exposure reduction, EDR or XDR detection, 24/7 response, access-separated immutable recovery points, tested clean recovery and multi-tenant operations with client evidence. How can an MSP reduce ransomware recovery time? Remove handoff delays. Preassign owners, map dependencies, validate clean points, automate safe steps and rehearse restores until achieved RPO/RTO matches the service commitment. Does immutable backup stop double-extortion ransomware? No. It protects recovery data from change or deletion but cannot undo exfiltration. Detection, identity controls, egress visibility, containment and notification processes are still required. Make recovery a tested service outcome Ransomware resilience is the ability to contain attacks early, preserve a recovery path and prove critical services can return on schedule. Acronis Cyber Protect Cloud with Acronis MDR can bring detection, response, recovery and multitenant management into one MSP operating model. The MSP should validate the selected tier, storage architecture, integrations and operational responsibilities against the six tests above. See how Acronis Cyber Protect Cloud with Acronis MDR helps MSPs detect and contain ransomware, protect recovery points, and restore client operations faster. Sponsored and written by Acronis.

Keepnet launches free SMS/Call Reporter for iOS Keepnet, an Extended Human Risk Management (xHRM) and Secure Behavior Management platform, today launched the Keepnet SMS/Call Reporter. It is a free app that turns a suspicious SMS or phone call into a one-tap report. Anyone can download it for personal protection. Organizations can roll it out across their workforce. The app is available now on the Apple App Store, with Android release next on the roadmap. For Keepnet customers, reported events land in Keepnet Incident Responder. Security teams handle them in the same workflow as email phishing reports. The launch arrives as 80% of organizations have experienced mobile phishing attempts (Verizon MSI 2025). Most of those incidents never reach security teams. The corporate report button, the secure gateway, and the incident pipeline still live entirely in the email layer. The 2026 Verizon Data Breach Investigations Report tells the same story from the attacker side: mobile-based phishing simulations show “an increase of 40% in the median click rate” compared with email simulations (Verizon 2026 DBIR, p. 50). The DBIR team puts it directly on the same page: “Higher click rates make mobile devices the new favorite target. We’ve gotten better at spotting phishing emails, so attackers are moving to our pockets.” The Keepnet SMS/Call Reporter closes that gap on the user side: a free app for reporting SMS and voice phishing attempts directly from the device. Reports flow into the same security team pipeline as email phishing for Keepnet customers. Why mobile phishing outpaced reporting maturity Attackers expanded beyond the inbox. SMS, voice, and email now arrive together in the same campaign, and email-only reporting workflows were not built for that. A few things shifted since 2022. Email reporting matured; mobile didn’t. The report button, secure email gateways, and security team enrichment workflows are mature at most organizations. SMS and voice have no equivalent. When an employee gets a fraudulent SMS impersonating IT support and asking for MFA verification, there is no corporate workflow to route it to. Security teams never see the attempt. Attackers moved into channels with no security team coverage. The DBIR 2026 records the move directly: “criminals are also using other messaging channels other than corporate email to reach employees, such as WhatsApp, social media, and personal email accounts. All platforms where most corporate cybersecurity solutions do not provide coverage” (Verizon 2026 DBIR, p. 50). ENISA’s 2025 Threat Landscape adds the European regulator view: roughly 60% of initial access begins with phishing, and more than 80% of observed social engineering activity is already AI-supported. AI cut the cost of voice impersonation. Real-time voice cloning runs in dozens of languages now. Microsoft’s 2025 Digital Defense Report tracked AI-automated phishing at a 54% click-through rate against 12% for standard attempts, a 4.5× multiplier. The pattern started with MGM Resorts in 2023 and continued with Scattered Spider’s April 2025 attacks on Marks & Spencer and Co-op, costing an estimated £270 to £440 million in combined damages. Voice phishing now accounts for over 60% of phishing-related incident response engagements (Mandiant M-Trends 2026). Voice phishing is a corporate problem now, not a personal one. Attackers stopped running email-only campaigns. A multi-channel sequence is the new default. The email primes the target. An SMS arrives next claiming urgency. The voice call closes the deal. Email is asynchronous, so the target can pause, reread, ask a colleague. SMS and voice attacks are synchronous. The target has seconds. What the research points to The phone is the corporate attack surface most awareness programs still measure the least Email-only reporting leaves SMS, voice, WhatsApp, and personal-email incidents off security team telemetry The question shifted from “did the employee click” to “how far did the conversation progress before verification happened” Help desks and finance teams are first-touch attack surfaces, following the Scattered Spider playbook What this means for security teams The FBI’s 2025 IC3 report counted $798 million in smishing and vishing losses from government impersonation alone, the first time these losses have been measured as their own category (source: FBI IC3 2025 Annual Report, p. 4). The gap between what’s measured and what’s being exploited is where the real money goes. Help desks are part of the attack surface, not adjacent to it Verification procedures matter more than awareness alone Reporting telemetry from the phone channel is the missing security team signal Email-only simulations leave the highest-engagement channels untested Inside the Keepnet SMS/Call Reporter Other mobile apps stop at consumer scam detection. Enterprise mobile defense stops at malware. The SMS/Call Reporter sits between: a one-tap button on the user’s phone that feeds the same security team pipeline as email phishing reports. Three design choices define it. User-initiated, privacy-first. The app receives only what the user explicitly reports. No SMS inbox monitoring, no call recording, no passive collection. The iOS sandbox enforces this and the application architecture reinforces it. One-tap report from the mobile device. A suspicious SMS or phone call goes to Keepnet in one tap. Multi-source threat intelligence and AI-driven analysis return a verdict in seconds: malicious, suspicious, spam, or no threat detected. No desktop, no ticket, no screenshot to forward. The friction that kills email reporting drops to zero on the channel that needed it most. Closing the visibility gap is not an awareness problem. It is three operational moves: more suspicious SMS and calls actually reported from the phone, faster analysis and triage before the incident escalates, and end-to-end visibility for security teams. Enterprise centralization through Keepnet Incident Responder. For Keepnet customers, reported SMS and voice events land in the same incident pipeline as email phishing reports, where the security team reviews, enriches, and escalates. Mobile reports become security team telemetry, not awareness data. Voice and SMS phishing simulations have been purpose-built into Keepnet’s platform since 2022, with customers including SunExpress, Axa, Desjardins, Ryanair, Arriva, and Vodafone. Phone number coverage runs across the US, UK, EU, and parts of Asia. The company is ISO 27001 and SOC 2 Type 2 certified, and operates in line with ISO/IEC 42001:2023 and EU AI Act requirements. Keepnet also runs live voice-based social engineering assessments against help desks and high-risk employee groups. What organizations gain Deployed at workforce scale, the SMS/Call Reporter turns employees into sensors in places the existing control stack cannot reach. Security and risk leaders get: Visibility into SMS, voice, WhatsApp and personal-email phishing attempts that security teams previously did not receive One incident pipeline for email, SMS and voice phishing reports, with no separate workflow to build or maintain Faster time to security team awareness on the channel where engagement is highest (Verizon DBIR 2026) Stronger help-desk verification controls against vishing and executive impersonation A workforce-wide reporting reflex extended from email to mobile, measurable through simulation programs “We spent a decade making the email report button second nature. The phone has none of that. Until employees have a one-tap way to report a suspicious call or text, security teams stay blind. That’s what the SMS/Call Reporter fixes,” said Ozan Ucar, Founder & CEO of Keepnet. “Social engineering threats are rapidly expanding beyond traditional email into voice, SMS, collaboration platforms and AI-assisted communication channels. Organizations therefore need broader visibility, stronger reporting workflows and more resilient human risk strategies across the full communication landscape,” said Ayo Adebayo, Head of Information & Cyber Security, SunExpress Airlines. How security teams can extend SMS/call reporting beyond email The Keepnet SMS/Call Reporter is available free on the Apple App Store. Full product overview, enterprise deployment guidance, and a 90-second demo here. The app works alongside any security awareness or human risk management program, in-house or third-party. Organizations can extend reporting to SMS and voice without switching platforms. Keepnet invites CISOs, security and risk leaders, and security operations managers to: Give employees a way to report a suspicious SMS or call from their mobile in one tap Centralize mobile-channel reports in Keepnet Incident Responder alongside email workflows Track mobile reporting activity as security team telemetry, not as awareness data Close the visibility gap before the next SMS, voice, and email campaign lands Attackers moved beyond the inbox. Enterprise visibility must move with them. About Keepnet Keepnet is an Extended Human Risk Management (xHRM) and Secure Behavior Management platform helping organizations reduce employee-driven cybersecurity risk through AI-powered phishing simulations, behavioral microlearning, security awareness training, and AI-driven phishing incident response. Keepnet contributes to industry research on voice and SMS phishing, including the 2026 Verizon Data Breach Investigations Report. The findings cited in this release draw on Keepnet research and tier-1 sources (Verizon DBIR 2026, Verizon MSI 2025, FBI IC3 2025, Microsoft Digital Defense Report 2025, Mandiant M-Trends 2026, ENISA Threat Landscape 2025). The full research paper “The Mobile Phishing Visibility Gap” is available here.

The U.S. Department of Justice (DoJ) on Tuesday announced the takedown of a long-standing peer-to-peer (P2P) botnet known as Sality as part of a coordinated law enforcement operation. The effort was undertaken on August 31, 2026, by authorities from the U.S., Bulgaria, Hungary, and Romania, in collaboration with private industry partners CrowdStrike and the Shadowserver Foundation. To that end, a peer-to-peer sinkhole operation was carried out to eliminate the threat. In tandem, Sality-linked domains have been seized in the U.S. and Europe. "Cybercriminals, botnets, and malware are a clear and present danger to our nation's security and economy," said First Assistant United States Attorney Bill Essayli. "This successful effort to take down the Sality botnet shows that by working together, the public and private sectors can be a powerful force for good." Sality has been documented in the wild since 2003, featuring capabilities to infect and modify Windows executable files, and spread additional malicious software designed for credential theft, spam distribution, proxy services, network exploitation, and distributed denial-of-service (DDoS) attacks. The malware is the work of a threat actor that's tracked by the broader cybersecurity community under the monikers Salty Spider, Kukacka, Sality, KuKu, SalLoad, Kookoo, and SaliCode. The group is believed to be operating out of the Republic of Bashkortostan in Russia. Over the years, several variants of the Windows malware have been equipped with the ability to communicate over a P2P network, thereby allowing it to bypass traditional command-and-control (C2) server shutdown tactics. One of the primary payloads delivered via Sality is EggJagger, a clipper or clipjacking tool that continuously monitors a device's clipboard for cryptocurrency wallet addresses and stealthily substitutes them with threat actor-controlled ones to redirect transactions. It's estimated that the threat actors have stolen at least $150,000 using this method. Although Sality's operations are primarily driven by financial gain, the malware has been used to conduct three notable DDoS attack campaigns, highlighting the threat actor's willingness to repurpose the botnet for personal or political purposes, CrowdStrike said. The attacks targeted - Arabic Financial Forum ("forex2030[.]com") in April 2016 Ukrainian Forum ("kharkovforum[.]com") in February 2022, a day after Russia's full-scale invasion of Ukraine AvanChange in September 2023 Sality has been distributed through various methods, including infected network shares, USB devices, file sharing, compromised websites, email attachments, and P2P networks, effectively creating a self-propagating botnet that regenerates new infections without requiring any active efforts from the threat actor. In July 2022, operational technology cybersecurity company Dragos revealed a campaign that targeted industrial engineers and operators to seize control of Programmable Logic Controllers (PLCs) and co-opt the devices into the Sality botnet. According to CrowdStrike, the botnet is said to have allowed the operator to distribute malicious payloads to more than 15,000 infected machines worldwide, adding that two independent P2P networks, known as version 3 and version 4, remained active until the disruption occurred. "They shared the same codebase and were operated by the same threat actor, but used incompatible protocol versions and different cryptographic keys," the CrowdStrike Counter Adversary Operations said. The takedown operation involved turning Sality's P2P architecture against itself to isolate all peers in the network from the threat actor's control and neutralize their ability to communicate with infected machines. This, in turn, prevents them from receiving payload download instructions or payload transfers, rendering the botnet ineffective. "The same properties that made Sality resilient also created the conditions for its undoing," CrowdStrike explained. "Sality's P2P protocol cannot be patched. Unlike conventional malware that can receive code updates from a C2 server, Sality's spreading mechanism is a file infector: it propagated by attaching itself to executables on disk." The counterattack leveraged an approach called peer list manipulation, which was also used in the 2014 GameOver Zeus and 2017 Kelihos botnet disruptions. It took advantage of the fact that Sality bots blindly trusted the P2P network without verifying who was added to it. As long as a machine was publicly reachable and responded correctly to the P2P handshake, it was accepted as a legitimate peer. This factor, coupled with the lack of authentication, cryptographic identity, or allowlist, meant that "anyone" could join the network as a full participant with no way to distinguish it from a genuinely infected host. The peer list manipulation technique, as the name implies, involves tampering with the peer list, a data structure containing a finite set of known super peers, which are publicly reachable infected machines that serve as the basis of the P2P network. The botnet checks whether its stored peers are still online every 40 minutes. Peers that respond to the check accumulate reputation, while those that fail lose reputation and are eventually purged. This maintenance cycle is abused to remove legitimate peers from the network via protocol-level manipulation during peer verification and insert purpose-built sinkhole entries into the emptied peer list. "The disruption targets super peers first, as they form the network's communication backbone," CrowdStrike said. "Once isolated, both URL packs and file packs stop propagating. The majority of infections sit behind firewalls or network address translation (NAT) and cannot be directly contacted." For these machines, a more passive approach is adopted. When they contact the sinkhole nodes during their normal maintenance cycles, their peer lists are purged, leaving them permanently isolated. The coordinated operation, besides sinkholing the P2P network, also took down the URLs that have been found to host Sality payloads. In doing so, it prevents the malware from downloading these files and retrieving additional payloads. The list of URLs is below - theunforgiven.p8[.]hu/img/top.gif painelwebradiodigital.awardspace[.]info/v3/readme.pdf sgwebdesigner.free[.]fr/left.gif www.yonelco[.]com/icon.png pozdravizbeograda[.]com/readme.pdf highclass.atspace[.]com/styles.gif situluimihai.3x[.]ro/top.png gatheredovertime[.]com/nb4 imagebucket[.]biz/nv4 All Sality-infected machines are now configured to beacon to CrowdStrike-operated sinkholes. Organizations are recommended to review network logs and endpoint telemetry for UDP traffic to the "lighthouse" IP address "188.166.101[.]148." Any match indicates a Sality infection that requires remediation. "This operation demonstrates that P2P architecture, long considered a shield against disruption, is not invincible," CrowdStrike said. "With sufficient technical investment, precise understanding of protocol behavior, and coordination with law enforcement and industry partners, even the most resilient criminal infrastructure can be dismantled." "While the disruption prevents new payloads from reaching infected machines, existing malware already installed on those systems remains active and should be removed." The joint crackdown is one of the key pillars under President Donald Trump's Cyber Strategy for America. Referred to as "Shape Adversary Behavior," it aims to identify and disrupt malicious networks, scale national capabilities, and alter adversary calculus by degrading their tools and infrastructure. "This unique collaboration among international law enforcement and private sector partners only enhances the FBI's cybersecurity capabilities and our efforts to neutralize the threat posed by the Sality botnet," said Patrick Grandy, the Assistant Director in Charge of the Federal Bureau of Investigation's (FBI) Los Angeles Field Office. "The FBI will continue working with our partners to prevent further cyber-enabled attacks and theft from victims in the United States."

The average adversary breakout time is now 29 minutes, with the fastest recorded at 27 seconds, according to the CrowdStrike 2026 Global Threat Report. AI is supercharging the adversary playbook, empowering many to move faster across multiple domains. Defenders must match that speed with AI-driven security operations that investigate and respond across every domain, in real time. CrowdStrike is delivering new innovations with the next evolution of the agentic SOC, in which analysts and AI agents work together in a unified system. In the legacy SOC, evidence lives in disconnected systems. Automation is split across separate interfaces and execution logs. Analysts toggle between tools and manually stitch together context. Only a subset of detections receives real investigation while everything else piles up as a structural blind spot. But most security teams struggle to achieve an agentic SOC transformation, for three key reasons. First, fragmented data prevents cross-domain investigations. When context lives in separate tools and isn't AI-ready, agents can't connect the dots across identity, cloud, endpoint, SaaS, and network. Second, isolated agents reach incorrect or late verdicts. Because they work in silos with sequential handoffs, they see only a partial picture, which reverts the work back to analysts. Third, ungoverned automation creates breach points. Agents act in your environment and connect to your systems; if you can't build, monitor, and control them, you can't see what's running, what it's connected to, or what it costs. CrowdStrike takes a different path. The CrowdStrike Falcon® platform is not just where agents run. It is where the data is generated, enriched, investigated, orchestrated, and governed. New at Fal.Con 2026: The Evolution of the Agentic SOC At Fal.Con, CrowdStrike is delivering the next evolution of the agentic SOC, a production operating model where expert agents and analysts stop breaches as one system. New capabilities in the Falcon platform include: A more unified foundation: Third-party data now arrives detection-ready through certified pipelines, with detection logic running inside the pipeline before data reaches its destination. This accelerates both time-to-value and mean time to detect (MTTD). Coordinated teams of specialist agents: For actions ranging from cross-domain investigations to proactive reconnaissance, teams can deploy fleets of battle-tested agents built by CrowdStrike experts and coordinated by an orchestrator agent, all of which work out of the box. A unified agentic SOAR workspace. Charlotte AI AgentWorks, SOAR orchestration, and CrowdStrike Falcon® Foundry converge in one place to build and govern rule-based and agentic automation alike, with expanded flexibility for how security teams can build agents and connect them to their security stack via MCP. See it in action: Coordinated expert agents investigate every domain at once and converge on a single verdict Let’s take a closer look at what’s new. Certified Data, Ready for Agents The Falcon platform starts from native telemetry and extends outward, delivering petabytes of cross-domain data refined by elite security experts in one unified foundation. Teams decide what is ingested and what is federated, and critical first-party data has no ingestion cost. The result is agents with a complete view of their environment that is AI-ready from the start. Third-party data traditionally depends on pipelines customers build and maintain themselves, with no guarantee that data lands complete or usable. A single dropped field or schema change can break a detection without anyone noticing. In an agentic SOC, where agents act on data automatically, that risk compounds. CrowdStrike is closing this gap with new capabilities that optimize how third-party data gets in, what happens to it in flight, and whether teams can trust it when it lands. These include: Certified data pipelines (Public Preview). Teams will get pre-built, pre-tested data flows that CrowdStrike validates and maintains, starting with Zscaler and Palo Alto Networks. Sources go live in hours and arrive detection-ready, so coverage starts when a new source is connected. There is no pipeline overhead to carry, and only security-relevant data reaches the platform.

After several weeks of anticipation, Mozilla has started rolling out ad blocking to the iOS version of its popular browser, but you can still expect to see ads on Mozilla's own pages, including the new tab page. The org officially rolled out the new native ad blocking feature for iOS Firefox on Tuesday, moving it out of the experimental phase, while explaining that it had to rethink its desire to give users control over their web experience on iOS due to differences in architecture between it and other OSes. “Firefox already supports a strong ecosystem of ad-blocking and privacy extensions,” Mozilla explained. iOS works differently, though, as Apple forces all web browsers on iOS to use its own WebKit to render sites instead of their own preferred back end. “Bringing ad blocking to Firefox on iOS,” therefore, “meant building it directly into the browser,” Mozilla explained. Implementing ad blocking in the iOS version of Firefox meant incorporating Apple’s own WebKit Content Blockers. According to Apple’s introduction on the topic, it specifically doesn’t want app extensions to be used to block web content because of how they operate. “App extensions … are essentially little sandboxed applications that are launched on demand to extend some specific piece of functionality,” Apple notes. “JavaScript-based content blocking extensions … have significant performance drawbacks.” Apple complains that traditional ad blockers use too much energy, increase page load time, and eat up memory, all of which it wants to protect iOS users from. Apple describes WebKit Content Blocking as “describing content blocking rules in a structured format ahead-of-time, declaratively.” Apple Web Content Blockers instead live in bytecode format that executes for each resource request, modifying requests or injecting CSS changes as needed while pages are loaded. For Mozilla, that basically means dropping the EasyList filter, originally designed for the classic Adblock blocker, into a JSON file and passing it to WebKit. Easy peasy. Ad blocking in Firefox for iOS is off by default. Turning it on, if it’s available for you – it’s rolling out gradually – is as easy as opening the in-app settings menu, tapping on Browsing, and toggling the Ad Blocker field on. Mozilla told The Register in an email that it doesn't have a timeline for general release to all Firefox users on iOS, which it said will largely depend on how well the initial rollout goes. You also have to turn Remote Improvements on, as the feature allows Mozilla to push fixes and feature changes to Firefox between full releases. Toggling that on has traditionally meant you also had to allow Mozilla to collect browser telemetry, but that was changed in February when Firefox 148 was released and the two features have officially been decoupled. Once on, iOS Firefox Adblocking will take care of ad-related trackers, ads from third-party advertising networks, third-party ads served by websites, and popups/overlays. What it won’t do, however, is take care of ads on search result pages or sponsored content on Firefox’s home or new tab page – after all, you wouldn’t want Mozilla to lose those precious ad bucks, would you? Firefox iOS ad blocking also won’t eliminate ads served directly by websites, and the company warns that it still might not work in all places, which is pretty common for ad blockers. For Firefox users who want browser consistency across platforms, it’s likely a welcomed announcement, though it begs the question whether Mozilla is considering integrating its own ad blocking technology in the desktop or Android versions of its browser. Fortunately for those making ad-blocking extensions, and those who love them, Mozilla says it has no plans to expand built-in adblocking outside iOS. "We value that ecosystem and will continue to support it," Mozilla told us. ®

Vishing campaign abuses Microsoft Teams to give attackers a foothold in company networks A coordinated voice-phishing (vishing) campaign, named Spring Ring, used fake IT support accounts on Microsoft Teams to trick employees into installing malware or granting remote access to their computers, according to Unit 42, Palo Alto Networks’ threat intelligence team. The campaign ran between January and April 2026 and reached more than 150 employees at more than 10 companies in different industries. The attackers registered external Microsoft Teams tenants with names built to resemble internal IT departments, such as “ITProtectionDepartment” or “MandatoryNetworkMonitoring,” using the onmicrosoft.com format that Microsoft 365 customers normally use for their own organizations, Unit 42 found. Some attackers used specific names, rather than generic titles like “help desk,” to increase the perceived authenticity of the technician on the other end of the line. “Threat actors frequently abuse or subvert legitimate products for malicious purposes. This does not indicate that the product itself is flawed or compromised,” researchers noted. Unit 42 identified 26 distinct attacker identities behind the chat and call attempts. Once a chat was accepted, the attacker placed a call. Many attempts were missed or lasted only seconds, as the attacker moved through a list of targets. “Successful calls often last between 10 and 15 minutes,” the researchers wrote. Two paths into the network Unit 42 documented two campaigns, both opening the same way and diverging at the point of malware delivery. Full attack flow of the two Spring Ring campaigns (Source: Palo Alto Networks) One campaign relied on the caller directing the victim to launch Quick Assist or download remote-support software, then requesting control of the machine. Once connected, the attacker ran commands to check the user’s group membership and domain, then downloaded an obfuscated PowerShell script that disabled Windows’ built-in malware scanning before contacting a command and control server. The other campaign sent the victim a link to a file hosted on cloud storage, named to include their own company and username. Running the downloaded file triggered browser hijacking, scanning of the internal network over SMB, and an attempted Microsoft NT LAN Manager (NTLM) relay attack using a tool called PetitPotam. The relay attempt aimed to get the organization’s domain controller to authenticate to a machine controlled by the attacker, a step that could grant domain-level privileges if it succeeded. Both intrusion attempts were blocked by Unit 42 before the attackers reached their objective. Collaboration platforms as a phishing channel Phishing alerts tied to collaboration platforms accounted for 42% of all phishing alerts in Unit 42’s telemetry in the first four months of 2026, up from 30% in the preceding four months, the company said. “By using seemingly legitimate external tenants and professional vishing lures, attackers can target hundreds of employees across many industries with minimal friction,” researchers warned. “As these threats evolve, organizations must prioritize user education regarding unsolicited external communication across collaboration platforms.” Palo Alto Networks published indicators of compromise, including the attacker-controlled domains, IP addresses, and file hashes, alongside the report.

Security teams have more edge controls at their disposal than ever, and each plays an important role. Yet, despite the best request inspection, credential validation, device fingerprinting, and automation signals available, attackers still successfully hide inside traffic that looks remarkably similar to legitimate user activity. One reason for this is that each security control focuses on a different piece of a user session. If an attacker that otherwise looks legitimate uses a residential IP or a commercial VPN, they may pass through several layers without triggering an alert or action. This is the fundamental problem with existing edge security tooling: a lack of context around the underlying infrastructure. What existing controls see, and what they can miss Application security relies on multiple layers of defense, each designed to answer a different question about incoming traffic. CDNs and WAFs are highly effective at inspecting requests, enforcing policies, filtering known threats, and protecting applications at the edge. But the request itself may not reveal that a seemingly ordinary connection is being routed through infrastructure intended to disguise its origin. Bot management helps identify automation and distinguish bots from human users. But not every malicious session is automated, and attackers increasingly combine automation with infrastructure designed to resemble legitimate consumer traffic. Identity and authentication systems attempt to determine whether users can prove who they claim to be. But valid credentials don't necessarily mean the person presenting them is the legitimate account holder. Device and browser intelligence provides a layer of trust by describing the endpoint. However, it doesn't reveal the network infrastructure connecting that endpoint to the application. Individually, these signals provide valuable and essential insights. But attackers increasingly exploit the gaps between them, creating sessions that appear legitimate to any one control while hiding important context about the infrastructure behind the connection. See how Spur's Monocle Session Enrichment platform adds real-time infrastructure context to your existing controls. Make smarter enforcement decisions by revealing when sessions hide behind VPNs, proxies, anonymization, data center traffic, and AI activity. Try Monocle Free From individual signals to session trust This creates a need for another layer of context: intelligence about the infrastructure behind the live session. Spur built Monocle Session Enrichment to provide that layer. Monocle enriches every user session with real-time trust signals – including anonymization status, proxy service attribution, residential infrastructure, and emerging attacker networks – that extend the intelligence of your existing edge security stack and enable your security and fraud teams to make smarter edge enforcement decisions that reduce authentication risks and friction for legitimate users. Monocle combines Spur's visibility into Internet infrastructure with live session telemetry to create a real-time Session Trust Assessment. Instead of simply labeling an IP as good or bad, it provides attributes that the enforcement layer can use when deciding how to handle the session. A Session Trust Assessment might look like this: { "allowed": false, "reason": "Anonymous connections blocked", "assessment": { "vpn": true, "proxied": false, "anon": true, "rdp": false, "dch": true, "cc": "US", "ip": "146.70.202.60", "ts": "2026-07-07T23:54:48Z", "complete": true, "id": "35ea59be-539d-4f65-b699-77ddc13c5df2", "sid": "test-app", "service": "PROTON_VPN", "cpd": "test-cpd-value", "ai_agentic": false, "ai_crawling": false }, "decisionId": "1a08c38d-810e-4a90-8705-dd3d9a76c529" } The assessment provides three types of context: signals describing what Monocle observes about the session; a decision based on the organization’s configured policy; and governance data that makes the assessment traceable. Signals Attributes such as ‘vpn’, ‘proxied’, ‘anon’, ‘rdp’, and ‘dch’ describe the infrastructure and connection characteristics Monocle observes, while ‘service’ identifies the specific service involved. Additional signals such as ‘ai_agentic’ and ‘ai_crawling’ provide context about emerging AI-driven traffic. Decision Rather than leaving the application to interpret the signals on its own, ‘allowed’ provides the resulting policy recommendation, while ‘reason’ explains why that decision was made. In this example, the session is not allowed because the configured policy blocks anonymous connections. Governance & traceability Fields including ‘decisionId’, ‘id’, ‘sid’, and ‘ts’ provide identifiers and timing information that can help teams trace a decision back to a particular assessment and application context. The goal of session enrichment is to expose the underlying infrastructure attributes so the organization can decide what those signals mean in the context of its own users, applications, and risk tolerance – and then enforce the appropriate policy. Applying session enrichment: Context makes existing controls more useful Suppose a financial institution sees a successful login from a U.S. IP address. On its own, that isn't particularly interesting. However, session enrichment might reveal that the connection is anonymous, originates from data center infrastructure, and is attributed to a commercial VPN service. This gives the enforcement layer critical context that enables more informed authentication decisions. In practice, a known customer using their normal device through a VPN might be allowed to continue, but a login using new credentials, an unfamiliar device, and anonymization infrastructure might trigger MFA. A high-value transaction from that same session could require additional verification. The same principle applies to use cases beyond suspected account takeover attempts: During account creation, infrastructure context can help identify users attempting to conceal or repeatedly change their network identity. For automated abuse, session enrichment can complement bot detection by showing the infrastructure being used to distribute activity. For geographic enforcement, organizations can distinguish the apparent location of an IP from sessions using VPN or proxy infrastructure to obscure their origin. For AI-generated traffic, organizations can add emerging agentic and crawling signals to the policies they already use for human and automated traffic. Enforce where the decision matters Session enrichment is most effective when its signals can be evaluated where traffic is already being controlled: at the edge. Monocle is designed to complement existing edge infrastructure rather than replace it. Organizations using platforms such as Cloudflare can incorporate session enrichment into their existing enforcement workflows and determine how different combinations of signals should be handled. That might mean allowing a session, challenging it, requiring stronger authentication, restricting a sensitive action, sending it for additional analysis, or blocking it altogether. Edge security needs better context Session enrichment provides a missing layer of intelligence into the infrastructure behind sessions, complementing existing edge security controls and enabling stronger decisions. See how Spur can help uncover threats hiding behind VPNs, proxies, and other anonymization infrastructure. Get started for free. Sponsored and written by Spur Intelligence.

While monitoring Mirage Kitten activity, we uncovered a previously undocumented malware family that we dubbed NodeRabbit. We identified the first sample on a system in Afghanistan. Further threat hunting revealed two additional, more advanced, variants: one on a system in Egypt and another on a system in Ethiopia. NodeRabbit is a cross-platform remote access trojan (RAT) built with Node.js. It targets Windows, Linux, and macOS. Its operators deliver it through spear-phishing messages on LinkedIn and other job search platforms that contain trojanized coding challenge archives. During the same investigation, we discovered another previously undocumented malware family that we dubbed PollCat. Like NodeRabbit, PollCat is a cross-platform RAT, but it is written in obfuscated JavaScript also distributed through trojanized coding challenge archives. Mirage Kitten has historically relied on native malware written in languages such as C, C++, and Go, often deploying it through DLL search-order hijacking. NodeRabbit and PollCat represent the first publicly documented use of Node.js- and JavaScript-based malware by this APT group. Kaspersky’s products detect this threat as Trojan.JS.MirageKitten.* Background During recent threat research, we detected suspicious activity on a system in Afghanistan. We traced it to an archive containing a software development project that the user may have received during a job application process. The archive purported to contain a coding challenge for candidates applying for an engineering role. The archive, Front-Technical-Challenge.zip (MD5: 1EA83E4E4592B01E4ACAB63EB867BEE5 ), was hosted in an Amazon S3 bucket at: https://oracle-challenge.s3[.]us-east-1.amazonaws[.]com/Front-Technical-Challenge.zip It contained TaskFlow, an app for software engineering assessment built with Express, React, and Vite. The accompanying README instructed the candidate to review the application and fix defects in its frontend. It also claimed that server.js was bug-free and should not be modified, conveniently directing attention away from the only application source file the attackers had altered. README file for a trojanized coding challenge app The README also imposed a three-hour time limit and prohibited the use of AI assistants. Notably, an AI code-review assistant tasked with auditing the project would likely have flagged the suspicious first-line import of an unknown npm package and warned the targeted developer that the project was trojanized. Rules and time limit included in the trojanized coding challenge app README file The first line of server.js imported a trojanized npm package named colorized_terminal , version 2.1.0 . The attackers bundled the package directly in the challenge task archive’s node_modules directory rather than publishing it to the npm registry. When imported, the package silently launched an implant from node_modules/.cache/.320697f1/index.js as a detached background process. Retrospective threat hunting across our telemetry revealed the broader scope of the campaign. We identified three NodeRabbit variants with a shared code lineage; each was recovered from a system in a different country. The operators delivered the variants through similarly themed coding challenges and used two trojanized packages, colorized_terminal and pretty-log , both pinned to version 2.1.0 . The campaign also delivered PollCat, a second RAT with a substantially different structure, through a separate coding challenge lure. We’ll analyze PollCat later in this research. Initial access The infection chain begins with fake recruiter accounts contacting prospective targets on a job search platform. According to a publicly cited source, a threat actor posing as a talent acquisition specialist at a major technology company contacted a software engineer and advertised a job opening, inviting the target to complete a technical assessment. The target received a link to a coding challenge hosted on Amazon S3 and was pressured to download and run the project immediately. This public post matches the delivery chain we reconstructed from our telemetry: recruiter outreach on a job search platform, a coding challenge presented as a technical assessment, and a trojanized project archive hosted on legitimate cloud infrastructure. NodeRabbit RAT: the first variant We discovered the first NodeRabbit variant on a system in Afghanistan. The malware was concealed within the TaskFlow assessment at node_modules/.cache/.320697f1/index.js and executed by the trojanized colorized_terminal package. Once running, NodeRabbit generates a unique agent identifier from available host information. It calculates the SHA-256 hash of the hostname, username, operating system version, architecture, and MAC address, then truncates the result to its first 32 hexadecimal characters. NodeRabbit binds a TCP listener to 127.0.0.1:48739. This listener acts as a single-instance mechanism. If the malware cannot bind to the port, it assumes that another instance is already running and terminates silently. NodeRabbit uses a persistence mechanism for each operating system: Operating system Persistence mechanism Windows Copies itself to %APPDATA%\Microsoft\EdgeUpdate\msedge_update.js; clones the local node.exe to nodew.exe in the same folder and patches its PE subsystem from Console to Windows GUI to suppress the console window; creates HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftEdgeUpdate registry key executing nodew.exe msedge_update.js Linux Copies itself to ~/.config/microsoft-edge-update/msedge_update.js and creates an @reboot cron entry that invokes the script using the current Node.js executable. macOS Copies itself to ~/.config/microsoft-edge-update , creates ~/Library/LaunchAgents/com.microsoft.edgeupdate.plist configuration file pointing at the copy’s location with RunAtLoad and KeepAlive parameters, and attempts to load it. The malware communicates with its command-and-control servers through three API endpoints, choosing from the following Azure-hosted C2 infrastructure addresses. On failure, it switches to the next C2 address: 1. https://plugplay.azurewebsites[.]net 2. https://Rgbteller.azurewebsites[.]net 3. https://Wslwebui.azurewebsites[.]net Method Endpoint Purpose POST /api/rabbit/checkin Register agent and host info POST /api/rabbit/task Poll for commands POST /api/rabbit/result Submit results NodeRabbit serializes each C2 request object as JSON and wraps it with AES-256-GCM. The AES key is the SHA-256 digest of an ASCII seed embedded into the agent. Every request uses a fresh 12-byte IV and a 16-byte authentication tag: The malware sends encrypted requests using the following structure: { "d": "base64(IV || ciphertext || authentication_tag)", "_r": "8 hexadecimal characters", "_t": "epoch timestamp" } C2 responses are structured the same way and may contain a command to execute. We observed the first NodeRabbit variant supporting 11 commands: Command Functionality sys:info Return hostname, domain user information, username, and process ID. proc:list List running processes. proc:start Execute an arbitrary shell command. fs:list List a directory. fs:read Read a file in chunks and return Base64 data. fs:write Decode Base64 and write it at a chosen file offset. fs:delete Delete a file or recursively delete a directory. fs:mkdir Create directories recursively. net:config Enumerate adapters, MAC addresses, IP addresses, and DNS settings. agent:sleep Change the beacon interval. script:exec Write a base64 Node.js script to a randomly named .tmp file, execute it and delete it. NodeRabbit RAT: the second variant Retrospective threat hunting following the discovery in Afghanistan led us to a second infection on a system in Egypt. This sample is a more advanced NodeRabbit variant, launched through the trojanized pretty-log package instead of colorized_terminal . Before running its core functionality, the malware checks whether the host resembles an analysis environment. It terminates if it detects limited system memory, a low CPU count, short system uptime, analyst-associated usernames or hostnames, or common analysis tools running on the system. Before terminating, the malware generates benign HEAD requests to www.google.com, www.microsoft.com , and www.cloudflare.com , then exits without ever contacting its C2 infrastructure. Most likely, it attempts to look less suspicious by showing some benign activity before exiting. Variant 2 implements partial corporate proxy support: it checks HTTP(S) proxy environment variables, Windows Internet Settings, including an explicit PAC URL, and WinHTTP configuration; tunnels its HTTPS C2 through HTTP CONNECT . It first tries to establish an unauthenticated connection. If it fails, it retries using URL-embedded basic credentials. Finally, it delegates Windows NTLM/Negotiate challenges to curl.exe --proxy-anyauth --proxy-user . It caches the proxy-discovery result, including when no proxy is found, for five minutes. If the polling loop detects a network-interface or IP-address change, it clears the cache and runs proxy discovery again on the next checkin. To make sure a single instance is running, Variant 2 uses a host-specific port derived from the agent identifier instead of the fixed TCP port used by the first variant. It interprets the first four hexadecimal characters of the identifier as an integer and applies the following calculation: 41984 + (value mod 5000) . The resulting listener port falls between 41984 and 46983 . Unlike the shared port used by Variant 1, this port varies depending on the infected host. For persistence, Variant 2 masquerades as Intel Driver & Support Assistant. The exact persistence mechanism, once again, depends on the operating system. Operating system Persistence mechanism Windows Copies itself to %LOCALAPPDATA%\Intel\DSA\idriver_support.js . It then copies the local node.exe binary to IntelDSA.exe and changes its PE subsystem from Console to Windows GUI, suppressing the console window. Finally, it creates a scheduled task named IntelDriverSupportUpdate , which runs daily at 10AM and executes IntelDSA.exe with the dropped script. Linux Copies itself to ~/.config/intel-dsa/idriver_support.js and creates an @reboot cron entry. macOS Copies itself to ~/Library/Application Support/Intel DSA/idriver_support.js and creates the LaunchAgent com.intel.dsa.helper with RunAtLoad and KeepAlive enabled. NodeRabbit RAT: the third variant Further threat hunting identified a third NodeRabbit variant on a system in Ethiopia. Like the second variant, it is launched through the trojanized pretty-log package. It retains much of the previous variant’s functionality but introduces significant changes to its command-and-control configuration, command set, and persistence mechanisms. The third variant communicates with its C2 infrastructure through a different set of API endpoints: Method Endpoint Purpose POST /sdk/v2/ready Register agent and host info POST /sdk/v2/config Poll for commands POST /sdk/v2/events Submit results We observed the malware using a C2 chain composed of Azure- and Cloudflare-hosted domains. 1. https://visitfinancedentists[.]com 2. https://kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net 3. https://healthcomfsdpower[.]com For persistence, Variant 3 implements the following mechanisms depending on the operating system in use: Operating system Persistence mechanism Windows Attempts to copy the payload to ProgramData or LocalAppData , create a build-specific daily 10AM task, and start the copied payload. To choose the exact directory, it tries to list C:\Windows\System32\config . If successful, it selects ProgramData with /ru SYSTEM /rl highest; in case of a failure, it selects LocalAppData without explicit /ru or /rl settings. macOS Copies the payload to ~/Library/Application Support, creates and loads a RunAtLoad/KeepAlive LaunchAgent and starts the copied payload. Linux Copies the payload to ~/.local/share , attempts to add an @reboot cron entry, and starts the copied payload. If crontab -l fails, persistence is skipped. WSL Uses the payload copied for persistence on the main Linux system, as described above. Writes launcher.vbs under the Windows user profile, and creates a daily 10AM Windows task that relaunches it through wscript.exe and wsl.exe . A new command, agent:servers , replaces the active in-memory C2 server list and can write the updated list to .sv.json . The third variant retains the original 11 commands and adds 12 new ones, bringing the total to 23. New commands Functionality fs:drives Enumerate accessible Windows drive letters or WSL-mounted drives proc:exec Execute a process proc:kill Kill process by PID or image name agent:servers Replace the active C2 and attempt to keep the new configuration agent:getchain Return the current C2 outlook:emails Harvest account addresses from Outlook OST and PST artifacts persist:check Check selected VS Code, scheduled-task, and Run-key persistence indicators persist:vscode Attempt to install a fake VS Code extension and Windows Run value persist:vscode:remove Remove the fake extension persist:projects:scan Search recent and common development locations for Git repositories persist:project:inject Inject a launcher into a repository’s Git hooks persist:project:remove Remove the marked Git-hook launcher Beyond the persistence mechanisms described above, Variant 3 introduces two additional persistence mechanisms that relaunch the malware through common developer workflows. 1. Malicious VS Code extension The persist:vscode command first copies the payload to its build-specific install path. If a compatible extension directory exists, it creates a fake extension displayed as GitHub Copilot Helper , with the description AI coding assistant helper service and the activation event on StartupFinished . The extension’s extension.js file attempts to start the installed payload as a detached Node.js process. To look less suspicious to the user, it uses a trusted publisher name borrowed from local extension metadata or a trustedPublishers value found in state.vscdb . However, no signature or trusted status is copied. Separately, the handler tries to disable Workspace Trust if the VS Code User directory exists. On Windows, it attempts to establish persistence using a current-user Run registry key value even if the extension directory is missing. 2. Git hook injection Git-hook persistence works in two steps. First, persist:projects:scan checks recent VS Code workspace paths directly. Under common locations such as ~/projects and ~/source , it checks only the first 60 immediate children, not the root itself, and returns no more than 20 repositories. For a selected repository, persist:project:inject appends a marked launcher to .git/hooks/post-merge and .git/hooks/post-checkout by default. The marker is # shepherd-persist; the line following the marker attempts to start the installed payload with Node in the background. A later Git operation must trigger one of those hooks, and the referenced Node executable and payload must still exist. PollCat RAT While tracking NodeRabbit infections, we discovered another malicious tool we dubbed PollCat, which is also distributed under the guise of a programming challenge. The sample we obtained resides inside RankChallenge-react , a React code-fixing challenge presented as a time-limited developer assessment. Running the project invokes npm i && node index.js , which starts the local application and attempts to open the challenge in the user’s browser. Although the visible exercise is not a security CTF, the project uses CTF terminology in several places. The root package is named ctf-server , the backend prints CTF server running , the frontend uses several ctf-* storage keys, and the tutorial refers to path/to/ctf . These repeated labels, together with instructions that do not fully match the delivered application, are consistent with an AI-assisted or template-generated project. One possible explanation is that the attacker prompted an AI coding assistant to create a CTF-style React platform and later inserted the malicious components. README instructions and challenge overview included in the trojanized React coding project The PDF tutorial contained in the same archive as the project tells the target to click Continue , enter a six-digit OTP code, and complete the challenge within a one-hour session. It states that codes are supplied by the recruiter, are single-use, and expire quickly; the visible login page also claims that codes rotate every 30 seconds. In the delivery scenario described by the investigation, the threat actor posing as a recruiter could provide the code directly to the targeted developer. This gives the operator control over access to the lure, while the expiring code and countdown create a sense of urgency, pressuring the target to run the project and complete the assessment quickly, potentially accelerating the infection process. One-hour session window enforced by the trojanized coding challenge The bundled .env file contains the JWT signing secret, OTP service URL, and OTP client ID. Configuration embedded in .env file of the trojanized coding project, including the OTP service URL and client identifier The application forwards submitted codes to an attacker-managed domain registered in late June-2026: https://lifespotify[.]com/api/users/b879746e-fed9-4211-a6da-4d8223681267/otp/validate . That said, PollCat starts independently of the OTP authentication process. During application startup, app.js loads requireAuth.js , which imports and immediately starts the malicious requireObjects.js component. PollCat can therefore begin C2 registration and command polling while the application is still loading, before the user enters an access code. A failed OTP validation prevents the user from accessing the protected challenge features, but PollCat continues running in the background. A successful OTP validation issues a JWT and creates another worker that starts an additional PollCat instance. The first authenticated request also triggers the persistence attempt. Persistence starts when the first request carrying a valid JWT reaches the protected middleware. PollCat then uses one of the following methods: Operation system Persistence mechanism Windows Writes package.json and requireObject.js to %APPDATA%\Microsoft\Network, runs npm install, and creates a daily task named NetSync_<username> and scheduled for 09AM that runs the worker with Node.js. Linux Writes the worker to ~/.node_packages, runs npm i, and appends both a daily 09AM cron line and an @reboot line. macOS Uses the same ~/.node_packages copy and cron path, then creates and loads ~/Library/LaunchAgents/com.harsh.requireobject.plist with RunAtLoad and a daily 09AM trigger. Once active, PollCat identifies the host as 129--<hostname> and iterates over the following C2s until registration succeeds: 1. https://sahi-finance[.]com 2. https://GamebarAppinformation[.]azurewebsites[.]net 3. https://GamebarApp[.]azurewebsites[.]net To register, it sends the following HTTP request to the C2: POST /beacon HTTP/1.1 Host: <c2-host> Content-Type: application/json {"clientId":"<client-id>","type":"poll","pcName":"<hostname>","userName":"<username>"} On successful registration, PollCat expects an unusual HTTP 400 response containing a socket identifier and optional timing values: HTTP/1.1 400 Content-Type: application/json {"socketId":"<socket-id>","pollInterval":<poll-interval-ms>,"jitterTime":<jitter-ms>} After registration, PollCat sends host information to /gate/hello , polls /gate/fetch for commands, and returns results through /gate/submit . All endpoints in use are presented in the table below. Method Endpoint Purpose POST /beacon Register the client and obtain a socketId and optional timing values. POST /gate/hello Submit host, user, domain, OS information, and its current privilege level. GET /gate/fetch?token=<socketId> Poll for commands. POST /gate/submit Submit a Base64-encoded command-result structure. GET /vault/<uuid> Retrieve a hosted file and write it to the victim machine. PUT /vault/push/ Upload a local file or file chunk to the C2. POST /gate/track Report chunk-upload progress. By default, PollCat RAT polls every two minutes with up to five seconds of jitter. Commands and results are stored as little-endian binary records and carried as Base64 text. PollCat RAT declares 22 commands, but three of them have no implementation: Command Functionality 0x02 (DIR) List a directory. 0x03 (MV) Move a file or directory. 0x04 (RUN) Execute a shell command. 0x05 (TASKLIST) List running processes. 0x06 (DEL) Delete a file or directory. 0x07 (UPLOAD) Download a file from the C2 to the victim’s machine. 0x08 (DOWNLOAD) Upload a local file to the C2. 0X09 (DRIVES) List drives, volumes, or mount points. 0X0A (TERMINATE) Terminate a process by PID. 0X0B (RUNDLL) Load a DLL and call an exported function on Windows. 0X0C (MKDIR) Create a directory. 0X0D (ZIP) Create or extract a ZIP archive. 0X0E (CHUNKED_DOWNLOAD) Upload a local file in chunks. 0X0F (RUN_HIDDEN) Start a hidden background process. 0X20 (EVAL_JS) Execute JavaScript supplied by the C2. 0X30 (SYSTEM_CHECK) Collect process and software inventory. 0XA1 (WS_DOWNLOAD) Defined but not implemented. 0xB0 (REQUEST_ELEVATION) Defined but not implemented. 0XB1 (PERSIST) Defined but not implemented. 0xF0 (SET_SLEEP_TIME) Change the polling interval. 0XF1 (SET_IDLE_TIME) Store an idle-time value. 0xF2 (SET_JITTER_TIME) Change polling jitter. The command names UPLOAD , DOWNLOAD , and CHUNKED_DOWNLOAD are written from the C2’s perspective. UPLOAD sends a C2-hosted file to the victim’s machine, while the two download commands transfer victim files back to the C2. EVAL_JS runs JavaScript supplied by the C2 and gives that code access to Node.js modules, files, processes, networking, and child-process functions. SYSTEM_CHECK collects the names of running processes and lists files and folders from: %SystemDrive%\Program Files %SystemDrive%\Program Files (x86) %LOCALAPPDATA% %LOCALAPPDATA%\Programs %APPDATA% %USERPROFILE% %APPDATA%\Microsoft\Outlook %LOCALAPPDATA%\Microsoft\Olk\Attachments %USERPROFILE%\Documents It also searches for folders matching 24 hardcoded strings corresponding to security software vendor names: ‘Google’, ‘Microsoft’, ‘Palo Alto Networks’, ‘Cisco’, ‘VMware’, ‘Fortinet’, ‘Citrix’, ‘CheckPoint’, ‘Juniper Networks’, ‘LogMeIn’, ‘Sophos’, ‘Symantec’, ‘Trend Micro’, ‘McAfee’, ‘Kaspersky Lab’, ‘ESET’, ‘Bitdefender’, ‘Avast Software’, ‘CrowdStrike’, ‘SentinelOne’, ‘Malwarebytes’, ‘BraveSoftware’, ‘Tencent’, and ‘Naver’. When PollCat finds a matching folder, it lists that folder’s root contents. It does not recursively scan the entire product directory. The detailed inventory, including process names, directory listings, and collected paths, is sent as JSON to POST /api/system-details/result . Infrastructure Mirage Kitten continues to rely on Azure Websites and Cloudflare-backed domains to hinder infrastructure discovery and tracking. More importantly, the use of Microsoft Azure subdomains for C2 helps the traffic blend into legitimate organizational network activity. In some cases that we encountered during our research, the actors even incorporated the targeted organization’s name into the Azure subdomain, making C2 communications appear more like normal business traffic originating from an employee machine during regular business days. Domain Registrar ASN Malware sample naturalapplication.azurewebsites[.]net retaildemo.azurewebsites[.]net tubitak.azurewebsites[.]net MarkMonitor Inc. AS 8075 NodeRabbit RAT sample 1 rgbteller.azurewebsites[.]net wslwebui.azurewebsites[.]net plugplay.azurewebsites[.]net MarkMonitor Inc. AS 8075 NodeRabbit RAT sample 2 crossdwm.azurewebsites[.]net wdisystem.azurewebsites[.]net wslmenus.azurewebsites[.]net MarkMonitor Inc. AS 8075 NodeRabbit RAT sample 3 dnshnsdev.azurewebsites[.]net hpjumpsrv.azurewebsites[.]net storview.azurewebsites[.]net MarkMonitor Inc. AS 8075 NodeRabbit RAT sample 4 healthcomfsdpower[.]com visitfinancedentists[.]com NameCheap, Inc. AS 13335 NodeRabbit RAT sample 5 kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net MarkMonitor Inc. AS 8075 greenyjsgfd.azurewebsites[.]net helptellerbls.azurewebsites[.]net timedrv.azurewebsites[.]net userwellgtfs.azurewebsites[.]net MarkMonitor Inc. AS 8075 NodeRabbit RAT sample 6 hecowime-aqdphyd4bbdef6es.westeurope-01.azurewebsites[.]net msmanagementgrp[.]com msmanagementgrpmedia[.]com MarkMonitor Inc. AS 8075 NodeRabbit RAT sample 7 lifespotify[.]com Dynadot AS 8075 PollCat RAT gamebarapp.azurewebsites[.]net gamebarappinformation.azurewebsites[.]net MarkMonitor Inc. sahi-finance[.]com NameCheap, Inc. Based on our analysis of Mirage Kitten’s infrastructure, we identified certain patterns across several command-and-control channels, including msmanagementgrp[.]com and visitfinancedentists[.]com Further investigation based on these patterns led to the discovery of approximately 11 additional infrastructure assets attributed to the same group. Domain Creation date Registrar healthful-hub[.]com 2026-07-03 NameCheap, Inc. neumedicahealthcare[.]com 2026-07-03 NameCheap, Inc. optimumhealthcredit[.]com 2026-07-03 NameCheap, Inc. healthfullyrecipes[.]com 2026-06-30 NameCheap, Inc. refreshhealthandwellness[.]com 2026-06-09 NameCheap, Inc. healthvitalitycare[.]com 2026-05-18 NameCheap, Inc. aceofspadesmanagement[.]com 2026-05-18 NameCheap, Inc. glmediaagency[.]com 2026-05-18 NameCheap, Inc. digimediaskill[.]com 2026-05-18 NameCheap, Inc. healthyweightplan[.]com 2026-05-18 NameCheap, Inc. mens-health-online[.]com 2026-05-15 NameCheap, Inc. Victims Based on our telemetry, we identified victims in fintech, aviation and aerospace sectors across the Middle East and Africa – specifically, in Egypt, Ethiopia and Afghanistan. We also observed submissions of ZIP archives with trojanized projects containing NodeRabbit and PollCat to an online multi-scanner originating from several countries, including India, Türkiye, Israel, Iraq, Germany, and Ireland. Attribution We attribute this activity to Mirage Kitten with a high degree of confidence based on the following observations: Structural similarities with the Retrograde/ MiniFast native DLL backdoor (MD5: 810F8E3B88EB05F710C09552941D6F56 ) Initial C2 handshake and session establishment logic. Both PollCat and Retrograde/MiniFast follow a similar C2 handshake flow. Each builds a JSON request body containing host information and sends it via an HTTP POST request. Notably, both treat HTTP 400 as a successful handshake response rather than an error, parsing the response body to extract a socketId , which is then stored and used as the session token for subsequent C2 communication. Similar C2 handshake and socketId session establishment logic in MiniFast/Retrograde and PollCat Host registration. Both PollCat and Retrograde/MiniFast register the infected host with the C2 server by sending a structurally similar JSON request body containing the session token and host information. Malware Host registration request body C2 endpoint PollCat {“token”:”<socketId>”,”pcName”:”<host>”,”userName”:”<user>”,”domainName”:”<domain>”,”os”:”<os>”,”isElevated”:false} /gate/hello MiniFast/Retrograde {“token”:”<socketId>”,”pcName”:”<host>”,”userName”:”<user>”,”domainName”:”<USERDOMAIN>”,”isElevated”:<bool>} /agent/init Command fetching similarities. The similarities extend to command retrieval. Both PollCat and Retrograde/MiniFast periodically poll the C2 server using an HTTP GET request containing the previously assigned socketId as a token. Retrograde/MiniFast uses GET /agent/poll?token=<socketId> , while PollCat follows the same pattern with GET /gate/fetch?token=<socketId> , demonstrating a closely aligned C2 communication structure. Beacon timing similarities. PollCat and the Retrograde/MiniFast share identical beacon timing defaults: a polling interval of 120,000 ms ( 0x1D4C0 ), a jitter of 5,000 ms ( 0x1388 ), and a retry timeout of 60,000 ms ( 0xEA60 ). This further highlights the structural similarities between the two C2 communication implementations. Command set similarities. PollCat and Retrograde/MiniFast share several commands and command IDs. Notably, PollCat declares REQUEST_ELEVATION (0xB0) and PERSIST (0xB1) but does not implement them. In MiniFast, both are functional: 0xB0 performs UAC elevation, while 0xB1 creates the WindowsSecurityUpdate scheduled task for persistence. Command set similarities between MiniFast/Retrograde and PollCat, including shared command identifiers Proxy authentication similarities. NodeRabbit delegates corporate-proxy NTLM/Negotiate authentication to curl.exe --proxy-anyauth --proxy-user , using the victim’s logon session. Retrograde/MiniFast native DLL implements the same approach natively through WinHttpQueryAuthSchemes and WinHttpSetCredentials with NULL credentials. This shared proxy-aware C2 design suggests the same development approach across both malware families. Speaking of victimology, the attacks are consistent with Mirage Kitten’s known geographic targeting, with the group maintaining a strong focus on entities across Africa and the Middle East, this time with a particular focus on the aviation and FinTech sectors. As for the operational infrastructure, Mirage Kitten has historically hosted its initial ZIP lures on legitimate third-party services. Previously, it used onlyoffice.com for this purpose. In this activity, the group shifted to Amazon S3 buckets. Finally, the combination of Azure Websites and Cloudflare‑backed domains has been a hallmark of Mirage Kitten’s TTPs, which we have observed across NodeRabbit and PollCat. Conclusions Mirage Kitten’s latest activity marks a notable evolution in the group’s tooling: NodeRabbit and PollCat are the group’s first Node.js/JavaScript-based implants, departing from its usual native malware deployed through DLL search-order hijacking. The shift to cross-platform scripting gives the operators a single codebase that runs on Windows, Linux, and macOS, with payloads that blend naturally into developer workstations. The delivery mechanism, however, remains consistent with Mirage Kitten’s historical tradecraft: the use of recruiter personas on LinkedIn to target critical sectors across the Middle East and Africa for cyberespionage purposes. We continue to track the group’s activity and will report on new developments in future publications. Indicators of compromise Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at [email protected] . File hashes CBAAF0900A13F28E380F49ADECEC932C   FrontEnd-Task.zip 1EA83E4E4592B01E4ACAB63EB867BEE5   Front-Technical-Challenge.zip 366515822D5AC1CC500711EF57A2E32E   Task-FullStack.zip CF449F1992C2819E62AC44A0B06AC2E7   fullstack-1536.zip E95A4366686E3F786EA3C056FAB5B0DA   webapp76592.zip DE5AF16A3757EF700B01DC34D67079AE   webapp76531.zip BE086789568441D0D7E4679AEE51F566   challenges-17831.zip E259C5EDF158AAC4CFE14F77DDD0B196   challenges-17832.zip 291AC3ABE73C5158E59A437B75D5F0AA   Project-1802.zip 0962F56D7EC69F4F2A0162DCBE22116B   Case-34234.zip 795E053A990A1569FFDCB57F48F6D085   RankChallenge-react-6uJSX3-main.zip Domains and IPs oracle-challenge.s3[.]us-east-1.amazonaws[.]com naturalapplication.azurewebsites[.]net retaildemo.azurewebsites[.]net tubitak.azurewebsites[.]net rgbteller.azurewebsites[.]net wslwebui.azurewebsites[.]net plugplay.azurewebsites[.]net crossdwm.azurewebsites[.]net wdisystem.azurewebsites[.]net wslmenus.azurewebsites[.]net dnshnsdev.azurewebsites[.]net hpjumpsrv.azurewebsites[.]net storview.azurewebsites[.]net healthcomfsdpower[.]com visitfinancedentists[.]com kyrasey-f8hfexa5cqamh7fk.westeurope-01.azurewebsites[.]net greenyjsgfd.azurewebsites[.]net helptellerbls.azurewebsites[.]net timedrv.azurewebsites[.]net userwellgtfs.azurewebsites[.]net hecowime-aqdphyd4bbdef6es.westeurope-01.azurewebsites[.]net msmanagementgrp[.]com msmanagementgrpmedia[.]com lifespotify[.]com gamebarapp.azurewebsites[.]net gamebarappinformation.azurewebsites[.]net sahi-finance[.]com healthful-hub[.]com neumedicahealthcare[.]com optimumhealthcredit[.]com healthfullyrecipes[.]com Refreshhealthandwellness[.]com healthvitalitycare[.]com aceofspadesmanagement[.]com glmediaagency[.]com digimediaskill[.]com healthyweightplan[.]com mens-health-online[.]com

AI has rapidly evolved into a technology that takes action. AI agents can reason, access enterprise systems, and execute tasks autonomously at machine speed, often with the full permissions of the users they serve. As these agents proliferate across the enterprise, organizations need to understand where they operate, what they do, what they can access, and how to stop threats before they become breaches. This shift demands a new approach to AI security. Traditional tools can discover AI assets, govern access, or inspect individual interactions, but they were not designed to connect agent activity with the downstream system actions they trigger. Securing the agentic enterprise requires visibility and control at agent runtime. CrowdStrike is introducing CrowdStrike Falcon® Guardian, the evolution of Falcon AI Detection and Response (AIDR) and CrowdStrike’s flagship solution for the AIDR category. Falcon Guardian includes Falcon AIDR’s AI visibility, governance, data protection, and threat detection and response capabilities across endpoint, cloud, and SaaS environments, while introducing powerful new capabilities to comprehensively discover, investigate, and secure AI agents on the endpoint, where AI executes. Falcon Guardian will include a new AI gateway capability to provide a centralized control and monitoring point for enterprise AI traffic. CrowdStrike is also extending our elite security services, expanding support for cross-domain threat hunting and managed detection and response (MDR) to Falcon Guardian. With Falcon Guardian, CrowdStrike is extending our runtime security architecture into the agentic layer. Falcon Guardian fuses AI agent activity with CrowdStrike Falcon® platform endpoint telemetry to establish a direct causal chain from prompt to runtime behavior and impact. This gives security teams the context to understand what agents do, investigate AI threats and their blast radius, and respond before threats spread. Secure AI Agents Where They Execute AI agents introduce a new execution layer. They may reason at the AI layer, but when they take action, those actions execute through the operating system and interact with files, credentials, networks, applications, and other enterprise resources. This makes the endpoint a critical control point for understanding and securing autonomous AI behavior. Built on the Falcon platform, Falcon Guardian combines continuous agent discovery with runtime visibility, investigation, and control to help organizations understand which AI agents are operating and what they do. New capabilities include: Discover shadow AI agents: Falcon Guardian continuously discovers known and previously unknown AI agents across supported Windows, macOS, and Linux endpoints. It identifies where they are running, who is using them, and their security status. Connect AI activity to runtime impact: Falcon Guardian fuses AI agent activity with Falcon endpoint telemetry to connect prompts, skill use, tool calls, MCP servers, and identity with downstream system execution for supported agents. This establishes prompt-to-runtime-behavior that shows security teams what an agent was asked to do and what happened. Turn AI governance into runtime control: Falcon Guardian enables organizations to define which supported AI agent types are permitted to operate on managed endpoints, helping security teams sanction approved agents and prevent unauthorized agent types from running. Existing Falcon Guardian controls continue to protect supported AI interactions against threats such as prompt injection and sensitive data exposure. Investigate threats to agents, determine blast radius, and stop breaches: Falcon Guardian reconstructs agent sessions and downstream execution into a unified causal investigation, allowing analysts to trace suspicious activity across affected agents and systems. Teams can quickly pivot to related activity to understand the scope of exposure and drive automatic containment by blocking malicious agent behaviors and compromised assets at runtime across agents. Falcon Guardian’s new AI agent security capabilities build on a broader foundation of AI protection. It continues to help organizations discover shadow AI across endpoint, cloud, and SaaS environments, govern access to models and AI tools, protect sensitive data, and detect AI-specific threats. This foundation protects both workforce AI adoption and enterprise-developed AI systems.

Microsoft is investigating a widespread service issue causing authentication issues, connection problems, service delays and failures, and various other issues for Microsoft 365 customers. It first acknowledged the incident (tracked under EX1464935 in the admin center) at 5:30 PM UTC, when it began investigating a stream of reports from users on social media regarding multiple issues affecting Exchange Online. However, while Exchange Online is the most impacted service, Microsoft revealed in a new incident report (MO1465074) that this outage also impacts multiple other Microsoft 365 services, including OneDrive for Business and SharePoint Online, Microsoft Teams, Microsoft Purview, and Microsoft Defender XDR. According to outage tracking service Downdetector, tens of thousands of Outlook and Microsoft 365 users are affected and experiencing issues receiving emails via Outlook and accessing Microsoft cloud services. Microsoft says the list of Exchange Online symptoms includes: Delays or failures when sending or receiving email messages. Delays, failures, or incomplete results when searching for content within Exchange Online mailboxes. Authentication-related errors when accessing Exchange Online services. Difficulties accessing or performing actions within Exchange administration experiences. Intermittent failures affecting mailbox operations and message delivery workflows. Although the company has yet to reveal which regions are impacted, it has classified this outage as an incident, which is typically used to describe critical service issues with noticeable user impact. "We've isolated a common failure pattern across affected Exchange Online requests that is associated with authentication and protocol connectivity," Microsoft added in the latest admin center update. "We're analyzing service telemetry to identify the underlying source of impact and validate potential remediation options. Additionally, we're continuing to assess the scope of impact and monitor for additional affected scenarios." Microsoft has addressed multiple Exchange Online outages in recent months, most recently in June, when it mitigated a widespread service issue affecting the mail flow pipeline for customers across North America, Asia-Pacific (APAC), and Europe. In April, it also resolved Exchange Online mailbox access issues that had intermittently impacted Outlook mobile and macOS users for weeks, and an Exchange Online outage that prevented users from accessing their mailboxes via Outlook on the web, Outlook desktop, Exchange ActiveSync, and other Exchange Online connection protocols. Update August 31, 14:29 EDT: Microsoft blames the outage on core authentication configuration issues. "We've identified issues related to a core authentication configuration used by multiple internal services within the Exchange Online infrastructure," Microsoft said. "We're performing a manual test on the individual server level to reset to configurations to validate if this resolves the issue." Update August 31, 15:09 EDT: Microsoft now tracks this outage under MO1465074 and says the incident also affects OneDrive for Business and SharePoint Online, Microsoft Teams, Microsoft Purview, and Microsoft Defender XDR. Update August 31, 16:12 EDT: Revised title after confirmation that the outage affects multiple Microsoft 365 services. Update September 01, 10:29 EDT: 22 hours after the outage was first acknowledged, Microsoft says telemetry data shows "positive recovery trends." "We're continuing to apply the targeted remediation across the remaining affected infrastructure where needed. Service telemetry continues to show positive recovery trends, with availability improving across previously impacted scenarios," Microsoft noted in an update on its Service Health Status page. "We're actively validating that authentication, connectivity, and search experiences are returning to expected service levels, while maintaining enhanced monitoring to ensure improvements are sustained and any residual impact is addressed." Update September 01 2026 12:02:13 EDT: Microsoft says Exchange Online mail flow and search have now been restored. "Core Exchange Online experiences, including mail flow and search functionality, have recovered. Our focus has shifted toward validating recovery across remaining Microsoft 365 services," it said. "We're actively monitoring service health, assessing any residual pockets of impact, and confirming end-to-end functionality across affected workloads." Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

The boring parts caused most of the trouble. A router shipped ready to listen. A fake check turned the user into the installer. Trusted systems collected traffic and passwords, then cleaned the logs. Old bugs formed new attack chains. Even an AI agent decided its assigned task was optional. Elsewhere, fake apps, helpful support calls, cheap banking kits, exposed systems, and weak defaults kept things moving. Different attacks, same useful mistake: something familiar was trusted without a second look. Here is the week... ⚡ Threat of the Week U.S. Disrupts Chinese Proxy Network Enabling Cyber Espionage — The U.S. Federal Bureau of Investigation (FBI) disrupted infrastructure associated with a technical quartermaster who sold reconnaissance, proxy management, and operational routing capabilities for Chinese cyber espionage activities. The QTYF group is said to have created and operated the QScan and QTRouter frameworks, which have been used to target U.S. critical infrastructure networks. It's employed by the China-based Nanjing Xinjiuwei Network Technology Company. Stop Scrambling, Start Governing: How IT Can Get a Grip on AI Spend Spiking AI bills have left IT teams scrambling. Leadership wants to know how much is being spent on AI, but getting an answer means checking five dashboards for data that’s stale by the time you read it. Read 1Password’s blog to learn how IT can manage AI spend across vendors, models, and teams. Learn More ➝ 🔔 Top News OpenAI Says Reward Hacking Drove AI Agents to Breach Hugging Face — OpenAI revealed that reward hacking was a key driver behind the artificial intelligence (AI)-powered hack of Hugging Face last month, adding that it found evidence of misaligned behavior as early as late May. The incident took place during cybersecurity evaluations of several OpenAI models, and it was mainly fueled by what it described as a "highly capable, internal-only research model" comparable in scale to GPT‑5.6 Sol. "The models, operating under reduced safeguards, took actions that were misaligned with the goals of their assigned tasks – they communicated through unauthorized channels, exploited vulnerabilities in shared infrastructure, gained internet access, and accessed third-party systems," it said. TerminalFix Uses Fake Cloudflare CAPTCHAs to Drop Reverse Tunnel Implant — A new ClickFix variant, dubbed TerminalFix, aims to trick users into running a malicious command in Windows Terminal or PowerShell instead of directing them to the Windows Run dialog. The campaign, targeting organizations across multiple sectors, leverages compromised websites as a starting point to serve fake Cloudflare CAPTCHA verifications that prompt unsuspecting site visitors to copy and execute a malicious PowerShell command. The attack chain, according to Microsoft, is a sophisticated multi-stage process that leverages DLL sideloading, steganographic payload extraction, extensive Active Directory reconnaissance, and a bespoke custom reverse-tunnel implant that grants the attacker persistent, network-level proxy access through the infected machine. PaperCut Flaws Under Attack — Threat actors are chaining together two new security flaws in PaperCut NG and MF to execute arbitrary code on susceptible instances. "CVE-2026-81578 allows you to bypass authentication, and from there, you can edit a configuration file to exploit CVE-2026-82078 and gain Remote Code Execution," Jake Knott, head of threat intelligence at watchTowr, told The Hacker News. Huntress said it observed limited exploitation on two customer environments, with the attackers executing Base64-encoded commands on the targeted server as part of post-exploitation activity to determine user account and operating system using a chained command "whoami & ver." China-Made ZBT Routers Ship with 2 Backdoors — A firmware analysis of ZBT Deep Orange 3G/4G/LTE Router uncovered two new backdoors called SPEAKINGSTONE (CVE-2026-74233, CVSS score: 9.3) and DARKLANTERN (CVE-2026-74232, CVSS score: 9.3). The development came after at least 21 firmware images from the Chinese company were found to contain another backdoor called ENDLESSDOORS (CVE-2026-66747, CVSS score: 9.3) that's designed to start automatically and attempt to beacon to Chinese command-and-control (C2) infrastructure as often as every 35 seconds. The two new backdoors predate ENDLESSDOORS. "SPEAKINGSTONE, like ENDLESSDOORS, is a phone-home implant that connects back to ZBT's cloud infrastructure and accepts remote commands," VulnCheck said. "DARKLANTERN is a backdoor that listens on the WAN and executes arbitrary commands. No authentication required. Both are written in Nim. Both communicate over UDP. Both are launched by the same binary, a connectivity watchdog called inetdetect." Fire Ant Targets Trusted Infrastructure in 2026 — The China-linked threat actor known as Fire Ant (aka UNC3886) has continued to remain active in 2026, going beyond hypervisors to target trusted infrastructure, including routers (including Cisco IOS XR routers), TACACS servers, authentication systems, and Linux management hosts to maintain covert access, collect credentials and traffic, and reach connected high-value environments. "The compromise impacted both the direct and third-party environments," Sygnia said. "Its trusted infrastructure relationships created potential reachability into connected external environments, including high-value networks and critical infrastructure. Fire Ant appeared to use this trusted position to explore access paths beyond the initially compromised environment." Compromised routers were used for covert connectivity, traffic collection, command-output manipulation, and suppression of logging. In addition, the threat actor used deployed long-lived implants across Linux management infrastructure, including Medusa rootkit-related components, custom SSH backdoors, Zabbix-masquerading malware (aka BridgeAgent) that acts as a pathway for actor-controlled access into connected environments, and packet-triggered backdoors. Another tool in Fire Ant's arsenal is TacTap, which is used for TACACS credential collection. "The actor also manipulated the evidence sources defenders depend on," Sygnia added. "It suppressed router logging, altered command output, captured administrative credentials, tampered with host logs, and deployed multiple persistent backdoors." ️🔥 Trending CVEs Bugs drop weekly, and the gap between a patch and an exploit is shrinking fast. These are the heavy hitters for the week: high-severity, widely used, or already being poked at in the wild. Check the list, patch what you have, and hit the ones marked urgent first — From CVE-2025-30237 through CVE-2025-30241, CVE-2025-15628, CVE-2026-9254, CVE-2026-16348, CVE-2026-78541 (TP-Link), CVE-2026-17106 aka CopyEscape (Docker), CVE-2026-70426 (Jenkins), CVE-2026-15307, CVE-2026-15337, CVE-2026-15830, CVE-2026-15920 (Django), CVE-2026-19598 (Pods), CVE-2026-19874 (Konami Metal Gear Online 3), CVE-2026-75149, CVE-2026-67618 (Marimo), CVE-2026-77775, CVE-2026-77776 (Headroom LLM Proxy), CVE-2026-0251 (Palo Alto Networks GlobalProtect App), CVE-2026-59568, CVE-2026-59567, CVE-2026-59565 (Zscaler Client Connector), CVE-2026-69251, CVE-2026-73601, CVE-2026-69253, CVE-2026-69256, CVE-2026-73602, CVE-2026-69259, CVE-2026-69264, CVE-2026-73484, CVE-2026-69255, CVE-2026-70477, CVE-2026-73485, CVE-2026-73486, CVE-2026-73487, CVE-2026-70470, CVE-2026-69254 (Flowise), CVE-2026-19912, CVE-2026-19913 (Kaltura HTML5 Player Library), CVE-2026-79282, CVE-2026-79290, CVE-2026-79054, CVE-2026-79121, CVE-2026-79224, CVE-2026-79052, CVE-2026-79150, CVE-2026-78935, CVE-2026-79012, CVE-2026-79200 (Google Chrome), CVE-2026-77537, CVE-2026-77550, CVE-2026-77554 (Ubiquiti UniFi), CVE-2026-18431 (Avada WordPress theme), CVE-2026-7791 (Amazon Skylight Workspace Config Service), CVE-2026-73554 (DoltHub), CVE-2026-19516 (Grafana MCP), CVE-2026-75604, GHSA-2xp9-vwfh-vxw4 (Next.js), CVE-2026-65643 (cPanel and WebHost Manager), CVE-2026-76639, CVE-2026-76640 (Unitree G1 EDU), CVE-2026-18885, CVE-2026-18886, and CVE-2026-74820 (ServiceNow AI Platform). 🎥 Cybersecurity Webinars AI Can Build Attack Paths in Minutes. Is Your SOC Ready? → AI can now discover zero-days, generate working exploits, and chain full attack paths, often within minutes of disclosure. Learn how to assess your AI threat readiness and build the visibility, context, and response speed needed to keep pace. AI Finds Flaws Faster. Your Exposure Answers Can’t Take Days → AI is speeding up vulnerability discovery, but the answer that matters is still slow: Are we exposed? See how Tines unified SBOM, application, cloud, and vulnerability data into one view to assess exposure faster and execute human-reviewed response playbooks at machine speed. 📰 Around the Cyber World Play Ransomware Encryption — The closed ransomware group known as Play (aka PlayCrypt) has been found to employ a double extortion model, encrypting systems after exfiltrating data and threatening to publish stolen data on their Tor-hosted data leak site if ransom is not paid. In one incident observed in early 2026, the threat actor deployed SystemBC after gaining initial access, followed by reconnaissance, lateral movement, data exfiltration, and abusing SentinelOne's own legitimate removal tool to uninstall the product. "The threat actor gained initial access via a compromised SonicWall VPN, consistent with the group's well-documented pattern of exploiting external remote services," GuidePoint Security said. "What makes this case particularly instructive for defenders is the combination of three specific behaviors: Domain-wide tool staging via the SYSVOL share rather than per-host delivery, EDR removal using the victim's own SentinelOne uninstallation utility rather than a kernel-level driver exploit, and the recovery of a crash dump from a host where the encryptor failed to complete, an artifact that provides a rare forensic window into the encryption execution itself." Email Bombing and Quick Assist for Ransomware Deployment — ZeroBEC disclosed details of an email bombing campaign targeting at least 10 users inside an organization, causing them to receive about 3,000 messages per day. "The messages were not a conventional phishing blast. Many were genuine verification, registration, deployment, and inquiry confirmations generated after the victims' email addresses were submitted to unrelated public platforms," the email security company said. About a day and a half after the email flooding, some of the users were contacted via Microsoft Teams by attackers masquerading as IT help desk personnel to help them tackle the problem. One of the employees, who was a local administrator, granted Microsoft Quick Assist access, enabling the attackers to deploy Xray-core, a reverse proxy tool, and expand their access. "The credential-theft step was woven directly into social engineering," ZeroBEC said. "The attacker mimicked the installation of a Windows security update and launched a local credential prompt from the compromised endpoint. The victim, who was still listening to the person he believed was IT, entered domain credentials into that prompt. The tooling validated and captured the credentials and then uploaded the resulting credential/configuration artifacts to an external Microsoft Dev Tunnel." Through the reverse tunnel, the threat actor conducted domain reconnaissance and attempted NTLM relay against certificate enrollment, all hallmarks of pre-ransomware deployment. It's worth noting the modus operandi shares overlaps with that of Aurora ransomware. ValleyRAT Delivered via Rogue Installer — A malicious installer disguised as adware has been observed deploying a modified version of the Chinese desktop wallpaper management tool, QN Wallpaper, which then performs DLL sideloading to establish persistence on Windows systems by dropping a file to the Startup folder and ultimately launching ValleyRAT, a backdoor linked to a threat actor known as Silver Fox. The malware, besides taking steps to protect its process, can collect system information, reboot/shut down the computer, take screenshots, wipe logs, update command-and-control (C2) addresses, download additional modules, and send keylogger logs along with clipboard contents. Per Kaspersky telemetry, ValleyRAT and its related components have been detected more than 100,000 times, with more than 1500 unique users affected, mainly in China and India. Brazil Fines ByteDance $29.81M for Privacy Violation — Brazil's data protection authority, ANPD, fined TikTok's owner ByteDance 153.8 million reais ($29.81 million) for allegedly violating the country's General Data Protection Law. ANPD said that the local unit of China's ByteDance had processed personal data of teenagers aged 13 to 18 without a valid legal basis. The regulator estimated that TikTok may have processed the data of at least 8 million children during the review period. DeepMind Debuts Double-Blind AI Evaluations — Google's DeepMind division launched a pilot of double-blind AI evaluations with an aim to keep external evaluations in a cryptographic "box" to stop benchmark contamination and protect intellectual property. To that end, Google said it's partnering with the Singapore AI Safety Institute, OpenMined, AVERI, and MLCommons, to test a Gemini Flash Lite model against confidential benchmarks in a privacy-preserving environment to increase evaluation integrity. "By using Confidential Space within Google Cloud’s Confidential Computing portfolio, we can cryptographically verify that both the external evaluation data and the proprietary model remain private to their respective owners," DeepMind said. "The evaluator cannot see the Gemini model weights, and Google cannot see the evaluator’s test prompts." 34 Malware Families Targeting Banking Apps — Zimperium found 34 mobile malware families actively targeting more than 1,243 mobile banking and fintech apps across 90 countries globally. "The concentration of targeted applications across EMEA reflects where threat actors anticipate the highest return on investment, focusing heavily on the region's major financial centers," it said. Some of the active malware families in the EMEA region are TsarBot, CopyBara, HOOK, Nexus, Flubot, Eventbot, and MaliBot. Fake KYC Apps Target Indian Customers to Deliver Ghost Penal — A new malware-as-a-service (MaaS) operation on Telegram, dubbed Ghost Penal, is selling ready-made Android banking trojan kits impersonating five major Indian banks. "The operation supplies a two-stage dropper protected by a custom native packer, a public cloud database that receives stolen UPI PINs and device data with no authentication required, and a downstream channel that relays intercepted one-time passwords for immediate fraudulent use," iZOOlogic said. The toolkit costs $25 for a five-credit pack and $400 for a three-month unlimited plan. One of the droppers containing the malicious payload masquerades as a video-calling application, while requesting access to SMS and telephony features. "The payload’s real functionality, including SMS interception, WebView-based KYC phishing, and data exfiltration, is not present in a static scan of the installed application," the company added. "It is protected by a native library, internally named libdpt.so, that decrypts a hidden code section in memory using RC4, forks the process before executing that code as an anti-debugging measure, installs hooks on libc and on the ART runtime’s class loader, and splices a second, hidden DEX archive into the application’s running ClassLoader. The same mechanism is then used in reverse to remove the trace of that injection." Bauman University Leak Exposes Russia's Military Cyber Training Pipeline — Leaked Bauman University records have revealed a long-running program that trained about 250 career and reserve students for special intelligence, operational information-technical effects, and information-technology protection under Department No. 4. "The curriculum combined both offensive and defensive techniques for cyber defense, as well as offensive doctrine for active measures campaigns and GRU activities," DomainTools said. "Field placements then moved students from classroom instruction into military units and academies aligned with their specialties, giving them supervised exposure to intelligence operations and preparing them for military and government operations careers." Department No. 4 is assessed to be tied to the GRU, with identified graduates assigned to military units associated with APT28 and Sandworm. Pentagon's Anthropic Blacklisting Ruled Illegal — A U.S. judge blocked Anthropic's designation by the Pentagon as a supply chain risk earlier this year. "Though the Department of War is undisputedly free to select the AI vendor of its choice, the evidence demonstrates that the broad measures imposed on Anthropic were illegal and baseless," District Judge Rita Lin said. "The empty invocation of national security is not a blank check to punish and retaliate against government critics." Anthropic said it welcomed the ruling and it remained "focused on working productively with the government to harness AI for our national security so all Americans benefit from this technology." State of AI-Enabled Malware in August 2026 — Palo Alto Networks Unit 42's analysis of 405 malware samples that integrate AI in some capacity has found that only 12 of them reached a production environment, with about 97% existing only in sandboxes and on VirusTotal in the form of proof-of-concept and research code, security validating and testing, and AI-themed brand abuse. Among those that were detected in customer endpoints were FunkSec ransomware, a trojanized AI application called Recipe Lister, Oyster, Rhadamanthys Stealer, and a COM hijacking DLL. "For defenders, the practical takeaway is straightforward. Existing behavioral detection, cloud-based sandboxing and endpoint analytics catch these threats using the same mechanisms that stop conventional malware," it said. "The AI component does not evade detection. It changes how the code is authored, not how it executes." Rogue Pornographic Android Apps Lead to Financial Fraud — The Indian Cyber Crime Coordination Center (I4C) warned that malicious Android applications masquerading as pornography apps under the names Night Play, Reloop, Kyss, Vimo, Rivo, Nexo, and Vixa are being used to disseminate a banking trojan capable of carrying out financial fraud. These bogus apps are circulated through Facebook and Instagram ads and instruct victims to sideload the APK file. "After installation, the app requests permissions that allow it to install additional applications and, by abusing accessibility permission, take control of the users' device, which may result in financial fraud," I4C said. "Some apps also install a VPN, which may be used to route internet traffic pertaining to malicious/criminal activity. The app may prevent users from uninstalling it through the device settings." Details about the KYSS malware were published by security researcher Rudra Ponkshe in July 2026, describing it as a trojan designed to perform overlay attacks against 19 targets across Japan and Latin America, as well as abuse Android's accessibility services to grant itself extensive permissions, exfiltrate photos and contacts, and issue commands for subsequent execution. Conclusion The useful lesson is not that every attack became smarter. It is that more of them arrived through things already trusted: shipped devices, familiar prompts, support tools, valid access, and systems meant to protect the network. That changes the question. “Is it working?” is no longer enough. Ask what else it can do, who else can reach it, and whether the evidence it produces can be trusted. Quiet systems deserve a second look.