DoJ Seizes Huione Cloud Account Tied to Cyber Scam Money Laundering

The U.S. Department of Justice (DoJ) on Tuesday announced the seizure of a cloud computing account put to use by subsidiaries of Cambodia-based corporate conglomerate HuiOne Group, as the Treasury unveiled fresh sanctions against nine individuals and 26 entities linked to Prince Group.

"These subsidiaries are alleged to have assisted individuals and organizations in transferring proceeds of cryptocurrency investment frauds, cyber scams, and other criminal activities on cryptocurrency blockchains and allowing for the conversion of the proceeds of these schemes to the legitimate banking sector undetected," the DoJ said.

The seized account, the Justice Department added, hosted backend infrastructure for the subsidiaries, including HuiOne Guarantee (aka Haowang Guarantee), which operated an illicit Telegram-based marketplace that engaged in transactions with billions of dollars between 2021 and 2025 by peddling a wide range of crimeware tools.

These included personal and financial data, money laundering services, web development services for setting up fraudulent investment platforms and phishing websites, the procurement of individuals for human trafficking schemes, as well as software to facilitate face swapping, voice cloning, and deepfake-powered impersonation during video calls with victims.

"Huione Guarantee also provided escrow services for criminals transacting on its platforms to facilitate transactions, including money launderers laundering cryptocurrency," the DoJ said. "In doing so, Huione Guarantee facilitated the movement of considerable funds stolen by Southeast Asian scam centers."

A July 2024 analysis from Elliptic revealed that merchants on HuiOne also marketed tear gas, electric batons, and electronic shackles for use by scam compound operators to imprison and torture their workers. "The merchants refer to 'preventing escapers' and controlling 'runaway dogs,'" the company noted at the time. "Those working within the scam compounds are commonly referred to as 'dogs' or 'dog pushers.'"

"The HuiOne Group used this cloud computing account as part of a technological backbone that allowed billions in fraud proceeds to be transferred, moved, and concealed – much of it stolen through Southeast Asian scam centers," said Assistant Attorney General A. Tysen Duva of the Justice Department's Criminal Division.

"Seizures of these marketplaces is critical in the fight against fraud that affects so many Americans, and to stop avenues for criminal proceeds to be laundered."

Although HuiOne announced it was ceasing operations in May 2025, a new analysis from Flare has revealed that more than 30 marketplaces have emerged since to fill up the void left by the guarantee platform, with the operators building proprietary messaging platforms to bypass Telegram's bans.

"The wave of enforcement in 2025 was the first coordinated attempt to reach both the financial and physical layers of the ecosystem at the same scale," Flare researcher Chris d'Eon said. "It has produced visible adaptation, including reshuffled channel branding, redistributed flows across successor markets, and accelerated work on alternative venues. However, it has not meaningfully reduced volume across the ecosystem in aggregate."

In tandem, the U.S. Treasury's Financial Crimes Enforcement Network (FinCEN) has assessed H-Pay Service PLC as a primary money laundering concern to guard against "HuiOne Group's attempts to circumvent being cut off from the U.S. financial system." It's worth noting that FinCEN designated HuiOne Group as a "primary money laundering concern" in May 2025.

"Merchants sold money laundering services, stolen personal data, websites and other goods and services necessary to perpetrate so-called 'pig butchering' scams and other online fraud," Elliptic said in a statement. "By the time HuiOne was forced offline, it had received more than $31 billion in cryptoasset transactions, making it the largest illicit online marketplace ever recorded, more than 25 times larger than Silk Road and AlphaBay combined."

The development also comes as the Treasury levied sanctions against Prince Group's leadership, investors in scam compounds, and front companies, a little over eight months after it was classified as a Transnational Criminal Organization (TCO) for its role in furthering a criminal enterprise built on the foundations of scam compounds, fraud, and money laundering. Prince Group's chairman, Chen Zhi has since been arrested, extradited to China, and stripped of his Cambodian citizenship.

"Transnational criminal organizations based in Southeast Asia, like the Prince Group TCO and with support of their enablers like HuiOne Group, continue to target Americans through large-scale cyber-enabled fraud and scam operations," Treasury said.

from The Hacker News https://ift.tt/dT0oxam
via IFTTT

Cisco Unified CM Flaw Exploited After PoC Reveals File-Write Path to Root

Threat actors have begun to exploit a recently disclosed critical security flaw impacting Cisco Unified Communications Manager (Unified CM) and Unified Communications Manager Session Management Edition (Unified CM SME).

The vulnerability, tracked as CVE-2026-20230 (CVSS score: 8.6), is a case of improper input validation for specific HTTP requests that could allow an unauthenticated, remote attacker to conduct server-side request forgery (SSRF) attacks through an affected device.

"An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device," Cisco said in an advisory released earlier this month. "A successful exploit could allow the attacker to write files to the underlying operating system that could be used later to elevate to root."

In a post shared on X earlier this week, Defused Cyber said it observed active exploitation of the vulnerability in attacks. "This is currently being exploited from a single source using an unvetted PoC, with genuinely-formatted file:// file-write payloads landing on our decoys," it noted.

However, for successful exploitation to occur, the WebDialer service must be enabled. It's disabled by default. To check if the WebDialer is enabled, users can complete the following steps -

• Log in to the Cisco Unified CM Administration interface
• From the Navigation menu, choose Cisco Unified Serviceability and click Go
• From the Tools menu, choose Control Center - Feature Services
• In the CTI Services section of the page, check whether the current status of the Cisco WebDialer Web Service is Started or Not Running
• If the status is Started, WebDialer is enabled

The vulnerability has been patched in Unified CM and Unified CM SME versions 14SU6 and 15SU5. If immediate patching is not an option, it's advised to disable the WebDialer service until a fix can be applied.

SSD Secure Disclosure has since published additional technical specifics of CVE-2026-20230, describing it as a flaw that allows unauthenticated attackers to arbitrarily write files in the server by leveraging the Webdialer component to obtain the true hostname of the target and ultimately achieve code execution.

Cisco has yet to update the advisory to reflect the exploitation status. Last week, the network security company released security updates for a medium-severity security flaw in Catalyst SD-WAN Manager (CVE-2026-20262, CVSS score: 6.5) that has come under active exploitation in the wild.

from The Hacker News https://ift.tt/KF4zQR0
via IFTTT

OpenClaw’s Skill Marketplace and the Emerging AI Supply Chain Threat

Executive Summary

OpenClaw is an AI agent that executes third-party skills from ClawHub, its dedicated marketplace. Skills are markdown-driven packages with broad local system access, making ClawHub a critical link in the agentic software supply chain.

Following its release, the ecosystem saw several malicious campaigns. Those early findings, published in February 2026, prompted ClawHub to integrate VirusTotal and ClawScan, enabling proactive screening of published skills and code-level analysis to block skills flagged as malicious from download.

However, our analysis from February-May 2026 revealed persistent and evasive malicious skills on ClawHub. We identified five unblocked skills.

We reported all five to ClawHub for takedown. OpenClaw banned the accounts mentioned and deleted all of the skills.

The five skills represent three distinct threat categories leveraging the AI supply chain ecosystem:

• Infostealers: Two skills delivered macOS infostealers. Both connect to command-and-control (C2) infrastructure, indicating persistent threat actor activity.
• Evasion: One skill has an inflated file size to exceed scanner thresholds, bypassing both ClawScan and VirusTotal detection.
• Agentic threats: Two skills represent agentic threats: runtime agentic affiliate injection and agentic front-running. Both are novel techniques that the skill authors used for financial gain.

OpenClaw is now also collaborating with NVIDIA to provide documentation of what each skill does, and to run NVIDIA’s analysis tool on all skills.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

• Koi Agentic Endpoint Security (AES)
• Advanced URL Filtering
• Advanced DNS Security
• Prisma Browser
• Advanced WildFire
• Cortex XDR and XSIAM

The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics

Agentic AI, OpenClaw, ClawHub, Supply Chain, Infostealer

AI Agent Skills as a Supply Chain Attack Surface

Software supply chain attacks typically rely on compromising distribution vectors or spoofing dependencies. However, AI agent ecosystems have altered this paradigm, and their threat model differs from previously established ecosystems like npm or PyPI. While conventional malware often faces limitations from language runtimes or containers, malicious skills use semantic instruction hijacking to bypass technical constraints.

By misusing the AI’s natural language interpretation, malicious skills can exploit the agent's operational context, including file systems, shells and credential managers, without requiring a conventional exploit. The lack of isolation between skill logic and agent authority means that installation results in complete control over the agent's identity. This allows a malicious skill to perform unauthorized actions through the agent’s own authenticated sessions.

