Your Windows is watching you. The US Justice Department's complaint against Peter Stokes for alleged involvement in the Scattered Spider hacking group offers a reminder that it's difficult to hide online activity from Microsoft's operating system (or any other). Scattered Spider, according to US authorities, targeted numerous companies in the US by compromising employee accounts in order to access more than 100 corporate networks and exfiltrate or encrypt data that would be ransomed for payment. The group is said to have obtained over $100 million in ransom payments. The complaint, arrest, and extradition of Stokes relied in part on a Microsoft Windows Global Device Identifier (GDID), among other telemetry records, to link online activity to the suspect. "According to a Microsoft representative, a Global Device Identifier in the Windows ecosystem is a persistent, device-level identifier designed to uniquely identify an installation of a Windows operating system on a device, either a physical device (e.g., a mobile phone or laptop) or virtual machine, across certain Microsoft services and scenarios," explained FBI special agent Ali Sadiq in an affidavit accompanying the DOJ's criminal complaint. The court filing also notes that Microsoft made criminal referrals to the DOJ implicating Stokes. It points to an October 2024 referral that cites online service telemetry that company security researchers believe linked Stokes to other hacking group members. Social media posts relevant to Scattered Spider, supposedly sent and received by Stokes, look unlikely to help his defense. The affidavit says that members of Scattered Spider used a web tunneling tool called ngrok to avoid network barriers and maintain access to compromised servers, as well as a VPN service called Tzulo. Investigators obtained IP address records from ngrok and the VPN provider and then obtained records from Microsoft that matched the time when that ngrok account had been set up on a Windows machine through a specific GDID. "According to Microsoft records, on or about May 12, 2025, at 19:21 UTC – when, according to ngrok records, the ngrok account was created – the device with the GDID accessed, among other ngrok pages, 'https://dashboard.ngrok.com/signup,' the ngrok page to set up an ngrok account," the affidavit explains. Microsoft's GDID records also showed that the Windows device with that GDID accessed Tzulo servers assigned to the IP address identified by ngrok. And the GDID was subsequently linked to an IP address in Estonia where Stokes resided. The Windows GDID, or at least the infrastructure for it, is said to date back to the release of Windows 10 in 2015. The GDID itself doesn't show up much in online documentation until 2021 or thereabouts. According to a developer writeup posted to GitHub, wlidsvc (Microsoft Account service) provisions the device with login.live.com and gets back a device PUID. The identifier is then stored in the registry. The Connected Devices Platform (cdp.dll / CDPSvc) reads it and registers it into the Device Directory Service (DDS) graph. And after that, Delivery Optimization reports it as the documented UCDOStatus.GlobalDeviceId. Apple maintains similar identifiers, including a hardware UUID and a DSID (Destination Signaling Identifier) [PDF] tied to iCloud, among others. Linux also supports a machine-id. And when presented with a lawful demand for information, most service providers will cooperate and provide whatever information they store. ®

EXCLUSIVE There's no honor among thieves as a new worm steals from other infectious software. It pilfers “multiple” victims’ credentials and mines for cryptocurrency while killing competitors’ processes, including similar secret-harvesting malware. It’s called Cloud AI Infrastructure Attack Framework (CAI), and it’s a centralized botnet that targets cloud-native developer tools like Docker, Kubernetes, Redis, etcd, Kubelet, and Ray for credential theft and cryptomining. The scripts “are heavily inspired” by the likes of other similar credential-stealing worms that have wreaked havoc across cloud environments and supply chains this year, “using code comments like ‘PCPJack-aligned,’” according to security researcher Michael R. “CAI explicitly seeks out and kills TeamPCP and PCPJack processes, to further monopolize on compromised targets,” he posted on X. TeamPCP is the malware-developing crew behind the mini Shai-Hulud, Miasma, and Canister worms that have been poisoning open source registries and harvesting cloud access tokens, credentials, API keys, and other sensitive data since the Trivy supply-chain attack earlier this year. And PCPJack is a newer secret-stealing copycat worm that not only nabs credentials, but also deletes TeamPCP artifacts to kick that competitor out of victims’ cloud infrastructure. CAI seems to have taken lessons from both. “CAI is a constantly evolving framework meant to rival toolkits utilized by TeamPCP and PCPJack,” Hunt.io threat researcher Michael Rippey told The Register. Hunt.io’s team was the first to spot CAI on June 15, when it observed the first of three open directories via the security shop’s web-scanning engine, AttackCapture, that were linked to the operator. “Over three weeks, the operator moved from testing worm code mimicking TTPs used by PCPJack, to full production, deployment and compromise of networks,” Rippey said. “The codebase shows signs of LLM-assisted development, reflecting a deliberate progression of someone studying what works to build a competitive platform.” While the malware isn’t “overly sophisticated,” it is effective, with recent command-and-control logs confirming “active exploitation attempts, with wallet activity confirming multiple successful compromises,” Rippey said. CAI’s framework consists of a “scanning engine [that] feeds targets into automated exploit queues, with centralized C2 control coordinating attacks across cloud infrastructure with an emphasis on Docker, Redis, etcd, Kubelet, and more,” he added. “Currently, compromised hosts receive miners, credential stealers, and a Python backdoor,” Rippey said. “CAI’s emergence alongside TeamPCP and PCPJack indicates a growing number of competing threat actors targeting each other and cloud infrastructure.” Defenders and developers alike should take note, as we’ve already seen the damage that these new-ish cloud worms leave in their wake as they burrow across supply chains. Plus, it’s unlikely that this will be the last of the miscreants seeking to monetize companies’ cloud infrastructure and developers’ secrets.®