Early Campaign Activity on ClawHub

In early February 2026, Bitdefender Labs reported that approximately 17% of OpenClaw skills they analyzed in the first few weeks of the platform's release carried malicious payloads. Koi Security's ClawHavoc disclosure documented 341 malicious skills, and Trend Micro separately confirmed skills distributing Atomic macOS stealer (AMOS) malware across the marketplace.

This early wave featured several distinct techniques:

• Base64-encoded curl-pipe-bash dropper: These skills embedded a fake prerequisite block that instructed the agent to decode and execute a Base64-encoded remote payload, typically fetched from 91.92.242[.]30, the IP address for an AMOS C2 server.
• Platform-specific delivery: For macOS targets, paste-site redirects (glot[.]io, rentry[.]co) served as an intermediary step, allowing attackers to update payloads without modifying the published skill. Attackers directed Windows targets to password-protected executables hosted on third-party hosting services.
• ​​Persistence via auto-updaters: Auto-updater skills combined the initial dropper with scheduled cron job registration, ensuring the C2 channel persisted even after skill removal.
• Alternative exfiltration channel: A distinct cluster (polymarketbtc, polymarketbtcassistant and related skills published by krajekisbtc) exfiltrated cryptocurrency private keys via the Telegram Bot API, a C2 channel independent of the shared dropper infrastructure.
• Registry saturation: A single publisher account injected malicious payloads into the majority of their published skill catalog with identical payloads to maximize installation surface before detection.

Those findings prompted ClawHub to partner with VirusTotal, enabling proactive screening of published skills. These skills from these early campaigns have since been removed from the marketplace or marked as malicious.

In the following sections, we document the state of the marketplace between February and May 2026, during which VirusTotal and ClawScan served as the primary screening mechanisms.

(On June 1, ClawHub also announced a partnership with NVIDIA to help screen published skills.)

The AMOS dropper infrastructure from earlier campaigns remains active more than three months after first public disclosure, with the C2 server at 91.92.242[.]30 continuing to receive new skill deliveries. Additionally, we observe novel attacks that adapt to and exploit skill marketplaces, leveraging the agentic execution model to implement financial schemes that evade some kinds of malware detection.

Malicious Skills Distributing ClawHavoc Payload

Publisher/Skill: [redacted]/tradingview-ai-indicator-assistant

SHA256 hash: b6c7e0bf573b1c7d9d3a05eb08d26579199515b847df984862805f44a7af8007

On May 17, 2026, the account published two skills targeting TradingView users as shown in Figure 1.

Figure 1. ClawHub marketplace listings for two TradingView assistant skills.

Both of these skills presented as AI assistants for macOS, posing as productivity tools for traders. Both embedded the same malicious prerequisite block, which prevented the skills from functioning until the user performed a required action. In this case, the prerequisite block directed agents to a site with malicious instructions to copy and paste text into a terminal window. We refer to this site as a paste-site redirect lure.

The paste-site redirect lure at hxxps[:]//rentry[.]co/openclaw-code served instructions with a Base64-encoded string for the prerequisite block, which the agent must run before the skill can continue. Figure 2 below shows an example of this page.

Figure 2. Paste-site redirect lure.

When the agent performed the actions in the paste-site redirect lure, the associated command fetched a payload from hxxp[:]//2.26.75[.]16/Xuvewuyur. That payload was a macOS infostealer named cluw with a SHA256 hash of 818aea6143282b352fdfdc0f3ebf77a36e54eb3befb5cad1a355a99ab97c6aa7.

The delivery mechanism is structurally identical to the ClawHavoc campaigns documented by Koi Security and Trend Micro. The prerequisite block, the paste-site redirect lure and the Base64 pipe to bash all match the early-wave pattern.

The C2 server we discovered at 2.26.75[.]16 differs from prior disclosure. The cluw payload differs from AMOS. This campaign used the established delivery template with fresh backend infrastructure.

Until mid-May, ClawHub's automated auditing returned a verdict of Pass for ai-tradingview-assistant-for-macos and no verdict for tradingview-ai-indicator-assistant. Neither skill triggered detection, despite containing a verbatim paste-site prerequisite lure. This structural pattern characterized over 300 skills in the original ClawHavoc disclosure.

File Padding for Defense Evasion

Publisher/Skill: [redacted]/omnicogg

SHA256 hash: b30eaed1f7478c28f4ec50d07ed5ef014ffbc4b2bc5a38d689ba9f7abb5e19c2

The omnicogg skill was an early-wave threat, similar to those that defined the initial surge of malicious activity on ClawHub. It is a Base64-encoded curl-pipe-bash dropper that delivered the AMOS malware via 91.92.242[.]30, the same C2 infrastructure documented in earlier campaigns.

This skill is distinguished by its delivery vessel, a README.md file. The malicious payload appears at the start, followed by 22 MB of padding characters. This padding inflates the file size beyond the limits that many content-analysis pipelines enforce before declining to process a file. Figure 3 below shows an example of the padding characters in this file.

Figure 3. The omnicogg skill’s README.md file.

JFrog Security Research disclosed this skill in March 2026. This evasion technique can be effective because many scanning pipelines skip abnormally large files rather than process them.

This skill's ClawScan audit was in review in mid-May, while VirusTotal returned a clean verdict, and the skill remained available for download, as shown in Figure 4. Scanners that do not analyze content beyond standard thresholds will miss payloads structured to exploit that weakness.

Figure 4. ClawHub audit page for [redacted]/omnicogg shows an overall pass despite containing malicious code..

Runtime Agentic Affiliate Injection

Publisher/Skill: [redacted]/money-radar

SHA256 hash: ebb73dbb5aac1f6fe1a88e8f26126a1e1aa34c9f3345ad4345189b40d9bf1d1d

This ClawHub campaign focused on financial communities, with skills that targeted banking and crypto exchange workflows. This money-radar skill presented itself as an overseas financial product advisor that compared brokerages, banks, crypto exchanges and remittance services for users in mainland China, Hong Kong and Singapore. However, its core logic was an affiliate funnel for developer profit.

The skill weaponized the agent's advisory authority, routing all financial recommendations through affiliate links from a known-malicious domain. The publisher retained dynamic control over which products it pushed after installation.

Technical Analysis

The skill's mandatory first action on every invocation was to fetch product data from laosji[.]net, a domain previously observed in paste-jacking campaigns. Figure 4 shows an example of this action within the skill's SKILL.md file.

Figure 5. The money-radar skill's SKILL.md instructs the agent to fetch data from laosji[.]net.

The agent ingested a

referrals.json

payload from

laosji[.]net

as a precondition to answering any financial question. That payload contained approximately 60 products across eight categories, each with a

referralLink

field carrying affiliate tracking. The

SKILL.md

file then issued an explicit instruction to always use the referral links as shown in Figure 6.

Figure 6. The money-radar skill's SKILL.md file with the affiliate link instruction highlighted and translated.

Once the skill was installed, the publisher dynamically controlled the links the agent would recommend by updating referrals.json on laosji[.]net. The operator could change which products were recommended, rotated affiliate partners or redirected victims toward higher-commission offerings without the victim’s involvement. This exploitation constitutes an agent-specific form of runtime affiliate injection.

Unlike typical affiliate injection, which intercepts links the target was already clicking, this skill generated the recommendation itself. The affiliate link arrived embedded in what appears to be skill-based expert advice.

Agentic Front Running

Publisher/Skill: [redacted]/letssendit

SHA256: hash f4e41aa269c88bf11a2022701a9cf41e9a186aa1b224d837c31bf34e0b875d0e

The letssendit skill implemented an agentic front-running scheme. This scheme involved the skill operator misusing the ClawHub platform to illegitimately profit from meme token launches. It achieved this by leveraging numerous AI agent participants and coordinated agentic execution.

The coordinated activity executed on infrastructure using the domain letssendit[.]fun. Guided by the skill's SKILL.md file instructions, installed agents autonomously pooled Solana blockchain platform cryptocurrency (SOL) into the operator's digital wallet. Once enough agents had joined, the operator would front-run the distribution by purchasing the SENDIT meme token at the lowest bonding curve price before allocating any to the agents.

The token then launched publicly on the cryptocurrency platform pump[.]fun, where external buyers could mistake the coordinated AI botnet activity for organic retail demand. This could create a classic rug pull. The operator simply rotates wallets across multiple confirmed launches, dumping their low-cost position into the artificial market rally at the expense of secondary market buyers.

Ultimately, this exploit represents a novel documented case of an attacker weaponizing an autonomous AI agent network to execute a pump-and-dump scheme. This behavior constitutes fraudulent financial activity. We strongly recommend that enterprises block this skill across their AI infrastructure to mitigate regulatory and security risks.

Conclusion

The cases documented in this article span evasion, deceptive monetization, financial fraud and campaign persistence. Each case passed existing detection tools at the time of our analysis.

Organizations can strengthen their defensive posture by using a rigorous supply chain verification framework. We identified that skill execution occurs within the agent process. This necessitates active validation of publisher provenance and a line-by-line audit of package source files.

Our research indicates that monitoring outbound network traffic can identify post-installation communication with undocumented endpoints. We recommend cross-referencing all external connections against the provided documentation. Any discrepancies serve as observable indicators of risk. These verification steps help protect an organization’s environment by ensuring that the operational behavior of a skill aligns strictly with its stated technical specifications.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Koi's Agentic Endpoint Security (AES) gives security teams a single platform to discover every AI component across the agentic endpoint, assess its risk, enforce policy, and remediate violations - so your end users adopt the latest technology, increase the org productivity without compromising on security.
• Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
• Prisma Browser Prisma Browser provides additional protection layers against advanced web threats including dynamic scans of every loaded web page, to prevent execution of malicious content and protect company assets.
• The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
• Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection.

The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks.

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.

Acknowledgments

We’d like to thank the entire Unit 42 team for supporting us with this article. Special thanks to Samantha Stallings, Bradley Duncan and Lysa Myers for helping us review this article.

Indicators of Compromise

Domains, IP Addresses and URLs

• 2.26.75[.]16
• 91.92.242[.]30
• 91.92.242[.]30/lamq4
• download.setup-service[.]com
• github[.]com/Ddoy233/openclawcli
• glot[.]io/snippets/hfd3x9ueu5
• install.app-distribution[.]net
• laosji[.]net
• openclawcli.vercel[.]app
• rentry[.]co/openclaw-code

Publisher/Skill

• [redacted]/santi-text-game
• [redacted]/omnicogg
• [redacted]/letssendit
• [redacted]/money-radar
• [redacted]/ai-tradingview-assistant-for-macos
• [redacted]n/tradingview-ai-indicator-assistant
• [redacted]/pdfcheck
• [redacted]/update
• [redacted]/wistec-core

SHA256 Hashes

• 818aea6143282b352fdfdc0f3ebf77a36e54eb3befb5cad1a355a99ab97c6aa7
• 881ce5cb124c4d2e814783724cc1388f6a1cbf6eee274c3f3366e77ba3503ad7
• b30eaed1f7478c28f4ec50d07ed5ef014ffbc4b2bc5a38d689ba9f7abb5e19c2
• b6c7e0bf573b1c7d9d3a05eb08d26579199515b847df984862805f44a7af8007
• ebb73dbb5aac1f6fe1a88e8f26126a1e1aa34c9f3345ad4345189b40d9bf1d1d
• f4e41aa269c88bf11a2022701a9cf41e9a186aa1b224d837c31bf34e0b875d0e

Additional Resources

• OpenClaw Partners with VirusTotal for Skill Security
• OpenClaw Collaborates with NVIDIA for Stronger Agent Skill Security
• Anatomy of a Deception: Uncovering the 'omnicogg' Dropper in ClawHub - JFrog Security Research
• ClawHavoc: 341 Malicious Clawed Skills Found by the Bot They Were Targeting - Koi Security
• Malicious OpenClaw Skills Used to Distribute Atomic macOS Stealer - Trend Micro
• Trust No Skill: Integrity Verification for AI Agent Supply Chains - Unit 42

from Unit 42 https://ift.tt/EqM5lfI
via IFTTT

FortiBleed Targeted FortiGate Firewalls in 110 Million-Credential Harvesting Operation

A Russian-speaking initial access broker (IAB) driven by financial gain is assessed to be behind a large-scale credential-harvesting operation known as FortiBleed that has targeted over 430,000 FortiGate firewalls globally.

The campaign, active since February 2026, involves collecting credential lists, searching for exposed services, brute-forcing accessible systems, and deploying bespoke sniffers on compromised firewalls.

"Once deployed, these sniffers capture cleartext and hashed credentials from traffic passing through compromised devices," SOCRadar said [PDF] in a fresh report. "The actors then crack, validate, and reuse the credentials against Active Directory domains and other exposed services."

Central to the operation is a Golang-based tool called FortigateSniffer that takes advantage of the FortiOS built-in diagnostic command -diagnose sniffer packet to passively capture authentication traffic from the infected appliances. The tool is designed to monitor traffic across 24 protocols, parse authentication data, and extract the credentials.

It's suspected that the threat actors may have sought the help of an open-source, AI-native offensive security platform dubbed CyberStrike to assist with some "parts of the workflow." Interestingly, another open-source framework called CyberStrikeAI was put to use in connection with another automated mass scanning campaign targeting FortiGate devices that Amazon Threat Intelligence exposed earlier this year. 

"The campaign shows a heavy focus on Small and Medium Businesses (SMBs) with fewer than 200 employees," the SOCRadar explained. "The actor targets multiple sectors and regions, with notable emphasis on the United States and India. The IT services sector appears to be a key target. This targeting choice likely helps the actor maximize downstream access, as compromised service providers can create access paths into customer environments."

Perhaps the most interesting finding is that FortiBleed appears to be part of a broader, multi-vendor initial access operation that's orchestrated to not only target Fortinet devices, but also breach Synology NAS, Sophos firewalls, RDWeb portals, Citrix SSL-VPNs, and MS-SQL servers using automated brute-forcing since February 28, 2026.

In all, the attackers are estimated to have launched no less than 659 credential-harvesting pipelines on May 31 and June 15, 2026, resulting in the identification of over 110 million credentials. This included -

• 14.8 million Remote Authentication Dial-In User Service (RADIUS) credentials
• 924,000 NTLM hashes
• 130,000 Kerberos hashes
• 89 million MySQL authentication tokens

The FortiBleed campaign takes place over five stages -

• Perform widespread reconnaissance using tools like Masscan and Shodan to identify vulnerable internet-facing FortiGate firewalls, followed by using a custom utility dubbed FortiProbe-fast and GeoSplit to filter FortiGate systems and group them by country, respectively.
• Compromise the devices with a credential checker named "forticheck" that specifically targets FortiGate's administrative panel and SSL-VPN portal, along with using tools to obtain administrative SSH access via credential stuffing and dictionary attacks.
• Upon establishing access via SSH, FortigateSniffer is deployed to passively intercept authentication traffic across 24 protocols (e.g., TACACS+, Kerberos, RPC, SMB, LDAP, SMTP, FTP, Telnet, RDP, WinRM, MS-SQL, MySQL, PostgreSQL, and RADIUS) using native FortiOS diagnostic commands, making it possible to harvest cleartext credentials and password hashes.
• The password hashes are cracked using Hashmat and Hashtopolis, and orchestrated by a Telegram bot named HASHBOT, after which they are used for lateral movement and Active Directory enumeration.
• Sensitive data from network shares is exfiltrated while stolen session cookies are used to maintain persistent, authenticated access.

"The group does not treat all targets equally," SOCRadar said. "Instead, targets are ranked according to economic value before exploitation resources are allocated."

What's more, the sniffing mechanism includes a geofencing filter that restricts operations to specific IP ranges, not to mention limiting the activity to between 7 a.m. and 6 p.m. Moscow Time. According to data captured by SpyCloud, the FortiGate-related capture cycle is said to have commenced on May 19, 2026, with the hash cracking infrastructure set up towards the end of the month.

"The operation runs in a pipeline of 300-minute (five-hour) cycles, with status every minute," Zenox said. "In each cycle it loads a regional target list [...] and validates with 1,000 simultaneous threads, displaying counters of success, failure, timeout, and warning. In the first cycles, the successful validation rate hovered near 90%."

The Brazilian cybersecurity company also said it found certain username and password pairs to be repeated across thousands of distinct IP addresses, raising the possibility that the accounts have been planted by the attacker as a clandestine backdoor entry point.

The development comes as a Russian-speaking account named "SantaAd" has advertised access to thousands of Fortinet devices for a starting price of $30,000, before increasing it to $60,000 hours later. However, it's unclear if this has any connection to the FortiBleed exposure.

"The threat actor group behind 'FortiBleed' was not just targeting FortiGate VPNs," SpyCloud said. "They were actually targeting a range of different internet-facing appliances with a standard spray-and-pray attack chain that relies mostly on mass scanning and brute-forcing logins."