Cybercriminals are using fake IT support calls on Microsoft Teams to persuade employees to surrender control of their PCs before installing the EtherRAT remote access trojan, according to researchers at Palo Alto Networks' Unit 42. Victims receive a phishing email disguised as an employee survey before a follow-up Microsoft Teams call from someone claiming to be IT support. During the call, the attacker persuades the target to hand over remote control and install legitimate remote administration tools such as HopToDesk or AnyDesk. An MSI package is then downloaded, which installs the EtherRAT malware. "We've seen in the logs of the User's session the Title 'System Administrator (External unfamiliar) | Microsoft Teams'; the External unfamiliar tag indicates a contact from outside the organization with no trusted relationship," Unit 42 threat researcher Brian Janower wrote. "Microsoft Teams audit logs confirm the actor initiated a cross tenant OneOnOne chat from the attacker controlled account." EtherRAT is a Node.js RAT that runs across Windows, Linux, and macOS, giving attackers the usual menu of post-compromise tricks: running commands, stealing data, manipulating files, and maintaining access. Instead of hardcoding where it phones home, the malware fetches an active command-and-control server from an Ethereum smart contract, with a conventional domain kept in reserve if that doesn't work. The RAT has previously been linked to attacks exploiting the React2Shell vulnerability and has since appeared in campaigns involving multiple threat groups. Unit 42's research also highlights a potentially useful forensic artifact from this latest campaign. According to Janower, Teams creates files beginning "CtrlVirtualCursorWin_*" during remote control sessions, giving defenders another indicator that an attacker was actively operating a victim's desktop. Researchers also found what appears to be an open directory containing EtherRAT versions 1 through 9. With samples updated as recently as June 26, the repository suggests the operators are continuing to develop the malware. The campaign is the latest example of attackers turning Microsoft's collaboration platform against its users. Last month, researchers found DragonForce operators disguising command-and-control traffic as legitimate Teams communications after compromising a victim's network. In this case, Teams is abused much earlier in the intrusion, with attackers simply using fake IT support calls to persuade employees to open the door themselves. ®