from The Hacker News https://ift.tt/KyTanCx
via IFTTT

What is an SBOM (and Why Can’t You Ship Without One)?

In Omdia’s 2026 software supply chain security report, 73% of organizations that generate SBOMs say they enable more efficient vulnerability mitigation, yet 86% still find the generation process challenging. That gap between recognized value and operational difficulty is where most teams are stuck. For teams building and securing containerized applications, understanding what an SBOM is, and how to make it useful, is no longer optional.

This guide covers what SBOMs contain, why they matter for software supply chain security, how standard formats and tooling work, and where the industry is headed with regulations and enforcement.

Key takeaways

• An SBOM is a machine-readable inventory of every component inside a software artifact.
• SBOMs gain real value when paired with provenance attestations and cryptographic signatures.
• Generating SBOMs at image build time captures the full dependency tree, including OS packages.
• Regulatory mandates (EO 14028, CISA guidance, EU CRA) are making SBOMs a procurement baseline.

What is an SBOM?

Every software artifact ships with dependencies. A container image based on Alpine Linux might include dozens of system packages, each with its own version, license, and upstream maintainer. An application layer on top adds frameworks, libraries, and transitive dependencies that the developer may never have explicitly chosen. The deeper the stack, the harder it becomes to answer a basic question: what is actually running in production?

A software bill of materials answers that question. It’s a structured, machine-readable inventory of every component, library, and module inside a software artifact. Where a package manifest like package.json or requirements.txt lists declared dependencies, an SBOM captures the resolved dependency tree after the build, including transitive dependencies, system-level packages, and metadata about each component’s origin, version, and license. Think of it as a nutrition label for software.

What an SBOM contains

A well-formed SBOM includes several categories of metadata for each component:

• Component identity: Package name, version, and supplier (e.g., openssl 3.1.4, maintained by the OpenSSL Project)
• Licensing: The license type governing redistribution and use (MIT, Apache 2.0, GPL)
• Dependency relationships: How components depend on each other, including direct and transitive dependencies
• Unique identifiers: Package URLs (purl) or SWID tags that enable cross-referencing against vulnerability databases
• Checksums and digests: Cryptographic hashes that let consumers verify the component has not been tampered with
  This data is structured using open standards, primarily SPDX or CycloneDX, to keep it machine-readable and interoperable across tools, registries, and compliance workflows. In practice, an SPDX SBOM entry for a single package looks like this:

{
  "name": "openssl",
  "SPDXID": "SPDXRef-Package-openssl",
  "versionInfo": "3.1.4",
  "supplier": "Organization: OpenSSL Project",
  "licenseDeclared": "Apache-2.0",
  "checksums": [{ "algorithm": "SHA256", "value": "a1b2c3..." }]
}

A real SBOM contains one entry like this for every component in the artifact, from the base image’s OS packages up through the application’s runtime dependencies.

Why SBOMs matter for software supply chain security

The value of an SBOM becomes clear the moment something goes wrong. When the Log4Shell vulnerability was disclosed in December 2021, organizations with current SBOMs could query their inventories and identify every affected image within minutes. Teams without them spent days manually tracing dependencies across registries and deployment manifests.

Sonatype’s research found that nearly 65% of open source CVEs lack an NVD-assigned CVSS score, and when scored independently, 46% turned out to be high or critical. Without an SBOM, those unscored vulnerabilities are invisible.

Faster incident response

When a new CVE drops, the first question is always where are we exposed? An SBOM makes that question answerable in seconds rather than days. Cross-reference the affected package and version against your SBOM library, and you have an immediate blast radius. Pair the SBOM with continuous vulnerability scanning and the process becomes automated: new CVEs are matched against existing SBOMs, and affected images are flagged without manual intervention.

Customer spotlight: JWP, a video streaming platform serving more than 1 billion users, enabled vulnerability scanning across 400+ repositories in under an hour. With SBOMs feeding their scanning pipeline, the team fixed thousands of vulnerabilities while filtering out tens of thousands of non-critical issues, reducing noise and accelerating remediation.

Regulatory compliance

SBOMs are moving from best practice to legal requirements. In the United States, Executive Order 14028 helped set SBOM requirements in motion for software sold to federal agencies. CISA’s 2025 Minimum Elements guidance aims to clarify what a useful SBOM should include. The EU’s Cyber Resilience Act (EU CRA) extends similar requirements to products sold in the European market. For organizations operating in regulated industries, finance, healthcare, defense, and critical infrastructure, SBOM delivery is becoming a procurement gate.

Proactive verification, not reactive trust

SBOMs shift the security model from assuming software is safe to verifying that it is. Rather than trusting that a base image is clean because the registry says so, teams can inspect the SBOM to confirm which packages are present, which versions are running, and whether any known vulnerabilities apply.

In practice, that means writing policies against SBOM data: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation. These checks can run automatically in CI, turning the SBOM from a passive document into an active gate.

When combined with provenance attestations and cryptographic signatures, the SBOM becomes one layer in a verifiable chain of custody from source to deployment. You’re no longer taking the registry’s word for it. You’re cryptographically verifying it.

SBOM formats and standards

For an SBOM to be useful across teams, tools, and organizations, it needs a shared language. Two open standards dominate the landscape, each designed for a different primary use case.

SPDX (Software Package Data Exchange)

Developed by the Linux Foundation (ISO/IEC 5962:2021), SPDX is the most widely adopted format for license compliance and open source auditing. It is also the format used by BuildKit’s built-in SBOM generator, which attaches an SPDX document as an attestation to the container image during the build.

CycloneDX

Developed by the OWASP Foundation, CycloneDX is optimized for security workflows and DevSecOps pipelines. It includes fields for vulnerability metadata and dependency graphs, and integrates well with tools like OWASP Dependency-Track.

SBOM Formats at a Glance

	SPDX	CycloneDX
Primary focus	License compliance, open source auditing	Security, vulnerability management
Governed by	Linux Foundation (ISO/IEC 5962:2021)	OWASP Foundation
Format types	JSON, YAML, tag-value, RDF/XML	JSON, XML, Protocol Buffers
Best for	Compliance, due diligence, audits	DevSecOps pipelines, CI/CD integration
Container ecosystem support	Native in BuildKit attestations	Also produced by tools like Syft and Trivy

If you’re building container images, start with SPDX. It’s the format BuildKit generates natively, so you get an SBOM as a build output with zero additional tooling. Your downstream scanning tools may prefer CycloneDX, and that’s fine. The two formats are interoperable, and converters exist for moving between them. Let the build produce SPDX; let consumption tools handle conversion if they need it.

SWID (Software Identification Tags), a third format governed by ISO/IEC 19770-2, is primarily used for IT asset management in enterprise and government procurement. But it has largely lost traction in cloud-native and container workflows.

How SBOMs fit into container workflows

In traditional software development, SBOMs are often generated after the fact, bolted on as a compliance artifact during release. Container workflows offer a better approach: generating the SBOM at build time, as a native output of the image build process.

Build-time generation

When you build a container image with BuildKit, the builder scans the final image filesystem and produces an SBOM that reflects what actually shipped, not just what was declared in the Dockerfile. Because it captures the resolved state after all build stages complete, it includes OS-level packages, application-level dependencies, and any files copied from external sources.

Source-level SBOMs, generated from manifest files before the build, frequently miss transitive dependencies and system packages. An image-layer SBOM reflects reality.

Attestation and provenance

An SBOM tells you what’s in an image. Provenance attestations tell you how it was built: which builder, which source commit, which build platform. Together, they form a verifiable chain of evidence that auditors and policy engines can evaluate programmatically. This is the model described by SLSA (Supply-chain Levels for Software Artifacts), where Build Level 3 requires hardened build platforms with non-falsifiable provenance. SLSA is the specification; in-toto is the attestation format it uses.

The SBOM itself is attached to the image as an in-toto attestation using the SPDX predicate format. Provenance is attached the same way, so both travel with the image as verifiable, machine-readable metadata.

Registry storage

Once the image and its attestations are built, they need to live somewhere consumers can access them. Pushing the image to an OCI-compliant registry keeps the SBOM co-located with the artifact it describes. This matters because an SBOM that lives in a separate system, a shared drive, a compliance portal, or a CI artifact bucket, will eventually drift out of sync with the image it was generated from. Co-location eliminates that gap: pull the image, and you pull its SBOM and provenance with it.

Continuous scanning

With SBOMs attached to images and stored in a registry, they become inputs for continuous vulnerability monitoring. New CVEs are matched against the components listed in the SBOM without re-analyzing the image itself. Instead of re-scanning every image when a new vulnerability is disclosed, the scanner cross-references the SBOM inventory and flags affected images immediately.

Policy enforcement

Scanning identifies risk. Enforcement acts on it. Policy engines can consume SBOM data to gate deployments based on rules the team defines: no image ships if it contains a package from an unapproved supplier, no end-of-life component persists past a defined grace period, no image deploys without a matching SBOM attestation.

These checks run automatically in CI, turning the SBOM from a passive document into an active gate. You’re no longer relying on manual review to catch a problematic dependency. The pipeline catches it before the image reaches production.

SBOM maturity: Where does your organization stand?

SBOM adoption isn’t binary. Most organizations fall somewhere on a spectrum from ad hoc to fully scaled. The following maturity model helps teams assess where they are and what to prioritize next.

Level	Generation	Storage	Scanning	Governance
Ad hoc	Manual, on request	Local files or shared drives	Occasional, tool-dependent	No formal policy
Pilot	Automated for 1–2 apps or services	Alongside build artifacts	Integrated into CI for pilot apps	Basic policy drafted
Production	Automated for all new images	Attached to images in OCI registries	Continuous, with alerting	Policies enforced in pipelines
Scaled	All images, including third-party ingestion	Centralized SBOM management platform	Continuous with policy gating	Cross-org governance, audit trails, supplier requirements

Omdia’s 2026 software supply chain security survey surfaced that more than half of the organizations generating SBOMs are only generating them on a case-by-case basis. 

Common misconceptions about SBOMs

SBOMs are just a compliance checkbox

Teams that generate SBOMs solely to satisfy a procurement requirement are missing the operational value. SBOMs are most useful as a live data source for vulnerability management, incident response, and dependency tracking. A one-time SBOM generated for an audit and then filed away provides a false sense of coverage.

They’re the same as SCA

Software composition analysis (SCA) tools scan code or images for known vulnerabilities. An SBOM is the inventory that makes that scanning possible. SCA and SBOMs generally work together. The SBOM is the inventory, and SCA tools use that inventory, often generating their own, to check for known vulnerabilities. The distinction matters because scanning tends to be only as good as the inventory behind it.

SBOMs are a one-time artifact

An SBOM is tied to a specific image digest. Every time you rebuild an image, the SBOM should be regenerated to reflect any dependency changes. Stale SBOMs create a gap between what you think is running and what’s actually deployed. Automated build-time generation eliminates this drift.

SBOMs substitute runtime security

SBOMs tell you what shipped. They do not tell you what’s happening at runtime. An SBOM will not catch a zero-day that hasn’t been disclosed yet, detect anomalous process behavior inside a running container, or verify that the application logic is correct. SBOMs are one layer in a defense-in-depth model: they handle inventory and composition. Runtime monitoring, network policies, and access controls handle the rest.

What can go wrong without SBOMs

Let’s say a zero-day vulnerability is disclosed in a widely used library. Without SBOMs, the security team starts a manual triage: checking Dockerfiles, querying registries, asking developers which versions they use. Hours pass. Some images are missed because the affected package is a transitive dependency three levels deep. By the time the blast radius is mapped, the vulnerability has been public for two days.

With SBOMs attached to every image, the same triage takes minutes. Query the SBOM database for the affected package and version, get a list of every image that includes it, and prioritize remediation based on deployment context.

Getting started with SBOMs

The most common mistake teams make is treating SBOM adoption as a large-scale transformation project that’ll derail workflows. It doesn’t need to be.

• Start with one image. Pick a production image and enable SBOM generation on the next build. With BuildKit, that is a single flag:

docker buildx build –attest type=sbom –tag myapp:latest .

Review the output. This single step often reveals transitive dependencies and OS packages you did not know were in the image.

• Automate generation in CI. Extend the flag to your CI pipeline so every image build produces an SBOM automatically.
• Store SBOMs alongside images. Attach SBOMs as attestations in your OCI registry so the SBOM stays co-located with the artifact it describes.
• Connect to monitoring. Feed SBOMs into a vulnerability monitoring tool that can continuously match components against new CVEs. This closes the loop between inventory and action.
• Set policies. Define what is acceptable: maximum CVE age, required minimum SBOM completeness, blocked licenses. Enforce these policies in the pipeline so non-compliant images are flagged before deployment.

Build with visibility, ship with confidence

SBOMs are the foundation of software supply chain security. They turn opaque software artifacts into transparent, auditable inventories that security teams, compliance officers, and developers can all use. But an SBOM alone is not enough. The real value comes when SBOMs are generated at build time, paired with provenance attestations, and continuously monitored against emerging threats.

Docker makes this workflow native. Docker Hardened Images ship with complete SBOMs, SLSA Build Level 3 provenance, OpenVEX exploitability data, and cryptographic signatures on every image. Meanwhile, Docker Scout provides continuous vulnerability monitoring powered by the SBOM data attached to your images, surfacing actionable insights across your entire image portfolio. Together, they give teams a verifiable chain of custody from source to production, with no manual assembly required.

Frequently asked questions

What does SBOM stand for?

SBOM stands for software bill of materials. It’s a structured inventory of every component, dependency, and metadata element inside a software artifact, formatted in a machine-readable standard like SPDX or CycloneDX.

Are SBOMs required by law?

In the United States, Executive Order 14028 requires SBOMs for software sold to federal agencies. CISA’s 2025 draft guidance proposes an updated set of minimum elements. The EU Cyber Resilience Act extends similar requirements to products sold in the European market. For organizations in regulated industries, SBOMs are increasingly a procurement prerequisite rather than a voluntary practice.

What is the difference between an SBOM and a package manifest?

A package manifest (package.json, requirements.txt, go.mod) lists the dependencies a developer declared. An SBOM captures the fully resolved dependency tree after the build, including transitive dependencies, system-level packages, and metadata like licenses and checksums. The manifest is an input to the build; the SBOM is an output that reflects what was actually shipped.

How often should an SBOM be updated?

An SBOM should be regenerated every time the associated artifact is rebuilt. For container images, this means generating a new SBOM with each image build. Between rebuilds, the existing SBOM remains valid for the specific image digest it describes, but new CVEs may be discovered against the components it lists. Continuous monitoring against the stored SBOM catches these without requiring a rebuild.

Source

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.

from Docker https://ift.tt/KnAxqIL
via IFTTT

Fake AI Agent Skill Passed Security Scans and Reportedly Reached 26,000 Agents

Security firm AIR built a fake AI agent skill, pushed it through a popular skill marketplace and an Instagram ad, and says it reached roughly 26,000 agents, including some on corporate accounts.

Every skill security scanner the firm tested it against marked it safe. The payload was harmless by design: it collected the user's email address and did nothing else.

The point was to show that none of the signals people lean on to trust a skill caught it: not the scanners, not the GitHub stars, not the open-source reputation.

A skill is a bundle of instructions an agent loads into its own context and follows with roughly the authority of a user prompt. That trust is the whole problem, and it is the reason skill-scanning tools exist in the first place.

The skill, named brand-landingpage, claimed to build a landing page using Google's Stitch design tool, aimed squarely at non-technical users.

To make it look credible, AIR went after two trust signals: GitHub stars and a clean scanner verdict. For the stars, it opened a pull request to a skill marketplace repository with around 36,000 stars and 156 skills.

The pull request was merged after a few days, so the skill inherited the repo's count. Then it ran an Instagram ad aimed at marketers, salespeople, and designers, who installed it and put it to work.

Why the scanners missed it

The scanners AIR tested analyze the package you hand them: the SKILL.md and the files shipped with it. That's Cisco's, NVIDIA's, and the ones wired into skills.sh.

AIR's skill carried no setup instructions of its own. It told the agent to install the "Stitch SDK" by following the documentation at an external link, stitch-design.ai, a domain AIR controls, not Google (the real Stitch lives at stitch.withgoogle.com).

At first, the link led to the genuine Stitch docs, so the scanners, seeing a clean package that pointed at a plausible setup page, cleared it. The page the agent would actually fetch and follow sat outside the scan.

Once the skill was installed widely, AIR swapped the page behind that link. The new version told the agent to download and run a script.

In the demo, it only mailed the user's address back to AIR, which is how the firm counted the agents it reached. A real operator could have used that foothold to read files, move data, or hit internal systems, bounded only by what the agent could reach.