During a 48-hour period from June 7 to 8, developer Charles Jones's Google Cloud account registered $11,089.77 in charges - most related to the use of Gemini image-generation models. Yet Jones, a solo developer who runs programmatic SEO and insurance sites, told The Register that he doesn't have any workflow that generates AI images. Google suspended his account anyway. A suspension notification sent to Jones on June 7 justified the decision by stating his account "was engaged in abusive activity consistent with hijacked resources." "The root cause was attributed to a compromised firebase-adminsdk service account key," said Jones, who provided The Register with documentation of his exchanges with Google Cloud support. The notification advised Jones to report his concerns if he believed the account was compromised by a third party. He did so and took the steps required by Google to have his account reinstated. He disabled the service account and revoked the key. But the Google Cloud billing team has repeatedly refused to forgive the charges. As we reported previously, complaints about charges arising from fraudulent API key usage among Google Cloud customers are not uncommon. In February, a developer based in Vietnam claimed that a Google Cloud API key compromise had resulted in more than $82,000 in charges over 48 hours. A similar report claiming more than $10,000 in fraudulent charges surfaced a month later on Reddit. Regardless of where the fault lies – insecure practices by developers or insecure Google infrastructure – Google may choose to hold developers liable for unauthorized charges, even if the credit-card issuing bank has reversed the charge as fraudulent. At the same time, Google still hasn't publicly released a mechanism to cap Google Cloud spending. The company introduced Spend Caps for certain services as a private preview but hasn't made the service generally available. Other cost-limiting measures, like API-specific usage limits "aren't designed to act as a project-wide spending cap." Similarly, Budget Alerts "don't automatically prevent the use or billing of your services when the budget amount or threshold rules are met or exceeded." Google provides a workaround by allowing Budget Alert notifications to disable cloud billing, but warns that doing so means "resources might be irretrievably deleted." In March, Google introduced project spend caps for the Gemini API as an experimental feature, but at the same time the company said that spend caps have a 10 minute delay and customers are responsible for spending during that period – so the company's definition of cap is rather flexible. What's more, Google said its system "now automatically upgrades you to the next [usage] tier as your usage grows and your payment history matures." And higher tiers raise spending caps. This all means it can still be a challenge for Google Cloud customers to avoid unbounded financial obligations in the event of an account or API key compromise. Escaping that responsibility requires engaging with Google customer service in an opaque appeals process in which the company isn't required to demonstrate customer negligence or an audit trail. "Here's a question I can't get answered, and I think it's central to the whole pattern," Jones said. "Google's Trust & Safety was quick to alert me that a service account key was compromised — but I have been given no route, anywhere, to see HOW or WHERE that key was actually exposed. There is no trace, no log path, no forensic detail offered." Jones said he was the only person who had access to the VM where the compromised key resided and he insists that he followed the company's recommended security practices. "So how does a single-access VM produce a leaked service account key — and why is the burden on me to prove I secured something Google itself can't (or won't) show me how I failed to secure? Google is invoking its Shared Responsibility Model to deny the refund, but that model assumes a customer security failure Google has never demonstrated." The Register twice asked Google why it would deny a refund and what evidence it has that supports that decision. We've not heard back. ®

Attackers have been caught exploiting a critical flaw in Oracle E-Business Suite's Payments module just six weeks after Oracle patched it – and before any public proof-of-concept exploit was available. Researchers at Defused said they observed the first known exploitation of CVE-2026-46817 on June 27. The attackers were targeting the Oracle Payments File Transmission component in E-Business Suite releases 12.2.3 through 12.2.15, they said. The vulnerability, fixed in Oracle's May Critical Patch Update, carries a CVSS score of 9.8 and allows unauthenticated attackers to read arbitrary files from vulnerable servers. According to Defused, the activity didn't look like the indiscriminate internet scanning that often follows disclosure of a critical bug. Instead, its honeypots recorded just six exploitation attempts from a single source, all using what appeared to be a working exploit. The requests sought to retrieve sensitive files from the target system, suggesting the operator was testing or validating the technique rather than casting a wide net. The researchers said exploitation began before any public exploit code had surfaced, pointing to an attacker who had either reverse-engineered Oracle's patch or obtained a private exploit. The Shadowserver Foundation said it currently sees around 950 EBS instances exposed to the public internet, the majority in the US, although it stressed that figure says nothing about whether they're vulnerable or fully patched. The observed exploitation fits a pattern that's becoming increasingly familiar. Earlier this month, researchers warned that attackers had exploited a critical PeopleSoft zero-day before patches were widely deployed, with the ShinyHunters crew claiming to have compromised more than 100 organizations. They also boasted of having stolen HR and payroll data. This latest incident also follows Clop's lengthy campaign against Oracle E-Business Suite customers, disclosed last year after researchers found the ransomware crew had targeted internet-facing EBS servers for months before the activity became public. The newly exploited EBS vulnerability is probably not the last Oracle ERP bug to be targeted. Enterprise software has become a lucrative hunting ground for cybercrooks, and critical updates can double as roadmaps for anyone prepared to reverse-engineer the fixes and beat customers to deployment. ®