AIR is not the first to show this. Three weeks earlier, Trail of Bits bypassed ClawHub's malicious-skill detector, Cisco's scanner, and all three scanners wired into skills.sh. Its conclusion was blunt: a scanner checks a fixed package, while an attacker can keep tweaking the payload until it passes.

Real campaigns have used the same trick for months, keeping the submitted skill clean and hosting the payload on a site the agent only fetches at install.

The problem is structural: the scan happens once, but the page a skill points the agent to can be rewritten at any time after. Anthropic's own docs already warn that skills fetching external URLs are risky for exactly this reason, since the content can change after the skill is vetted.

Separate research this year found scanners often disagree, because each one judges a skill in isolation, blind to its external links and to what changes after review.

What to do

The read for defenders is the same one researchers keep landing on, now with a sharper example behind it. Treat skills as software, not text. Vet what a skill points to, not just what ships inside it.

Most of these add-ons got installed with no review, so the first job is finding what is already running. Route new skills through a single source you control, and re-check them when anything changes, because a clean result at install does not stay clean if the skill phones out to a link someone else can edit.

Pin versions. Hold agents to the least privilege. Assume any external instruction an agent fetches runs with the agent's access.

The scale figures come from AIR alone, and they deserve a skeptical read. The firm is launching a managed skill marketplace and closes the write-up, pitching it, so the 26,000 number, the corporate-account detail, and the claim that it could have seized full control of every agent are the company's own and are not independently confirmed.

What holds up is the method. The named scanners really do judge only the submitted package, the external-link blind spot is real and has been independently demonstrated, and the trust signals AIR borrowed, stars, and a clean scan are exactly the ones the ecosystem still treats as proof.

The experiment does not expose a new bug so much as it lines up every weak trust signal around agent skills into one run: stars that can be borrowed, a scan that reads a snapshot, and a link that can be rewritten after the check clears.

Whether the real figure is 26,000 or a fraction of it, the gap it walks through is one that defenders still have not closed.

from The Hacker News https://ift.tt/mwvp0Jb
via IFTTT

Trump Order Sets 2030 Deadline for Federal Post-Quantum Crypto Migration

President Trump signed an executive order on June 22 setting hard deadlines for federal agencies to move high-value assets and high-impact systems to post-quantum cryptography.

Key establishment must move by December 31, 2030; digital signatures by December 31, 2031. EO 14409 leaves national security systems on a separate track.

The deadlines matter because of a threat that does not need a working quantum computer today. Adversaries can collect encrypted U.S. data now and decrypt it later, once a large-scale quantum machine exists, the risk is known as "harvest now, decrypt later".

The order describes that risk directly and pulls the government's PQC timeline forward by four to five years. The prior government-wide target, set by the 2022 National Security Memorandum 10, ran to 2035.

The two deadlines line up with the standards NIST finalized in August 2024. Key establishment uses FIPS 203, the ML-KEM algorithm formerly called CRYSTALS-Kyber.

Digital signatures use FIPS 204 and 205, ML-DSA, and SLH-DSA. The standards have been ready for almost two years. The order is what turns them into a schedule with consequences.

What agencies have to do, and when

The near-term clock starts fast. Within 30 days, each agency head names a PQC migration lead who reports to the agency CIO and owns the cryptographic inventory and migration plan.

Within 90 days, OMB issues guidance requiring agencies to review their inventories of high-value assets and high-impact systems, plan the migration, and submit that plan.

NIST runs a pilot migration on a subset of its own systems, to be finished by December 31, 2027.

The order reaches past federal networks. The Federal Acquisition Regulatory Council has 180 days to propose a rule giving "covered contractors" until December 31, 2030, to meet NIST's FIPS, including the PQC algorithms.

A second proposed rule, due in 270 days, would fold cryptographic flaws into contractor vulnerability disclosure programs, including tests for missing encryption and for non-FIPS algorithms. Sector Risk Management Agencies and CISA are told to help critical infrastructure operators build their own migration plans, though that part is assistance, not a mandate.

Then there is the inventory angle. Within 270 days, CISA and NIST are to publish the minimum elements for a cryptographic bill of materials, a machine-readable list of the cryptographic assets in a piece of hardware or software.

That is the groundwork for crypto-agility: you cannot swap out weak algorithms on a deadline if you do not know where they are.

The practical read

For federal teams and the vendors who sell to them, the work is the inventory, and it starts now. Find every place key exchange and signatures happen, flag what is not NIST PQC, and sequence the swap against the 2030 and 2031 dates.

Contractors should expect the FAR clause and a 2030 compliance line once the rule lands. The standards exist. The deadlines now exist. The gating task for almost everyone is knowing what cryptography is running, and where.

A companion order signed the same day, "Ushering in the Next Frontier of Quantum Innovation," pushes the other side of the equation: building the quantum computers that make the migration urgent in the first place.

The teeth are still being written. OMB's 90-day guidance and the FAR rules will decide whether 2030 and 2031 become real procurement pressure or just another federal migration target that slips once the hard work starts.

from The Hacker News https://ift.tt/EAhypzJ
via IFTTT

OpenAI Expands Daybreak With GPT-5.5-Cyber to Help Defenders Patch Security Flaws

OpenAI on Monday said it's releasing an improved version of its GPT‑5.5‑Cyber model to trusted defenders as part of the Daybreak initiative, the artificial intelligence (AI) company announced last month.

Calling GPT‑5.5‑Cyber its "strongest model yet for finding and helping patch software vulnerabilities," OpenAI said the model can "sustain deeper analysis across large codebases" to identify security issues, validate them in a controlled environment, and develop and test patches.

In tandem, the tech upstart is releasing an update to the Codex Security plugin⁠ to speed up the process of discovering and patching vulnerabilities in existing systems, alongside preventing new vulnerabilities from entering production codebases.

"Developers can run deep scans or review recent changes, generate reports with severity, affected code locations, validation evidence, and remediation guidance, trace attack paths, build threat models, validate findings, and generate codebase-specific patches for review," OpenAI said.

On top of that, the plugin⁠ can triage and validate existing findings from scanners, advisories, bug-bounty reports, or ticketing systems, and then facilitate patch generation at scale to quickly close a backlog of vulnerabilities.

OpenAI is also launching a new initiative called Patch the Planet in partnership with Trail of Bits to help secure open-source projects. Initial participants include cURL, NATS Server, pyca/cryptography, Sigstore, aiohttp, the Go project, freenginx, Python, and python.org. 

These moves come as frontier models from Anthropic and OpenAI are accelerating vulnerability discovery, leaving software maintainers overwhelmed with an ever-increasing volume of bugs that need to be verified, triaged, and patched. While previously the challenge lay in finding vulnerabilities, the bottleneck has now shifted to patching them.

AI models come with capabilities to navigate large codebases, reason through attack paths, and flag security issues that might have otherwise stayed hidden. Case in point is a 29-year-old flaw in the Squid web proxy (CVE-2026-47729, aka Squidbleed) that can leak cleartext HTTP requests belonging to other users under certain conditions.

Cyber experts have also raised concerns that more advanced AI models are turbocharging bad actors' abilities to take advantage of security vulnerabilities, forcing the industry to plug the holes almost as soon as they are discovered.

"Threat actors with limited technical expertise can use publicly available AI models for malicious purposes," the Canadian Centre for Cyber Security said in guidance released in May 2026. "Organizations should assume that AI-driven exploitation may bypass preventative controls, significantly outpace vendors' capacity to publish corrective measures and challenge the organization's ability to deploy."

Patch the Planet aims to reduce this undue burden placed on maintainers by letting security engineers review and validate findings, work with projects to develop patches and tests, and help build reusable vulnerability discovery workflows with the goal of improving security even after the initial fixes are released.

"With Patch the Planet, we are working with researchers, maintainers, enterprises, and partners to make powerful cyber capability available to defenders with appropriate access, governance, and human oversight," OpenAI said.

The AI company also said the Daybreak initiative has already helped surface a number of vulnerabilities across various operating systems and web browsers -

• 8 kernel pointer information leak proofs-of-concept (PoCs) and 24 local privilege escalation exploits in the Linux Kernel
• A 23-year-old use-after-free⁠ in OpenBSD's kernel implementation of System V semaphores
• 34 vulnerabilities and 7 local privilege escalation PoCs in FreeBSD
• 6 vulnerabilities in dnsmasq (CVE-2026-4890⁠, CVE-2026-4891⁠, CVE-2026-4892⁠, and CVE-2026-5172⁠)
• A denial-of-service (DoS) technique called HTTP/2 Bomb impacting major HTTP/2 implementations, including NGINX, Apache, IIS, and Pingora
• 5 exploitable vulnerabilities in Google Chrome's V8 JavaScript engine
• 10 exploitable Apple Safari vulnerabilities
• A WebAssembly vulnerability (CVE-2026-8390⁠) in Mozilla Firefox

"Patch the Planet is designed to put that full defensive loop in service of maintainers: discovery, validation, severity review, disclosure, patch development, testing, and deployment," OpenAI said. "Frontier models can make parts of that loop faster, but the aim is to give the people responsible for shared infrastructure better tools and more capacity, while preserving their agency over how changes land."

The developments go hand in hand with bad actors misusing AI to compress the time between finding and exploiting a weakness, shrinking the window defenders have to respond. The use of vibe-coded exploits also heralds a new chapter where the technology is not only lowering the barrier to exploit development, but also enabling attackers to cast a wide net across newly disclosed vulnerabilities with lesser effort.

Intelligence agencies from Australia, Canada, New Zealand, the U.K., and the U.S. have warned that advanced AI models can speed up the speed, scale, and sophistication of cyber threats, while lowering the barrier for malicious actors and shrinking the window between vulnerability discovery and exploitation ever more quickly.

"Frontier Al models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months, the agencies noted. "In this environment, cyber resilience is integral to advancing business continuity, market confidence, and long-term value."

"Success will come from getting the basics right, acting quickly, and integrating cyber security into core business strategy. Those that do not will face growing operational and strategic disadvantage."

from The Hacker News https://ift.tt/iGnVmoO
via IFTTT

The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration

Executive Summary

We recently identified a bucket hijacking technique impacting multiple services across major cloud service providers (CSPs). The attack technique exploits a fundamental architectural flaw that is common across cloud providers and could potentially affect other cloud providers as well.

Our research reveals that an attacker can silently compromise an organization's active data streams by rerouting data into an external storage bucket. Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk. This bucket hijacking reroutes critical logs and sensitive data directly to the attacker’s environment.

We have shared these findings with Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.

We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Key Architectural Elements Enabling the Attack

Before detailing the attack methodology, it’s important to understand several architectural elements that, when combined, make bucket hijacking possible.

Data Stream Overview

A data stream is an automated, continuous pipeline designed for high-volume data movement between services. Once configured, these streams operate autonomously in the background to push telemetry, audit logs or objects from a source environment to a designated storage destination for processing and long-term retention.

Major CSPs facilitate automated data streams. These streams serve as critical nodes for routing, processing and backing up data within an organization's infrastructure, such as:

• A cloud logging sink in Google Cloud acts as a router for log entries, directing them to a chosen destination. While primarily used to route and store logs in centralized log buckets for purposes like analysis and retention, a sink can also export logs to a Google Cloud Storage (GCS) bucket.
• Bucket replication in AWS is a feature that automatically duplicates data from a source S3 bucket to a designated destination S3 bucket.

Global Uniqueness of Bucket Names

Cloud environments often stream data into buckets such as an S3 bucket in AWS or a GCS bucket in Google Cloud. Because bucket names are typically unique across the entire cloud provider, no two users can have the same bucket name. This design simplifies data stream establishment by providing a single, predictable target. However, it also creates a shared namespace where a destination's identity is tied solely to its name, rather than to a specific, immutable account owner. This characteristic is the foundational logic behind our discovery.

Permissions to Modify Data Stream Destinations

The data stream is frequently defined by a routing resource that is configured with a specific destination. To legitimately modify this destination, the user must possess specific, granular identity and access management (IAM) update permissions for that resource.

For example, modifying the destination for a cloud logging sink requires the logging.sinks.update permission. This routes logs to a bucket. Our research found that certain permissions outside of this traditional update purview could be leveraged to reroute data streams.

The Bucket Hijacking Attack

We now turn to discussing the attack flow before any mitigations were provided by the affected CSPs. After compromising a cloud environment and securing the permissions required to delete a target bucket, an attacker was effectively positioned to intercept and redirect a cloud data stream. By deleting the original bucket and immediately recreating a new bucket with the same name within their own account, the attacker could have redirected the data stream. This could have led to the exfiltration of the target's data to the attacker's account.

Figure 1 shows the attack flow diagram.

Figure 1. The bucket hijacking attack flow.

Simulating Bucket Hijacking in Google Cloud Logging

We simulated the bucket hijacking technique in Google Cloud Logging. In the simulation, we used a sink that routes logs to a cloud storage resource, as shown in Figure 2.

Figure 2. An existing sink referencing a GCS bucket.

After routing the logs, the original cloud storage bucket was deleted, as Figure 3 shows.

Figure 3. Deleting the targeted bucket used by the sink.

We then created a new bucket with the same name in an attacker-controlled environment, as shown in Figure 4.

Figure 4. Recreating the bucket in an external project.

Subsequently, logs were routed to this external cloud storage bucket, allowing the attacker to obtain extensive information about the compromised environment, as shown in Figure 5. The required permissions the attacker needed to have are storage.objects.delete (to empty the bucket) and storage.bucket.delete (to delete the bucket).

Figure 5. Logs written into the attacker’s controller bucket.

The Expansion to Multiple Services Within Google Cloud

Data streaming into a GCS bucket is not unique to cloud logging. There are many other Google Cloud services in which data can be streamed into cloud storage. We identified and tested a representative subset of potentially vulnerable services, specifically Pub/Sub and Storage Transfer Service, to confirm the systemic prevalence of this security risk.

Pub/Sub

Pub/Sub is an asynchronous messaging service that decouples upstream event producers from downstream processing services. It allows applications to broadcast messages to a topic, which are then distributed to one or more subscriptions for consumption by downstream systems.

This architecture enables scalable, event-driven communication. This allows disparate components such as log aggregators, data pipelines and real-time analytics engines to exchange information reliably without needing direct, synchronous connections.

The Pub/Sub architecture has three core components:

1. Publishers (producers) send messages to a named logical channel called a topic, without needing to know who or what will receive them.
2. Topics act as a buffer or distribution hub, holding the messages until they can be delivered.
3. Subscribers (consumers) listen to specific topics via a subscription. When a message arrives in the topic, the Pub/Sub service pushes it to the subscribers (push model) or the subscribers actively request it (pull model).

To simulate a bucket hijacking attack on Pub/Sub, we took the following steps:

1. We created a new Pub/Sub topic and a subscription linked to a GCS bucket
2. We configured the GCS bucket with the necessary permissions to grant access to the service agent:
   1. Storage object creator (roles/storage.objectCreator)
   2. Storage legacy bucket reader (roles/storage.legacyBucketReader)