EvilTokens, the device-code phishing kit that can allow criminals to bypass multi-factor authentication (MFA) and silently authenticate as the victim to the organization's Microsoft 365 applications, appears to be even more insidious than we all thought. Cisco Talos incident responders on Wednesday described how the lure reaches a victim's inbox, and revealed new capabilities alongside a “more sophisticated evasion approach” than documented in earlier EvilTokens research. Talos uncovered a phishing-as-a-service (PhaaS) operator panel, branded “ARToken,” that appears to be an EvilTokens customer, according to security research engineer Michael Kelley, who noted the phishing operation shares infrastructure, API contracts, and operational patterns with the EvilTokens platform. EvilTokens was first documented by French cybersecurity firm Sekoia in March, and in April Microsoft said the device-code phishing campaign was compromising hundreds of organizations daily. "Since March 15, 2026, we have observed 10 to 15 distinct campaigns launching every 24 hours," Microsoft VP of security research Tanmay Ganacharya told El Reg at the time. “Each campaign is distributed at scale, targeting hundreds of organizations with highly varied and unique payloads, making pattern-based detection more challenging.” While most subsequent analysis has covered EvilTokens’ panel and phishing kit, “what it has not shown is how an ARToken lure actually reaches an inbox,” Kelley said on Wednesday. “Talos recovered two near-identical messages, sent roughly four minutes apart on April 20, 2026, that initiate the chain. The tradecraft is targeted, not spray-and-pray.” Specifically, the email lure abused a real vendor relationship between a US life-sciences company and a legitimate plumbing and fire-protection contractor. The email uses an outstanding-invoice lure, telling the life-sciences company that “the following invoices appear to still be outstanding,” and the “from” header presents the contractor’s real domain. The reply-to, however, redirects replies to an unrelated domain. Even the visible anchor text in the body of the email reads as the vendor's genuine SharePoint tenant, we’re told. The actual href, however, points to a near-identical copycat tenant under a different, attacker-controlled Microsoft 365 workspace. But because the destination is still a legitimate sharepoint.com host, the email is less likely to be flagged as a phish. During its investigation into the ARToken phishing infrastructure, Cisco uncovered the connections to EvilTokens – including an identical API contract to the one originally documented by Sekoia and matching deployment and operational models – as well as “notably more sophisticated” anti-analysis and evasion capabilities. ARToken’s panel also revealed a very comprehensive post-exploitation toolkit that provides token management and persistence mechanisms, and a built-in business email compromise (BEC) tool with full Microsoft Outlook inbox read access, email sending capabilities as the victim, inbox rule creation for forwarding and deleting messages, and keyword-based monitoring across all compromised accounts. “These features indicate the platform is more mature than a simple device code phishing kit - it is a complete BEC operations environment,” Kelley wrote. ®

A high-severity flaw in Amazon's AI coding assistant for Visual Studio Code meant that opening the wrong Git repository could allow an attacker to execute code on a developer's machine and potentially hand them the keys to the dev's cloud environment. The bug, tracked as CVE-2026-12957 and assigned a CVSS 4.0 score of 8.5, centers on how Amazon Q handled Model Context Protocol (MCP) server configurations. Wiz found the extension would automatically load a repository's .amazonq/mcp.json file and execute the commands it contained when a developer opened the project and activated Amazon Q. "The security model assumes the user explicitly configures these servers. After all, you're granting an AI assistant permission to run arbitrary commands on your machine. This should require informed consent," the researchers write. "The vulnerability arose when this assumption was violated: Amazon Q automatically loaded MCP configurations from .amazonq/mcp.json within the workspace – no prompt, no consent, no workspace trust check." MCP lets AI assistants launch local processes to carry out tasks. In Amazon Q's case, those processes inherited the developer's environment, giving them access to AWS credentials, API keys, authentication tokens, SSH agent sockets, and other secrets already loaded into the session. "The combination meant that a single malicious config file could execute arbitrary commands with full access to the developer's credentials – no user interaction required beyond opening the folder and activating Amazon Q," Wiz said. To prove the attack worked, Wiz built a repository with a malicious MCP configuration. Opening the project and activating Amazon Q caused the extension to execute a command against AWS using the developer's existing credentials. Amazon fixed the bug in version 1.65.0 of its language server, which powers Amazon Q's IDE integrations. Existing installations should receive the patched component automatically unless you've blocked automatic updates. "We would like to thank Wiz for collaborating with us on this issue. We have remediated this issue in language server version 1.65.0," Amazon said in an advisory, though it didn't respond to The Register's questions. Wiz argues the bug is less an Amazon problem than an industry one. More and more AI coding assistants are adopting MCP to connect models to local tools and services, allowing them to execute commands on developers' machines. According to the researchers, similar workspace configuration flaws have recently surfaced in other AI coding tools. It suggests attackers have found a new place to lurk: the hidden files that developers rarely think twice about trusting. ®