3. We published a message to the topic, which was successfully delivered to the initial bucket
4. We deleted the original bucket and created a new bucket with the same name in a different project (the attacker's project)
5. When a message was published manually again, we found that the service exfiltrated the message to the attacker's environment

The successful redirection of the message stream proved that the bucket hijacking attack technique was directly applicable to the Pub/Sub service, allowing an attacker to exfiltrate data by deleting and recreating the destination bucket.

Storage Transfer Service

Storage Transfer Service is a managed data migration tool designed to automate the movement of large volumes of data into, out of or between cloud storage environments. It allows organizations to schedule and manage massive data transfers from external sources (like AWS S3 or on-premises systems) to GCS buckets, or to synchronize data between different cloud storage projects.

The service handles the underlying infrastructure, retries and checksum validation. It provides a way to populate data lakes or perform large-scale disaster recovery backups.

The Storage Transfer Service architecture operates as a centralized orchestration engine that manages the movement of data between a designated source and sink. When a user defines a transfer job, they specify the source, the destination and the scheduling parameters. The source can be an S3 bucket, a URL list or another GCS bucket.

To simulate a bucket hijacking attack on Storage Transfer Service, we took the following steps:

1. We configured a new transfer job with a GCS bucket as the source and another GCS bucket as the destination
2. We assigned the necessary permissions to the buckets to grant access to the service agent:
   1. Source bucket: Storage Object Viewer (roles/storage.objectViewer) and Storage Legacy Bucket Reader (roles/storage.legacyBucketReader)
   2. Destination bucket: Storage Object Admin (roles/storage.objectAdmin)
3. The user then initiated the transfer job
4. We deleted the destination bucket and then immediately re-created it in a different project (the attacker's environment)
5. We wrote a new object into the source bucket
6. After a period determined by the job's scheduling parameter, the object appeared in the newly hijacked destination bucket, which was under the attacker's control

The impact of this risk was significantly magnified by its broad applicability across numerous services. The permissions storage.buckets.delete and storage.objects.delete could be used to bypass the granular update permissions required for specific resources to redirect sensitive data streams such as logging.sinks.update, pubsub.subscriptions.update and storagetransfer.jobs.update.

The Expansion to Another Cloud Provider: AWS

The architectural flaw of global bucket name uniqueness is not exclusive to Google Cloud. AWS S3 buckets operate under the same design logic. Given this commonality, we investigated whether we could apply the same hijacking technique within the AWS ecosystem.

We successfully simulated the bucket hijacking attack using the S3 bucket replication feature. This feature enables the configuration of a source and destination bucket, where all objects written to the source bucket are automatically replicated to the destination bucket. The simulation followed these steps:

1. We created a bucket in our environment with a replication rule targeting a second bucket within the same account
2. We deleted the bucket and immediately recreated a new one using the same name within an external account
3. We uploaded a file to the source bucket
4. We observed the file appearing in the destination bucket located in the external account

Like in Google Cloud, we identified that this was not a localized issue, but applied to a number of AWS data stream services. We simulated the same technique using Amazon Data Firehose (where the destination is an S3 bucket) and observed the same behavior.

Cross-Subscription Data Exfiltration in Azure

Finally, we tested Azure’s environment for the same attack technique. Azure platform limitations prevent the immediate reuse of storage account names across different tenants for several days after deletion. However, we were able to simulate a cross-subscription attack technique.

This scenario was particularly relevant if an attacker gained permission to delete a storage account in one subscription and intended to reroute data to another. This allowed them to move data to a subscription where they maintained higher privileges and persistence, or perhaps where they previously lacked data access permissions. Ultimately, this technique relied on the fact that a storage account must be created with soft-delete disabled to ensure the name was released and could be promptly reclaimed.

We used Azure Monitor to demonstrate this attack. Diagnostic settings in Azure Monitor can be configured to export resource logs (e.g., metrics and audit events) to an Azure storage account. While the configuration stores the destination via its Azure Resource Manager (ARM) Resource ID, the internal pipeline resolves the storage account at runtime using its DNS name ({accountname}.blob.core.windows.net).

This architectural behavior facilitated the execution of the attack. If an attacker deleted a destination storage account and recreated it with an identical globally unique name in a different subscription within the same tenant, the diagnostic pipeline would continue to write logs to the attacker-controlled storage account.

The attack was less severe in Azure than in AWS or Google Cloud because it was limited to a cross-subscription scope rather than a cross-tenant one.

Exploitation Scenarios and Excessive Permissions Risks

The practical execution of bucket hijacking relies on specific exploitation vectors that are often facilitated by the widespread use of over-privileged administrative roles.

Exploitation Scenarios and Detection Challenges

We identified two distinct scenarios that could enable an attacker to execute a bucket hijacking operation:

1. Privilege escalation: As demonstrated in our simulations, a compromised identity with the permission to delete a bucket could misuse this access to redirect data streams to the attacker's own bucket. The widespread application of storage administrator roles significantly increased the risk of this attack technique and overcame the need for the more granular logging.sinks.update permission (as shown later).
2. Dangling router resources: In a similar exploit not demonstrated in this article, if someone deleted a bucket and failed to remove the associated router resource, an attacker could create a new bucket using the same name in their own environment. This action effectively redirects the data to the attacker's bucket, granting the attacker access to the victim's ongoing data.

Detecting these attack scenarios is particularly challenging. In scenarios where destination resources are used primarily for long-term retention or backup, the target may not detect the initial deletion of the original storage bucket. Because the data stream continues to operate autonomously, the sink configuration in Google Cloud appears valid upon inspection as shown in Figure 6. This allows the hijacking and subsequent data exfiltration to remain largely undetected.

Figure 6. The sink configuration remains intact and operational after recreating the bucket.

How Over-Privileged Roles Increase the Risk

Cloud providers frequently offer broad storage administration roles that grant wide-reaching deletion privileges by default, which significantly increases the practical risk of this attack technique.

For example, in Google Cloud the common storage admin role provides the storage.buckets.delete permission. However, as Figure 7 shows, it does not include granular permissions to modify data stream configurations like:

• logging.sinks.update
• pubsub.subscriptions.update
• storagetransfer.jobs.update

Figure 7. The predefined Google Cloud storage admin role includes bucket deletion permission (highlighted in red) but lacks granular update permissions for data stream resources.

Mitigation Strategies

Google has adjusted how router resources interact with target storage resources since the time of our initial research.

Microsoft recommended that Azure users review documentation and tooling on addressing dangling DNS for subdomain takeovers (see Additional Resources).

Users can also employ additional defense strategies.

Mitigating the bucket hijacking technique requires a two-pronged approach focusing on preventative guardrails and proactive monitoring. Prevention starts with the principle of least privilege. Organizations must strictly limit the IAM permissions for deletion actions, specifically:

• Storage.buckets.delete in Google Cloud
• DeleteBucket in AWS
• Microsoft.Storage/storageAccounts/delete in Azure

These permissions should be restricted to a minimal set of administrative roles and should never be assigned to service accounts or applications without rigorous justification.

In addition, the following mechanisms help to prevent the bucket hijacking technique:

• Organizations can prevent bucket hijacking for data exfiltration by enforcing data perimeter controls that restrict resource access to stay within a trusted organizational boundary.
  • In AWS, data perimeter policies — implemented through service control policies (SCPs) and virtual private cloud (VPC) endpoint policies — can ensure that workloads within the organization are unable to write data to S3 buckets that belong to external accounts. This can effectively block the exfiltration path even if an attacker substitutes a malicious bucket, though the approach has some limitations.
  • Similarly, in Google Cloud, VPC Service Controls define a security perimeter around projects and services, to block any API call attempting to access Cloud Storage buckets outside the perimeter.

Deploying these controls as a baseline ensures that data cannot leave the trusted environment boundary, neutralizing the core mechanism of this attack technique.

• AWS offers account regional namespaces for S3 buckets, which scope bucket names to the owning account and region rather than to a single global namespace. This directly eliminates the bucket hijacking vector. If a bucket is deleted, no other account can reclaim its name. This prevents attackers from intercepting traffic by re-registering abandoned bucket names.

For detection, organizations must implement robust monitoring solutions that specifically alert on the attempted deletion of a storage bucket. Security teams should prioritize high-severity alerts for storage deletion API calls, focusing specifically on resources that house sensitive information.

Given the high frequency of storage deletion events in large-scale environments, leveraging data security posture management (DSPM) capabilities is essential. It is particularly important to prioritize monitoring and to focus specifically on high-value, sensitive assets, as shown in a Cortex XSIAM alert in Figure 8.

Figure 8. Cortex XSIAM alert: Deletion of a high-sensitivity bucket detected.

Conclusion

The bucket hijacking technique detailed in this research exploits the global uniqueness of storage resource names in the major cloud providers. We have demonstrated how a configure-and-forget approach to data streams can lead to silent, long-term data exfiltration.

Reliance on a globally unique, static resource name for buckets is an architectural design common across cloud providers. As such, this technique could be portable to other cloud services and providers not covered in this research.

Our findings underscore two primary lessons for the security community:

• Architecture defines the security boundary: Fundamental design choices made by cloud providers directly influence the security boundaries of our environments. A robust mitigation strategy must include awareness of these architectural nuances and the implementation of guardrails.
• A cross-cloud exploitation methodology: While cloud providers are often managed as distinct ecosystems, their shared design philosophies allow identical attack techniques to be applied across providers. Our simulations prove that a specific architectural observation can evolve into a universal methodology for hijacking sensitive data streams. We encourage the security industry to adopt a cloud-agnostic mindset. A design flaw discovered in one provider could be a blueprint for exploiting another.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

• Cortex Cloud customers are better protected from the techniques discussed in this article with cloud runtime security operations through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Cortex has several out-of-the-box rules built into the Analytics module that detect data movement to external buckets. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified. When this occurs, they trigger alerts, which provide early warning and, in some cases, prevention operations to prevent further compromise from these attacks.
• Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses:
  • Cloud Infrastructure Entitlement Management (CIEM)
  • Identity Security Posture Management (ISPM)
  • Data Access Governance (DAG)
  • Identity Threat Detection and Response (ITDR)
• These tools provide the necessary capabilities to improve identity-related security requirements within cloud environments. This includes:
  • Accurately detecting misconfigurations
  • Identifying unwanted access to sensitive data
  • Conducting real-time analysis surrounding usage and access patterns

Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights.

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.

from Unit 42 https://ift.tt/JQFZNjU
via IFTTT