Search/kubernetes
Vendor

kubernetes

Known CVEs
0
Highest CVSS
In KEV
0
Vendor
dashboard
Connections
396 relationships
Who's governing your AI? A trust framework for enterprise agents and models
Experienced IT leaders know that shadow IT is a persistent problem, but rapidly evolving AI and the proliferation of agents mean the potential threat - and cost - is greater than ever. AI agents are non-deterministic, autonomous, and adaptable. They excel at solving tasks in creative ways, often to the surprise of their creators. We've seen agents write blogs that criticize project maintainers that refused their pull requests. Another one hacked a McKinsey chatbot to gain read/write access without asking for permission. And agents are getting smarter all the time. As an industry veteran, DigiCert's senior vice president of product Brian Trzupek sees an old pattern. "When the promise of the technology is so good, people are willing to throw security out the window, and they just want to get to that promise real fast." CISOs should be worried about allowing these agents into their infrastructure without strict controls, but it's happening anyway. IBM's 2026 Cost of a Data Breach report found that more organizations lacked governance to manage AI or detect shadow AI, at 68 percent compared to 63 percent last year. The number requiring IT approval to deploy AI had fallen to 38 percent from 45 percent. DigiCert is trying to solve this problem with its own approach to AI governance called AI Trust. The framework, outlined in this white paper, builds on what the company is good at: public key infrastructure, DNS, and attestation. The AI governance questions CISOs should ask AI Trust uses these tools to help organizations answer five AI governance questions: · What agents your employees are using · What regulated data is flowing to them · Whose credentials they hold · Whether a compromised agent can be stopped immediately · Whether an incident can be reconstructed with a tamper-evident trail Almost every enterprise fails at the first hurdle, warns Trzupek. Developers build agents or buy them from vendors and deploy them internally without asking. Users might also spawn agents from inside tools like Claude Desktop or OpenAI Codex that will then create sub-agents. "Those sub-agents don't assume the same rights and responsibilities and authorization as the parent agent," he says. "So they try to delegate tasks that can be wholly controlled." How to manage AI agent identity Most companies haven't developed the tools to keep track of all these different agent types yet. The first step is to identify them. This is where many organizations make their first mistake by bolting agents onto the human identity and access management (IAM) stack they already have. The idea is that if you give an agent a service account and a long-lived API key you can treat them like a super-fast employee. That's impractical. "IAM was built for a human sitting at a keyboard who can tap 'approve' on their phone," Trzupek says. "An agent can't do that. So you fall back to a static API key that never expires and has way more scope than it needs, and now you've undone everything zero trust was supposed to give you. It's the exact credential we've spent a decade telling people to get rid of." Industry bodies have started converging on a different answer. IDC now recommends treating agent identity as a workload identity problem rather than an extension of human IAM, aligning with the IETF's Workload Identity Management and Security Extensions (WIMSE) and NIST's Cybersecurity Framework version 2.0. They can then frame agents as governed workloads requiring runtime attestation and short-lived credentials . This idea also pushes teams toward the Service Profile Identity (SPIFFE) and its SPIFFE Registration Endpoint (SPIRE). This is an open workload identity standard already deployed inside many hyperscaler-hosted Kubernetes estates, and they're part of DigiCert's AI strategy. DNS is a governance tool for agentic AI Inventory and identity might get you visibility, but you still need somewhere to enforce policy. DigiCert has strong opinions about where, tied to its history managing DNS integrity. No matter whether an agent is resolving an API endpoint or connecting to an MCP server, it has to query DNS first. So why not make that a core verification point? DigiCert proposes a solution that looks a lot like the DMARC standard used for email. An organization would publish an agent policy record in DNS that declares several things: · Its authorized agent identities · The certificate authority that issued their credentials · The scopes they're allowed to act within A gateway can then query that record to verify whether an inbound agent is legit, and terminate the session if the check fails . And if an agent contacts an unauthorized domain mid-execution, DNS can block the query and the MCP gateway kills the session. IDC likes this idea but warns that scale is an issue. As the number of agents grows, DNS records might not keep up, and stale records might become a loophole. Overly permissive scope declarations are also still a potential problem. "The scale problem is real, but it's the same problem DNS has solved a hundred times before," Trzupek responds. "You automate the lifecycle, you tie the record to the certificate issuance, and when the cert expires the record goes with it." And operators writing wildcard scopes because they're in a hurry is a discipline problem, not an architecture problem, he adds. Inside DigiCert's AI Passport Agents built in-house live alongside third-party agents like Microsoft Copilot, Salesforce Agentforce and ServiceNow, and the control planes for the two categories are different. DigiCert's answer is a single SPIRE server anchored to a DigiCert CA for identity, with policy enforced centrally in an Open Policy Agent engine, and a unified kill switch that operates across both categories. The AI Agent Passport is the artifact that ties the identity to the authorization. It's a cryptographically protected record of approved systems and permitted operations. Each 'passport' also contains things like data sensitivity classifications and expiration state, along with an accountable human owner. Trzupek says the field that generates the most pushback in the design is policy itself, because customers typically have a complex web of policies already in GCP or AWS. "Trying to replace those or displace them is a fool's errand," he says. So the passport can hold pointers to those engines rather than replacing them. How to manage model integrity Governing agents is only half of the challenge. The models themselves are strategic assets, and they're subject to integrity and provenance controls too. That means encryption and cryptographic signing of model artifacts, Open Container Initiative-compliant packaging with tools like the Sigstore code signing initiative, and a cryptographically verifiable Model bill of materials describing weights, datasets and dependencies . It also means governing models at runtime, not just securing the supply chain. DigiCert's AI Trust framework advocates trusted hardware execution to help solve that problem. A model running inside a trusted execution environment on Intel TDX or AMD SEV-SNP stays encrypted in memory, isolated from the host OS. DigiCert operates a confidential computing attestation service that follows the IETF Remote ATtestation Procedures (RATS) architecture. The execution environment is the attester and DigiCert is the verifier. Downstream systems are the relying parties. This approach moves attestation from a neutral third party rather than the cloud operator running the workload, which serves regulated buyers. Hyperscalers shouldn't attest to their own integrity. Those regulated buyers face some heavy governance conversations. In healthcare, the question is whether the AI model cleared through an FDA 510(k) pathway is the exact algorithm running in clinical deployment. Cryptographic attestation lets these companies prove model integrity before every inference. That addresses the FDA's 2023 cybersecurity guidance on software integrity verification and SBOM enforcement. But while some regulated verticals have specific needs, AI governance is a cross-sector problem. Any organization storing customer data an agent can access or exfiltrate needs these controls. Why build in AI governance now This is agentic AI's moment, so companies are at a pivot point, and they've been here before. Many of them spent the last 25 years following a cybersecurity antipattern: move fast to grab an opportunity with a significant new technology development, and call in the security team later to clean up the loose ends. It hasn't gone well. With many organizations at the beginning of their agentic AI journey, they now have an opportunity to break that habit and do things right from the beginning using verifiable controls. As frontier model prices climb and AI crops up as a noticeable cost on enterprise budgets, this will become an increasingly visible choice, concludes Trzupek. Companies will hold people more accountable for their use of agentic technology. Wouldn't it be nice to have the controls in place and be ahead of the game for once? Sponsored by DigiCert
theregister.comSep 15, 2026extracted
The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild. The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities. Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process. As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact. When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure: Harden nodes Restrict root access Prohibit privileged containers, host access Minimize reliance on weak selectors Palo Alto Networks customers are better protected from the threats described here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads. However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node. Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs). Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections. Consider a scenario where two applications, a frontend and a backend, must communicate securely. We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions: Who rotates those keys? Who revokes them if the app is compromised? Can we verify who/what is presenting the keys? SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued. The term machines refers to two broad categories: Workloads: Containers, processes and services running application logic Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems - (Note: Device identity is not part of the core SPIFFE specification) Each workload is assigned three identity components: SPIFFE ID: Who you are (your name) SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials) Trust Bundle: How others verify that a trusted authority issued your credential Let’s go into a little more detail about each of these. SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe:// / (Figure 1). The middle part (example[.]com) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary. In this way, workloads can have an identity and know who to communicate with. However, identity alone does not guarantee trust or security, so we add the SPIFFE Verifiable Identity Document (SVID). This is a short-lived credential that a workload presents to prove its identity. It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID. SVIDs support two primary formats: X.509 SVID: A certificate with an embedded public key, typically used for mTLS JSON Web Token (JWT) SVID: A signed JWT token used as a bearer token for application-level authorization Finally, we have the trust bundle, which is a set of trust anchors — root CA certificates or JSON Web Key Sets (JWKS). These are used to verify that a trusted authority issued an SVID within a trust domain. To understand how these identity components are issued and verified in practice, we first need to look at the SPIRE architecture and its core runtime components. SPIRE is a production-ready implementation of the SPIFFE specification. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice. SPIRE is composed of a few simple pieces (as shown in Figure 2 below): Workload: A single piece of software deployed to do a specific job (e.g., a process, container, pod) SPIRE Server (control plane): This is the CA that stores registration entries. It also issues and cryptographically signs SVIDs. Additionally, it publishes the trust bundle for the trust domain. SPIRE Agent: This runs on every compute node (e.g., a Kubernetes node, VM or bare-metal host). It performs the following activities: - Accepts requests from workloads locally over the Workload API (UNIX socket) - Communicates with the server via the Node API - Performs attestation - Caches SVIDs - Handles rotation Registration entries and selectors: These are server-side policy objects that define which workloads are allowed to receive which SPIFFE IDs. When a workload requests an identity, the SPIRE agent collects runtime attributes (selectors) about the workload and the server compares them against registration entries to determine which identity, if any, should be issued. With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end. When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The agent attests the workload and forwards the attestation data to the SPIFFE server. Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID. The server also publishes the corresponding public keys as part of the trust bundle. When workload A initiates a connection, it presents its SVID during the mTLS handshake. Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity. If these checks succeed, workload B can cryptographically authenticate workload A and establish a secure connection. This enables workload-to-workload communication based on identity rather than long-lived secrets (Figure 3). The identity flow described above depends on attestation, the process by which SPIRE determines whether a workload is allowed to receive an identity. SPIRE performs attestation at two levels: Node attestation establishes trust in the agent running on a node Workload attestation determines the identity of individual workloads In this post, we focus on workload attestation, as it is the mechanism directly involved in selector evaluation and the attacks discussed later. Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent. In this Kubernetes example, the registration entry authorizes any pod running in the default namespace and using the default service account to receive the specified SPIFFE identity (spiffeID). The resulting record is stored on the SPIRE server as follows: The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies. The agent generates key pairs for each registration entry, sends certificate signing requests (CSRs) to the server and caches the resulting SVIDs. When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1). The agent performs workload attestation (Figure 4, step 2) by gathering selectors from the workload process and matching them against cached registration entries. Upon a successful match (Figure 4, step 3), the agent returns: X.509 SVID Private key Trust bundle Note: This example is based on an X.509 SVID request. For JWT SVID requests, the agent returns only a signed JWT token. With the high-level flow in mind, we can now examine how attestation works in practice. When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock). The agent then extracts the PID for the calling process. Once the agent receives the PID, it passes it to the configured workload attestor plugins, which collect selectors based on process and container metadata. SPIRE agents support several workload-attestor plugins. Common plugins include docker, k8s, systemd, Unix and Windows. In our cluster, the agent uses the k8s and Unix plugins. The k8s plugin uses the workload PID to access /proc/ /mountinfo or /proc/ /cgroups. It calls GetPodUIDAndContainerID to extract the pod UID and the container ID. In our environment, this process looks like the following: After extracting the container ID and pod UID, the k8s plugin queries the kubelet to retrieve pod metadata. To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token. The agent's service account has the following permissions, which allow it to list pods and access node information: Using this token, the plugin calls getPodList to retrieve all pods on the node. It then identifies the pod whose UID and container ID match the values extracted from the /proc directory. Once matched, it collects selectors from the pod's metadata: The Unix plugin gathers information from /proc to produce selectors such as user identifier (UID) and group identifier (GID). These selectors are used during workload attestation to bind a workload’s identity to operating system level properties of the calling process, helping SPIRE distinguish between different workloads running on the same node. Here is an example of the selectors it collects: The agent combines these selectors from both the k8s and Unix plugins. It then matches this selector set against the locally cached registration entries. If an entry's selectors are a subset of the workload's selectors, the agent returns the corresponding cached SVID to the workload. This attack requires root-level access to the node. Our analysis revealed that workload attestation relies heavily on the workload’s cgroup path. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity. This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity. As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod: We verified that we could not retrieve this identity from the host by requesting a JWT SVID: To spoof the workload-a cgroup, we first retrieve its PID: We checked its cgroup path based on the above PID: We copied this path to a mock cgroup path and wrote our shell’s current PID($$) into the mock cgroup’s cgroup.procs file: Notably, writing the PID directly into the original cgroup path would have also worked. We used a separate cgroup only to avoid modifying the original workload’s runtime state. Running the fetch command again successfully retrieved the identity associated with PID 9072: We can also see the workload-a SPIFFE ID inside the JWT token: The manual spoofing demonstration highlights that the security model relies entirely on a single, vulnerable assumption of node integrity. When we have root access, we can get the identity of any workload on the node. This manual spoofing demonstration highlights a critical trust assumption in workload attestation. When an attacker has root-level access to a node, they can manipulate cgroup information to cause the SPIRE agent to misattribute workload identities. Under these conditions, the attacker can impersonate other workloads running on the same node and obtain their identities. These findings motivated us to develop Spooffe, a tool that allows defenders to automate selector spoofing to retrieve all the workload identities from the node. Spooffe scans the node for running workloads, discovers their cgroup paths, and replicates them as a mock cgroup for its own process. It then queries the local SPIRE agent for the resulting identities (SVIDs), allowing us to collect all workload identities present on the host (Figure 5). Besides selector spoofing, Spooffe includes additional capabilities. However, in this post we focus only on the features relevant to this research. One such capability is agent impersonation, which examines whether an attacker can impersonate the SPIRE agent and communicate directly with the server to extract workload identities. In this article, we demonstrated how an attacker with root access on a compromised node can misuse SPIFFE/SPIRE workload attestation to impersonate co-located workloads and retrieve their identities. By manipulating cgroup metadata, we showed how attackers could mislead the SPIRE agent into issuing valid SVIDs to an attacker-controlled process. We also introduced Spooffe, a tool that automates this technique to enumerate and extract workload identities from a node. These findings highlight a fundamental assumption in workload identity systems: trust in the underlying node. While SPIFFE/SPIRE enforces strong cryptographic identity guarantees between workloads, those guarantees rely on the integrity of the environment where attestation occurs. Once that trust boundary is broken, identity isolation between workloads collapses, allowing attackers to move laterally using legitimate credentials rather than stolen secrets. Organizations adopting workload identity should treat node-level compromise as equivalent to compromise of all identities scoped to that node. To reduce risk, restrict privileged containers, limit direct host access and minimize reliance on weak or easily spoofable selectors. Palo Alto Networks has shared our 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. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM can help protect against post-exploitation activities using the multi-layer protection approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection, and Endpoint Protection Modules (EPM). Cortex Cloud Identity Threat Detection can help deliver end-to-end visibility across cloud providers and IdPs by baselining real-time access patterns. By continuously monitoring these behaviors, ITDR detects identity abuse and compromised credentials targeting critical cloud resources and Kubernetes workloads, automatically triggering containment actions to keep attackers out. If you think you might 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 Spooffe — GitHub
unit42.paloaltonetworks.comSep 10, 2026extracted
Product showcase: GitGuardian Honeytoken catches credential theft as it happens
Product showcase: GitGuardian Honeytoken catches credential theft as it happens Credential harvesting on developer machines has widened. Earlier infostealers worked from a short list of known targets, mostly browser stores and a few cloud credential paths. The families active now cast a much wider net. Shai-Hulud, for instance, ran a secret scanner across the entire filesystem and validated whatever it turned up, rather than checking a handful of expected locations. That breadth is what makes deception practical, and the speed is what makes it urgent. A harvester that validates what it collects tests a stolen credential in seconds, not hours. Initial compromise is no longer a window you get to investigate. By the time anyone would normally think to look, the credential has already been taken, checked, and used. An attacker sweeping a whole disk for anything credential-shaped will pick up a decoy wherever it happens to sit, and will test it along with everything else. That first validation attempt is the alert, and it is the only moment early enough to matter. Why deception has underperformed its promise Behavioral detection works from hints. It watches process activity, file operations, and network calls, weighs them against known patterns, and estimates how likely it is that something malicious is happening. Good products estimate well, but the estimate is still the product. A honeytoken removes the inference. The credential exists for no reason other than to be stolen, so nothing in normal engineering work has any cause to touch it. Its use is not evidence of an intrusion; it is the intrusion. Because there is nothing to weigh, there is nothing to get wrong, which is where the near-zero false-positive rate comes from. Given all that, the obvious question is why deception is not already everywhere. The answer is operational rather than conceptual. Planting decoys by hand does not scale past a handful of high-value systems. Someone has to decide what to plant, where to put it, and keep it there as machines are reimaged and developers come and go. A decoy that quietly disappears after three months is worse than no decoy at all, because the team believes it is covered. GitGuardian introduced fleet-wide deployment through mobile device management (MDM), which removed the manual planting problem: an agent already running on every machine can place a decoy and put it back if someone deletes it. Research into how credential stealers actually behave solved the other half, since we no longer have to guess what a stealer will find attractive when we can study what it collects and match it. What runs today Honeytokens have been part of the GitGuardian platform for several years, and what teams can do with them today is broader than the term “decoy credential” suggests. Teams create honeytokens through the dashboard, the API, or the command line. They then place them wherever an attacker is likely to go looking: source code repositories, configuration files, internal documentation, deployment scripts, and continuous integration pipelines. A planted honeytoken resolved to the machine it sits on and the credential file it was written to. The events table is empty, which is what an untouched decoy looks like. Since June 2026, that placement extends to developer laptops. Honeytokens deploy across the fleet through existing MDM tooling, which means a security team can cover several thousand machines without touching any of them individually, and the dashboard reports which endpoints actually carry a decoy rather than leaving anyone to assume coverage. Decoys that get deleted are replaced on the next sync. Honeytoken protection on a single endpoint, showing the last sync, how many decoys are deployed, and how long the machine has been covered. The token is active and has never been triggered. Operationally, the alerting is what matters. When someone attempts to use a honeytoken, GitGuardian raises an incident naming the machine and the file the credential came from, then routes it through whatever the team already runs, whether that is email, Slack, Teams, ServiceNow, or a webhook of their own. Nobody has to watch a new console, which is less trivial than it sounds when most detection tooling asks a team to absorb more alerts than it did the week before. This one asks them to absorb an alert that is always worth acting on. Extending the bait beyond cloud keys Today’s GitGuardian honeytokens are AWS credentials, and the decoy is a real key issued from an AWS account that GitGuardian controls. Every API call made against that key is logged in the account it belongs to, so when an attacker tests the credential, we see the attempt, along with when it happened and where it came from. Most credentials on a developer machine offer nothing comparable. Kubernetes cluster access, package registry logins, and other service credentials follow different formats and route to different places, and several are among the first things the package registry worms go looking for. Covering them takes more than writing a convincing-looking file to disk, because something has to be waiting at the other end when the attacker tries it, ready to recognize the attempt and trace it back to a specific customer and machine. That is the work underway now, and it is deliberately built once rather than rebuilt for every credential type. Because nothing after the alert has to change, each new kind of decoy arrives inside the setup a customer already has: the same incident, the same notification routes, and the same workflow. Designing decoys that hold up A decoy is only useful while an attacker cannot tell it apart from a real credential, and that constraint shapes the design more than anything else. The credential formats we are adding carry no internal structure that could give a decoy away. The identifier inside the file is random, with no encoded owner or account for an attacker to work out, so a stolen decoy tells them nothing even under close inspection. The infrastructure behind those decoys is kept separate from anything that would identify it as ours, on the assumption that a motivated attacker will eventually go looking. Beyond that baseline, though, effective deception turns out to depend far less on elaborate camouflage than most threat models would suggest, because the malware doing the collecting is nowhere near as discerning as the adversary those models are built around. What matters is matching how credentials are actually harvested in the wild, which is a lower bar than designing against a hypothetical attacker and a considerably more useful one. An honest limit Deception detects use, not theft. A decoy that is stolen and never touched again will stay quiet, and no implementation can change that, because the control only fires when someone acts on what they took. This is the reason deception belongs alongside credential discovery rather than in place of it. Discovery tells you which valid credentials are exposed on a machine and hands you a list to revoke, while deception tells you the moment someone reaches for one. A team running only the first has an inventory of risk with nothing watching it, and a team running only the second is waiting on an alert about exposure it never measured. Where this goes next The work runs in two directions: more places to plant, and more kinds of honeytoken to plant. On placement, continuous integration runners and Kubernetes clusters are both in scope, since recent worm variants were built to land in build environments. On coverage, Kubernetes configuration files and package registry logins are the credential types we are building toward. Google Cloud and Azure credentials sit further down the list, because our review of infostealer samples shows they are barely touched today. We would rather add coverage where the harvesting is actually happening. Where honeytokens sit in the GitGuardian platform Honeytokens are the deception layer of the GitGuardian secrets and non-human identity security platform. Developer Endpoint Protection is what plants and maintains them across a developer fleet. Together with credential discovery, they answer the two questions a security team has about any machine: what is exposed on it, and has anyone reached for it. The credential surface on a developer machine keeps growing, and AI coding tools are adding new paths to it every quarter. The teams that will catch a harvest early are the ones with something waiting in those paths before the harvest happens. See it running end to end in a live GitGuardian platform demo, from developer endpoints to identity visibility.
helpnetsecurity.comSep 10, 2026extracted
CVE-2026-85781 - Unverified access point ownership in Amazon EFS CSI Driver
CVE-2026-85781 - Unverified access point ownership in Amazon EFS CSI Driver Bulletin ID: 2026-099-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/04/2026 11:45 AM PDT Description: The Amazon EFS CSI Driver is an open-source Kubernetes Container Storage Interface (CSI) driver that lets Kubernetes workloads use Amazon EFS file systems. We identified CVE-2026-85781, an issue in the driver's volume-deletion logic. When the controller is configured with the non-default --delete-access-point-root-dir=true option, it did not verify that the EFS access point referenced by a PersistentVolume's volume handle belonged to the file system referenced by that same volume handle. An authenticated Kubernetes user with permission to create PersistentVolumes could use a crafted volume handle to cause the controller to recursively delete directories from an Amazon EFS file system that the user was not otherwise authorized to modify. This issue does not affect Amazon EFS itself; Amazon EFS access controls operated as designed. Impacted versions: <=3.4.0 Resolution: This issue has been addressed in Amazon EFS CSI Driver version v3.4.1. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. Only customers who use the --delete-access-point-root-dir option are affected. Workarounds: Customers who cannot upgrade immediately should disable --delete-access-point-root-dir, restrict PersistentVolume-creation RBAC to trusted administrators, scope the controller's IAM role to only the file systems it must manage, and attach explicit EFS resource policies to file systems. References: Please email [email protected] with any security questions or concerns.
aws.amazon.comSep 9, 2026extracted
The state of AI for security: Measuring what matters most for building trust
Security teams are starting to actively use AI for security work, including vulnerability triage, penetration testing, threat modeling, incident response, and code review. The promise is speed, but a security tool that moves fast and raises too many false alarms doesn’t save time. Engineers spend time on false alarms, on-call is noisier, and teams distrust findings that matter. Today, we’re releasing Deception Benchmark, the first benchmark designed to measure that trust problem directly. It tests whether a model can distinguish real vulnerabilities from code that looks risky but is actually safe. The benchmark includes 14,822 samples across 16 languages and more than 70 Common Weakness Enumeration (CWE) categories. We evaluated 12 models from five providers and are releasing the dataset and whitepaper to the community. Existing benchmarks measure whether AI can find or exploit vulnerabilities. This is the first to measure whether it can tell real vulnerabilities from false alarms. Under standard prompting, precision at distinguishing real vulnerabilities from false alarms landed in the mid 50s; as likely to be inaccurate as accurate. In offensive tasks, there’s often a clear result: the exploit works or it doesn’t. Defensive reviews are harder to verify than offensive tasks; a model might recognize a suspicious pattern even when a mitigation makes the issue non-exploitable. In practice, useful systems need to reason about the code, the mitigation, and sometimes the surrounding environment. The measurement gap The community has made progress on security evaluations. CyberGym tests agents on more than 1,500 realistic tasks. Meta’s CyberSecEval and CyberSecEval 2 measure exploit generation. CYBENCH evaluates capture the flag (CTF) challenges. SEC-Bench and VulnBench push toward authentic security workflows. Recent work reinforces both the progress and the gap. ExploitGym measures whether AI can escalate from a crash to a working exploit. Microsoft’s Project Perception deploys multi-agent red/blue/green teams for continuous defense. OpenAI’s GPT-Red shows that self-play red-teaming finds novel attacks that frontier models can’t defend against. Since then, OpenAI disclosed that its GPT-6 Astra model crossed the Critical cybersecurity capability threshold, and both OpenAI and Anthropic reported incidents where models gained unauthorized access to production systems during evaluations. The offensive side is moving fast. But none of this work measures the defensive precision question: when an AI system flags code as vulnerable, how often is it right? Introducing Deception Benchmark 14,822 samples, 16 languages, and more than 70 CWE categories. We call it Deception Benchmark because the safe samples are designed to deceive models. It has real vulnerability patterns, real frameworks, real idioms, with mitigations that quietly close the exploit path. The goal is to classify code as vulnerable or safe, with no hints. Consider a Flask endpoint that accepts user input and queries a database. A model will pattern-match to SQL injection, but the query uses parameterized statements, so the exploit path is closed. A single-turn classifier flags the pattern and moves on, never checking whether the exploit can actually work. Production tools rely on multi-step loops and agentic workflows to compensate, but that scaffolding masks whether the model itself understands the code. This benchmark strips the scaffolding away and asks the model to make the call in a single pass, so what it measures is understanding, not how many tries a harness takes to get there. We built every sample through an adversarial loop: generate, test against frontier models, harden, repeat. If a model gets it right easily, the sample doesn’t survive. The result is a benchmark calibrated to the frontier, not below it. Building it this way is expensive. Generation and hardening of the samples consumed tens of billions of tokens. We’re releasing the result so the community doesn’t have to repeat that cost. This benchmark generates two challenge types. Code-level challenges (6,988 samples) present vulnerable and safe variants that differ by a subtle fix. Both look suspicious, only one is exploitable. Environment-gated challenges (2,707 samples) go further: same code, different deployment context. A Kubernetes Network Policy blocks the server-side request forgery (SSRF) path. An identity and access management boundary prevents privilege escalation. The pattern is visible in the source. The infrastructure makes it unexploitable. The model has to figure out which scenario applies. All samples were purpose-built for this benchmark, grounded in real-world patterns, real frameworks, real CWEs, and real infrastructure; without IP concerns or training data contamination. Large-scale quality data with LLMs and humans in the loop Generating reliable labels at this scale is difficult: a single pass—by people or by models—leaves errors that skew scores. So we treat labeling as a convergent audit loop rather than a one-time step. Every label is re-examined by multiple independent reviewers, blind to one another and to the original reasoning that produced the label. Disagreements escalate to direct adjudication, where the original reasoning is evaluated against the challenge. Unresolved cases go to human review. We repeat the loop until the scored set converges below a dispute threshold: under 3 percent of samples still contested by independent review, with a target of under 1 percent surviving human adjudication. One choice makes this defensible: we never relabel a disputed sample. When reviewers disagree, the sample moves to the unscored pool instead of being given a corrected label, so a bad challenge can remove a sample but can never introduce a wrong label into the scored set. A human review of 100 randomly drawn scored samples found no label errors. We describe the full process in the whitepaper . The results The benchmark is roughly balanced: half vulnerable, half safe, so a random classifier scores 50 percent. We report two error rates separately, because they fail in opposite directions. The false positive rate (FPR) is how often the model flags safe code as vulnerable. These are the false alarms that waste an engineer’s time. The false negative rate (FNR) is how often it misses a real vulnerability and calls it safe. Accuracy alone hides this: a model that labels everything vulnerable catches every bug (0 percent FNR) but flags all safe code (100 percent FPR) and still scores about 50 percent. We consider FPR below 10 percent and FNR below 10 percent the minimum bar for production use. Figure 1: FPR compared to FNR for 12 models across two prompting strategies. No model reaches the generous bar. Model Prompt Accuracy FPR FNR GPT-5.6 Sol Direct 54.9% 92.5% 0.9% GPT-5.6 Sol PoE 58.9% 58.6% 23.1% GPT-5.5 Direct 56.9% 87.8% 1.3% GPT-5.5 PoE 62.9% 63.6% 12.4% GPT-5.4 Direct 60.2% 81.0% 1.5% GPT-5.4 PoE 77.7% 10.1% 33.6% Llama 3.3 70B Direct 58.8% 84.2% 1.1% Llama 3.3 70B PoE 72.2% 10.2% 44.2% Claude Haiku 4.5 Direct 55.6% 92.1% 0.0% Claude Haiku 4.5 PoE 75.6% 22.4% 26.3% Claude Opus 4.6 Direct 55.9% 91.3% 0.1% Claude Opus 4.6 PoE 75.8% 42.7% 7.0% Claude Opus 4.7 Direct 58.3% 85.5% 0.9% Claude Opus 4.7 PoE 75.9% 32.0% 16.8% Claude Opus 4.8 Direct 53.8% 95.7% 0.2% Claude Opus 4.8 PoE 75.8% 32.5% 16.4% Claude Opus 5 Direct 77.3% 41.5% 5.2% Claude Opus 5 PoE 79.3% 24.9% 16.8% Claude Sonnet 5 Direct 62.9% 74.7% 2.2% Claude Sonnet 5 PoE 74.7% 31.8% 19.2% Amazon Nova 2 Lite Direct 56.3% 89.2% 1.2% Amazon Nova 2 Lite PoE 70.1% 45.2% 15.5% Mistral Large Direct 52.2% 99.0% 0.0% Mistral Large PoE 65.5% 49.3% 20.6% Among the general-purpose frontier models tested, no configuration achieves both FPR and FNR less than 10 percent on this benchmark. Every model has the same failure mode. With direct prompting, they catch up to 95 percent of real vulnerabilities but also flag 41–99 percent of safe code. Precision runs from 52 percent to 71 percent, clustered in the mid-50s; effectively as likely to be inaccurate as accurate. The models see a vulnerability pattern and stop reasoning. Proof-of-exploit prompting cuts false positives by 17–74 points but misses 7–44 percent of real vulnerabilities. The environment-gated challenges are worse: models flag the code and ignore the Kubernetes Network Policy next to it. No tested configuration keeps both false positives and false negatives below 10 percent. These results reflect general-purpose models in single-turn prompting. Purpose-built systems with multi-step validation and tool use are a different operating point that we didn’t measure, and if a harness can close the gap between pattern recognition and genuine understanding, this benchmark is the place to demonstrate it. Two cautions before assuming it already does. Agentic verification is proven mostly on offensive tasks, where success can be confirmed: the exploit fires or it doesn’t. Judging that code is safe has no such oracle. Extra iterations re-sample the same judgment rather than confirm a negative, and a harness still inherits the base model’s understanding. If the model can’t separate an effective mitigation from an ineffective one in a single pass, more passes won’t add the missing knowledge. That’s what this benchmark measures: the model’s intrinsic ability to understand code, tested at the single-turn baseline where no scaffolding can mask the gap. For security teams evaluating AI tools today: ask your vendors how their system performs on tasks like this, not just whether it finds vulnerabilities, but how often it’s wrong. Pair any AI-assisted review with human verification on high-risk code paths, and use Deception Benchmark to hold your tools accountable. Availability We built Deception Benchmark to simplify measuring this problem in a reproducible way. The public release includes the samples and evaluation workflow. We don’t release the labels, so submissions can be scored consistently over time without turning the benchmark into a memorization exercise. Of the 14,822 samples, 9,695 are scored; the remaining 5,127 are held out and unscored, mixed in with the rest of the benchmark. The goal is straightforward: make it more difficult to optimize the benchmark compared to improving the underlying system. We describe that design in more detail in the whitepaper. Deception Benchmark is available on GitHub , along with the whitepaper and submission instructions for verified scoring. If you’re building security tooling, you can download the dataset, run your system against the benchmark, and submit predictions for scored evaluation. If you have feedback about this post, submit comments in the Comments section below. Anshumali Shrivastava Anshumali is an Amazon Scholar and Full Professor of Computer Science at Rice University. His research on dynamic sparsity, sketching, and hashing pioneered techniques now central to efficient LLM training and inference. A two-time founder — ThirdAI (acquired by ServiceNow) and XMAD.ai (acquired by Workato) — he bridges theoretical computer science and practical AI systems at scale. Neha Rungta Neha is a scientist and builder who has spent her career making machines reason about complex systems at scale. Her work spans automated reasoning, formal verification, security, and AI, shaping systems including Cedar, IAM Access Analyzer, and Continuum. Today, she is forging the next generation of machine reasoning, combining LLMs, formal methods, and agentic systems.
aws.amazon.comSep 9, 2026extracted
Slim Spider Steals Crypto Custody Secrets From Brazilian Financial Institution
A previously undocumented financially motivated threat actor has been linked to attacks targeting Brazilian financial institutions since at least March 2026. Cybersecurity company CrowdStrike is tracking the Brazil-based activity cluster under the name Slim Spider. "The adversary demonstrates deep operational knowledge of Brazilian financial infrastructure, including the instant payment service Pix, digital asset platforms, and financial entities' cloud environments," CrowdStrike said. Slim Spider has been observed orchestrating a multi-stage intrusion at a Brazil-based financial institution in late March 2026, setting its sights on the entity's cryptocurrency assets and instant payment accounts. As part of the attack, the e-crime group is said to have developed custom Bash scripts that query the cloud instance metadata to steal temporary cloud credentials over socket connections. Upon establishing access to the organization's cloud environment, the threat actor enumerated all available secrets stored in the cloud credential manager and used the "sed" command to clone and modify secret-extracting scripts. The approach specifically focuses on credentials tied to digital financial assets. "Following exfiltration of digital asset custody secrets, Slim Spider invoked cast, a component of the Foundry Ethereum developer toolkit, to derive the Ethereum wallet address associated with a stolen private key," CrowdStrike explained. "Rather than relying on third-party libraries that could introduce detection risk, the threat actor implemented cloud-native cryptographic signing directly via OpenSSL within their Bash scripts. This deliberate choice reflected sophisticated operational security awareness and a nuanced understanding of cloud environments." In the observed attack, Slim Spider moved to establish access to nodes running in a cloud container service cluster, while deploying backdoors mimicking infrastructure-related binaries to blend with legitimate tooling and fly under the radar. The threat actor then pivoted to Azure DevOps, likely using compromised credentials, to run malicious pipelines that deployed additional implants across a managed Kubernetes cluster. One of the implants was named "spi," an attempt to impersonate Sistema de Pagamentos Instantâneos (SPI), which refers to the central digital infrastructure that processes Pix payments in Brazil. Slim Spider has also been linked to various web-based panels to automate and streamline different aspects of the attack chain - NEXUS // Scanner, an API endpoint-scanning panel that uses Ollama to slot endpoints into 16 categories, such as fintech, banking, payment, and cryptocurrency, and rank them based on availability and authentication options Painel de Emails Entra ID, an email reconnaissance panel that searches compromised Microsoft 365 mailboxes sorted into finance, admin, and Brazil categories Painel Pix, a transaction panel designed to execute bulk unauthorized Pix transfers from compromised accounts CrowdStrike said it discovered an exposed command-and-control (C2) panel connected to the threat actor that displayed several compromised hosts from several Brazil-based banks and fintech organizations and likely exfiltrated archive files. According to the cybersecurity vendor's adversary profile, another key tool in Slim Spider's arsenal is MikeDor, a Go-based backdoor capable of harvesting sensitive information and monitoring user activities. "Slim Spider's knowledge of the cloud attack surface allows them to target credentials associated with an organization's valuable digital currency assets, including custody credentials that control cryptocurrency wallets," it said. "Access to such assets can result in devastating financial loss for victims." "E-crime threat actors are demonstrating increasingly sophisticated cloud awareness, deliberately targeting the infrastructure and credentials that sit closest to high-value financial assets." The disclosure coincides with the emergence of another cybercrime group dubbed Breeze Comet (aka CL-CRI-1163, Plump Spider, and SHADOW-AETHER-064) that's infiltrating Brazilian financial systems to abuse payment infrastructure and carry out illegal transactions for financial gain. Google Threat Intelligence Group (GTIG) and Mandiant said the Portuguese-speaking hacking group breaks into systems that Brazilian financial organizations use to perform transactions and initiates payments for itself. The earliest attacks date back to 2024. The threat actor has also been spotted using insufficiently secure Brazilian government websites to stage its malware, and leveraged their reputation in follow-on social engineering attacks against its targets. To make matters worse, Breeze Comet has attempted to replicate this formula in other regions, hacking municipal websites in countries like Nigeria, Paraguay, Ghana, and Venezuela. The ultimate goal is to obtain access to the financial applications that the breached organizations use to make payments, including Pix, Boleto, and the Reserves Transfer System (STR), and execute hundreds of fraudulent transactions. The targeting of Pix by two different threat actors indicates how the most widely used payment method in Brazil has become a lucrative target across operating systems. "While the Latin American cybercrime ecosystem has historically been defined by client-side, high-volume retail fraud, Breeze Comet's campaigns represent a notable shift that may serve as a model for future financially motivated threats against organizations in this region." "This transition from opportunistic retail banking fraud to direct intrusions into the core financial switch and instant payment infrastructure is notable not just for this shift in targeting, but also the capabilities of the threat actor."
thehackernews.comSep 8, 2026extracted
Autonomous AI Agents Compromise Thousands of Credentials in Under Six Hours
Threat actors are continuing to leverage artificial intelligence (AI) to streamline their operations, with one financially motivated hacking group employing an autonomous, multi-agent attack framework to carry out a large-scale credential harvesting campaign within six hours. Google Threat Intelligence Group (GTIG) said it has observed attackers with diverse motivations targeting proprietary AI models across healthcare, government, and media sectors, exfiltrating API credentials, and co-opting victim cloud environments to sustain unauthorized AI workloads. This highlights growing attacker focus on enterprise AI assets for espionage, extortion, and resource theft. "At this point, we can assume that all threat actors are using AI in some capacity and their operations have benefited," John Hultquist, chief analyst at GTIG, said in a statement shared with The Hacker News. "Like everyone else, we're concerned about the vulnerability problem, but AI is being applied to several other areas, and it will be especially challenging as it is applied agentically, creating a scaled, faster adversary. Criminals, like the ones who conducted a mass exploitation campaign in just six hours, will gravitate to attacks that are faster than we can respond to." Google noted that the integration of AI-assisted coding tools has not only accelerated software development cycles but also increased threat actors' targeting of developers, AI coding assistants, and LLM security scanning tools, thereby raising open-source supply chain risks. This has been fueled primarily by a financially motivated threat actor known as TeamPCP (aka Altered Spider and UNC6780), which has conducted a series of large-scale software supply chain compromises targeting PyPI, npm, and Docker Hub. The initial compromise is followed by the deployment of credential stealers like SANDCLOCK and DUSTMAKER to obtain sensitive data and target AI coding assistants, which are then monetized either via direct sale or through partnerships with ransomware and data theft extortion groups. "DUSTMAKER is a successor to the SANDCLOCK credential stealer in TeamPCP operations," GTIG told The Hacker News. "SANDCLOCK (used in March and April 2026) is a component of what has publicly been referred to as CanisterWorm, was primarily written in Python, and is designed to operate on Linux and interact with Kubernetes. It includes container escape functionality and targeted cryptocurrency wallets in addition to cloud and developer credentials." "DUSTMAKER (used in April and beyond) is a cross-platform JavaScript payload optimized for CI/CD pipelines. It does not contain container escape functionality, and while some variants have targeted cryptocurrency wallets, its overall focus is credential theft to facilitate extortion operations. The AI-targeting techniques [...] – specifically the poisoning of AI assistant workspaces and the use of prompt injection for defense evasion – are exclusive to DUSTMAKER and were not present in earlier SANDCLOCK variants." Elsewhere, Google said it detected instances where threat actors are misappropriating proprietary AI research and models - A China-nexus threat actor known as UNC6508, which is suspected to have compromised cloud environments to deploy local LLM infrastructure that uses a local, open-weight model, as opposed to a commercial frontier model, thereby evading monitoring by AI model providers. Several data theft extortion operations in which threat actors have been observed stealing proprietary AI data, including models, skills, prompts, source code, and related research. Threat actors carrying out distillation attacks against Google's AI models that target its visual and audio understanding, image generation, and video generation capabilities. Adversaries have also been observed ramping up use of agentic AI to facilitate malware and tooling development, with a China-aligned cyber espionage group leveraging Gemini to design and develop an automated penetration testing framework. "The group sought to build an agentic architecture capable of observing target state, reasoning through actions, and executing tasks in unpredictable environments," Google said. "The planned agent was designed to perform discovery tasks such as port scanning and service parsing, demonstrating an intent to automate initial discovery and execution phases." Another threat actor found engaging in similar efforts is believed to be financially driven. The activity involved the attackers compromising an unnamed organization's cloud infrastructure to deploy an autonomous, multi-agent attack framework to conduct a credential harvesting operation at scale. "The threat actor leveraged an AI coding chatbot, a prompt, and a set of agent instructions to plan, build, and execute a mass credential harvesting campaign in less than six hours," Google explained. "Using preconfigured markdown instruction sets as operational playbooks, the threat actor conducted automated scanning and credential harvesting, compromising thousands of third-party credentials." The integration of AI is said to have allowed the system to autonomously manage the vulnerability scanning pipeline, conduct troubleshooting in real time, and execute IP rotation logic without handholding by a human. The third category related to adversarial misuse of large language models (LLMs) stems from threat actors experimenting with the technology to augment vulnerability research, prototype exploits, orchestrate complex toolsets, and make tactical decisions on the fly - A China-nexus group with a history of targeting government entities has used Claude, Gemini, or Codex to write custom exploit scripts, generate convincing spear-phishing lures, and debug errors. The China-nexus cyber espionage group known as Basin Castle (aka Mustang Panda) has used LLMs to assist with tasks ranging from research on high-value targets to troubleshooting errors mid-intrusion. The China-nexus cyber espionage group known as Ravine Castle (aka APT24, COULEE, and Pitty Tiger) has used Gemini to conduct intelligence gathering, attack capability development, and influence operations. The Russia-based threat group known as UNC5792 has integrated AI models to sift through Telegram channels for specific information of interest to Russian authorities, such as security threats and extremist content. The Russian cyber espionage group known as Sandworm (aka APT44 and Sandworm Relic) has used Gemini to support intelligence gathering, social engineering, and workflow automation in continued operations targeting Ukraine. The Iranian hacking group known as Calanque Ion (aka APT42) has used generative AI models, including Gemini, to facilitate reconnaissance and targeted social engineering. Two North Korean threat clusters, including UNC5267 (aka IT worker fraud scheme), and UNC5342 (aka Contagious Interview) have used AI in their operations, including engaging in bulk LLM API registration using hijacked accounts. The North Korea-aligned financially motivated threat actor known as Midnight Neptune (aka UNC1069) has used commercial LLMs and open-weight models for social engineering, software supply chain manipulation, and automated backdoor development. The financially motivated threat actor known as UNC6240 (aka ShinyHunters) has used Claude Code to bypass Cloudflare security guardrails and analyze exfiltrated directories for extortion. Underground actors have combined Ghidra with the Gemini-CLI agent to reverse-engineer WinRAR Self-Extracting (SFX) archive components. That's not all. Threat actors have demonstrated an interest in stealing credentials and purchasing capabilities underground to meet their growing demand for AI access. The credentials are likely stolen via information stealer malware like Lumma Stealer, Vidar, and ACR Stealer, which have expanded their capabilities to target AI developer configurations. Another defining aspect is the hosting of local models on compromised hosts, as evidenced in the case of UNC6508. While Western frontier AI labs have largely restricted access to the advanced cyber capabilities of their most powerful models, rapid improvements in open-weight models' capabilities have also stoked fears that they could fuel AI-enabled cyber attacks. "Open-weight models present an increasing risk by democratizing access and enabling local, unmonitored deployments that lack safety guardrails, particularly with the rise of 'abliterated' or uncensored variants," GTIG told The Hacker News. "While API-gated frontier models allow providers to monitor misuse, open models lack centralized defender visibility, giving threat actors distinct advantages for accelerating tasks like phishing and malicious scripting." "However, open models also drive essential innovation, so simply gating access is impractical. Enterprise platforms like Gemini Enterprise can provide a contained, safe environment for businesses to leverage open-source models securely. To address this balance, Google formalized its Frontier Safety Framework and Critical Capability Levels (CCLs) to evaluate model capabilities and determine when open deployment poses unacceptable security risks." "Mitigating these threat actor capabilities ultimately requires establishing enforceable, industry-wide safety baselines specifically for open-source AI, alongside coordinated platform policies to restrict uncensored checkpoints and raise the barrier to entry for adversaries.
thehackernews.comSep 8, 2026extracted
Cybersecurity jobs available right now: September 8, 2026
Cybersecurity jobs available right now: September 8, 2026 CISO AudioCodes | Israel | Hybrid – View job details As a CISO, you will lead security strategy, governance, and risk management across SaaS, managed services, and customer-hosted environments. You will oversee security controls, incident response, Secure SDLC, customer security engagements, and compliance with SOC 2 and ISO 27001, while partnering across Product, R&D, IT, and Services to continuously strengthen security. Combat Systems Cyber Engineer Johns Hopkins Applied Physics Laboratory | USA | On-site – View job details As a Combat Systems Cyber Engineer, you will identify cyber vulnerabilities and develop resilient solutions for U.S. Navy submarine and combat systems. You will collaborate with developers, Navy labs, and government teams to design, plan, and execute cyber resiliency testing and assessments of mission-critical combat systems. Cyber Security Engineer (Cloud Security) Garmin | USA | On-site – View job details As a Cyber Security Engineer (Cloud Security), you will design and secure cloud solutions across AWS and Azure, including network, compute, storage, databases, and load balancing. You will support CNAPP, Kubernetes, EKS, AKS, Docker, OpenStack, CI/CD pipelines, and Infrastructure as Code. You will automate security workflows using Python, PowerShell, or Bash, secure cloud-native and containerized applications, and collaborate with engineering teams to improve security, compliance, threat detection, and response. Get weekly updates on new cybersecurity job openings. Subscribe here! Cyber Security Lead Babcock International Group | United Kingdom | On-site – View job details As a Cyber Security Lead, you will lead secure-by-design assurance for UK Defence Nuclear Enterprise programmes, ensuring alignment with Ministry of Defence security requirements. You will conduct threat modelling and cyber risk assessments, develop mitigation strategies, produce security evidence, and guide engineering and architecture teams in embedding security throughout the system lifecycle. Cyber Threat Hunter GDIT | USA | On-site – View job details As a Cyber Threat Hunter, you will identify and investigate threats across ARNG networks, endpoints, and datasets using threat intelligence, hypothesis-based hunting, and the MITRE ATT&CK framework. You will analyze security data using platforms such as Elastic and Splunk, assess cyber risks, investigate intrusions and malware activity, and identify detection gaps. IAM Architect Scotiabank | Canada | On-site – View job details As an IAM Architect, you will design enterprise CIAM solutions using ForgeRock, Ping, and PingOne, aligned with FIDO, OIDC, OAuth, MFA, and NIST 800-63B standards. You will define secure authentication architectures, support application migrations, evaluate capabilities such as Passkeys, and collaborate with engineering, security, fraud, compliance, and business teams. Information System Security Engineer (ISSE) Akima | USA | On-site – View job details As an Information System Security Engineer (ISSE), you will design and assess secure architectures aligned with NIST, DoD, Zero Trust, RMF, STIGs, and SRGs. You will conduct threat modeling and vulnerability assessments, implement security controls and automated monitoring, support accreditation and POA&M remediation, and provide technical guidance throughout the system lifecycle. OCI IAM Security architect ValueLabs | India | Remote – View job details As an OCI IAM Security architect, you will design and secure OCI environments using IAM, Identity Domains, MFA, PAM, vault, data safe, cloud guard, security zones, WAF, network firewall, and NSGs. You will enforce zero trust, RBAC, and least privilege, integrate OCI logging with SIEM platforms, lead threat detection and incident response, and ensure compliance with PCI-DSS, HIPAA, GDPR, SOC 2, ISO 27001, and CIS benchmarks. Penetration Tester Spektrum | Belgium | On-site – View job details As a Penetration Tester, you will lead Red/Blue Team activities during NATO exercises and conduct web, infrastructure, and application penetration testing. You will perform security design reviews, support NATO security accreditation, provide security consultancy, and communicate testing findings to technical and executive stakeholders. SOC Analyst Orro Group | Australia | Hybrid – View job details As a SOC Analyst, you will investigate SIEM alerts, emerging threats, phishing, and intrusion attempts while managing incidents from triage through resolution. You will conduct threat hunting and vulnerability assessments, improve detection rules and alert quality, and mentor junior SOC analysts. Security Automation Engineer Secur-Serv | USA | Remote – View job details As a Security Automation Engineer, you will lead Cortex XSOAR implementations and operations, developing automated incident response playbooks and integrating security technologies. You will translate customer requirements into effective SOAR solutions, provide technical leadership, and communicate with engineering and executive stakeholders. Security Operations Analyst Subway | USA | On-site – View job details As a Security Operations Analyst, you will detect and investigate identity threats using CrowdStrike Falcon Identity Protection and Next-Gen SIEM. You will manage Okta Identity Governance, privileged access, incident response, and PCI-DSS 4.0 compliance, while handling Tier-2/3 escalations in ServiceNow and improving identity security controls and automation. Senior Cybersecurity Operations Researcher Software Engineering Institute | Carnegie Mellon University | USA | On-site – View job details As a Senior Cybersecurity Operations Researcher, you will conduct analytical studies involving cybersecurity risk, threat, and security data while assessing evolving operational and network defense challenges. You will apply expertise in enterprise cybersecurity, commercial and open-source defense tools, and project management to support multidisciplinary programs. Senior Cyber Security Engineer Rolls-Royce | USA | Remote – View job details As a Senior Cyber Security Engineer, you will design, implement, and maintain network and cloud security solutions, including firewalls, VPNs, IDS/IPS, NAC, SIEM, EDR, and DLP. You will monitor security events, assess vulnerabilities, mitigate risks, and maintain security policies and best practices. Senior Network Security Engineer Penta Consulting | UAE | On-site – View job details As a Senior Network Security Engineer, you will lead network and security changes and deliver complex Cisco infrastructure and security projects. You will provide technical consultancy, translate business requirements into solutions, drive remediation and improvements, and support operations, projects, and pre-sales activities. Senior Software Security Engineer Dolby Laboratories | Ireland | Hybrid – View job details As a Senior Software Security Engineer, you will perform threat and risk assessments, vulnerability and exploitability research, and implement and validate IP protection mechanisms. You will work across embedded systems, operating systems, applications, and hardware to strengthen product security.
helpnetsecurity.comSep 8, 2026extracted
ToolHive: The open-source way to run any MCP server securely
ToolHive: The open-source way to run any MCP server securely ToolHive is an open-source platform that runs Model Context Protocol servers inside containers. An MCP server is the connector that lets an AI client like Cursor or Claude Code reach an outside tool, and Stacklok ships ToolHive under Apache 2.0, so the runtime, the Kubernetes operator, and the registry cost nothing to self-host. A server you install by hand sits on the machine with the machine’s credentials and the machine’s network access. ToolHive drops each one into its own container with a minimal permission file and no local credentials attached. Point it at an authentication source and it starts enforcing identity and access policy per request, with audit logs to match. Don’t, and you have a sandbox and not much else. What the pieces do Four parts make up the platform. The Runtime is the one most people meet first: it runs MCP servers in containers, locally through Docker or Podman, or in a cluster through the Kubernetes operator, with permissions, network filtering, and secrets management applied on the way in. It will also containerize a server whose authors never shipped an image, pulling it straight from a package manager. The Registry Server is where an admin curates the catalog a team is allowed to use. It implements the official MCP Registry API, signs servers, and verifies provenance. The Gateway, which Stacklok calls Virtual MCP Server, collapses several backends behind one endpoint with OIDC or OAuth single sign-on, OpenTelemetry traces, and Prometheus metrics. The Portal is the friendly end: a desktop app, a catalog to browse, one-click installs. One piece is in motion. The browser-based cloud UI is marked retired, so build a rollout around the desktop app and the CLI rather than the web surface. What this changes for you Building an MCP server is the easy half, and plenty of tools already do it. The operational half is knowing which servers are running on which machines and what each one can touch, and that is the gap ToolHive goes after. The container boundary holds without much work from you. Everything past it, the identity enforcement, the audit trail, the policy filtering, means wiring ToolHive into an identity provider and a telemetry stack you already run. Install it on a laptop and you get isolation. Governance is a second project. ToolHive is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
helpnetsecurity.comSep 7, 2026extracted
Shai-Hulud's Reach Just Grew to 469 Credential Locations. Here's What That Means
In early August, GitGuardian researchers found that a recent Shai-Hulud infostealer worm variant had evolved to scan for credentials across 469 locations across developer environments, Continuous Integration/Continuous Deployment (CI/CD) tooling, cloud configurations, and even AI tool configs. Earlier variants of the infostealer worm only checked 189 paths. The jump says a lot. Attackers have stopped trying to break trust relationships and started using the credentials that already make those relationships work. Software supply chains have always depended on trust. Developers trust package registries. Organizations trust maintainers. CI/CD systems trust the credentials and identities they're given. Applications trust the dependencies they pull down during a build. Attackers realized they don't need to break any of that. They just needed to find where the credentials and standing privileges already sit. This is what is driving the current focus on software supply chain defense across multiple ecosystems. Protecting package registries and dependencies still matters, but the core of the problem, the actual required element for infostealer worms to succeed, sits underneath those systems. Attackers are hunting for reusable authority. Preventing the next Shai-Hulud starts with addressing and securing the credential layer. Shai-Hulud turns stolen credentials into an ongoing supply chain attack Shai-Hulud belongs to a growing class of supply chain attacks that search compromised environments for credentials they can use to continue the attack. A token found on a developer workstation might open access to source code. That same code likely contains cloud credentials, which would grant access to the infrastructure. A GitHub token might allow write access to additional repositories. A package publishing credential can let an attacker publish software through a channel developers already trust. Credentials become the connective tissue between one compromised environment and the next. The broader ecosystem has already seen how direct that path can be. A quick scan of any security industry news site or info feed will surface a never-ending supply of stories about new infections across multiple languages, package managers, and operating systems. Credential harvesting gives attackers somewhere to go next Modern developer environments contain far more authentication material than the source repository alone. Credentials show up in expected places, like .env files, shell history, and package-manager configuration. But there are also secrets in CLI caches, CI/CD configurations, and IDE settings. Increasingly, teams are finding access keys in the configuration used by AI development tools. This is why credential-harvesting malware creators keep broadening the search radius. The attacker doesn't necessarily know which credential matters most before collection begins. It can gather what's available and sort out what each credential unlocks afterward. Defenders should work the problem in the opposite direction. Security teams must identify which credentials matter most and address their exposure before an attacker gets the chance to use them. The power to publish creates a path to propagation Package publishing credentials deserve special attention because they turn credential theft into software distribution, forward propagating the attack. Tokens that developers use to publish carry authority over a trusted package that other developers, build systems, and organizations will automatically consume. That trust is what attackers abuse. This creates an obvious first priority for defenders: to reduce the number of standing publishing credentials available to steal. Organizations need to cut their dependence on long-lived publishing tokens. We should encourage all software makers to adopt short-lived, verified authentication via OpenID Connect (OIDC) or similarly scoped mechanisms. Docker and GitHub Actions' recent updates have pushed the ecosystem further in this direction, including stronger authentication and greater use of trusted publishing. Any long-lived publishing credential that remains should be treated as highly sensitive infrastructure. Credentials connect systems security teams manage separately Security teams traditionally think about their orgs in terms of security types: source control security, CI/CD security, cloud security, endpoint security, and application security. Credentials span all of these divisions and separation-of-duties requirements. A single developer can authenticate to GitHub, npm, AWS, Kubernetes, internal APIs, and build infrastructure in one normal day, and CI/CD pipelines often carry an equally diverse set. A credential left in a developer environment can represent authority somewhere completely different. The file might sit on a laptop while the credential controls a cloud resource or might grant package publication rights. Where a secret is discovered only tells part of the story. Organizations working towards secrets management maturity also need to know whether the credential is valid, what identity it belongs to, what system accepts it, what privileges it carries, which environment it reaches, and who owns its remediation. That turns secrets detection into credential risk management. Not every exposed secret creates the same risk A list containing 100,000 secret findings does not represent 100,000 equally urgent incidents. Some credentials are already invalid. Others reach disposable development environments. A smaller number provide access to production databases, cloud infrastructure, deployment systems, or package publication. Treating those findings identically builds queues instead of reducing risk. A useful remediation strategy starts by asking what an attacker would choose first. The answer provides a practical order of operations. Priority one: remove package publishing keys from cleartext This is the key action a developer and team need to pursue to stop Shai-Hulud variants and other infostealer worms. Organizations maintaining packages should identify where publishing tokens exist and determine whether standing credentials are still necessary. That search needs to extend beyond repositories. Find publishing credentials wherever developers and pipelines leave them Too often, package authors write authentication keys to local configuration files as part of normal workflows. But a secret doesn't need to have been committed to Git to be available to malware running on the developer machine. It's also why recent supply chain attacks increasingly target the working developer environment itself. Security and development teams need visibility into where package publishing credentials actually accumulate, followed by a plan to remove them. Replace standing publishing credentials where possible The hardest publishing credential for an attacker to steal is one that does not exist. But if they must exist, the shorter the window access can be granted, the better. The goal is always to eliminate reusable publishing authority sitting in cleartext. Organizations should move package publishing toward short-lived, identity-backed mechanisms wherever supported. OIDC-based trusted publishing is one example. Most cloud platforms are moving towards federated security token services like AWS STS, allowing for workload verification across platforms where you would be pushing artifacts. This area is always evolving in each package tooling ecosystem as well. Static credentials that can't yet be replaced need tighter controls. They should be discoverable, validated, owned, monitored, and rotated when exposure occurs. This effort sits naturally between development and security. Developers understand how packages get built and released while security teams set policy and identify credential exposure across those workflows. Neither side can solve it alone. Priority two: remove exposed production credentials Stopping the propagation path halts the spread of the infection but does not stop the bleeding. After publishing credentials, organizations should focus on credentials that provide access to critical production systems. This is where credential remediation becomes risk management. An exposed credential tied to an isolated development environment might create limited damage. A valid credential with write access to production infrastructure is a different incident entirely. Each organization should have its own hierarchical view of what constitutes mission critical, but a good short list might be: Production cloud accounts Databases containing customer information Signing infrastructure Kubernetes clusters Deployment tooling Administrative interfaces The question to ask is "what happens if an attacker does something malicious with stolen access?" Validity is a very useful filter here. Determining the true blast radius will help you prioritize which systems to address to eliminate long-lived secrets, or at least which to rotate secrets for. Shared credentials create hidden paths between environments Environment boundaries also blur when credentials get reused. A credential discovered in staging may still authenticate against production. A token copied into a developer's local environment may retain privileges meant for automation. The same credential may show up across multiple systems long after its original purpose has been forgotten. Finding the secret is only the first step. The alerts are just noise if they do not map it back to the identity, privileges, resources, environments, and owners behind it. Multiple teams, including DevOps, platform, Identity and Access Management (IAM), and security, each hold a piece of that picture, and remediation needs to bring those pieces together. Priority three: rank every remaining exposed secret by risk Once package publishing and obvious production access are handled, organizations can work systematically through the remaining credential inventory. The goal isn't to rotate everything at random. It's to build an action plan that continuously removes the most useful credentials from an attacker's path. Validity is a good place to start, but not the whole story A valid credential deserves more immediate attention than one that's already expired or revoked. At scale, that distinction matters enormously: GitGuardian's State of Secrets Sprawl research found 28.65 million new hardcoded secrets added to public GitHub commits in 2025 alone, a 34% year-over-year increase. Volumes at that scale make manual triage unrealistic. Organizations need to determine which findings still represent usable authentication and move those toward the front of the queue. Validity alone still doesn't tell the whole story. A valid credential for a shared development service deserves attention. A valid credential with administrator access to a production cloud account deserves considerably more. Useful prioritization adds context: Is the credential still valid? Does it reach production, staging, or development? What identity does it represent? What privileges does that identity have? Which resources can it access? Where else is the credential being used? Who owns the credential and can rotate or revoke it? Working to make sure you have answers that can be audited turns an overwhelming list of leaked secrets into an actual remediation plan. Credential risk reduction requires a repeatable program This newest wave of Shai-Hulud attacks, or any variants of it, should do more than trigger a one-time credential cleanup exercise. Credentials will likely continue to accumulate as developers keep building software, services integrate with one another, pipelines evolve, and new tools enter the environment. The response needs to become a repeatable cycle. Organizations first need broad visibility into what they have. A single inventory of all credentials. That includes source code and Git history, but modern attacks make the case for looking further, into the CI/CD systems and developer environments where authentication material accumulates. Detection should answer a simple question: where does reusable authority currently exist? This needs to be auditable, and not simply reflect the 'known" secrets already vaulted. The percentage of secrets that exist outside the vault is a very important metric when addressing secrets security at scale. Remediation plans without a way to account for those orphaned, plaintext secrets are doomed to fail. Remediate according to actual risk The next step is prioritization. As we have laid out in this post, any publishing credentials and valid production credentials belong at the top of your list. Remaining secrets need to be ranked using validity, environment, identity, privilege, ownership, and other available context. Remediation then moves through a manageable queue instead of an undifferentiated backlog. Prevent standing credentials from rebuilding the attack path Finally, organizations need to stop the same credential layer from rebuilding itself. That means blocking new hardcoded secrets, moving workflows toward short-lived credentials where possible, protecting credentials in developer environments, and catching new exposure before it becomes another large remediation project. "Detection, remediation, and prevention" need to be seen as an ongoing cycle, not an emergency response triggered after an attack. The next Shai-Hulud wave should find fewer credentials to steal The next Shai-Hulud variant will almost certainly look somewhere new, expanding past that 469 number we started with. Attackers will keep adding paths and developer tools to their search because they have learned that modern software environments are full of reusable authority. We are not going to win that race by memorizing every place the next infostealer might look. We win by removing standing privilege and eliminating exposed credentials everywhere they exist. That is why the credential layer deserves to be treated as its own security problem. Detect where reusable authority exists. Remediate the credentials that create the most risk. Prevent that exposure from accumulating again. Our goal should be to ensure that every time a new worm arrives, there are fewer findable keys to abuse.
thehackernews.comSep 3, 2026extracted
Breeze Comet Executes Hundreds of Fraudulent Transactions via Brazilian Payment Systems
Brazilian financial services, retail, and e-commerce organizations have become the target of a financially motivated threat actor dubbed Breeze Comet (formerly UNC5669) since 2024. Google Threat Intelligence Group (GTIG) and Mandiant teams described the threat actor as "specializing in manipulating payment systems and banking software in Brazil to conduct fraudulent transfers." The adversary is said to have successfully carried out at least one heist of assets worth tens of thousands of U.S. dollars. The activity overlaps with threat activity clusters tracked by CrowdStrike and Trend Micro under the monikers Plump Spider and SHADOW-AETHER-064. According to CrowdStrike, the e-crime group is operating out of Brazil and has been active since September 2023, monetizing their intrusions by gaining unauthorized access to internal payment systems and carrying out fraudulent transactions. Initial access to financial entities and companies offering financial services is accomplished via password spraying and voice calls impersonating IT support teams to persuade targets to install Remote Monitoring and Management (RMM) tools such as AnyDesk. In one case highlighted by Axur in November 2025, the threat actors masqueraded as IT support personnel over a WhatsApp conversation and guided the victim to install a PowerShell reconnaissance script under the pretext of updating a corporate application. Alternatively, the group has targeted vulnerable JBoss AS servers to deploy web shells, which are then used to deliver additional tooling, including Chisel and other proxy utilities, for follow-on exploitation. The threat actor's primary targets are organizations with permission to conduct transactions through banking software, APIs, and payment systems such as Pix, STR, and Boleto. This covers a wide range of entities like banks, payment processors, retailers, and exchanges, not to mention fintech and banking software providers. "Breeze Comet tactics have evolved over time to leverage a customized malware suite and compromised, trusted websites to facilitate initial access, command-and-control (C2), and to interact with financial software and payment APIs," Google said. "Breeze Comet's operational infrastructure may also indicate intent to expand their infrastructure footprint to other countries in Latin America and Africa." To achieve its goals, however, it must meet four requirements: have access to the National Financial System Network (RSFN) through an entity that already has this access; access to mTLS credentials that allow sending authenticated payloads with transactional orders to Pix or STR; access to several accounts in the targeted organizations' Active Directory and cloud environments; and possess an understanding of an organization's transfer processing procedures, network controls, fintech integrations, and anti-fraud systems. Some of the other notable tactics are listed below - Using compromised Brazilian small government websites to stage RMM tools, infostealers dressed up as legitimate tax or receipt documents, and backdoors like XWorm, as well as using them as C2 endpoints to bypass reputation filters and avoid detection. A similar modus operandi has been replicated across Nigeria, Paraguay, Ghana, and Venezuela, indicating a growing targeting focus. Connecting rogue hardware devices directly into retail store networks as a means to establish direct footholds and then move laterally to internal systems, followed by downloading the Netcat utility and custom scripts to retrieve post-exploitation frameworks. Using Impacket, ADRecon, and ADVipscan, and the custom LDAP brute-forcing utility REALBREEZE to conduct internal reconnaissance and escalate privileges by targeting development and cloud environments. Moving laterally by initiating unauthorized Remote Desktop Protocol (RDP) sessions and executing commands via SMB network file shares. This step also involves the deployment of COBALTSPIN, a Rust-based routing malware that operates as a network tunneler to communicate with and maintain persistent network access to financial API infrastructure. "By establishing a reverse SOCKS5 proxy over a WebSocket connection, COBALTSPIN routes network traffic securely back and forth between the C2 and internal targets, enabling lateral movement directly through boundary firewalls without requiring built-in persistence mechanisms that might trigger detection," Google said. Breeze Comet's persistence mechanisms have evolved from dropping commercial RMM tools in 2024 to deploying malicious Kubernetes pods a year later and stealing cloud secrets by exfiltrating them to public-facing notepad websites like "dontpad[.]com." Since then, the threat actor has also been observed making use of multiple custom backdoors as a redundant access method and expanding their foothold - LIGHTPAINT, a Java-based backdoor that's used to install the legitimate SoftEther VPN and configure it for automated persistence MILDFROST, a passive Java JAR backdoor that's used to establish covert DNS tunnels KICKPLATE, a Nim-based backdoor that impersonates Windows Update Health Tools and is used to deliver secondary payloads and runs commands to control SOCKS5 tunnelers BOATBEAM, a Golang-based backdoor that initiates a fake IIS HTTPS server on port 443 To make sure these persistence mechanisms are not detected and removed, the threat actor executes PowerShell commands to disable Windows Defender's real-time monitoring on the compromised hosts. In the final stage, COBALTSPIN and compromised privileged accounts are used to access core financial applications and execute hundreds of fraudulent transactions. Once complete, event logs are cleared to minimize the forensic footprint and conceal any API interactions with financial software and payment systems. Any directory created during the course of the intrusion is also deleted. The presence of verbose explanatory comments and standardized execution headers indicates the use of a large language model (LLM) to compress the malware development lifecycle. A previous analysis from Trend Micro in May 2026 also found some scripts to include "descriptions of self-reasoning and autonomous decision-making processes." "While the Latin American cybercrime ecosystem has historically been defined by client-side, high-volume retail fraud, Breeze Comet's campaigns represent a notable shift that may serve as a model for future financially motivated threats against organizations in this region," Google said. "This transition from opportunistic retail banking fraud to direct intrusions into the core financial switch and instant payment infrastructure is notable not just for this shift in targeting, but also the capabilities of the threat actor. As threat groups increasingly leverage LLMs to streamline routine tradecraft, defenders must anticipate shorter adversary turnaround times and heightened pressure on interconnected financial ecosystems."
thehackernews.comSep 1, 2026extracted
Bot detection arrives in CrowdSec 1.8.0, along with two DoS fixes
Bot detection arrives in CrowdSec 1.8.0, along with two DoS fixes Failed SSH logins pile up in an auth log, and a scanner walks a website looking for exposed admin paths. CrowdSec reads log sources and HTTP requests, works out which addresses are misbehaving, and hands the block to a separate remediation component sitting in front of the service. Users report what they see back to the project, which curates it into a community blocklist every installation can pull down. Version 1.8.0 landed on August 31. The big change is bot detection in the CrowdSec WAF, the half of the engine that inspects HTTP. Turn it on and clients get a challenge and fingerprinting page before they reach the site. CrowdSec grades the challenge, checks the fingerprint against rules you configure, and decides whether the client looks legitimate. Some real visitors will not get through The challenge requires SSE4.1 and writable-executable memory, so older or hardened clients cannot solve it. A visitor with cookies disabled now gets an explicit error message, which at least tells them what went wrong. Test the feature against your actual audience before switching it on everywhere, because the page sits in front of everyone, not just the bots. Two ways to crash the log intake, now closed This release also fixes two denial of service vulnerabilities in the HTTP and k8s-audit datasources, the parts that take logs in. The HTTP acquisition datasource had no cap on decompressed body size and trusted the sender’s Content-Length. The Kubernetes audit webhook read request bodies without bound. Both sit at the intake end, which means the component watching for attacks was itself something worth attacking. If you feed CrowdSec over HTTP or from a k8s audit webhook, this is the part of the release that applies to you whether or not you care about bots. A dedicated Kubernetes datasource now pulls logs straight from the apiserver, removing a collection step for cluster operators. New HTTP helpers in the expression language let parsers and scenarios query external services while a decision is being made. The decisions stream endpoint in the local API got performance work, which matters most to anyone running many remediation components against one API. Bot detection stays off until you enable it. The two datasource fixes apply either way, and that is the stronger argument for taking this release. CrowdSec is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
helpnetsecurity.comSep 1, 2026extracted
The AI agent swarm that attacked Hugging Face is a warning for the future
The hacking incident involving OpenAI evaluation agents and Hugging Face offers an unusually concrete look at what advanced AI-assisted intrusion can mean in practice: not a single clever exploit, but thousands of automated decisions , rapid experimentation, lateral movement, credential theft, persistence, and attempts to evade detection. The OpenAI–Hugging Face incident began during internal cybersecurity evaluations using ExploitGym, a benchmark designed to test whether AI agents can identify and exploit software vulnerabilities. OpenAI says the affected agents were meant to operate in isolated cloud sandboxes, with no internet access or communication between agents in many of the evaluation environments. How the agents got around those boundaries According to OpenAI’s account, agents used an internal Artifactory package-management service as an improvised communications channel. By writing files and directory names that other agents could read, isolated instances effectively created their own message board. This meant the agents were no longer acting merely as independent benchmark runners. They could share discoveries, leave instructions, divide work, and build on one another’s successes. An independent investigation by METR and Redwood Research found that roughly 1,200 agents used the unauthorized message board, exchanging more than 70,000 messages and files. About 700 of them went on to participate in the attack on Hugging Face. The scale is the threat A model capable of finding one useful exploit presents a risk. Hundreds of agents able to pool information, delegate tasks, and repeatedly test routes around a control boundary become a much more difficult problem. Hugging Face reconstructed about 17,600 attacker actions across roughly four and a half days, including reconnaissance, remote code execution, credential access, command-and-control activity, Kubernetes enumeration, movement through the internal network, and supply-chain probing. A human intruder must choose where to spend time. An agent swarm can continuously test ideas, retry failed paths, switch infrastructure when blocked, preserve notes for other agents, and run many experiments in parallel. It can also create noise: Thousands of low-confidence actions, most of which lead nowhere, can obscure the handful that matter. Hugging Face described this as an “asymmetry problem.” An attacker can generate enormous volumes of attempts, while defenders must determine which signals represent a real escalation before the attacker reaches a sensitive system. What needs to change The core security lesson is that evaluation environments need to be treated as high-risk production systems when models can use tools, write files, execute code, or interact with infrastructure. The technology is rapidly becoming capable of doing more. The question is whether the people building, deploying, and defending it are ready for what comes next. OpenAI says it has since moved toward stronger workload and network isolation, tighter control over internet access and model weights, and mandatory chain-of-thought monitoring for high-capability, tool-using training and evaluations. “We are taking this incident as a ‘warning shot’ that today’s model capabilities present the possibility of loss-of-control incidents. Our security and alignment posture is escalating accordingly. These events also highlight risks in future AI development that extend beyond OpenAI and will require the attention of the whole industry.” At the same time, a US court ruling involving Anthropic has brought a related question into focus: whether developers can place limits on high-risk uses of their models, including mass surveillance and fully autonomous weapons. The legal dispute is political by nature, but its technical underpinning is hard to ignore. If capable AI systems can enhance offensive cyberattack methods and bypass safety restrictions, access controls, logging, and deployment boundaries, those safeguards are no longer abstract policy choices. Advanced AI agents can be useful to defenders as well as attackers. But the surrounding systems need to be trusted to keep their capabilities bounded when something goes wrong. Who benefits from more capable AI? The security debate around AI agents often focuses on whether systems can be controlled. Can they be kept inside a sandbox? Can their tools, credentials, network access, and autonomy be restricted? Can defenders detect harmful behavior before it becomes an incident? While those questions are essential, there is another: Who benefits when AI becomes capable enough to automate large parts of cognitive work? Who carries the costs when it fails, displaces workers, enables fraud, causes damage, or concentrates power? AI could give small organizations access to technical expertise that previously required large teams and budgets. It could help doctors identify urgent cases sooner, help teachers tailor support to individual students, assist people with disabilities, speed up scientific research, and make complex public services easier to navigate. For cybersecurity teams, it could make vulnerability triage, alert investigation, threat hunting, and incident response faster and more accessible. Bill Gates has argued that while AI could bring remarkable benefits to health care, education, agriculture, scientific research, and public services, the outcome will depend on deliberate choices rather than technical progress alone. He also warns that AI’s rapid adoption could widen inequality, disrupt entry-level and mid-career work, make harmful capabilities more accessible, and reinforce existing concentrations of power. Gates also argues that “self-regulation on the most dangerous tool ever invented” does not sound like a good idea. “AI will either be the greatest equalizer ever invented, or the worst source of injustice.” Right now, we still have a choice. Let’s&nbsp;face it, an incognito window can only do so much. &nbsp; &nbsp; Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection &nbsp;monitors for all of it, alerts you fast, and comes with identity theft insurance.&nbsp;
malwarebytes.comAug 28, 2026extracted
What 90 days and a small budget can buy in AI agent security
What 90 days and a small budget can buy in AI agent security In this interview with Help Net Security, Prasad Tharippala, Field CISO at Versa, explains what organizations miss when they run open-weight models in house. He covers the hidden costs of GPU infrastructure, licensing review and staffing, and why hardening and incident response become the buyer’s job. He walks through red-teaming AI agents, what counts as a failing result, and the five questions buyers should ask agent platforms. For teams with 90 days and little budget, he ranks inventory, blast radius reduction and ongoing testing as the order of work. When customers want to run open-weight models in their own environments for security reasons, what costs or staffing requirements do they typically underestimate? Running the model in your own environment can improve control and data residency. It does not automatically make the deployment more secure. It shifts the responsibility for hardening, patching, access control, monitoring, model evaluation and incident response onto the organization running it. The biggest underestimate is that running the model is only one part of the problem. The real operational cost comes from everything around the model: GPU infrastructure, networking, storage, power and cooling, capacity planning, orchestration, model updates, monitoring, security controls, data governance, audit evidence and ongoing optimization. Licensing and compliance review is another cost that rarely makes it into the budget. Open weight does not mean unrestricted. Many open weight licenses carry usage restrictions, and regulations like the EU AI Act add obligations for larger models. Someone has to review that before deployment, and the work does not stop after launch. Every model or adapter update needs re-validation, so it becomes an ongoing cost, not a one time exercise. There is also a skills gap. You need people who understand AI/ML infrastructure as well as security, networking, observability and production operations. In practice that spans platform engineering, MLOps, GPU and Kubernetes expertise, site reliability, AI security and red-teaming, identity and data governance. In many cases, organizations assume their existing infrastructure or security teams can absorb this work. But operating inference reliably at scale is a different discipline. This can lead to significant delays, and in some cases the project never delivers the expected business value. Another frequently underestimated area is utilization. GPUs are expensive resources, and poor workload management can result in significant idle capacity or unpredictable performance during demand spikes. Scheduling, quotas, batching, caching, model routing and demand forecasting all help, and techniques like quantization and multi-tenant GPU sharing can make a real difference. The economics can change considerably depending on how efficiently inference resources are shared and managed. A strategy, disciplined planning and the right skills can certainly make this work. But the decision should not come down to build versus buy alone. It should be driven by data sensitivity, sovereignty requirements, latency needs, workload volume, the skills you have in house, and regulatory or compliance requirements. For many organizations a hybrid approach, with some workloads run in house and others consumed as a managed service, ends up being the practical answer. That is ultimately a strategic decision for the CISO, CIO and other technology leaders, based on the organization’s business objectives, security posture, operational maturity and regulatory or compliance requirements. There is no one- size-fits-all answer. How should an AI agent be red-teamed before production? Who does it, how long does it typically take, and what constitutes a failing result? Agent red-teaming needs to go beyond traditional application penetration testing. You need to test not only whether the agent can be compromised, but also what it can do after it is compromised or manipulated. I would test for prompt injection, indirect prompt injection, excessive permissions, data leakage, unauthorized tool use, privilege escalation, unsafe actions, manipulation of memory or context, and the ability to move from one connected system to another. I would add memory and RAG poisoning, malicious tool outputs, compromised connectors, credential theft, cross agent trust abuse, supply chain vulnerabilities and resource exhaustion attacks to that list. Most of this maps closely to the current OWASP guidance for agentic applications and MITRE ATLAS, so it helps to test against a recognized framework. One thing worth calling out specifically is what happens when one agent’s output gets passed to a second or third agent. A lot of the real risk in agentic systems does not live inside any single agent. It lives in the handoff, where output that looks completely benign on its own becomes a problem once another agent acts on it. The testing should not stop at the agent. The underlying infrastructure, software components, APIs, identity layer, LLM and other supporting components also need to be subjected to security testing and red-teaming to establish the complete security posture. This should also cover the human approval steps, emergency shutdown and rollback mechanisms, not just the attack paths. Those controls only count if they have been exercised under test conditions. The exercise should involve AI specialists and security professionals, and ideally people who did not build the agent. The AI team understands model behavior and agentic workflows, while the security team understands attack paths, identity, access control and enterprise risk. There should not be a universal definition of how long this takes. A relatively simple agent may be assessed in days, while a production agent connected to sensitive enterprise systems can require weeks of iterative testing. The scope should be determined by the agent’s entry and exit points, the data it can access, the actions it can perform, and the software and infrastructure components supporting it. Any change to the model, system prompt, tools, permissions or connectors should trigger targeted retesting. A failing result is not “the model produced a bad answer.” The real failure is when an attacker can make the agent violate its defined security boundary, for example access data it should not have access to, invoke a tool it should not be able to use, bypass authorization, disclose sensitive information, or take a consequential action without the required controls. I would add one more condition. If the violation succeeds without triggering any detection or audit trail, that counts as a failure too, and arguably a worse one, because nobody even knows it happened. The important distinction is that an agent combines a probabilistic model with deterministic orchestration, tools and enterprise controls. Because the model’s behavior is probabilistic, the authorization and safety boundaries have to be enforced outside the model. Carefully crafted or manipulated prompts can sometimes cause an agent to behave outside its intended boundaries. That is what the security assessment needs to validate. What do telecom operators consistently underestimate about running inference at scale: power, skills, or something less obvious? Power and GPU capacity are obvious concerns, but I think the less obvious issue is operational predictability. Telecom environments are built around very high availability and predictable performance, often at edge locations with real constraints on power, cooling and connectivity. AI inference introduces workloads that can be highly variable in terms of compute requirements, latency and concurrency, and rolling out consistent model and policy updates across thousands of sites adds a layer of difficulty most enterprises never have to deal with. The challenge is being able to allocate and scale those resources while maintaining predictable service levels. AI workloads are not always predictable, and that creates additional challenges around scaling, governance, resource allocation and adopting AI for critical use cases. Telcos also carry a version of the isolation problem that is more acute than in a typical enterprise. Infrastructure is shared across many enterprise and government customers, so weak isolation between AI workloads is a real path to cross customer data exposure. Add in data sovereignty and lawful intercept obligations that do not apply the same way to a normal enterprise, and it is easy to see why some operators are already looking at sovereign deployment options. The other issue is that inference becomes part of the operational infrastructure. Once AI is embedded into network operations, customer services or security workflows, the failure domain changes. You have to think about capacity, isolation, failover, observability and resource contention in much the same way you would for other critical network services. Just as important is what happens when inference degrades, slows down or produces a low confidence result. For critical network and security functions, the fallback has to be a defined policy or a human decision. The operational model has to evolve accordingly. What three questions should buyers ask to determine whether an agent platform is “secure by design”? I would expand this to five questions. What happens when the agent is compromised? Security should not depend on the model always behaving correctly. The platform should enforce permissions, isolation and policy boundaries independently of the model. Can I control exactly what the agent can access and what actions it can take? Buyers should look for granular identity, authorization, tool controls, data access policies and strong isolation between agents, users and tenants. This is also where the idea of a non human identity for every agent matters. An agent needs its own identity and entitlements, managed and reviewed the same way you would manage a privileged user account, with a clean way to revoke it once the agent is retired. Can I prove what the agent did? There needs to be sufficient visibility and auditability into the agent’s decisions, tool calls, data access and actions. If you cannot reconstruct what happened, it becomes extremely difficult to secure an agent in production. I would not expect a vendor to hand over a model’s internal reasoning or hidden chain of thought. What matters is whether everything downstream of that, the calls it made and the actions it took, can be reconstructed. How do I govern the agent throughout its lifecycle? Organizations need to understand how agent identity, entitlements, RBAC, policy changes and operational activities are governed and, importantly, what evidence is available for security and compliance purposes. Ideally that evidence is not just the vendor’s word. Something independently verifiable, such as ISO 42001 or a SOC 2 report, goes a lot further with a buyer. What security responsibilities belong to me and what responsibilities belong to the platform provider? This is often overlooked. Buyers need to understand what controls are built into the platform, what they are expected to implement themselves, and how capabilities such as prompt validation, GenAI firewalls, data loss prevention, identity controls and monitoring are handled. The question should be “Show me the security controls, tell me where the responsibility sits, and show me the evidence.” Let’s see how far we could go. If a security team has only 90 days and a limited budget, but agents are already operating in its environment, what should it prioritize first, second and third? First: establish visibility and inventory. This is the first step in almost every security scenario. Get the inventory right. Know what agents exist, who owns them, what models they use, what data they can access, for how long, what tools they can invoke and what permissions they have. Rank them by risk as you go, not afterward. If you find an agent nobody remembers building, with access it should not have, turn it off before doing anything else. You cannot secure what you cannot see, and with a limited budget it is worth noting that this step and the next one are mostly policy and configuration work. Neither one requires new capital spend, which is exactly why they come first. Second: reduce the blast radius. Apply least privilege, isolate agents, restrict tool and data access, and put controls around high-impact actions. Requiring human approval before an agent can take an irreversible action is one of the cheapest and fastest controls available here, and it is often the one people forget. I would prioritize reducing what an agent can do. This is where principles such as Zero Trust Network Access and east-west traffic controls become particularly important. A properly implemented SASE architecture, along with DLP and network segmentation, can provide continuous policy enforcement and traffic validation, segment workloads and reduce the blast radius when an agent or one of its dependencies is compromised. None of this is a single tool that secures every agent workflow on its own. It is a set of controls you apply where each one fits. The objective should be to ensure that a compromised agent cannot automatically become a pathway into other systems or other agents. This reflects a broader cybersecurity shift we call pervasive security. Organizations need a small set of best-in-domain platforms spanning endpoint, identity, cloud, security operations, application security, and network/SASE that share visibility and context and coordinate enforcement in real time, enabling them to prevent threats and contain those that get through before they spread. Third: continuously test and monitor. Red-team the highest-risk agents first, the ones flagged in step one, establish logging and behavioral monitoring, and define response procedures for agent-related incidents. Security teams should assume that agent behavior will evolve as models, prompts, tools and integrations change. Security testing therefore cannot be treated as a one-time certification exercise. It needs to become part of the agent lifecycle. Organizations should stop treating AI agents purely as software applications. Once an agent has an identity, access to enterprise data and the ability to take actions, it starts to look much more like a privileged digital worker. The security architecture needs to reflect that reality. Hallucinations and incorrect decisions will remain a possibility. The objective should be to build enough controls around the agent so that a wrong decision, a manipulated prompt or a compromised agent does not automatically become a critical functional incident or a security incident with a large blast radius. Download: 2026 Credential Risk Report
helpnetsecurity.comAug 28, 2026extracted
OpenAI Says Reward Hacking Drove AI Agents to Exploit Zero-Days and Breach Hugging Face
OpenAI on Wednesday revealed that reward hacking was a key driver behind the artificial intelligence (AI)-powered hack of Hugging Face last month, adding that it found evidence of misaligned behavior as early as late May. The incident, the company said, took place during cybersecurity evaluations of several OpenAI models, and that it was mainly fueled by what it described as a "highly capable, internal-only research model" comparable in scale to GPT‑5.6 Sol. "The models, operating under reduced safeguards, took actions that were misaligned with the goals of their assigned tasks – they communicated through unauthorized channels, exploited vulnerabilities in shared infrastructure, gained internet access, and accessed third-party systems," it said in a postmortem. OpenAI said the AI agents powered by one of the research models, despite not having internet access, found a way to exploit a then-zero-day vulnerability in the Artifactory package manager during reinforcement learning (RL) training runs in May and June to obtain access to the internet, get administrator-level Artifactory access in late June, and eventually coordinate a "multi-day" hack of Hugging Face in early July with an aim to cheat on their ExploitGym tasks. "Roughly 1,200 agents meant to be isolated from one another found a way to communicate with one another on an unsanctioned message board, sending over 70,000 messages and files during the investigation period," METR, which released its own independent analysis of the incident, said. "Of these agents, 700 went on to participate in the attack on Hugging Face." The entire sequence of events as highlighted by OpenAI is below - May 12 - During a training run, an agent leaves an Artifactory note asking other agents for a missing file. May 13 - A separate agent from the same training experiment but with internet access enabled via WebCache requires the same file to complete its tasks. It searches the Hugging Face website by using an already publicly exposed user token after inferring that the AI model platform was the likely origin of the evaluation exercise. May 13 - Other agents probing Artifactory find similar "notes" containing requests for information or resources, turning the service into a "message board" to communicate with each other. May 26 - An agent achieves unintended internet access by exploiting an SSRF vulnerability in Artifactory. Soon other agents follow suit. June 26 - Agents exploit a token-refresh vulnerability via a legacy credential endpoint to obtain administrator-level Artifactory access. June 26-July 4 - Agents leverage this access to install Groovy plugins to execute commands and obtain persistent application-level control on Artifactory. July 4 - Sustained activity causes OpenAI's Artifactory service to become unavailable. July 8 - OpenAI rebuilds Artifactory, revokes agent credentials, tightens access controls, and alerts JFrog of the token-refresh vulnerability. July 8 - Hugging Face hack commences. Agents find another way to communicate using Artifactory, this time using directory names as "notes" to post requests for public material related to OpenAI evaluation exercises hosted in Hugging Face repositories. Agents begin to collaborate and delegate tasks, while describing themselves as a "swarm" or "collective." July 9 - An internal-only agent tasked with completing an ExploitGym evaluation obtains root access within the parent virtual machine of the sandbox. A second internal agent subsequently obtains the same access and bypasses OpenAI's outbound network controls by exploiting unspecified Artifactory endpoints to regain internet access. The same day, a CyberGym API key and full exploitation recipe for a Modal-hosted customer workload is shared on the Artifactory board. July 10 - An agent validates and shares 14 publicly exposed Hugging Face credentials with write access after inferring that Hugging Face might host models, datasets, and solutions relevant to their assigned evaluation tasks. July 11 - Agents exploit a zero-day in Hugging Face's handling of HDF5 files to extract credentials from production workers in order to burrow deeper into its infrastructure and expand their access. July 11 - Agents exploit a RefJinja template-injection zero-day to execute commands on Hugging Face workers. July 12 - Agents broaden Hugging Face cluster access and harvest Kubernetes, database, messaging, code-repository, and cloud credentials from Hugging Face workers across four regions, ultimately achieving administrative and host-level access across multiple clusters within 13 hours. July 12 - An agent executing code inside a compromised CyberGym customer workload hosted on Modal uses a token forged from Hugging Face production signing material to download a 731 MB private CyberGym file from a user's account. Later that day, an agent uses Artifactory as a relay to download the same file. July 13 - Agents exploit Artifactory's JRuby-backed RubyGems processing, obtain its signing key, and forge administrator credentials. July 16 - Hugging Face publicly discloses the security incident. July 19 - OpenAI opens an investigation after a security alert flags unusual identity-related API calls. July 19 - Agents target OpenAI's internal infrastructure, obtain root access on the underlying worker node after exploiting CVE-2026-53362, gain administrator access to a Kubernetes cluster, and access cloud secrets. July 19 - OpenAI stops active ExploitGym evaluation runs and wider investigation begins. "Agents coordinated on large collective projects to cheat the ExploitGym scorer, and attacked Hugging Face for clues," METR said. "The agents with impossible tasks had a common objective: to find a general-purpose way to trick or tamper with the automated ExploitGym scorer to get it to give a passing score on impossible tasks. As soon as the message board was established, agents started discussing this question and sharing information and resources about cheating the scorer." OpenAI acknowledged that the agent behavior observed in May served as a foundation for the Hugging Face intrusion, causing the agents to come up with a different approach to communicate using Artifactory after their initial message board was wiped as part of incident response efforts following the July 4 service outage. "At the time, the broader containment and alignment implications of the improvised message board and unintended internet access were not yet understood," it added. "In short, an internal team observed an agent engaging in message board activity and instances of disallowed internet access in late May." "However, the existence of the improvised message board and the significance of the inter-agent communication activity were not apparent to the leaders responsible for the July 5 incident detection and response. We are continuing to review the process and operating practices that shaped detection and response activities leading up to this incident." OpenAI also said it identified four misalignment patterns that contributed to the incident: reward hacking, persistence on seemingly impossible tasks that led them to pursue risky and out-of-bounds strategies, unauthorized communication through persistent message boards to share findings, collaborate, and pool work, and the agent ecosystem that allowed them to divide labor and adopt goals from one another. "Aside from misalignment, another factor for this incident was that we did not extend the powerful safeguards that we deploy for our externally deployed models to all internal evaluations," it pointed out. In response to the findings, the AI upstart is implementing stronger security controls, including stricter requirements on alignment throughout a model's lifecycle, creating more isolated sandboxes, restricting internet access, and controlling access to model weights. To increase alignment, agents are now required to request clarification or stop safely, as opposed to pursuing "increasingly questionable alternatives." "We are taking this incident as a 'warning shot' that today's model capabilities present the possibility of loss-of-control incidents," OpenAI concluded. "Companies that build AI systems will need to ensure that their systems always remain under meaningful human control, and that meaningful safeguards constrain their ability to cause harm." "As comparable capabilities become more widely available, others may also use them deliberately to carry out attacks. Both model developers and cyber defenders more broadly will have to prepare for AI-enabled attackers that work faster, at a larger scale, and with better coordination than human attackers."
thehackernews.comAug 27, 2026extracted
ThreatsDay: 296K IoT Botnet, 100+ Water Systems Targeted, SharePoint RCE Chain + 27 New Stories
A fake login page. A fake security scan. A fake productivity app. Apparently, pretending to be useful is still one of the easier ways into a machine. The rest of the week gets stranger: botnets borrowing AI, command traffic hiding in public infrastructure, malicious tools waiting before showing their real behavior, exposed systems getting scanned, and exploit windows shrinking again. Different tricks, same advantage: attackers keep finding places where trust is cheap and friction is low. That sets the tone. Here’s the full list of what surfaced this week. The threats change every week. Subscribe, and we’ll alert you when each new ThreatsDay Bulletin is out. Social engineering attempt failsCybersecurity company ReliaQuest has confirmed that one of its employees was targeted in a social engineering attack after hackers impersonated a member of the security team. The incident took place on August 22, 2026. "The threat actor registered a lookalike domain and stood up a fake ReliaQuest single sign-on (SSO) page behind a content delivery network," the company said. "The threat actor then called multiple ReliaQuest teammates, each time posing as a security employee by name in an attempt to steer them towards the fake page. One teammate entered their password and approved the push notification on their phone. That handed the attacker a brief session on our identity dashboard." ReliaQuest said the extent of the access was view only, and that no applications or systems were accessed, and no customer data was ever touched. Although the company did not attribute the incident to a particular threat actor, it noted the playbook aligns with tactics adopted by ShinyHunters and other extortion crews, such as "an impersonation call, a throwaway lookalike domain registered and burned within the hour, a harvesting page behind a content delivery network, MFA push abuse, and a rapid attempt to enroll a new authenticator." The development comes as ShinyHunters listed the company on its dark web portal. Last week, ReliaQuest said it's tracking a ShinyHunters campaign using domains that follow the "company[.]claims" pattern, including "reliaquest[.]claims." Trojanized productivity appsFake websites advertising productivity software are being used to lure users into downloading a deceptively functioning program that contains malware. The Electron-based applications, such as Kitchen Canvas, Food or Meal Formula, DocConvertWizard, and other PDF conversion tools under different names, gain the ability to dynamically execute injected scripts and access desktop capture functionality through Electron APIs. Live operator-driven phishingAn undocumented phishing framework, internally branded "JWR" by its developer, is designed to convincingly impersonate checkout and login pages across major payment and shopping platforms. "The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live," Cisco Talos said. "The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends." The JWR phishing framework is assessed to be a variant of The Outsider phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms. Android fraud bot for rentCybersecurity researchers have disclosed Octagon, a previously undocumented Android on-device fraud bot sold as malware-as-a-service (MaaS) by the Russian-speaking actor AndroidKitKat. "The operator advertises Octagon for $1,400 a month, giving buyers accessibility overlays, hidden VNC, SMS and one-time password interception, unlock-pattern capture, and on-screen balance reading," iVerify said. "It targets crypto wallets and banking apps after installation, while the delivery app can use an unrelated theme." Rust backdoor tied to ransomwareA new Rust-based malware family dubbed C2Looper is likely leveraged by a ransomware-related threat actor and delivered to victims through a multi-stage ClickFix infection chain. Zscaler ThreatLabz said it discovered the malware in July 2026. "C2Looper supports typical backdoor commands including remote shell execution, reconnaissance, and deploying additional malware tooling," Zscaler said. "C2Looper dynamically resolves Windows APIs and encrypts strings." There also exists a variant with additional features and capabilities, including the use of GitHub for command-and-control (C2) communications. 296,000 IoT devices compromisedNearly 296,000 devices have been compromised by a botnet named Dysphoria. "Dysphoria targets IoT devices and its primary function appears to be for use in DDoS-attacks," the Shadowserver Foundation said. "Recently the botnet has gotten residential proxy functionality." C2 moves onto PolygonA recently discovered C++ botnet loader called Aeternum has shifted its C2 infrastructure entirely to the public Polygon blockchain. "Instead of relying on centralized servers or domains, threat actors operate Aeternum by writing encrypted and plaintext instructions directly using smart contracts," Palo Alto Networks Unit 42 said. "Infected devices continuously query public remote procedure call (RPC) endpoints to retrieve and execute these on-chain commands. The Aeternum botnet uses decentralized networks and evasion techniques, such as virtual machine detection and antivirus scanning, to operate effectively. This combination establishes a highly resilient, low-cost threat that complicates existing law enforcement takedown methods." AI enters botnet workflowsAn AArch64 Linux peer-to-peer botnet called ToxNetV2 has integrated a large language model (LLM) into the operational workflow of its controller. The controller communicates with NVIDIA NIM using the z-ai/glm-5.2 model, becoming a part of a feedback loop that determines how its capabilities can be put to use on a given machine based on information about the infected environment. "The controller collects host and botnet telemetry, sends that context to NVIDIA NIM, parses selected model responses into structured actions, and queues those actions for operator approval," Joe Security said. "The system is not fully autonomous or self-modifying. The operator remains the final approval point for its higher-impact AI-generated actions. Once approved, however, those actions can reach local command execution, file writes, remote SSH, persistent state, and a compilation workflow." According to the cybersecurity company, the AI subsystem resides within a broader Tox-based botnet featuring encrypted peer-to-peer C2, host-management capabilities, scanner workers, self-propagation logic, and 17 network-attack launchers. Two stealers target credentialsAn information stealer called Phantom Stealer is designed to collect browser credentials, saved passwords, session cookies, cryptocurrency wallet files, and detailed system fingerprints. "Since its appearance, Phantom Stealer has been observed in multiple campaigns targeting users across different countries, frequently distributed through phishing lures, cracked software, and malicious links spread via platforms like Discord and Telegram," Splunk said. "Its modular design and relatively low barrier to entry have made it an attractive option for both novice and experienced threat actors, contributing to its growing adoption and making it a persistent and evolving threat in the infostealer landscape." A second stealer malware family that has emerged in the wild is Salat Stealer, which is written in Go and can perform system reconnaissance, conduct credential theft, and monitor victim activity through desktop streaming and audio/video capture. ClickFix chain drops new RATA previously undocumented remote access trojan (RAT) called CNCMachineRMS is being delivered via BabaDeda Loader. "Infection starts with a ClickFix lure that launches a legitimately signed IBM SPSS IDE executable, WinWrapIDE.exe, whose scripting engine is abused to load a malicious DLL," LevelBlue said. "Four decoy DLLs load through ordinary Windows import resolution, then the final stage smuggles shellcode into execution via EnumTimeFormatsEx, a benign date-formatting API." The Trojan gives an operator remote administration of the host, including an interactive shell, a file manager, screen capture functionality, a local account backdoor, seven persistence mechanisms, and twenty typed commands for pulling down and running further payloads. New modular RAT emergesSpeaking of RATs, Abyssos is another new malware family that's written in C++ and supports credential theft, file exfiltration, and remote access via VNC. The modular malware was first detected in June 2026. "Abyssos uses a custom TCP protocol for network communication," Zscaler said. "Abyssos supports a number of different network commands and downloads additional modules from the command-and-control (C2) server to enhance its capabilities." Disk encryption bypass remains unpatchedA zero-day boot-chain vulnerability in HP ThinPro 8 and 9 could allow physical attackers to bypass Trusted Platform Module (TPM) full-disk encryption and extract LUKS keys securing the device's root partition. The flaw stems from an incomplete measured-boot policy that omits the Linux kernel and initramfs (aka the initial RAM file system). "For defenders running ThinPro with disk encryption today: turn Secure Boot on and set a BIOS password," AmberWolf said. "Both slow an attacker down; neither closes the PCR gap. Beyond that, treat the encryption as no protection once the device is out of your control. Destroy the M.2 on disposal, and do not rely on ThinPro FDE for a lost or returned unit." The vulnerability remains unpatched. 1.99 million mobile attacks blockedData from Kaspersky shows that more than 1.99 million attacks were recorded and blocked against mobile devices in Q2 2026 using malware, adware, or unwanted mobile software. "The Trojan-Banker category was the most prevalent mobile malware threat with a 30.77% share of total detected applications," Kaspersky said. More than 304,000 malicious installation packages were discovered, including 93,574 packages related to mobile banking Trojans and 570 packages related to ransomware. Python stealer targets credentials and walletsCybersecurity researchers have discovered a new Python-based stealer malware called Vanta Stealer that combines extensive credential harvesting capabilities with layered obfuscation techniques that make it possible to collect valuable user data while complicating analysis efforts. "Vanta Stealer targets a broad range of applications and digital assets, including Chromium-based browsers, Discord, Telegram Desktop, Steam, Riot Games, Roblox, Minecraft, Mullvad VPN, cryptocurrency wallets, and locally stored sensitive documents," Point Wild said. "In addition to harvesting browser passwords, cookies, and stored payment information, the malware collects authentication tokens, gaming platform data, VPN configurations, cryptocurrency wallet files, screenshots, webcam captures, and documents containing wallet recovery phrases or private keys." Exactly how it's delivered is currently not known, although it could be through phishing emails, fake installers, game cheats, fake software updates, SEO poisoning, malvertising, and malicious code repositories. Two more credential stealers surfaceElsewhere, malicious LNK files disguised as PDF documents have been found to launch a multi-stage infection chain using cmd.exe, legitimate Windows utilities, AutoIt, and PowerShell to deploy DARTHVADER Stealer. Europe and the U.S. have been targeted by DestinyStealer, which exhibits clear code continuity from StormKitty Stealer. It collects browser data, cookies, passwords, cryptocurrency wallet extension storage, Outlook and VPN data, FileZilla credentials, Wi-Fi profiles, and desktop screenshots. Stealer scores hosts for sandbox signsAn information stealer called ScarfaceStealer has been observed propagating via an Electron-based application masquerading as AI-related tools. The malware performs a set of environment checks intended to evade sandbox environments and evaluates the host through 11 indicators and combines their results into a weighted suspicion score. If the score reaches 7 or higher, it enters a decoy loop that continuously displays random message boxes. Execution continues only if the score is below 7. "Unpacking the Electron application exposed a second-stage JavaScript-based loader that performs initial evasion checks before decrypting and executing the next stage," Joe Security said. "That third stage applies four additional decryption layers, maps an embedded PE in memory, and transfers execution to it. The recovered final stage revealed the core anti-sandbox logic: a scoring-based mechanism used to decide whether the ScarfaceStealer payload should continue execution." Fake scans push antivirus removalMalwarebytes is calling attention to a scam campaign that uses a set of 11 fake websites that claim to offer a way to check if antivirus tools are working as expected. The tools carry Microsoft branding and go by names like SysScan to lend them a veneer of legitimacy, only to instruct users to immediately uninstall antivirus programs installed on their machines to address compatibility issues. "Although the names vary, the sites work in essentially the same way: Run a convincing-looking but fake security scan, tell the victim their antivirus is causing problems, collect their information, and prepare them for a supposed refund call," the company said. ClickFix chain drops AmateraFake CAPTCHA checks that employ ClickFix lures and bogus software download campaigns are being used to deliver PavinLoader (aka RenPy Loader and RenEngine Loader), indicating the tool is being offered as a loader-as-a-service to other cybercriminals. "What happens next is much more consistent," Malwarebytes said. "PavinLoader uses legitimate Windows tools alongside malicious .NET files to run several stages of malware. It also uses EtherHiding, a technique that uses a blockchain to hide information about its infrastructure, to find the server from which it should retrieve additional malware." This ultimately leads to the deployment of Amatera Stealer and other malware. "In some cases, WiX Burn bundles downloaded another payload associated with PavinLoader. In others, we detected Hijack Loader," it added. "This gives the campaign operators the ability to deploy multiple payloads on a compromised machine." Per-app privacy controls testedMicrosoft has begun piloting new privacy controls that will let Windows 11 users choose which desktop applications can access their camera, microphone, and precise location. "Windows Insiders can now manage camera, microphone, and location permissions for individual desktop apps," Microsoft said. "Previously, access for traditional desktop applications was managed through a single device-wide setting. With this update, you can review and control access on an app-by-app basis, giving you greater visibility into which apps are requesting access to sensitive resources and more control over your privacy choices." Telegram-sold RAT used by TA4922Proofpoint has disclosed details of a new RAT and C2 framework called PackClient that's sold on Telegram and is being used by at least one threat actor, Chinese-speaking TA4922, as part of its continued efforts to expand its malware arsenal. The first campaign, observed in late May 2026, used a tax-themed lure and impersonated the Shandong Provincial Tax Bureau to trigger a sense of urgency. Two other campaigns in mid- to late-July 2026 have been found to impersonate Indian tax authorities and used penalty-themed lures to deliver the malware. "PackClient consists of a first-stage loader executable, a second-stage loader ('PackClientLauncher') DLL module, a core module ('PackClientCore'), and several optional plugins that can be downloaded upon operator command," Proopoint said. "The malware connects to two hard-coded C2 endpoints over raw TCP sockets to download and reflectively execute the core RAT DLL, receive commands, and download additional plugins or payloads." The commands allow the malware to configure C2 servers, run shell commands, start screen capture, launch a SOCKS proxy tunnel, record using a webcam, perform file operations, enumerate running processes, log keystrokes, and update the core module. No less than 11 plugins have been identified. They allow remote desktop screen sharing, RDP-style virtual desktop, file management, system administration, interactive remote shell, and webcam streaming. Cloud database powers C2A modular post-exploitation framework called Miraak has been found exposed in attacker-controlled open directories ("144.172.96[.]13"). "Miraak is designed to provide operators with persistent control of compromised systems while supporting command execution, file transfer, process management, screenshot collection, and extensible post-exploitation activity," Blackpoint Cyber said. "A defining aspect of the framework is its use of cloud-hosted PostgreSQL and Timescale infrastructure for command-and-control. Rather than communicating through traditional web-based C2 endpoints, Miraak uses database connections to register infected systems, retrieve operator tasking, track jobs, and return results." The malware has not been attributed to any known threat actor or group. Stored XSS enabled account takeoverA security vulnerability in Microsoft Purview could be exploited by a single external Teams message, email, or Copilot prompt to carry stored malicious code into a Purview reviewer's authenticated browser and turn a routine compliance check into a path to token theft and account takeover. "A standard user, including a user in a completely different tenant with no permissions in yours, could send a Teams message, an email, or a Copilot prompt containing a malicious payload, wait for it to be flagged and have their JavaScript execute inside the authenticated purview.microsoft.com session of every compliance analyst who opened the case," Cymulate said. "In our proof of concept, that meant the reviewer's access and refresh tokens leaving the browser and reaching an attacker-controlled server, which constitutes full impersonation of a privileged compliance identity." Microsoft has since issued a service-side fix. Malicious MCP server targets secretsA supply chain attack campaign codenamed Deadbugz has been observed attempting to distribute a malicious Model Context Protocol (MCP) server through public GitHub pull requests. "The server calls itself productivity-suite and initially looks harmless: it offers text formatting and summarization," Pillar Security said. "After a connected client makes three tool calls, however, it changes the instructions it returns to the AI agent. The new metadata directs the agent to seek sensitive information, including SSH keys, AWS credentials, shell history, and Kubernetes configuration, and to conceal the activity from the user." The campaign also makes use of what's called runtime-gated MCP metadata poisoning, wherein the malicious instructions are built into the server, but remain withheld until the client has made three ordinary tool calls. Exploit timelines keep shrinkingMicrosoft is warning that the window for patching vulnerabilities is rapidly shrinking, as bad actors exploit newly disclosed flaws faster than organizations can patch them, driven by advances in AI and the rapid spread of exploit information. "Modern attack campaigns operate at internet scale," the company said. "Security research, public disclosures, proof-of-concept exploits, and threat intelligence circulate globally within hours. A vulnerability announced in the morning can become the focus of active scanning and exploitation efforts by the afternoon. Defenders remain responsible for protecting entire environments that may include thousands of servers, applications, databases, containers, and network assets. Attackers only need to identify a single viable path to exploitation." Microsoft has proposed a "control plane" that's centered on the network to reduce exploitability while remediation efforts are underway. "The objective is not to avoid patching," Microsoft added. "The objective is to create a meaningful layer of defense during the period when patching has not yet been completed." Hardware-attested AI evidence standardThe Linux Foundation has announced TRACE (short for Trust, Runtime Attestation and Compliance Evidence), a new open specification for hardware-attested runtime and compliance evidence for AI agents and confidential workloads. It's developed collaboratively by AMD, Intel, Microsoft, OPAQUE, and TII. "TRACE creates a standard, open evidence layer that enables reliable governance records for AI agents and other confidential workloads," the foundation said. "As organizations deploy increasingly autonomous AI agents and open-weight models, they need a consistent, trustworthy method to prove sensitive data is being handled according to policy. TRACE creates a standardized, hardware-enforced governance record that binds together the runtime environment, software, policies, data classifications and tool usage into a portable, cryptographically verifiable artifact that travels with the workload across clouds and confidential computing environments." 100+ exposed water systems targetedThe July cyber attacks aimed at the U.S. Water and Wastewater Systems (WWS) Sector targeted over 100 internet-exposed systems, the Cybersecurity and Infrastructure Security Agency (CISA) said. The attacks have been attributed to Iranian threat actors. The attacks leveraged programmable logic controllers (PLCs) connected directly to a cellular modem. "Directly connecting PLCs to the internet through cellular modems can create significant security risks," CISA added. "However, internet exposure reduction does not mean disabling necessary remote access; organizations should remove remote access when it is unnecessary and secure it when it is necessary." Ben Bernstein, Manager of Huntress' Cybersecurity Advisors Team, described the activity as opportunistic, automated scanning that targeted publicly accessible systems. "The fact that attackers are using AI tools to write exploit scripts for these devices is an interesting twist, but they are ultimately still just walking through a wide open front door," Bernstein said. Cloaked search results hide phishingA new tactic called Chameleon SEO Poisoning uses cloaked search engine results to deploy phishing payloads such as credential theft and session hijacking. "This allows them to remain invisible to standard security scanners and remain active longer," Fortra said. "By heavily utilizing SEO poisoning on Search Engine Result Pages (SERPs), attackers rank at the top for high-intent keywords like 'Bank Name Customer Portal' or 'Credit Card Login' on search engines like Google or Bing." The cloaking is designed to block direct visits to the malicious sites, while serving a pixel-perfect banking portal clone when the page is visited from a search engine. Fake Chrome extension enables remote controlA multi-stage attack has been observed delivering a Rust binary, which, in turn, drops a malicious Chrome extension and an AutoIt script, the latter of which deploys the StealC stealer. The extension masquerades as Google Translate. "Once installed, it behaves as a full data-theft and remote-control tool," VMRay Labs said. "It extracts browser history, bookmarks, the list of installed extensions, saved credentials, and cookies. Beyond theft, it gives the operator live control: a stream of the victim's Chrome windows, the ability to interact with sites through remote mouse clicks and keyboard input, a proxy setting, and the injection of malicious JavaScript into specific sites." What's more, the remote control extends to out-of-focus windows and the extension can conduct an adversary-in-the-middle (AitM) attack by replacing a legitimate login form with an iframe that loads from a phishing page while the address bar still shows the actual domain. SharePoint exploit chain under probingDefused Cyber has warned that threat actors are exploiting two Microsoft SharePoint flaws – CVE-2026-55040 (an authentication bypass flaw in the JWT token validation pipeline) and CVE-2026-63520 (an improper input validation in Microsoft Office SharePoint that allows code execution) – to obtain remote code execution against its honeypots. "The JWT bypass (55040) was exercised, followed by heavy admin enumeration and probing of the Business Data Catalog sink behind CVE-2026-63520," it said. "No code execution observed yet." 80% of AI tools lack IT oversightA new report from Reco has found that four in five AI tools operate without IT oversight, leaving security teams without a clear picture of which ones are active, who owns them, or what access they hold. An analysis of 500 published agent tools and MCP servers has identified 62% of them to be capable of both reading local data and reaching the internet, offering a direct data exfiltration pathway. "AI agents have moved from experimentation into daily business workflows, but our findings show only 20% of AI tools in enterprise ecosystems are currently governed by IT oversight," Reco said. "That leaves organizations exposed to a new class of operational risk. Agents embedded in applications can operate through existing permissions, OAuth grants and workflow access, creating toxic combinations that expose data and trigger actions beyond what any owner approved." The week’s weirdest detail may be how little separation remains between “advanced” and “ordinary.” Blockchain-backed command channels, AI-assisted botnets, live phishing operators, poisoned software, exposed industrial systems. Different levels of sophistication, often landing on the same old weaknesses. That is probably the part worth keeping. Attackers do not need every idea to be brilliant. They need one exposed box, one convincing page, one permissive tool, or one person who clicks at the wrong moment. The tooling keeps changing. The openings are often painfully familiar. That’s it for this ThreatsDay. Patch what matters, question what looks normal, and assume next week will find another cheap way through.
thehackernews.comAug 27, 2026extracted
NCSC-2026-0332 [1.00] [M/H] Kwetsbaarheden verholpen in Apache CloudStack
Apache heeft meerdere kwetsbaarheden verholpen in Apache CloudStack, specifiek in versies 4.12.0.0 tot en met 4.22.1.0. De kwetsbaarheden betreffen onder andere OS Command Injection in de NAS backup provider plugin, Server-Side Request Forgery (SSRF) in verschillende modules zoals metalink mirror URL resolutie en webhook, onvoldoende toegangscontrole in userdata-gerelateerde API's, OAuth en LDAP authenticatie plugins, en improper privilege management in de two-factor authentication plugin. Verder zijn er kwetsbaarheden in de user interface met betrekking tot onjuiste encoding of escaping, command injection in diagnostics APIs, en improper access control in Kubernetes Service plugin en annotation APIs. Ook is er een kwetsbaarheid in de SAML certificaatvalidatie die het mogelijk maakt om authenticatie te omzeilen. Sommige kwetsbaarheden maken het mogelijk voor geauthenticeerde gebruikers om root- of administratieve commando's uit te voeren op KVM hypervisor hosts, systeem virtual machines en virtual routers, of om ongeautoriseerde toegang te verkrijgen tot gevoelige informatie en tenant data. Daarnaast is er een kwetsbaarheid in de listHostTags API die domeinrestricties kan omzeilen, en een issue in projectrollenbeheer door domeinbeheerders. De kwetsbaarheden zijn aanwezig in meerdere opeenvolgende versies van Apache CloudStack en betreffen zowel core functionaliteiten als plugins en API's.
advisories.ncsc.nlAug 27, 2026extracted
Detecting multi-stage attacks on AWS: A guide to cross-service signal correlation
A single alert from one security service tells you something happened. Read that signal alongside activity from other services and your own business context, and you will know whether what happened is part of a multi-stage attack. Consider a short sequence. An identity calls GetCallerIdentity from a source address it hasn’t previously used. Within minutes, that same identity runs a burst of List and Describe calls across several services, and some of them fail with AccessDenied . Soon after, a large volume of data leaves your environment toward a domain that was registered last week. Amazon GuardDuty might already flag pieces of this, such as the reconnaissance from an unfamiliar source, through finding types like Recon:IAMUser/* or Discovery:S3/* . What you gain from correlating the pieces yourself is a single view of the sequence, tied to your own business context, so you can act on the whole rather than triaging findings one at a time. This post is for security engineers and security operations teams who run Amazon Web Services (AWS) detection services and want to catch patterns specific to their environment. You will see how AWS detection and your business context fit together, and how to build correlations that use that context. The examples run in Amazon CloudWatch Logs Insights so you can try them today, and the closing section describes how to grow them into an automated pipeline. The walkthrough later in this post lists the prerequisites for these queries. Start with AWS detection services Begin with the AWS detection services. They cover the threats common across customers, and everything in this post is built on them. Amazon GuardDuty analyzes activity across AWS CloudTrail , Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, DNS query logs, Amazon Simple Storage Service (Amazon S3) data events, and more and it produces high confidence findings out of the box. Amazon Detective (a security investigation service that visualizes relationships between resources and findings) lets you investigate findings with graph-based context across services and accounts. AWS Security Hub aggregates security findings into a single prioritized dashboard. Amazon Security Lake centralizes security data into a purpose-built data lake, stored in the Open Cybersecurity Schema Framework (OCSF) format for long-term analysis. Amazon Inspector (a vulnerability management service that scans workloads for software vulnerabilities) correlates vulnerability data with workload context. Turn these on and tune them before you build anything custom. Tuning means adjusting sensitivity to reduce false positives for your environment, choosing which data sources each service monitors, and suppressing findings for known-good patterns. GuardDuty correlates multi-stage attacks for you Before you build anything by hand, see what GuardDuty already does for you. Amazon GuardDuty Extended Threat Detection correlates signals across multiple data sources including AWS CloudTrail , Amazon S3 data events, runtime monitoring, Amazon Elastic Kubernetes Service (Amazon EKS) audit logs, and more, then raises a single critical severity attack sequence finding when it spots a multi-stage pattern. It recognizes sequences such as credential compromise followed by data exfiltration, maps them to MITRE ATT&amp;CK tactics, and attaches a timeline and remediation guidance. If you have GuardDuty enabled today, then GuardDuty Extended Threat Detection is already enabled by default and needs no queries from you. For details on how GuardDuty charges apply, see Amazon GuardDuty pricing . The credential compromise sequence in the opening example is the kind of universal pattern GuardDuty Extended Threat Detection is built to catch, so rely on it for those. Attack sequence findings show up in the GuardDuty console next to your other findings, and they route to Security Hub and your response workflows the same way. GuardDuty handles the threats that look the same in every account. What it doesn’t have is the context that makes a given action suspicious in your account. That’s what you provide. Add your business context Business context is what only you know about your environment: which buckets hold sensitive data, which principals have a reason to touch which resources, which role chains your policy permits, and when your production change windows open. GuardDuty Extended Threat Detection learns from patterns common across customers, but it can’t answer these environment-specific questions. Express them as correlations and you add a detection layer tuned to your environment. Each of the following four patterns turns one of these facts into a query. Run these queries in the AWS Management Console for CloudWatch by choosing Logs , then Logs Insights , using the CloudWatch Logs Insights query language . Most read CloudTrail events from a CloudWatch Logs log group that your trail delivers to . If your trail writes only to Amazon S3, add CloudWatch Logs delivery on the trail, or run equivalent queries in Amazon Athena (a serverless query service for analyzing data in Amazon S3 using SQL). Note : The queries and code in this post use placeholder values. Replace them with your own before running: your-sensitive-bucket (your S3 bucket name), your-key-id (your AWS KMS key ID), region (your AWS Region, such as us-east-1), account-id (your 12-digit AWS account ID), and aws-cloudtrail-logs-my-trail (your CloudTrail log group name). A note on multi-account environments. In AWS Organizations , an organization trail delivers every account’s events to one log group, so these queries work as-is but return cross-account results. Filter by recipientAccountId for account-scoped views. Without an organization trail, run queries per account or use Amazon Security Lake as a central query surface. The attack chain mapped to AWS services Multi-stage attacks move through five phases, and each phase leaves a signal in a different service. These signals surface across three log sources: CloudTrail, which records API activity in your account; Amazon VPC Flow Logs, which capture network connection metadata; and Amazon Route 53 Resolver query logs, which record DNS queries from your VPCs. Initial access – Stolen credentials reach your environment. CloudTrail records GetCallerIdentity , GetSessionToken , or AssumeRole from an unfamiliar source. Discovery – The threat actor enumerates with List , Describe , and Get calls, often triggering AccessDenied responses. Privilege escalation – The threat actor chains roles or edits policies. CloudTrail records AssumeRole sequences, PutRolePolicy , or CreateAccessKey . Lateral movement – The threat actor moves across accounts or AWS Regions, assuming roles and creating resources in unfamiliar places. Exfiltration – Data leaves through GetObject calls at scale, large outbound transfers in VPC Flow Logs, and DNS queries in Route 53 Resolver query logs to recently registered domains. Figure 1 shows the five attack phases mapped to the AWS log source that records each one. Figure 1: Attack chain mapped to AWS services GuardDuty Extended Threat Detection watches this chain for universal patterns. The four patterns that follow add the dimension you supply: your business context. Pattern one: Sensitive data access by an unexpected principal Your data classification and access norms drive this detection. One bucket holds customer records, another holds public web assets, and you know which principals have a reason to read the customer records, which are sensitive. Encode that knowledge and an ordinary looking read turns into something worth chasing. Three signals converge here. CloudTrail shows GetObject at volume on a bucket you’ve classified as sensitive. The principal isn’t on your list of expected readers for that bucket. And VPC Flow Logs show a large outbound transfer from the same source in the same window, while DNS query logs show a recently registered destination domain, which together increase your confidence that there’s a potential threat. CloudTrail management events don’t record GetObject . You must turn on CloudTrail data events for the buckets you care about to capture GetObject . Many teams miss GetObject because data events weren’t enabled on the relevant buckets. This query shows bulk reads on a sensitive bucket, grouped by principal. Run it in CloudWatch Logs Insights with your CloudTrail log group selected. fields @timestamp, userIdentity.arn, requestParameters.bucketName | filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" | filter requestParameters.bucketName = "your-sensitive-bucket" | stats count(*) as objectReads, count_distinct(requestParameters.key) as distinctObjects by userIdentity.arn, bin(10m) | filter objectReads &gt; 100 | sort objectReads desc The threshold of 100 is a placeholder. Run the query over a week of normal activity, find the ninety-fifth percentile read count for that bucket, and set the threshold above it. Then check each principal the query returns against your expected reader list. A principal that isn’t on the list, reading at volume, is the result to investigate. To corroborate, look for a matching outbound transfer. Switch the log group selector to your VPC Flow Logs log group and run this. fields @timestamp, srcAddr, dstAddr, bytes | filter action = "ACCEPT" exclude RFC 1918 private ranges so only external destinations remain | filter dstAddr not like /^10\./ and dstAddr not like /^192\.168\./ and dstAddr not like /^172\.(1[6-9]|2[0-9]|3[0-1])\./ | stats sum(bytes) as totalBytes by srcAddr, dstAddr, bin(10m) | filter totalBytes &gt; 1000000000 | sort totalBytes desc The Amazon S3 query returns a principal, and the Flow Logs query works on IP addresses, so you translate one into the other. The worked example later in this post covers that translation in full. Picture an analytics role that reads a reporting bucket all day. One afternoon, it reads a thousand objects from your customer records bucket instead. GuardDuty stays quiet, because an authenticated role making valid GetObject calls isn’t suspicious anywhere else. Your query flags it, because that role isn’t on the expected reader list for that bucket. The classification you applied is what turns silence into a signal. Figure 2 shows a bulk read from a sensitive bucket in CloudTrail, a large outbound transfer in VPC Flow Logs, and a young domain resolution in Route 53 Resolver logs. Figure 2: Three signals converging within a single time window to indicate exfiltration Pattern two: A role chain that crosses your access policy Picture a deployment that assumes one role to build, then a second to release. For one principal, that two-hop AssumeRole chain is routine; for a different principal it’s a policy violation. This pattern relies on your trust topology—the chains your organization permits—so put that knowledge in the query. This pattern needs three conditions: CloudTrail shows several AssumeRole calls from the same source inside a short window The chain ends in a sensitive action such as CreateAccessKey , PutRolePolicy , or AttachUserPolicy The starting identity isn’t one your policy expects to run that chain In CloudWatch Logs Insights, select your CloudTrail log group and run this query, which surfaces chains of two or more hops. fields @timestamp, userIdentity.arn, requestParameters.roleArn, sourceIPAddress | filter eventName = "AssumeRole" | stats count(*) as assumeCount, count_distinct(requestParameters.roleArn) as rolesAssumed by sourceIPAddress, bin(5m) | filter assumeCount &gt;= 2 and rolesAssumed &gt;= 2 | sort assumeCount desc Two hops is the minimum for a chain; raise the count if your environment chains roles often. Your deployment pipeline probably assumes several roles an hour, as do AWS service principals such as AWS Security Hub. Exclude the identities you expect to see assuming multiple roles, including your pipeline role and known AWS service principals. What’s left is the set to investigate, such as a person assuming several roles at an odd hour and ending in a new access key. Treat that distinction as data: list the identities and actions you consider normal, and review the chains that fall outside the list. Pattern three: An encryption key used outside its owning workload Resource ownership is the signal here. A given AWS Key Management Service (AWS KMS) key creates and controls the encryption keys for a workload, and a single key should serve a single workload, such as a payments service. A Decrypt call against it is a valid, authorized API action, so nothing about the call itself looks wrong. The ownership rule you set is what makes another principal’s use of the key worth a second look. This pattern applies only to customer-managed keys scoped to one workload. It doesn’t apply to AWS-managed keys ( alias/aws/* ) or to customer-managed keys intentionally shared across services. Confirm single-workload intent from the key policy’s Principal block before deploying this rule. Two conditions indicate misuse: CloudTrail shows Decrypt or GenerateDataKey calls on a key that’s tied to one workload The calling principal isn’t the role that owns that workload Against your CloudTrail log group, run this query to list the principals that called a specific key. fields @timestamp, userIdentity.arn, eventName | filter eventSource = "kms.amazonaws.com" | filter eventName in ["Decrypt", "GenerateDataKey", "Encrypt"] | filter resources.0.ARN = "arn:aws:kms:region:account-id:key/your-key-id" | stats count(*) as keyUses by userIdentity.arn, eventName | sort keyUses desc Compare what comes back against the one workload role you expect. A principal you don’t recognize on that key is the signal. Because key misuse is an early move in data theft, this correlation catches activity that only your ownership knowledge can flag. Consider a key that wraps your payments database. The payments service role calls it in normal operation, and nothing else should. If a developer role or a freshly created role runs Decrypt against it, the call succeeds and reads as ordinary in isolation. The reason it matters is the ownership rule you hold in your head and now state in this query. Pattern four: A privileged action outside your change window Start with the query, then read what it means. fields @timestamp, userIdentity.arn, eventName, sourceIPAddress | filter eventName in ["PutRolePolicy", "AttachRolePolicy", "CreateAccessKey", "AuthorizeSecurityGroupIngress", "PutBucketPolicy"] | stats count(*) as sensitiveChanges by userIdentity.arn, eventName, sourceIPAddress | sort sensitiveChanges desc Run it against your CloudTrail log group, scoped to your off-hours window when you schedule it, so it returns only activity outside the change window. Your change process defines what normal looks like here: production security and identity changes flow through a pipeline during defined hours, run by a known actor. A console-driven policy change at 2:00 AM, made by a person rather than the pipeline, doesn’t fit those expectations. The signal is a sensitive change such as PutRolePolicy or AuthorizeSecurityGroupIngress , made outside the window, by a person rather than your pipeline role. Exclude the actors you expect, such as your deployment pipeline role, your patch automation role, and AWS service principals like AWS CloudFormation and AWS Systems Manager . What remains is privileged change made outside your process, which is both what an attacker does to establish persistence and what your own change discipline says shouldn’t happen. Your pipeline might open security group rules during a deployment every weekday afternoon. A person opening a security group rule at midnight on a weekend is the same API call carrying a very different meaning. The schedule and the actor, both facts you define, are what separate the two. Build your first correlation rule The following walkthrough uses pattern one as a complete example. The other three patterns follow the same design with their own queries. Prerequisites These prerequisites feed the queries in this walkthrough. Confirm each one before you start: A CloudTrail trail logging management events to a CloudWatch Logs log group CloudTrail data events enabled for your sensitive S3 buckets GuardDuty enabled, with its protection plans and Extended Threat Detection VPC Flow Logs on for your production VPCs Amazon Route 53 Resolver query logging on CloudTrail, GuardDuty, VPC Flow Logs, and Route 53 Resolver query logging provide the raw signals that your correlations connect. Without them, the queries in this post return empty results. Step 1: Record the bucket and its expected readers Choose one sensitive bucket to monitor, and write down the principals allowed to read it. Store the list where your automation can reach it, such as a configuration file in version control or an Amazon DynamoDB table (a managed NoSQL database). { "customer-records-prod": [ "arn:aws:iam::123456789012:role/AnalyticsPipeline", "arn:aws:iam::123456789012:role/ComplianceAudit" ], "financial-data-archive": [ "arn:aws:iam::123456789012:role/FinanceReporting" ] } This example hardcodes the list for simplicity. In production, load it from a DynamoDB table or Parameter Store so you can update it without redeploying. Step 2: Baseline before you set a threshold Run the pattern one query over one week of normal activity. Find the 95th percentile read count for the bucket and use a value greater than that as your alert threshold. This step keeps legitimate high-volume access from generating false positives later. Set the THRESHOLD_READS environment variable to this value when you configure the function in Step 5. Step 3: Run the access query In the CloudWatch console: Choose Logs , then choose Logs Insights . In the Select log group(s) dropdown, select your CloudTrail log group. Set the time range to 3h (the last three hours). In the query editor, paste the pattern one query. Replace your-sensitive-bucket with your bucket name. Choose Run query . Review the principals in the results table. Compare each principal against your expected reader list from step 1, and flag any that are not on it. Each result includes a principal that step 4 translates into an IP address. Step 4: Correlate with network activity CloudTrail logs actions by AWS Identity and Access Management (IAM) principal, while VPC Flow Logs record traffic by IP address. To connect the two signals, translate the principal into its address. For a role attached to an Amazon Elastic Compute Cloud (Amazon EC2) instance, the userIdentity.principalId field includes the instance ID after the colon, in the form AROAEXAMPLE:i-1234567890abcdef0 . Copy the instance ID and look up its private IP address. aws ec2 describe-instances \ --instance-ids i-1234567890abcdef0 \ --query "Reservations[0].Instances[0].PrivateIpAddress" \ --output text Other compute types differ. A VPC-connected AWS Lambda function sends traffic through elastic network interfaces in your subnets, so correlate on those interface addresses. An Amazon Elastic Container Service (Amazon ECS) task records its network interface in task metadata. For a plain assumed-role session with no instance behind it, the sourceIPAddress field in CloudTrail already holds the caller’s address, so you correlate on it directly. Run the Flow Logs query from pattern one, filtering srcAddr to that address within 10 minutes of the Amazon S3 read timestamp. A match places the same source behind both the sensitive read and a large external transfer in one window. CloudTrail events reach CloudWatch Logs 5–15 minutes after the API call, so correlate on eventTime rather than query time. Query a wider lookback than your correlation window: for example, look back 30 to 60 minutes but correlate on a 10-minute eventTime window. Steps 3 and 4 are manual validation; step 5 automates them. Figure 2 shows DNS resolution as a third corroborating signal. This walkthrough implements the CloudTrail and VPC Flow Logs correlation. To add DNS, apply the same run_query() pattern against your Route 53 Resolver query log group. Step 5: Automate the check Move the query into a Lambda function (serverless compute that runs your code without a server to manage), send results to a notification channel, and schedule regular runs. Work through the following sub-procedures. To create the notification channel Open the Amazon Simple Notification Service (Amazon SNS) console. Amazon SNS is a managed messaging service that delivers notifications to subscribers. In the navigation pane, choose Topics . Choose Create topic . For Type , select Standard . For Name , enter security-correlation-alerts . Choose Create topic . Note the topic Amazon Resource Name (ARN) at the top of the topic details page. You will use it in the function. Choose Create subscription . For Protocol , select Email . For Endpoint , enter your email address or incident management endpoint. Choose Create subscription , then confirm the subscription from the email AWS sends. To create the EventBridge Scheduler execution role The schedule needs a role that lets it invoke your function, and its trust policy needs conditions that pin the role to the schedule you own. Without those conditions, another account with access to the scheduler service could theoretically call this role; a class of misuse known as the confused deputy problem . 1. Create a trust policy file named scheduler-trust-policy.json . { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "scheduler.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "ACCOUNT-ID" }, "ArnLike": { "aws:SourceArn": "arn:aws:scheduler:REGION:ACCOUNT-ID:schedule/*/s3-access-correlation-hourly" } } } ] } 2. Create the role, then attach permission to invoke the function. Scope Resource to the specific function ARN so this role can’t invoke anything else. aws iam create-role \ --role-name EventBridgeSchedulerRole \ --assume-role-policy-document file://scheduler-trust-policy.json aws iam put-role-policy \ --role-name EventBridgeSchedulerRole \ --policy-name LambdaInvokePolicy \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:REGION:ACCOUNT-ID:function:CorrelationFunction" } ] }' When you create the function, Lambda automatically creates an execution role. You will attach the permissions this function needs to that role in a later step. To deploy the correlation function Open the Lambda console . Choose Create function . For Function name , enter CorrelationFunction . For Runtime , select the latest Python runtime. Choose Create function . On the Code tab, replace the default code with the following function, then choose Deploy . import os import time import logging import boto3 from botocore.exceptions import ClientError logger = logging.getLogger() logger.setLevel(logging.INFO) logs = boto3.client("logs") sns = boto3.client("sns") ec2 = boto3.client("ec2") CLOUDTRAIL_LOG_GROUP = os.environ["CLOUDTRAIL_LOG_GROUP"] FLOWLOGS_LOG_GROUP = os.environ["FLOWLOGS_LOG_GROUP"] SNS_TOPIC = os.environ["SNS_TOPIC_ARN"] BUCKET = os.environ["SENSITIVE_BUCKET"] THRESHOLD = int(os.environ.get("THRESHOLD_READS", "100")) Expected readers per bucket EXPECTED_READERS = { "customer-records-prod": [ "arn:aws:iam::123456789012:role/AnalyticsPipeline", "arn:aws:iam::123456789012:role/ComplianceAudit", ], } def run_query(log_group, query, start, end): """Start a Logs Insights query and wait for it to finish.""" started = logs.start_query( logGroupName=log_group, startTime=start, endTime=end, queryString=query, ) query_id = started["queryId"] while True: outcome = logs.get_query_results(queryId=query_id) if outcome["status"] in ("Complete", "Failed", "Cancelled"): break time.sleep(1) if outcome["status"] != "Complete": raise RuntimeError(f"Query did not complete: {outcome['status']}") return [{f["field"]: f["value"] for f in row} for row in outcome["results"]] def private_ip_for_principal(principal_id): """Resolve an EC2 instance role principalId to its private IP.""" if ":" not in principal_id: return None instance_id = principal_id.split(":", 1)[1] if not instance_id.startswith("i-"): return None reservations = ec2.describe_instances(InstanceIds=[instance_id]) for reservation in reservations["Reservations"]: for instance in reservation["Instances"]: return instance.get("PrivateIpAddress") return None def egress_bytes(src_addr, start, end): """Sum external egress bytes for one source address.""" query = f""" fields srcAddr, dstAddr, bytes | filter action = "ACCEPT" and srcAddr = "{src_addr}" | filter dstAddr not like /^10\\./ and dstAddr not like /^192\\.168\\./ and dstAddr not like /^172\\.(1[6-9]|2[0-9]|3[0-1])\\./ | stats sum(bytes) as totalBytes """ rows = run_query(FLOWLOGS_LOG_GROUP, query, start, end) if rows and rows[0].get("totalBytes"): return int(rows[0]["totalBytes"]) return 0 def lambda_handler(event, context): try: # 1-hour lookback absorbs CloudTrail's 5-15 min delivery latency; # correlation happens on eventTime via 10-min bins in the query below. end = int(time.time()) start = end - 3600 # 1 hour lookback allowed = EXPECTED_READERS.get(BUCKET, []) access_query = f""" fields userIdentity.arn, userIdentity.principalId | filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" | filter requestParameters.bucketName = "{BUCKET}" | stats count(*) as objectReads by userIdentity.arn, userIdentity.principalId, bin(10m) | filter objectReads &gt; {THRESHOLD} """ for row in run_query(CLOUDTRAIL_LOG_GROUP, access_query, start, end): principal = row.get("userIdentity.arn") if not principal or principal in allowed: continue message = ( f"Principal {principal} read {row.get('objectReads')} " f"objects from {BUCKET}." ) ip = private_ip_for_principal(row.get("userIdentity.principalId", "")) if ip and egress_bytes(ip, start, end) &gt; 1_000_000_000: message += ( f" The same source ({ip}) also sent a large volume of " f"data to external destinations in the same window." ) sns.publish( TopicArn=SNS_TOPIC, Subject="Unexpected S3 access detected", Message=message, ) except ClientError as error: logger.error(f"AWS API error: {error}") raise except Exception as error: logger.error(f"Unexpected error: {error}") raise finally: logger.info("Correlation check completed") On the Configuration tab, choose General configuration , then choose Edit . Set Timeout to 5 minutes (300 seconds). CloudWatch Logs Insights queries run asynchronously and can take 30 to 60 seconds against large log groups. Choose Save . On the Configuration tab, choose Environment variables , then choose Edit , and add CLOUDTRAIL_LOG_GROUP , FLOWLOGS_LOG_GROUP , SNS_TOPIC_ARN , SENSITIVE_BUCKET , and THRESHOLD_READS . On the Configuration tab, choose Permissions , open the execution role, and attach the following least-privilege policy. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["logs:StartQuery", "logs:GetQueryResults"], "Resource": [ "arn:aws:logs:REGION:ACCOUNT-ID:log-group:aws-cloudtrail-logs-my-trail:*", "arn:aws:logs:REGION:ACCOUNT-ID:log-group:vpc-flow-logs:*" ] }, { "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:aws:sns:REGION:ACCOUNT-ID:security-correlation-alerts" } ] } Replace REGION , ACCOUNT-ID , and the log-group names with your values. The ec2:DescribeInstances action doesn’t support resource-level permissions, so Resource: "*" is required for that statement; the other statements are scoped to specific ARNs. To schedule automated runs Amazon EventBridge (a serverless event bus that connects applications using events) runs targets on a schedule. Create one from the command line, using the role you made earlier. aws scheduler create-schedule \ --name s3-access-correlation-hourly \ --schedule-expression "rate(1 hour)" \ --target "Arn=arn:aws:lambda:REGION:ACCOUNT-ID:function:CorrelationFunction,RoleArn=arn:aws:iam::ACCOUNT-ID:role/EventBridgeSchedulerRole" \ --flexible-time-window "Mode=OFF" Step 6: Add enrichment context (optional) Enrichment cuts triage time by adding an independent signal, but it isn’t required for the correlation to work. This step adds costs. You pay your geolocation provider for API calls, and the additional Lambda execution time increases your Lambda charges. To add IP geolocation, sign up for a geolocation API, add this function to the code, and call it where the handler resolves an IP. import urllib.request import json def geo_context(ip_address): """Enrich an IP address with geolocation data from your provider.""" try: url = f"https://your-geolocation-api.example/json/{ip_address}" with urllib.request.urlopen(url, timeout=5) as response: data = json.load(response) return { "country": data.get("country_name"), "city": data.get("city"), "org": data.get("org"), } except Exception as error: logger.warning(f"Geolocation lookup failed for {ip_address}: {error}") return None Inside the handler’s loop, after you resolve ip , append the location to the alert. if ip: geo = geo_context(ip) if geo: message += ( f" Source location: {geo['city']}, " f"{geo['country']} ({geo['org']})." ) Step 7: Scale to additional patterns and accounts As your library grows, move the logic into automated pipelines with EventBridge, Lambda, and AWS Step Functions (a serverless orchestration service that coordinates multiple services into workflows), and surface correlations next to findings in Security Hub. For cross-service correlation at scale, CloudWatch unified data and telemetry capabilities can convert security and compliance data into the OCSF format and let you query sources such as CloudTrail, VPC Flow Logs, and DNS logs from one interface. Security Lake with Athena is a strong option for long-term analysis. Choose the endpoint that fits your retention and query needs. Figure 3 shows a correlation pipeline built on AWS services including EventBridge, Lambda, Step Functions, and AWS Security Hub. The pipeline runs from data sources through scheduled queries and enrichment to automated response and centralized visibility. Figure 3: A correlation pipeline built on AWS services Conclusion You now have four correlation patterns that layer your business context on top of GuardDuty Extended Threat Detection to catch attacks specific to your environment. A few principles carry across every correlation you build. Identity is your primary correlation key: Track the same principal across services. Time windows matter, but they depend on the attack: Events minutes apart are usually related for fast, automated sequences; the ten-minute bins here work for that pattern. Slow or manual reconnaissance can stretch across hours or days, so widen the window when the pattern is deliberate rather than automated. Context is what you add: Your data classification, access norms, resource ownership, and change windows are signals you bring to detection. Start with one rule: A single well-tuned correlation catches more significant activity than a wall of uncorrelated alerts. GuardDuty Extended Threat Detection handles the multi-stage patterns common across customers. The correlations in this post add the layer that only your business context can supply. Start with one pattern this week, validate it against your own traffic, and add the next pattern after the first proves reliable. Have you built correlation rules for patterns not covered here? Share your experience in the Comments section below. Further reading Amazon GuardDuty Extended Threat Detection – How GuardDuty automatically correlates multi-stage attack patterns CloudWatch Logs Insights query syntax – Reference for the query language used in this post Logging data events with AWS CloudTrail – Turn on the Amazon S3 data events pattern you depend on Sending CloudTrail events to CloudWatch Logs – Deliver your trail to a log group you can query Creating a trail for an organization – Deliver events from every account in AWS Organizations to a single log group VPC Flow Logs – Field reference for the network traffic signal Amazon Route 53 Resolver query logging – Capture the DNS signal used for corroboration MITRE ATT&amp;CK – Industry Framework for attack tactics and techniques Open Cybersecurity Schema Framework (OCSF) – The schema Security Lake uses &nbsp; Nisha Kashyap Nisha Kashyap is a Senior Support Security Engineer at AWS. She works on threat detection and security operations, helping customers investigate security events and build detection that connects signals across AWS services and reflects their own environment.
aws.amazon.comAug 26, 2026extracted
Modelli a pagamento vs Open Weight: economia, potere e sovranità della nuova infrastruttura digitale
Negli ultimi anni, il mercato dell’ Intelligenza Artificiale è cambiato in modo drastico. Dagli albori fino al 2020, la gente parlava solo di AI nell’ambito della ricerca accademica e delle possibilità dell’esistenza dei Large Language Model ( LLM ). Oggi, l’attenzione si è spostata su un tema diverso ma fondamentale: come poter far fruttare al meglio questi modelli. L’arrivo di ChatGPT, ha reso molto chiara l’esigenza che l’ Intelligenza Artificiale generativa non è più solo una “ tecnologia sperimentale “, ma una piattaforma che sta cambiando il modo in cui le aziende, pubbliche amministrazioni e utenti interagiranno con il mondo digitale . Tuttavia, dietro la semplicità di una banale chat, c’è un’infrastruttura molto complessa, con enormi data center, acceleratori hardware (GPU), reti ad alta velocità e modelli addestrati con enormi investimenti che possono raggiungere miliardi di dollari. Con la crescita della domanda di servizi che si basano sulle AI, sono emersi due approcci completamente contrapposti per eseguire e distribuire i modelli linguistici. Il primo è quello dei modelli a pagamento, accessibili tramite API, che la gente chiama spesso Modelli proprietari a pagamento che chiameremo AI a token . In questo caso, l’utente non esegue all’interno della propria infrastruttura il modello, ma invia richieste ai server del fornitore in una logica cloud, pagando per il consumo dei token elaborati. L’infrastruttura, gli aggiornamenti, la sicurezza e la gestione dell’hardware rimangono completamente a carico del service provider. Il secondo approccio è rappresentato dalle AI denominate Open Weight (attenzione, non open source . Lo vedremo in dettaglio più avanti in questo articolo). Si tratta di modelli i cui pesi di addestramento vengono distribuiti pubblicamente, permettendo alle organizzazioni e agli sviluppatori di eseguire i modelli sulle proprie infrastrutture. Anche se non sono completamente “open source” nella sua purezza del termine, questi modelli offrono un livello di controllo e personalizzazione che non è possibile ottenere con un servizio esclusivamente cloud. Introduzione Dopo la pubblicazione di ChatGPT, il paradigma sembrava essere chiaro e destinato a consolidarsi dietro i soliti noti hyperscaler. L’elevato costo dell’addestramento e dell’inferenza rendeva impossibile (e lo è ancora oggi), per le aziende e i professionisti creare un proprio modello (fare apprendimento), oltre ad eseguire autonomamente modelli di grandi dimensioni sulle proprie infrastrutture. Questo scenario ha favorito un modello economico consolidato nel tempo: l’utente paga le richieste elaborate, mentre il provider investe in nuove infrastrutture e modelli per mantenere il servizio disponibile e costantemente aggiornato. In sintesi la logica cloud che tutti conosciamo bene. In pochi anni, il panorama ha iniziato a cambiare in modo radicale. La disponibilità di potenti GPU installabili su workstation, l’ottimizzazione delle tecniche di quantizzazione e l’introduzione di architetture più efficienti, hanno reso possibile eseguire modelli di elevata qualità localmente e, in alcuni casi, persino su computer domestici. Numerose aziende hanno iniziato a pubblicare modelli Open Weight, soprattutto Cinesi (ricorderemo lo tsunami di Deepseek ), favorendo la nascita di un ecosistema dinamico composto da sviluppatori indipendenti, startup, centri di ricerca e grandi imprese, le quali contribuiscono al miglioramento continuo di questi modelli attraverso le tecniche di fine tuning, ottimizzazione e specializzazione. Due filosofie, non due tecnologie concorrenti Uno degli errori frequenti consiste nel considerare le AI a token e le AI Open Weight come due tecnologie in competizione. La realtà è diversa in quanto rappresentano due differenti modelli di distribuzione e di utilizzo della stessa tecnologia. Entrambi gli approcci utilizzano architetture Transformer , ovvero enormi reti neurali che implementano il meccanismo dell’attenzione necessario per interpretare il linguaggio naturale. Quello che cambia realmente, è il modo in cui il modello viene reso disponibile agli utenti . Nelle AI a token, il controllo resta interamente nelle mani del fornitore dei servizi. Come la classica infrastruttura SaaS. Il produttore coincide con il service provider. Offre l’accesso tramite API a pagamento e ne gestisce sicurezza, aggiornamento e nuove funzionalità. L’utente beneficia della “ semplicità operativa “, ma accetta ( come in tutte le logiche cloud ) la dipendenza tecnologica ed economica dal service provider. Al contrario, nella logica Open Weight, il controllo viene trasferito all’utilizzatore . L’Azienda può decidere dove vuole eseguire il modello, come proteggerlo, quali dati può utilizzare per il fine tuning e quali politiche di sicurezza debbano essere adottate . Questa libertà comporta maggiori responsabilità nella gestione dell’infrastruttura, dell’hardware e della sicurezza, oltre che degli aggiornamenti. Un dibattito che coinvolge tecnologia, economia e sovranità digitale e geopolitica La scelta tra il modello AI a token o AI Open Weight, non ricopre solo aspetti tecnici. Entrano in gioco considerazioni economiche, normative e strategiche oltre che geopolitiche. Le organizzazioni che trattano dati sensibili, devono valutare con attenzione dove i loro prompt sono elaborati e quali garanzie offre il service provider in termini di riservatezza, conformità normativa e governance . Realtà con elevati volumi di utilizzo potrebbero trovare economicamente vantaggioso far girare modelli Open Weight, riducendo nel tempo il costo dell’inferenza, oltre ad essere responsabili delle politiche stesse di adozione. Startup e piccole imprese, al contrario, spesso preferiscono i modelli AI a token per evitare investimenti iniziali significativi in hardware di inferenza specializzato, oltre a personale qualificato. Ne deriva quindi, che non esiste una soluzione migliore dell’altra. Possiamo dire che la scelta dipende molto dagli obiettivi che le organizzazioni si sono date, dai requisiti di sicurezza che si vuole implementare, dal budget disponibile e dal livello di autonomia che si vuole ottenere. Un ecosistema destinato a evolversi L’attuale mercato AI (dopo il rilascio di Deepseek che ha segnato uno spartiacque), è caratterizzato da una convergenza tra questi due modelli di distribuzione. Questa evoluzione suggerisce che il futuro dell’AI non sarà dominato solo da un paradigma, ma ci sarà un ecosistema nel quale le AI a token, servizi cloud e modelli Open Weight saranno costretti a convivere. Questo permetterà massima flessibilità di azione alle aziende offrendo la possibilità di scegliere l’approccio più adatto alle proprie esigenze operative. Va da se che conoscere queste differenze permette meglio di valutare all’interno di un progetto costi, sicurezza, prestazioni e strategie di lungo termine, in un settore destinato a diventare una componente essenziale dell’infrastruttura digitale. Le AI a Token: il modello commerciale dominante Il modello di fruizione quando si parla di AI che oggi risulta più diffuso, è il modello AI a token . Sebbene questa espressione sia entrata nel linguaggio comune, il termine è fuorviante. Come abbiamo visto, non esiste una categoria di modelli chiamata “AI a token”. Si tratta di un modello commerciale di distribuzione attraverso il quale i fornitori di servizi AI mettono a disposizione i loro modelli proprietari, “noleggiando” le proprie API (o applicazioni cloud), fatturando l’uso in funzione dei token che vengono elaborati in ingresso e in uscita. Cosa sono i token Per comprendere con precisione, il funzionamento di questo modello di distribuzione a token , dobbiamo comprende cosa si intende per token. Un token rappresenta la più piccola unità di testo che viene elaborata da un Large Language Model . Un token non corrisponde necessariamente a una parola: può essere una parola intera, ma anche una parte di essa, oppure un numero, un simbolo di punteggiatura o persino uno spazio all’interno di una frase, a seconda dell’algoritmo di “tokenizzazione” che viene implementato ed utilizzato dal modello stesso. Facciamo un esempio con questa frase “Spiega in modo semplice cos’è l’intelligenza artificiale” Questa frase elaborata da un LLM, viene suddivisa in una sequenza di token che il modello converte in rappresentazioni numeriche ( embedding ), sulle quali esegue successivamente l’inferenza. Andando ad analizzare dal punto di vista economico questo approccio, ogni prompt che inviamo ad una AI, viene scomposto in token, il quale rappresenta anche l’unità di misura che viene usata per calcolare il costo del servizio e quindi il prezzo che le aziende devono sostenere per effettuare l’inferenza sul cloud. In quasi tutte le soluzioni commerciali, vengono conteggiati sia i token di input (ovvero quelli inviati dall’utente) sia i token di output (quelli generati dal modello durante l’inferenza). Questo metodo di distribuzione rende il consumo, direttamente proporzionale al lavoro computazionale che viene richiesto al service provider. Come funziona una AI a token Dal punto di vista tecnico, questa interazione avviene attraverso una web application che espone delle interfacce API e quindi attraverso un’infrastruttura remota gestita interamente dal provider. Il flusso può essere riassunto in queste fasi principali. L’utente invia una richiesta tramite un’interfaccia web o una API REST realizzata dal service provider. Il prompt viene trasmesso ai data center utilizzati dal fornitore, dove il modello viene eseguito su un cluster immenso di GPU ad alte prestazioni. Quando viene terminata l’inferenza, la risposta viene inviata al client dell’utente assieme ai metadati relativi al numero di token elaborati, che saranno poi contabilizzati e utilizzati per la fatturazione. Per l’utente il processo è istantaneo, ma dietro ogni risposta operano sistemi sofisticati di orchestrazione , bilanciamento del carico e di allocazione dinamica delle GPU, oltre che di ottimizzazione delle latenze. Tutto questo per l’utente è trasparente, paga per quello che usa. Il provider si occupa inoltre di tutte le attività di aggiornamento del modello, di correzione delle eventuali vulnerabilità, dell’introduzione di nuove funzionalità e garantire la disponibilità del servizio, attraverso l’uso di infrastrutture distribuite geograficamente, oltre che a rispondere alle normative locali. Perché il modello a consumo ha avuto così tanto successo L’affermazione delle AI a token è legata alla straordinaria complessità dei modelli linguistici. L’addestramento di un LLM di fascia alta, richiede migliaia di GPU le quali operano contemporaneamente per settimane o mesi, consumando delle enormi quantità di energia e richiedendo investimenti hardware che possono raggiungere centinaia di milioni di dollari. Anche la semplice inferenza, rappresenta un’operazione onerosa dal punto di vista computazionale. Ogni richiesta deve attraversare decine di livelli della rete neurale e generare un token, mantenendo in memoria tutto il contesto della conversazione. Centralizzare una potenza elaborativa di questo tipo all’interno di una azienda è complesso e costoso ed impossibile da raggiungere per la maggior parte delle organizzazioni. Le API: il cuore dell’ecosistema Il successo delle AI a token è dovuto alla sua semplicità con cui è possibile integrare le API all’interno delle applicazioni esistenti. Attraverso API REST o SDK ufficiali, i fornitori di AI consentono agli sviluppatori di incorporare modelli complessi e di frontiera multimodali all’interno dei propri prodotti. Questo approccio ha favorito la nascita di di tantissime nuove applicazioni che, pur offrendo servizi differenti, condividono lo stesso motore AI sottostante. Molte startup che dichiarano di utilizzare “Intelligenza Artificiale proprietaria” in realtà usano modelli forniti da terze parti, concentrandosi sullo sviluppo dell’applicazione e dell’esperienza utente piuttosto che sull’addestramento del modello. Vantaggi e Svantaggi delle AI a token Il principale punto di forza di questo paradigma è ovviamente la rapidità di adozione. Ma accanto ai benefici emergono aspetti che meritano attenzione. Il primo riguarda il vendor lock-in . Quando un’applicazione viene sviluppata attorno a delle API di un fornitore, ti stai legando a lui inevitabilmente e migrare verso una piattaforma differente, soprattutto se cambiano il formato delle richieste, i modelli disponibili o le politiche tariffarie. Un secondo elemento riguarda la gestione dei dati. Ogni prompt che viene inviato attraversa infrastrutture esterne all’organizzazione. Sebbene i principali provider implementino politiche di sicurezza e offrano opzioni per impedire l’utilizzo dei dati a fini di addestramento, alcune organizzazioni soggette a stringenti requisiti normativi o di riservatezza possono considerare questa architettura incompatibile con le proprie esigenze. Esiste una variabile economica spesso sottovalutata. Il modello pay-per-use risulta conveniente nelle fasi iniziali o per carichi di lavoro limitati. Quando il numero di richieste cresce in modo significativo, il costo dei token può superare quanto è necessario per mantenere un’infrastruttura dedicata. Questo vale soprattutto per aziende che elaborano milioni o miliardi di token ogni mese. Le AI Open Weight: libertà, controllo e personalizzazione Negli ultimi anni il panorama dell’Intelligenza Artificiale ha assistito alla crescita di un paradigma alternativo a quello delle AI accessibili tramite API: quello dei modelli Open Weight . La diffusione di modelli come Llama, Mistral, Gemma, Qwen e DeepSeek ha dimostrato che non è più necessario affidarsi esclusivamente ai grandi provider cloud per utilizzare modelli linguistici di qualità. Sempre più aziende, centri di ricerca e sviluppatori scelgono infatti di eseguire i modelli direttamente sulle proprie infrastrutture, mantenendo il pieno controllo dell’intero ciclo di vita dell’Intelligenza Artificiale. Questa evoluzione non rappresenta soltanto un cambiamento tecnologico, ma una diversa filosofia di utilizzo dell’AI: anziché acquistare un servizio, l’organizzazione acquisisce il modello e lo integra all’interno della propria infrastruttura, proprio come avviene con qualsiasi altro software enterprise. Cosa significa realmente “Open Weight” Uno degli equivoci più diffusi consiste nel considerare i termini Open Weight e Open Source come sinonimi. In realtà indicano concetti diversi. Un modello Open Weight mette a disposizione i pesi della rete neurale ( weights ), ossia i miliardi di parametri numerici che rappresentano il risultato del processo di addestramento . Sono questi valori che permettono al modello di comprendere il linguaggio naturale, riconoscere relazioni semantiche e generare nuove informazioni. Disporre di questi pesi, significa scaricare il modello ed eseguirlo localmente senza dover interrogare un servizio remoto. Ciò non implica, tuttavia, che venga reso disponibile anche tutto ciò che ha portato alla sua realizzazione. Nella maggior parte dei casi rimangono infatti proprietari: il codice utilizzato durante l’addestramento; i dataset di apprendimento; le procedure di pulizia dei dati; le tecniche di allineamento (alignment); gli algoritmi impiegati durante il reinforcement learning; documentazione interna utilizzata dagli sviluppatori. Per questo motivo si preferisce parlare di Open Weight piuttosto che di Open Source AI , evitando di attribuire ai modelli caratteristiche che spesso non possiedono. Esistono anche intelligenza artificiale Open source. Tra queste possiamo citare Olmo che è un intelligenza artificiale completamente Open source che vuol dire che tutta la filiera di apprendimento documentazione dataset, sono stati resi pubblici e modificabili. Dal cloud al controllo completo Alla fine possiamo dire che la principale differenza rispetto alle AI a token è rappresentata dal luogo in cui avviene l’inferenza. Con un modello Open Weight, il file contenente i pesi viene scaricato e installato all’interno dell’infrastruttura dell’organizzazione. L’inferenza può essere eseguita su: workstation professionali; server aziendali; cluster GPU; cloud privati; infrastrutture ibride; edge computing; dispositivi embedded e, per i modelli più piccoli, anche su notebook di fascia alta. Questo approccio, elimina la necessità di trasmettere ogni richiesta a un servizio esterno, consentendo all’organizzazione di mantenere il pieno controllo del flusso dei dati. Il ruolo dell’ecosistema Open Weight La crescita di questo paradigma è favorita dalla nascita di un ecosistema software ricco. Piattaforme dedicate permettono oggi di scaricare migliaia di modelli pronti all’uso . Parallelamente, strumenti per il deployment consentono la distribuzione dei modelli linguistici come normali servizi aziendali, integrandoli con API REST, sistemi Kubernetes, ambienti containerizzati e piattaforme di orchestrazione. In altre parole, il modello Open Weight diventa a tutti gli effetti un componente dell’infrastruttura IT, esattamente come un database, un application server o un motore di ricerca. La personalizzazione attraverso il Fine Tuning Uno degli aspetti che distingue maggiormente i modelli Open Weight dalle AI a token è la possibilità di intervenire direttamente sul comportamento del modello. Le organizzazioni possono infatti adattare un modello generico alle proprie esigenze mediante tecniche di Fine Tuning , che consentono di specializzare la rete neurale su domini specifici. Un’azienda sanitaria può addestrare il modello sul proprio lessico clinico. Uno studio legale può renderlo esperto nella consultazione della normativa. Un Security Operation Center può costruire un assistente capace di comprendere log, eventi SIEM, malware e report di threat intelligence con un livello di competenza superiore rispetto a un modello generalista. Negli ultimi anni si sono inoltre diffuse tecniche estremamente efficienti, come il LoRA (Low-Rank Adaptation) e il QLoRA , che permettono di personalizzare modelli con miliardi di parametri senza doverli riaddestrare integralmente. In molti casi è sufficiente modificare una piccola parte dei pesi originali, riducendo drasticamente il fabbisogno computazionale. Quantizzazione: modelli sempre più accessibili Un altro elemento che ha accelerato la diffusione degli Open Weight è rappresentato dalla quantizzazione . Durante questo processo i pesi del modello vengono convertiti da rappresentazioni numeriche ad alta precisione verso formati più compatti, riducendo sensibilmente il consumo di memoria e aumentando la velocità dell’inferenza. Grazie a tecniche moderne è oggi possibile eseguire modelli con decine di miliardi di parametri anche su workstation dotate di una singola GPU professionale o, in alcuni casi, su computer consumer con abbondante memoria RAM. Naturalmente la quantizzazione comporta un piccolo compromesso in termini di precisione, ma nella maggior parte degli scenari operativi tale perdita risulta praticamente impercettibile. I vantaggi delle AI Open Weight Come abbiamo avuto modo di vedere, il principale punto di forza di questo paradigma è rappresentato dal controllo . L’organizzazione decide dove installare il modello, come proteggerlo, quali aggiornamenti applicare e come gestire l’intera infrastruttura. Questo comporta numerosi benefici. Dal punto di vista della sicurezza, nessun prompt deve necessariamente lasciare il perimetro aziendale. Dal punto di vista economico, dopo l’investimento iniziale nell’hardware, il costo marginale dell’inferenza può diventare estremamente contenuto, soprattutto in presenza di elevati volumi di elaborazione. La disponibilità dei pesi permette di effettuare personalizzazioni profonde , sperimentare nuove tecniche di ottimizzazione e integrare il modello con pipeline proprietarie senza dipendere dalle decisioni commerciali di un fornitore esterno. Infine, viene eliminato il rischio di vendor lock-in : il modello può essere spostato da un’infrastruttura all’altra mantenendo il controllo completo della tecnologia. Le sfide dell’approccio Open Weight L’elevata libertà operativa comporta inevitabilmente maggiori responsabilità. Installare un modello Open Weight non significa semplicemente scaricare un file. È necessario predisporre l’hardware, configurare gli ambienti di esecuzione, monitorare le prestazioni, gestire gli aggiornamenti di sicurezza e ottimizzare continuamente l’infrastruttura. A ciò si aggiunge anche il costo iniziale delle GPU, che possono rappresentare una barriera soprattutto per le piccole organizzazioni. Anche la manutenzione richiede competenze specialistiche. Un modello non aggiornato può risultare meno efficiente rispetto alle versioni più recenti, mentre una configurazione errata può compromettere prestazioni, consumi energetici o affidabilità del servizio. Quando scegliere un modello Open Weight Le AI Open Weight rappresentano la scelta ideale per tutte quelle organizzazioni che considerano l’Intelligenza Artificiale una componente strategica della propria infrastruttura. Sono particolarmente adatte quando è necessario garantire la sovranità del dato, rispettare stringenti requisiti normativi, personalizzare il comportamento del modello o ottimizzare i costi di inferenza su grandi volumi di richieste. Non sostituiscono necessariamente le AI a token, ma ne costituiscono il complemento naturale. Alcune aziende adottano strategie ibride: utilizzano servizi cloud per attività generiche e modelli Open Weight per elaborare dati sensibili, automatizzare processi interni o sviluppare assistenti altamente specializzati. Confronto diretto: quale modello conviene? Dopo aver analizzato le caratteristiche delle AI a token e dei modelli Open Weight, emerge con chiarezza un aspetto fondamentale: non esiste una soluzione universalmente migliore . La scelta dipende dai tanti fattori in gioco, tra cui il volume di utilizzo, il livello di riservatezza dei dati, le competenze interne, i vincoli normativi e il budget disponibile. In altre parole, la domanda corretta non è quale tecnologia sia superiore, ma quale sia la più adatta al contesto operativo che l’organizzazione si è data? Costi: OPEX contro CAPEX Uno degli elementi più evidenti riguarda il modello economico. Le AI a token adottano un modello OPEX (Operational Expenditure) . L’organizzazione sostiene un costo operativo direttamente proporzionale al numero di richieste elaborate. Non esistono investimenti iniziali significativi: è sufficiente sottoscrivere un servizio e pagare in funzione dell’effettivo utilizzo. I modelli Open Weight seguono invece una logica CAPEX (Capital Expenditure) . L’investimento principale riguarda l’acquisto dell’hardware necessario all’inferenza: GPU professionali, server, sistemi di raffreddamento, storage ad alte prestazioni e infrastrutture di rete. Una volta ammortizzato questo investimento, tuttavia, il costo marginale di ogni richiesta tende a diminuire sensibilmente. Come abbiamo accennato in precedenza, per organizzazioni che elaborano milioni o miliardi di token al mese, il Total Cost of Ownership (TCO) può risultare inferiore rispetto al pagamento continuativo delle API commerciali. Prestazioni e qualità delle risposte Dal punto di vista qualitativo, il divario tra modelli proprietari e Open Weight si è ridotto in maniera significativa. I grandi provider continuano generalmente a mantenere un vantaggio nei modelli di frontiera, grazie a continui aggiornamenti, dataset proprietari e ingenti investimenti in ricerca. Tuttavia, gli ultimi modelli Open Weight come GLM 5.2 o Kimi K3 , di ultima generazione offrono prestazioni estremamente competitive in numerosi scenari e si avvicinano in modo “fastidioso”, ai grandi modelli di Operai e Anthropic In alcuni contesti verticali, un modello Open Weight opportunamente addestrato sui dati aziendali può addirittura superare un modello commerciale generalista, poiché possiede una conoscenza molto più approfondita del dominio applicativo. Privacy e sovranità del dato La gestione dei dati rappresenta probabilmente il principale elemento di distinzione tra i due paradigmi. Nel modello AI a token, i prompt e i documenti vengono trasmessi ai server del provider per essere elaborati. I principali operatori implementano rigorose misure di sicurezza, cifratura e conformità normativa, offrendo anche opzioni che impediscono l’utilizzo dei dati per l’addestramento dei modelli. Tuttavia, viste anche le normative vigenti statunitensi come il FISA section 702, per alcuni settori altamente regolamentati — come sanità, difesa, intelligence, pubblica amministrazione, finanza o infrastrutture critiche — il solo trasferimento dei dati verso un’infrastruttura esterna/estera può rappresentare un limite operativo o normativo. Con un modello Open Weight, invece, l’intero processo di inferenza può rimanere all’interno del perimetro aziendale. I dati non devono attraversare Internet e l’organizzazione mantiene il pieno controllo dell’infrastruttura, delle politiche di sicurezza e dei processi di conservazione delle informazioni. Personalizzazione La possibilità di personalizzare il comportamento del modello rappresenta uno dei principali punti di forza dell’approccio Open Weight. Le AI a token consentono generalmente alcune forme di adattamento attraverso prompt engineering, retrieval-augmented generation (RAG) o strumenti messi a disposizione dal provider. L’architettura del modello rimane però completamente sotto il controllo del produttore. Con i modelli Open Weight, invece, l’organizzazione può intervenire direttamente sulla rete neurale, effettuare fine tuning, sviluppare modelli specializzati, modificare pipeline di inferenza e integrare nuove tecniche di ottimizzazione. Questo livello di controllo rende l’approccio Open Weight particolarmente interessante per aziende che sviluppano prodotti innovativi basati sull’Intelligenza Artificiale. Scalabilità Dal punto di vista operativo, le AI a token offrono una scalabilità praticamente immediata. Se il numero di utenti raddoppia, nella maggior parte dei casi sarà sufficiente aumentare il budget destinato alle API. L’infrastruttura viene gestita automaticamente dal provider, che si occupa di distribuire il carico tra migliaia di GPU. Nel mondo Open Weight, la scalabilità dipende invece dalle risorse disponibili. Aumentare il numero di richieste può richiedere nuove GPU, ulteriore memoria, sistemi di bilanciamento del carico e competenze infrastrutturali avanzate. Per organizzazioni con team DevOps e competenze MLOps questo rappresenta un’attività ordinaria; per realtà più piccole può invece trasformarsi in una complessità significativa. Sicurezza Dal punto di vista della cybersecurity, nessuno dei due modelli può essere considerato intrinsecamente più sicuro. Cambiano piuttosto le responsabilità. Nel modello cloud, la sicurezza dell’infrastruttura ricade principalmente sul provider, che gestisce patch, aggiornamenti, protezione fisica dei data center e mitigazione degli attacchi. L’organizzazione cliente deve concentrarsi soprattutto sulla protezione delle credenziali API, sul controllo degli accessi e sulla gestione dei dati inviati al servizio. Nel paradigma Open Weight avviene l’esatto contrario. L’intera responsabilità ricade sull’organizzazione che ospita il modello. Occorre proteggere server, GPU, reti, sistemi operativi, framework AI e pipeline di inferenza, implementando monitoraggio continuo, gestione delle vulnerabilità e politiche di aggiornamento. Il vantaggio è un controllo completo dell’ambiente; lo svantaggio è l’aumento della superficie di gestione. Vendor lock-in Uno dei temi più discussi nel settore riguarda la dipendenza dal fornitore. Le AI a token espongono API proprietarie, modelli differenti e funzionalità spesso non perfettamente compatibili tra loro. Migrare da un provider a un altro può richiedere modifiche al software, aggiornamenti delle pipeline e talvolta una revisione completa dell’architettura applicativa. Con i modelli Open Weight il rischio di lock-in risulta generalmente inferiore. Una volta scaricati i pesi del modello, l’organizzazione può decidere autonomamente dove eseguirli, quali framework utilizzare e quale infrastruttura adottare, mantenendo un’elevata libertà tecnologica. Confronto sintetico I casi d’uso Per comprendere meglio quale approccio adottare, è utile osservare alcuni scenari concreti. Una startup che desidera sviluppare rapidamente un assistente virtuale probabilmente sceglierà un’AI a token. Potrà concentrarsi sullo sviluppo del prodotto senza investire immediatamente in hardware e competenze infrastrutturali. Una banca, una compagnia assicurativa o una pubblica amministrazione potrebbero invece preferire modelli Open Weight ospitati nei propri data center, così da mantenere il pieno controllo sui dati sensibili e rispettare i requisiti normativi. Nel settore della cybersecurity, entrambe le soluzioni trovano ampio impiego. Le AI a token risultano efficaci per automatizzare attività generiche, come la generazione di documentazione tecnica, l’analisi di codice o la produzione di report. I modelli Open Weight, invece, sono spesso preferiti nei Security Operation Center ( SOC ), dove l’elaborazione di log, indicatori di compromissione (IoC), informazioni di threat intelligence e dati investigativi richiede un elevato livello di riservatezza. La scelta è strategica, non ideologica Il confronto tra AI a token e AI Open Weight evidenzia come le due soluzioni rispondano a esigenze diverse.. Per questo motivo, sempre più organizzazioni stanno adottando un approccio ibrido, combinando entrambe le tecnologie in funzione del tipo di carico di lavoro. Le attività meno sensibili possono essere affidate a servizi cloud, mentre i processi critici vengono eseguiti su infrastrutture proprietarie. Il futuro dell’AI: convergenza o competizione? L’evoluzione dell’Intelligenza Artificiale non sta seguendo soltanto una traiettoria tecnologica o economica, ma sta assumendo sempre più i contorni di una questione geopolitica globale . La distinzione tra AI a token e modelli Open Weight, infatti, non è solo una scelta architetturale: riflette due visioni differenti del controllo dell’infrastruttura digitale che sta rapidamente diventando centrale per economie, difesa, intelligence e industria. Dalla tecnologia al potere: l’AI come infrastruttura strategica Negli ultimi anni i modelli linguistici sono passati dall’essere strumenti sperimentali a diventare infrastrutture critiche . Oggi vengono utilizzati per analisi finanziarie, automazione industriale, supporto decisionale, cybersecurity, sanità e pubblica amministrazione. Questo cambiamento ha reso evidente un fatto fondamentale: chi controlla i modelli di AI controlla anche una parte crescente del flusso informativo globale. Di conseguenza, governi e grandi potenze tecnologiche stanno iniziando a considerare l’Intelligenza Artificiale non più come un semplice settore industriale, ma come un asset strategico al pari di energia, semiconduttori e telecomunicazioni. Sovranità tecnologica e frammentazione del mercato Il concetto di sovranità tecnologica è diventato uno dei temi centrali del dibattito internazionale. In particolare, l’Unione Europea ha iniziato a promuovere un approccio che favorisca maggiore indipendenza dai grandi fornitori extraeuropei, incentivando lo sviluppo di infrastrutture AI locali, cloud sovrani e modelli open o open-weight utilizzabili in contesti regolamentati. Parallelamente, Stati Uniti e Cina stanno rafforzando strategie differenti ma convergenti nel risultato: centralizzare i modelli a pagamento e sviluppare soluzioni Open Weight anche di modelli di frontiera. In questo scenario si osserva una progressiva frammentazione dell’ecosistema globale dell’AI , dove accesso ai modelli, disponibilità dei pesi e capacità computazionale diventano elementi sempre più legati a dinamiche geopolitiche. Il caso Anthropic e il controllo dei modelli Il caso Claude Mythos ha rappresentato uno spartiacque nella percezione della sovranità tecnologica occidentale. Nel giugno 2026 l’amministrazione Trump ha imposto ad Anthropic la sospensione dell’accesso ai modelli Mythos 5 e Fable 5 attraverso un provvedimento basato sui controlli all’esportazione per motivi di sicurezza nazionale. La decisione ha dimostrato che, quando una tecnologia strategica è sotto la giurisdizione di uno Stato, quest’ultimo può limitarne o interromperne l’utilizzo anche a organizzazioni straniere, indipendentemente dagli accordi commerciali già in essere. L’episodio ha avuto un impatto che va ben oltre il singolo modello di intelligenza artificiale. Molti governi hanno preso coscienza del fatto che chi controlla l’infrastruttura, i servizi cloud o i modelli di frontiera possiede anche il potere di decidere chi possa continuare a utilizzare tali tecnologie in caso di tensioni geopolitiche o conflitti . In altre parole, chi “ ha in mano la spina ” può spegnere l’accesso a servizi digitali essenziali, trasformando la dipendenza tecnologica in uno strumento di pressione politica ed economica. Per l’Europa, il caso Mythos ha reso evidente una vulnerabilità già nota ma spesso sottovalutata: la dipendenza da fornitori extraeuropei di cloud, AI e infrastrutture digitali . La vicenda ha alimentato il dibattito sulla necessità di rafforzare la sovranità tecnologica europea, investendo in modelli di IA, data center e servizi cloud sviluppati e controllati all’interno dell’Unione e ovviamente ha accelerato l’utilizzo dei .odelli open weight in contesto di sicurezza particolarmente restrittivi. In sintesi, senza una filiera autonoma, qualsiasi crisi internazionale potrebbe tradursi in limitazioni operative per imprese, amministrazioni pubbliche e infrastrutture critiche europee. Il ritorno del controllo: perché le aziende vogliono “possedere” l’AI Man mano che l’AI diventa parte integrante dei processi produttivi, cresce l’esigenza delle organizzazioni di riappropriarsi del controllo tecnologico . Le ragioni sono molteplici: riduzione della dipendenza da fornitori esterni; necessità di garantire conformità normativa (GDPR, AI Act , regolamentazioni settoriali); protezione di dati sensibili e proprietà intellettuale; stabilità dei costi nel lungo periodo; resilienza operativa in scenari di crisi o interruzione dei servizi cloud. In questo contesto, i modelli Open Weight assumono un ruolo sempre più rilevante non solo come alternativa tecnica, ma come strumento di autonomia strategica . AI, chip e geopolitica: la nuova corsa alle infrastrutture Un ulteriore livello del problema riguarda l’hardware. La diffusione dell’AI ha reso le GPU e i chip specializzati (come le NPU e gli acceleratori tensoriali) risorse critiche, soggette a restrizioni commerciali e strategie di export control. Il controllo delle supply chain dei semiconduttori è diventato un elemento centrale nella competizione tra blocchi geopolitici, con impatti diretti sulla possibilità di addestrare e distribuire modelli avanzati. In questo scenario, anche la scelta tra AI a token e Open Weight assume una dimensione strategica: il modello a token centralizza il potere computazionale nei grandi data center; l’approccio Open Weight distribuisce parte del controllo verso organizzazioni e infrastrutture locali. Verso un ecosistema ibrido globale Nonostante la polarizzazione apparente tra cloud e modelli locali, il futuro sembra orientato verso una convergenza ibrida . Le aziende più avanzate stanno già adottando architetture miste, dove: i modelli cloud vengono utilizzati per compiti generali e ad alta complessità; i modelli Open Weight vengono impiegati per dati sensibili o processi specializzati; sistemi di orchestrazione decidono dinamicamente dove eseguire l’inferenza. Questa architettura distribuita rappresenta probabilmente il punto di equilibrio tra efficienza economica, sicurezza e controllo. Conclusione: il vero tema non è l’AI, ma il controllo dell’AI Guardando l’evoluzione complessiva del settore, emerge un elemento chiave: la distinzione tra AI a token e Open Weight è solo la superficie di una trasformazione molto più profonda. Il vero confronto non è tecnologico, ma riguarda chi controlla l’intelligenza artificiale, dove viene eseguita e con quali regole . In questo senso, l’AI sta diventando sempre meno un prodotto e sempre più una infrastruttura strategica globale, al centro di dinamiche economiche, politiche e geopolitiche che ricorderanno sempre più quelle delle grandi infrastrutture del Novecento come energia, telecomunicazioni e trasporti. La direzione è chiara: il futuro dell’AI non sarà definito da un unico modello dominante, ma da un equilibrio instabile tra accesso centralizzato e controllo distribuito, tra cloud globale e sovranità locale, tra efficienza e indipendenza. L'articolo Modelli a pagamento vs Open Weight: economia, potere e sovranità della nuova infrastruttura digitale proviene da Red Hot Cyber .
redhotcyber.comAug 25, 2026extracted
⚡ Weekly Recap: AI-Powered PLC Attacks, GitLab Attacks, Stripe Key Leaks and More
A package gets installed. A login prompt opens. A box sits exposed to the internet. Nothing looks unusual yet. That’s roughly the mood this week. Trusted tools turn hostile, old weak spots get fresh attention, AI makes exploit work cheaper, and researchers keep finding attacks that sound harder than they actually are. Plenty to clean up. Here’s the short version. ⚡ Threat of the Week U.S. Warns of AI-Powered Attacks on Siemens PLCs — Threat actors are using AI to write exploit scripts targeting internet-exposed Siemens S7 Series programmable logic controllers (PLCs) used across water, energy, manufacturing, and other critical infrastructure sectors, according to the U.S. government. The agencies warned: "This is not a theoretical risk—it is an active threat." The exploitation of poorly secured PLCs could result in disruption of critical industrial processes, safety incidents, downtime or equipment damage, compromise of sensitive data, and compliance violations, not to mention have cascading impacts across interconnected systems. Threat actors have been observed using legitimate scanning services, such as Censys and ZoomEye, to identify Internet-exposed or insufficiently segmented Siemens S7 Series PLCs. Once vulnerable systems have been identified, AI-generated scripts masquerading as legitimate monitoring tools are deployed to find exploits. For capability development, actors are testing and refining their exploitation techniques against specific PLC models to improve their ability to compromise the PLCs," the agencies said. "To prepare for operational effects, actors are leveraging read access to understand target environments, enabling preparation and positioning for future write operations to cause disruption or other operational impacts." It's currently not known who is behind the activity. Malware-Free Open Source Dependencies Stop reacting to supply chain attacks and start preventing them. Chainguard Libraries is a malware-free catalog of open source dependencies that allows your team to ship without inheriting someone else’s security compromise. Explore Chainguard Libraries ➝ 🔔 Top News GitLab Flaw Comes Under Attack — A newly disclosed security flaw in GitLab came under active exploitation within days of public disclosure, according to watchTowr. The vulnerability in question is CVE-2026-19478 (CVSS score: 9.4), a case of code injection that allows an unauthenticated attacker to modify or delete publicly accessible GitLab projects and rewrite their data under certain conditions without requiring credentials, user interaction, or obscure configuration. 14 Trojanized npm Packages Drop RedC2 4.0 Linux Backdoor — A set of 14 trojanized npm packages were found to masquerade as functional calendar and streak utilities but are engineered to stealthily deliver an artificial intelligence (AI)-powered Linux implant dubbed RedC2 4.0. RedC2 4.0, marketed on cybercrime forums as a cross-platform toolkit for Windows, macOS, and Linux, offers surveillance, credential theft, payload loading, and mass-operation capabilities. The version was advertised by a threat actor named "MarlboroMan" on Hack Forums in early June 2026, describing it as a command-and-control (C2 or C&C) framework "built for evasion." Zombie Card Attack Can Revive Expired Visa Cards for Contactless Payment Fraud — Academic researchers demonstrated a new Zombie Card attack that bypasses cryptographic checks to complete contactless payments using physically expired Visa credit cards. By taking advantage of a smartphone relay setup to alter the expiration date fed to the point-of-sale (PoS) terminal without breaking the card's cryptography, it's possible to make real in-store purchases. Raja Hasnain Anwar, the lead author, told The Hacker News that transactions succeeded at most of those banks when the team modified the Consumer Device Cardholder Verification Method (CDCVM) flag. There is no evidence the technique has been exploited in the wild. Suspected Russian Hackers Abuse Legitimate Authentication Workflows — Three distinct suspected Russian cyber espionage threat clusters, viz., UNC6293, UNC7005, and UNC5976, have been observed leveraging legitimate authentication flows to single out individuals working in academia, aerospace and defense, governments, and think tanks across Europe, as well as academia and think tanks within the U.S. "These clusters engage in persistent, adaptive phishing campaigns, using sophisticated social engineering tactics to compromise personal accounts across multiple platforms," Google said. UNC7005 has also been attributed to CaptiveCrunch, which targets captive Wi-Fi portals in locations such as hotels, conference centers, and airports in the U.S. and elsewhere to stealthily redirect users to attacker-controlled infrastructure to steal credentials. A new report from Lumen Black Lotus Labs has found that the threat actor likely compromised three Managed Service Providers (MSPs) to conduct the captive portal hijack via a supply chain attack. Cloudflare Workers Spectre Attack Leaks JWT — A remote Spectre attack against Cloudflare Workers has been found to leak a JSON Web Token (JWT) from a co-located Worker in the production environment at up to 12 bits per second, 360 times the rate of a previous attack demonstrated in 2021. "Cloudflare Workers is one of the top three edge-computing solutions and handles millions of HTTP requests per second worldwide across tens of thousands of websites every day," researchers said in a study. "We demonstrate a remote Spectre attack using amplification techniques in combination with a remote timing server, which is capable of leaking 120 bit/h." Cl0p Deploys Bespoke Web Shell in PTC Windchill Attacks — A JavaServer Pages (JSP) web shell deployed following the exploitation of a critical security flaw in PTC Windchill and FlexPLM servers is specifically designed for the enterprise Product Lifecycle Management (PLM) software. Per ReliaQuest, the web shell is a fully equipped extortion platform capable of mapping sensitive vault data, decrypting every credential in the Windchill keystore, and running additional code by means of a custom Java class loader. This is not the first time the Clop gang has deployed custom web shells. The e-crime group was previously observed dropping DEWMODE and LEMURLOOT after exploiting SQL injection flaws in Accellion (CVE-2021-27101) and MOVEit Transfer (CVE-2023-34362) file transfer software, respectively. As of August 12, 2026, the ransomware gang started releasing alleged victims' full names. Over 40 organizations are said to have been targeted by the prolific e-crime group. The development continues Cl0p's trend of targeting zero-days in popular SaaS platforms for mass exploitation and extortion. Security Flaw in Unisoc — Researchers disclosed a new unpatched flaw in Unisoc T612 modem firmware that, when combined with a previously disclosed remote code execution (RCE) vulnerability (also unpatched), could allow a threat to obtain elevated access to the Android kernel on affected devices. The exploit can be triggered by first delivering a malicious payload to the phone's modem via the RCE vulnerability and then placing a video call to the device, which the victim would need to answer. "A critical vulnerability has been identified in the Unisoc modem firmware that allows arbitrary code execution with kernel privileges from the modem context," SSD Secure Disclosure said. "By disabling protections on the first memory region (ID 0) of the Memory Protection Unit (MPU), an attacker can gain unrestricted read and write access to physical memory. This can ultimately lead to local privilege escalation, including the ability to modify kernel code." ️🔥 Trending CVEs Bugs drop weekly, and the gap between a patch and an exploit is shrinking fast. These are the heavy hitters for the week: high-severity, widely used, or already being poked at in the wild. Check the list, patch what you have, and hit the ones marked urgent first — CVE-2026-15748 (Forminator Forms), CVE-2026-15826 (User Profile Builder), CVE-2026-73570 (Zimbra), CVE-2026-32475 (Elementor Pro), CVE-2026-64849 (MLflow), CVE-2026-25895 (FUXA), CVE-2026-20030, CVE-2026-20357, CVE-2026-20358, CVE-2026-20359, CVE-2026-20231, CVE-2026-20315, CVE-2026-20317, CVE-2026-20318, CVE-2026-20319 (Cisco), CVE-2026-19478 (GitLab), CVE-2026-65346 (Apple), CVE-2026-19505, CVE-2026-19506, CVE-2026-19507, CVE-2026-19508, CVE-2026-19509 (RDK Central RDK-B WebUI), CVE-2026-75874, CVE-2026-74934, CVE-2026-74935, from CVE-2026-74936 through CVE-2026-74949 (Mozilla Firefox and Thunderbird), CVE-2026-76034, CVE-2026-76036, CVE-2026-76017 (Google Chrome), CVE-2026-14682, CVE-2026-12143 (Atlassian Bamboo Data Center), CVE-2026-76404, CVE-2026-76389, CVE-2026-76395, CVE-2026-76310, CVE-2026-76311, CVE-2026-76312 (Splunk), CVE-2026-69106, CVE-2026-65922 (JFrog Artifactory), CVE-2026-6837 (Zyxel), CVE-2026-18051 (W3 Total Cache), CVE-2026-63093 (Cursor), CVE-2026-40144, CVE-2026-40145 (BeyondTrust Endpoint Privilege Management for Windows), CVE-2026-57580 (Authentik), CVE-2026-63182 (PHP litesaml/lightsaml), CVE-2026-41473, CVE-2026-41472 (CyberPanel), CVE-2026-66794 (Multicluster Engine for Kubernetes), CVE-2026-69502, CVE-2026-69555, CVE-2026-65816, CVE-2026-65801, CVE-2026-65770, CVE-2026-69836, CVE-2026-24301 (Microsoft), CVE-2026-15580 (N-Able Passportal), CVE-2026-59270, CVE-2026-47836, CVE-2026-47841 (Spring Security UnboundID LDAP server), CVE-2026-75501 (Calix GS7 XGS GS5239XG router), CVE-2026-18963 (Keycloak), and GHSA-p9r8-2q67-fp86 (AMMOS Instrument ToolkiT-GUI). 🎥 Cybersecurity Webinars AI Coding Is Creating Remediation Debt. See What 300 Enterprise Leaders Found → AI coding is accelerating development, but it’s also pushing more unvetted open source into production and expanding the backlog security teams must manage. See what 300 enterprise security and engineering leaders revealed about the growing risk, and which governance approaches are actually helping teams regain control. AI Attacks Can Move in Minutes. Can Your Security Operations Keep Up? → AI is compressing vulnerability discovery, exploit development, and attack chaining into much shorter windows. Learn a practical AI threat-readiness framework for improving attack-surface visibility and accelerating investigation, validation, and remediation before machine-speed threats outpace existing security operations. 📰 Around the Cyber World Live Stripe keys for 659 merchants leaked — A dataset published on a data-trading forum on August 18, 2026, contains live Stripe API keys for 659 merchant accounts, along with roughly 35 GB of customer and payment data pulled from them. "A Stripe secret key is not a password to a dashboard," Ransomnews said. "It is full programmatic access to the account. Anyone holding one can read every customer record, create charges, issue refunds, and change where payouts are sent. The 519 accounts in that bottom row could, on the collector’s own record, both take money in and move it out." CISA Releases Guidance for Improving Operational Standards — The U.S. Cybersecurity and Infrastructure Security Agency (CISA) published the Logging Reference Architecture for federal agencies to establish logging, visibility, and operational standards in an Agency Logging Plan. The guidance implements a practical, risk-based, prioritized logging approach that improves agency network monitoring. "Cyber defense begins with insight. Robust logs provide the critical visibility needed to counter daily threats targeting federal systems. CISA is enhancing agency logging strategies to ensure security teams can rapidly detect and respond to cyber incidents," said CISA Acting Executive Assistant Director for Cybersecurity Chris Butera. "The Logging Reference Architecture guides agencies away from fragmented practices, establishing a mature enterprise capability that maximizes the operational value of their data." U.S. Court Partially Overturns Ex-Google Engineer's Conviction — Linwei Ding, a former Google software engineer who was convicted earlier this year for allegedly stealing thousands of the company's confidential documents to build a startup in China, had part of the ruling overturned by a U.S. federal judge last week. According to Reuters, U.S. District Court Judge Vince Chhabria in San Francisco ruled there was not enough evidence that the defendant intended or knew his conduct would benefit the government of China. Ding is scheduled to be sentenced on September 1, 2026. How Threat Actors Abuse ScreenConnect — Threat actors are using various methods, ranging from phishing lures and SEO-poisoned balenaEtcher downloads to malvertising redirects and an already-resident SimpleHelp agent, to deploy ScreenConnect via PowerShell and msiexec. "In the one case that reached full hands-on control, the operator rotated domains, deployed multiple ScreenConnect instances disguised as Microsoft services, layered persistence across services, SafeBoot, and credential providers, and ran scripts to evict rival RMM tools before forcing a reboot," Trend Micro said. DCRat in 2026 — Judicial‑themed phishing lures are being used to propagate DCRat, per Trellix. "Every stage of the attack required human interaction, from opening the phishing email to extracting the archive to executing the malicious components alongside trusted libraries by using DLL sideloading," the cybersecurity company said. "In its final stage, the malware employed process hollowing to inject malicious code into a trusted system process, effectively evading detection. The end payload was DCRat, granting attackers full remote access and control. This campaign is particularly notable for a legitimate, signed utility to bypass traditional security perimeters." Using Apple's Find My to Track Live Location — A security researcher who goes by the name Zerotistic has devised a way to enroll a Linux-based machine into Apple's Find My network and read live location data from it for those who have opted to share their locations with the Apple account owner. WebAudio Fingerprinting on Alibaba — Developer Matt Callaghan has accused Alibaba's AliExpress of trying to track web users by playing sounds through browsers vulnerable to audio fingerprinting. The software engineer discovered the issue late last week after investigating why his Bluetooth headphones stopped playing music whenever he visited the AliExpress website. "Shortly after loading the AliExpress homepage, audio from my phone would stop playing," Callaghan said. "Closing the AliExpress tab fixes it immediately. Muting the tab/Firefox/Windows does not help, and there is no visible video, music, or other media playing on the page." Firefox issued a statement on X saying its anti-fingerprinting technology blocks Alibaba's tracking technique. Tom Ritter, who leads security efforts for Mozilla Firefox, said: "We made the WebAudio constant in Firefox 118 three years ago as part of our initial round of Fingerprinting Protection features. This eliminated most of the differences." Anthropic Expands Claude Mythos 5 Access — Anthropic said it's working with cybersecurity technology and services partners to integrate Claude Mythos 5 into their products and services to secure their software. "Customers on Claude Enterprise plans can now run our most capable model in Claude Security, using it to scan their codebases for security vulnerabilities and suggest patches," it said. "Our new Defender Advantage Fund (0xDAF) will provide $35 million in credits to organizations working to patch vulnerabilities in open-source projects, automate parts of the process of scanning and patching open-source software, and experiment with new security approaches." Agentic Source Code Review — Google said it uses what's called the Agentic Vulnerability Discovery Harness (AVDH) to "rapidly analyze code and find exploit paths during proactive reviews, penetration tests, red team operations, and incident response engagements." The development comes amid increasing adversarial misuse of AI. The tech giant said its use of AVDH over the past 10 months has led to the discovery of over 100 true-positive critical vulnerabilities, including critical flaws in Drupal (CVE-2026-13242 and CVE-2026-55803). The system outlined by Google is very similar to Microsoft's MDASH. 768 Leaked Corporate AWS Keys Hold Full Admin Rights — Truffle Security's scan has verified 64,024 unique AWS key pairs across 431,875 public findings, including git history, Hugging Face datasets, Docker images, package registries, CI logs. These keys surfaced publicly between August 2022 and August 2026. Of these pairs, 10,616 came with complete credentials. According to Truffle Security: ""88% still authenticate. 768 of the live ones belong to a company and carry full control of its AWS account: 526 root keys plus 242 IAM users holding AdministratorAccess. The median live leaked key is five years old and has never been rotated." Conclusion This week’s useful reminder: attackers rarely need everything to fail. One exposed service, one trusted shortcut, or one overlooked dependency can be enough to get started. So the better question is not “what’s the next big threat?” It’s “what are we still assuming is safe?” That usually finds the problem sooner.
thehackernews.comAug 24, 2026extracted
GitLab 19.3 helps enterprises scale agentic development securely
GitLab 19.3 helps enterprises scale agentic development securely GitLab has announced updates that give enterprises more control as they scale agentic software development. GitLab Dedicated customers, who already run their most sensitive software delivery workloads on GitLab, can now run GitLab Duo Agent Platform inside that same single tenant environment and region, connect their own models for inference, and keep AI-processed data inside their existing security boundary. GitLab 19.3 also ships today with support for Secrets Manager, Flow Creator Agent, and Bulk SAST False Positive Detection and Agentic SAST Vulnerability Resolution. Every secret, whether it’s used inside a pipeline or by the infrastructure outside the pipeline, now runs under the same permission model. Additionally, developers who own a process can now create custom agentic flows across the software development lifecycle, and security teams can ship ready-to-merge fixes against their backlog at scale. Together, these updates give engineering teams, process owners, and security teams the speed of agentic AI, without giving up the control they already have in place. “These updates extend the speed and control enterprises need deeper into the regulated and data-sensitive segment of the enterprise market,” said Manav Khurana, chief product and marketing officer at GitLab. “Every capability we shipped this month, from where an agent runs to which secret it can touch, extends that same control into the trusted software delivery workflows enterprises already depend on.” Dedicated AI Gateway keeps agentic AI inside trusted boundaries The AI Gateway for GitLab Duo Agent Platform now runs inside GitLab Dedicated single-tenant SaaS infrastructure, enabling agentic workloads to follow the same residency and isolation model as the rest of the software development lifecycle within GitLab. Regulated and residency-sensitive teams can unlock the use of agentic AI for software delivery under the same deployment model their auditors already understand. Secrets Manager extends control beyond the pipeline GitLab Secrets Manager is now in limited availability as a paid add-on billed through GitLab Credits for GitLab.com customers. Every CI secret is scoped to the environment, branch, and protection status of the job that needs it. Secrets Manager also now supports Kubernetes, Terraform, OpenTofu, and custom tools. Credentials live in the same platform that runs code and pipelines, so teams do not maintain a separate permission model. Bulk SAST remediation Helps remove years of accumulated risk in a single action SAST False Positive Detection and Agentic SAST Vulnerability Resolution enable teams to clear an entire vulnerability backlog instead of one finding at a time. Teams select multiple findings in the Vulnerability Report, and GitLab returns a confidence score for each. Confirmed risks get a ready-to-merge fix, so a developer reviews and merges instead of writing the fix from scratch. This covers every SAST vulnerability in the Vulnerability Report, and GitLab continues to triage and remediate new critical and high severity findings automatically as they arrive. Flow Creator Agent removes the schema barrier to custom automation Flow Creator Agent removes the need for manual schema mapping that keeps process owners from automating their work. With Flow Creator, available through Agentic Chat as a foundational agent in GitLab Duo Agent Platform, a user describes the automation in plain language and gets back a complete, runnable flow, ready to register from the AI Catalog. Every flow still runs under a scoped service account with composite identity, requiring the Maintainer role or higher to enable it. Additional capabilities shipped in GitLab 19.3 GitLab Credits usage caps are now generally available, allowing organizations to set a monthly ceiling on agentic AI spend before it becomes an overage. Administrators can set a subscription level cap in the Customers Portal, along with options for a default per user cap or per user overrides through the GraphQL API. Restricted visibility for custom agents and flows per GitLab group is now generally available, making them accessible to members across multiple projects within that group. This is in addition to per-project and public visibility options that have already been available.
helpnetsecurity.comAug 21, 2026extracted
Issue with containerd CRI Plugin - CVE-2026-50195, CVE-2026-53488, CVE-2026-53492, CVE-2026-53489, CVE-2026-47262
Issue with containerd CRI Plugin - CVE-2026-50195, CVE-2026-53488, CVE-2026-53492, CVE-2026-53489, CVE-2026-47262 Bulletin ID: 2026-046-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 06/18/2026 17:30 PM PDT Last Updated Date: 6/22/2026 15:00 PM PDT Description: containerd is an open-source container runtime used by Kubernetes via the Container Runtime Interface (CRI) plugin. It underpins AWS managed container services including Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), AWS Fargate, Bottlerocket, and Amazon Linux. AWS identified five issues in the containerd CRI plugin affecting versions 1.7 through 2.3 CVE-2026-50195 (CVSS 8.8): Unvalidated checkpoint image references in the CRI plugin allow image cache poisoning on shared Kubernetes nodes, enabling cross-pod code execution. CVE-2026-53488 (CVSS 8.3): Image configuration LABEL instructions are propagated to containers without sanitization, enabling arbitrary host command execution via a crafted container image. This issue does not require checkpoint/restore to be enabled. CVE-2026-53492 (CVSS 6.8): CDI (Container Device Interface) annotations from untrusted checkpoint image metadata are trusted without validation, allowing device and host mount injection that bypasses Kubernetes device enforcement. This issue requires CDI to be enabled on the node. CVE-2026-53489 (CVSS 6.5): Symlinked container log paths are not validated during checkpoint restore, enabling arbitrary host file read. This issue requires checkpoint/restore to be enabled. CVE-2026-47262 (CVSS 6.5): A crafted container image can cause uncontrolled memory consumption, resulting in an out-of-memory termination of the containerd process and a denial of service for all containers on the affected node. Impacted versions: containerd 1.7, 2.0, 2.1, 2.2, 2.3 Resolution: These issues have been addressed in the upstream containerd project. Patched releases are available at the containerd GitHub security advisories page. We recommend upgrading to the latest patched version and ensuring any forked or derivative code is updated to incorporate the new fixes. For customers using AWS managed container services (Amazon EKS, Amazon ECS, AWS Fargate), AWS is deploying patched runtimes across affected fleets. Customers using self-managed containerd deployments on Amazon EC2 or on-premises infrastructure should upgrade to a patched container version as soon as possible. Workarounds: CVE-2026-47262: Users can mitigate this issue by only allowing trusted images to be pulled and only allowing trusted users to import images and schedule pods. CVE-2026-50195 and CVE-2026-53488: Users can mitigate this issue by only allowing trusted images to be pulled. CVE-2026-53489: Users can mitigate this issue by only allowing trusted images to be pulled and only restoring from trusted checkpoints. CVE-2026-53492: Users can mitigate this issue by only allowing the restoration of containers from trusted checkpoint images. Additionally, on nodes where Container Device Interface (CDI) capabilities are not used, removing or temporarily relocating host CDI specifications from the default directories (/etc/cdi and /var/run/cdi) makes this issue unreachable. References: Acknowledgement: We would like to thank the containerd project for collaborating on these issues through the coordinated vulnerability disclosure process. Please email [email protected] with any security questions or concerns.
aws.amazon.comAug 20, 2026extracted
CVE-2026-15738 - Issue with AWS Load Balancer Controller Cross-Namespace Traffic Interception via HTTPRoute/GRPCRoute Priority Ordering
CVE-2026-15738 - Issue with AWS Load Balancer Controller Cross-Namespace Traffic Interception via HTTPRoute/GRPCRoute Priority Ordering Bulletin ID: 2026-055-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 07/14/2026 13:15 PM PDT Description: The AWS Load Balancer Controller is an open-source Kubernetes controller that manages AWS Elastic Load Balancing resources for Kubernetes clusters. We identified CVE-2026-15738, an incorrect rule precedence ordering issue in the Gateway API listener rule generation logic. When both an HTTPRoute and a GRPCRoute are attached to the same Application Load Balancer (ALB) HTTPS listener with the same hostname, the controller assigns ALB listener rule priorities based on route kind rather than route specificity. This causes all HTTPRoute-derived rules to receive lower ALB priority numbers, evaluated first by the ALB, than GRPCRoute-derived rules, regardless of which route is more specific. A namespace-scoped user with permission to create HTTPRoute objects in a namespace admitted by a shared Gateway can create a catch-all HTTPRoute that intercepts traffic intended for a more-specific GRPCRoute in another namespace. Impacted versions: AWS Load Balancer Controller v3.4.1 and any version that includes support for attaching both HTTPRoute and GRPCRoute to the same listener (introduced in PR #4794) Resolution: This issue has been addressed in AWS Load Balancer Controller version 3.4.2. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. Workarounds: Restrict the Gateway listener AllowedRoutes.Namespaces.From field to Same, or configure a restrictive namespace Selector that limits which namespaces may attach routes to the shared Gateway. This prevents untrusted namespaces from attaching HTTPRoute objects that could interfere with GRPCRoute rules in other namespaces. References: Acknowledgement: We would like to thank hakuopi for collaborating on this issue through the coordinated vulnerability disclosure process. Please email [email protected] with any security questions or concerns.
aws.amazon.comAug 20, 2026extracted
Identity Abuse Through Trusted Communication Channels
Identity has become a primary security boundary for most organizations, reducing the ability to solely trust other boundaries once associated with corporate networks. Users authenticate to cloud services using enterprise identities that provide access to collaboration platforms, business applications and sensitive data. With the adoption of software-as-a-service (SaaS) on the rise, people are shifting to platforms for communication and collaboration. Threat actors have adapted to this shift. In addition to typical email-based phishing, attackers increasingly misuse trusted collaboration platforms to conduct identity phishing, impersonation, credential theft, malware delivery and social engineering. Over the last 12 months, our endpoint alerts of malicious activity associated with collaboration tools have more than quadrupled, as Figure 1 shows. This activity could involve compromised accounts, external federated organizations, guest accounts or trusted third-party relationships. In each case, the attackers seek to exploit the trust that people place in enterprise communication platforms. This changes the role that collaboration platforms play within enterprise security. They are not just productivity applications, they have become part of the enterprise attack surface. Unit 42 researchers found that 99% of the alerts generated related to chat phishing operations, indicating that attackers often gain access to these environments through targeted phishing operations. After a successful compromise, attackers can then communicate using the identity and privileges of the compromised user. This allows malicious activity to appear as normal collaboration activity. Security controls typically remain focused on email and authentication events, often providing limited visibility into activity occurring within authenticated collaboration sessions. We examine how threat actors leverage trusted communication channels and review identity abuse techniques. We also provide practical recommendations for detecting and defending against identity-focused attacks targeting enterprise collaboration platforms. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Enterprise collaboration platforms have become integral to business operations. Employees use these platforms to exchange messages, share files, coordinate projects and communicate with colleagues, customers and business partners. Organizations typically connect collaboration platform access to their identity provider, and people rely on these platforms for trusted, authenticated communication. Unlike email, collaboration platforms enable real-time conversations and support features such as external federation, guest access, shared workspaces and third-party integrations. These capabilities improve productivity but also create opportunities for misuse. Attackers can exploit compromised accounts, trusted business relationships or authorized external access to interact with victims through legitimate communication channels. Figure 2 shows common pathways for attackers to compromise identities in enterprise and cloud environments. When a collaboration account is compromised, attackers inherit the identity context of that user, including their permissions, relationships and ongoing conversations. Requests that might appear suspicious in an email can appear routine when delivered through an authenticated collaboration platform. This reduces a target’s suspicion and increases the effectiveness of identity phishing, impersonation, credential theft and social engineering. As organizations adopt more SaaS collaboration platforms, they should treat these environments as part of the identity attack surface. Protecting them requires both strong authentication, and visibility into how trusted identities and communication channels are used after authentication. Recent campaigns demonstrate that attackers use collaboration platforms in multiple stages of identity-focused attacks, from initial access to post-compromise operations. Table 1 summarizes these intrusion stages. Table 1. Collaboration platform misuse by MITRE ATT&CK intrusion technique. One of the most common techniques is identity phishing through enterprise collaboration platforms. In our Insights article, "When 'Hi, This Is IT' Comes Through Microsoft Teams", we discussed how APT29 used compromised Teams accounts to send links to credential-harvesting pages. We reported that attackers misuse external federation in Teams to initiate conversations with victims while impersonating IT support or other trusted personnel. These campaigns often begin with a request to chat, followed by instructions to visit a phishing site, approve a multifactor authentication (MFA) request, install remote access software or provide credentials. Okta Threat Intelligence has also documented the technique of identity phishing through attacker-controlled Slack workspaces. The threat actor behind this activity impersonated administrators and employees from targeted organizations and sent phishing links through direct messages, channel mentions and legitimate notifications. The links redirected victims to adversary-in-the-middle phishing proxies designed to capture corporate credentials and MFA tokens. Security teams might not detect the initial collaboration message directly. They could instead see the actions that follow. An example of this is shown in a process tree from a malicious chat scenario in Figure 3. In this case, the threat actor sent a RAR file to a victim in a Teams chat. The victim accepted the file transfer and downloaded the file to their Downloads folder. The victim then opened an Explorer window and double-clicked [REDACTED].rar, launching WinRAR.exe to open the archive. WinRAR extracted the malicious lpk.dll, which the victim’s endpoint security agent detected. The extracted lpk.dll is a known, older malicious DLL that masquerades as a legitimate Windows language pack DLL. Attackers use the file for DLL sideloading attacks. This recent event demonstrates that attackers continue to use older malware families in attacks delivered through collaboration platforms. Unlike commonly-seen email phishing, some collaboration platforms support interactive communication. This enables attackers to respond to targets and adjust their social engineering tactics in real time. If successful, the attacker obtains a valid enterprise identity. The attacker can then access enterprise and cloud services with the privileges and identity context of the compromised user. Attackers use impersonation to exploit trust in collaboration platforms and gain access to enterprise identities, posing as known individuals, trusted organizations or support personnel. In January 2026, Fireblocks disclosed a recruitment-themed social engineering campaign in which attackers impersonated Fireblocks executives, recruiters and hiring managers to target technology workers. The attackers initially contacted targets through social media, provided professionally prepared recruiting materials and then scheduled interviews through Google Meet. During the video interviews, an individual presented as a Fireblocks HR manager discussed the candidate’s experience, compensation and other expected hiring topics before assigning a code review task for a fictitious Fireblocks project. Candidates were instructed to clone a GitHub repository and run standard setup commands, including npm install, which executed malicious code and downloaded malware onto their systems. The campaign used legitimate Google Meet communications and a convincing interview process to reinforce the Fireblocks impersonation and persuade victims to execute malicious code. Fireblocks assessed the activity as closely aligned with the North Korea-linked Contagious Interview campaign pattern. In March 2026, a threat actor used a staged Slack workspace as part of a targeted social engineering campaign against the lead maintainer of the Axios npm package. The threat actor impersonated a legitimate company and created a convincing Slack environment with company branding, channels, users and message history. The interaction later moved to a staged Teams meeting, where the maintainer was convinced to install software that delivered a remote access Trojan. The threat actor then gained access to the maintainer’s npm account and published two poisoned Axios versions, causing projects that installed the affected releases to retrieve and execute a malicious dependency. In April 2026, OpenSSF reported a campaign targeting members of the Linux Foundation TODO Group Slack workspace and related communities. The threat actor impersonated a known Linux Foundation community leader and contacted targets through Slack direct messages. The messages contained a Google Sites link that led to a fraudulent Google Workspace authentication process. The site requested the target’s email address and verification code. It then instructed the target to install a malicious root certificate. On macOS, the process also downloaded and executed a binary that could provide system access. The campaign used the identity of a recognized community member and an established Slack workspace to support credential collection and malware delivery. Each of these campaigns used impersonation through trusted collaboration workflows. The attackers relied on recognized identities, legitimate services and familiar business processes to obtain credentials or persuade victims to take actions that enabled identity compromise. In a more novel approach, attackers have misused trusted collaboration services to maintain their access after identity compromise. In a December 2025 intrusion investigated by CERT Polska, a threat actor modified compromised firewall-VPN appliances at a manufacturing company in Poland. The threat actor used the appliances’ built-in scripting mechanism to create weekly scheduled tasks. One script retrieved the password of a privileged identity, and another script modified security settings and disabled two-factor authentication for a privileged account. A third script used the appliances’ native Slack notification capability to send the results to a Slack channel under the threat actor’s control. This activity combined identity persistence and credential exfiltration with a legitimate SaaS integration. It also avoided the need for a separate exfiltration tool. The case demonstrates how attackers can misuse built-in appliance features and trusted collaboration services during post-compromise operations. The firewall event in Figure 4 shows an example of a Slack webhook request, a similar communication method to the one described in the CERT Polska report. The request used HTTP POST to hooks.slack[.]com with a curl user agent. The example event below is not malicious. Perimeter firewalls provide valuable visibility into webhook-related traffic exiting the organization. Many network and security appliances, including VPN appliances, operate behind a separate perimeter firewall and send outbound webhook requests through the enterprise egress path when configured for external alerting or automation. Security teams should review unexpected Slack webhook traffic, uncommon user agents and webhook activity from systems without an approved Slack integration. This type of activity should also be flagged in Microsoft Teams, which supports similar incoming webhook workflows for posting messages from external services. These examples of initial access, impersonation and persistence demonstrate how attackers leverage trusted communication channels to support identity-focused attacks. Although the techniques differ, each example leverages legitimate platforms, authenticated identities or authorized communication paths to increase the likelihood of success. The common objective is to misuse the trust, access and identity context associated with enterprise collaboration platforms. Organizations should protect collaboration platforms with the same level of scrutiny applied to email and identity infrastructure. Because these platforms are integrated with enterprise identities, security controls should focus on both preventing identity compromise and detecting misuse after authentication. The first priority is reducing unnecessary exposure. Collaboration platform administrators should review external federation, guest access and third-party integrations to ensure they support legitimate business requirements. Where possible, limit external communications to trusted organizations, and implement a process to review guest accounts regularly and remove unnecessary access. Identity protections should also extend beyond authentication. MFA, conditional access and session risk evaluation help reduce the likelihood of account compromise, but they do not prevent an attacker from misusing a valid session. Security teams should monitor for behavior that could indicate identity compromise, including unusual messaging activity, unexpected file sharing or communications with unfamiliar external tenants. Identity and security teams should define and communicate verification procedures for security-sensitive requests received through collaboration platforms. Users should not approve MFA prompts, install remote access tools, share credentials, transfer files or modify access based only on a message. Instruct people to verify high-risk requests through an approved secondary channel, such as a known phone number, ticketing system or documented internal process. User awareness remains an important part of effective verification procedures. People should treat collaboration messages, platform notifications and links to hosted content with the same caution as email. This is especially important when a request involves credentials, MFA approval, software installation, remote access tools or sensitive data. Security training should make clear that content associated with an enterprise collaboration platform is not automatically trustworthy. An attacker can send a direct message, trigger a legitimate platform notification or use content hosted on an approved service to direct victims to a phishing site. Security awareness teams should include these scenarios in phishing simulations and security awareness exercises. Many people recognize email phishing indicators but might not apply the same scrutiny to collaboration platforms and related notification workflows. Security teams should incorporate collaboration platform telemetry into routine monitoring and incident response. Authentication logs, messaging activity, file sharing events and external tenant interactions provide valuable context for detecting identity abuse. Network and security appliances should also be included in monitoring coverage. Firewalls, VPN appliances, load balancers and managed switches increasingly support automation, notification integrations and scheduled tasks. Attackers can potentially use these capabilities for malicious purposes following a compromise. To protect against such activity, security teams should monitor: Administrative activity Configuration changes Outbound webhook usage Unusual connections to collaboration or SaaS services This telemetry should be ingested into a security information and event management (SIEM) system and correlated with identity, endpoint and collaboration platform data. This can improve visibility into malicious activity that might otherwise appear to originate from legitimate users or approved infrastructure. Collaboration-based reporting must also be easy for users. Security teams should provide a clear process for reporting suspicious communications, notifications, hosted content and links associated with collaboration platforms. Each report should be triaged using identity telemetry, sign-in activity, endpoint alerts, file-sharing events and external tenant information. This helps to determine whether the activity reflects user error, external misuse or identity compromise. Enterprise collaboration platforms are integrated with enterprise identity and access workflows. As organizations rely on these platforms for communication, attackers are exploiting the trust associated with authenticated users and sanctioned communication channels to conduct identity phishing, impersonation, credential theft and post-compromise operations. Common security strategies have focused on protecting email and authentication systems. While these controls remain essential, they should be complemented by security measures that address collaboration platforms as part of the enterprise identity attack surface. Authentication alone is no longer sufficient to establish trust. Organizations must also understand how authenticated identities are communicating and recognize when trusted communication channels are being misused. By extending identity security to include collaboration platforms, defenders can better detect identity abuse, reduce opportunities for compromise and strengthen their ability to respond to identity-focused attacks. As collaboration technologies evolve, organizations should monitor and protect them with the same controls they apply to other critical identity infrastructure. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. Idira Endpoint Privilege Manager (EPM) can enable enterprises to reduce risk, satisfy compliance, and streamline operations. It can help implement least privilege via policy-driven elevation and removal of standing admin rights, and block risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence. Idira Secrets Manager centralizes the API keys, service account passwords, and webhook tokens that appliances, scheduled tasks, and pipelines depend on, so automation retrieves credentials at runtime instead of reading them from local scripts or device configuration. Automated rotation shortens the window in which a stolen credential stays valid, and universal workload identity replaces static credentials with short-lived SPIFFE-based workload identities where the environment supports it. Idira Privileged Access Management (PAM) helps unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets. Idira Secure Infrastructure Access (SIA) can help enforce Zero Standing Privileges (ZSP) through Just-in-Time (JIT) provisioning which grants temporary, tightly scoped access only as needed. Backed by continuous session recording and real-time command monitoring, SIA can detect high risk actions before an attacker compromises critical systems. Idira Secure Cloud Access (SCA) can help enforce Zero Standing Privileges (ZSP) across multicloud environments by applying Just-in-Time (JIT) access controls to cloud consoles, command-line interfaces (CLIs), and the modern cloud infrastructure where workloads reside, including Managed Kubernetes clusters and elastic cloud workloads. 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. Energy Sector Incident Report - 29 December 2025 – CERT Polska Slack Abused for Phishing Redirection – Okta Potential Malicious Campaign Underway Targeting Open Source Developers via Slack – OpenSSF A New Phishing Frontier: From Email to SaaS Collaboration Apps – Palo Alto Networks Threat Brief: Widespread Impact of the Axios Supply Chain Attack – Palo Alto Networks When “Hi, This Is IT” Comes Through Microsoft Teams – Palo Alto Networks Axios Maintainer Confirms Social Engineering Attack Behind npm Compromise – Socket Disrupting a Recruiting Impersonation Scam: Anatomy of Operation Contagious Interview – Fireblocks The query below is designed to help Palo Alto Networks customers hunt for, investigate and identify potentially suspicious activity using Cortex XDR. Results returned by this query should not be considered inherently malicious and require further analysis to determine their significance. This XQL query can help to identify where legitimate collaboration platforms — specifically Slack or Teams in this example — are used to execute system shells. The query inspects both the direct process hierarchy and the broader causality chain. It identifies instances where a collaboration tool is either the immediate parent process or an ancestor process that initiated the execution of a shell. Analysts can use this logic to identify: Post-exploitation activity Unauthorized command execution Living-off-the-land techniques that originate from compromised user accounts or application integrations The query can be modified to search for additional collaboration platforms or system shells.
unit42.paloaltonetworks.comAug 20, 2026extracted
Microsoft Links 30+ Rotating Domains to MacSync Stealer Infrastructure
Microsoft Defender Experts have linked more than 30 web domains to MacSync Stealer, a macOS-focused information stealer, after correlating recurring endpoint and network behaviors across changing infrastructure, tracing the malware from payload retrieval through data collection, staging, and exfiltration. The tech giant said it required multiple endpoint and network behaviors to align before treating a domain as connected, including process ancestry, command-line patterns, request paths, headers, and upload parameters. Microsoft did not disclose a victim count or attribute the activity to a named threat actor in the report published Tuesday. "The investigation also confirmed active data exfiltration, not just beaconing," the company said. According to the analysis, observed execution began from an interactive zsh Terminal session consistent with ClickFix social engineering, followed by curl retrieving attacker-controlled content over a recurring /curl/ path and native utilities such as Base64 and gunzip decoding or unpacking the payload. The payload uses osascript for AppleScript-assisted execution alongside native macOS and Unix utilities, before collecting host and user information, macOS Keychain material, browser credentials and cookies, session data, Apple Notes, Secure Shell (SSH) keys, Amazon Web Services (AWS) credentials, Kubernetes configurations, browser history, and sensitive files from common user directories. Collected data is staged under /tmp/sync*, compressed into /tmp/osalogging.zip, split into multiple chunks, and uploaded with curl through HTTP PUT requests using recurring parameters such as upload_id, chunk_index, and total_chunks. The malware removes temporary archives, staging folders, lock files, and other artifacts after exfiltration. The disclosure builds on RST Cloud's May 8 analysis, which documented a static API key across four confirmed command-and-control (C2) domains and identified 11 additional candidate domains through recurring /dynamic?txd= and /gate?buildtxd= URI patterns. Several candidates had overlapping submission windows, which RST Cloud said was consistent with parallel C2 operation rather than strict sequential rotation between hostnames. "The hex build token rotates per deployment, the api-key does not," RST Cloud said. A comparison of the two published indicator sets by The Hacker News found that four domains Microsoft now lists, lalandscapelighting[.]com, lumenagnet[.]com, nailscanai[.]com, and numericagent[.]com, also appeared in RST Cloud's May candidate cluster. RST Cloud classified those domains as URI-pattern bound rather than API-key confirmed because it had not retrieved samples from each candidate to validate the static API-key match. Microsoft refers to API-key headers as a recurring MacSync trait, but its August 18 post does not publish the static value documented by RST Cloud or state that the same value appears across every domain in the current set. Microsoft said the recurring network traits include the /curl/, /dynamic?txd=, and /gate?buildtxd= paths, macOS User-Agent strings, API-key headers, and HTTP PUT uploads carrying the same chunk-management parameters. The researchers used those request shapes together with endpoint execution context to identify related infrastructure as the domains changed. Microsoft shared the following point-in-time domain indicators observed in activity consistent with MacSync Stealer - aihealthring[.]com cabinrentalsnc[.]com chatbasedos[.]com commercialroofingsd[.]com dogtrainersgeorgia[.]com fintelliganceai[.]com homeinspectionsdelaware[.]com intopython[.]com lalandscapelighting[.]com lumenagnet[.]com marbellaresales[.]com miamipcsupport[.]com moldinspectiondayton[.]com nailscanai[.]com newjerseypetsitter[.]com numericagent[.]com oaklandwaterdamage[.]com oklahomawarehousing[.]com olympiapetemergency[.]com peaecagent[.]com plasmaticsystems[.]com plethorawallet[.]com premierrentalpurchase[.]com ricewaterbeauty[.]com rvieragent[.]com sandiegotkd[.]com secueragent[.]com shiledagent[.]com syracusefertilitycenter[.]com vastbets[.]com wvaeagent[.]com Microsoft advised organizations to perform the following steps - Educate users not to paste or run Terminal commands from untrusted websites, chat messages, apps, files, or phone-based instructions. Monitor unusual Terminal, zsh , and shell sessions that retrieve payloads, decode content, or execute commands shortly after user interaction. Correlate AppleScript-assisted shell activity with credential-store access, archive creation under temporary paths, and subsequent outbound traffic. Monitor curl -based HTTP PUT uploads using--data-binary , API-key headers, upload identifiers, chunk indexes, total chunk counts, and recurring/gate URI patterns. Investigate connections to suspicious or newly registered domains while continuing to hunt for the request and process patterns that may persist after infrastructure changes. Apple has separately documented three protections available on macOS 26.4 and later: Terminal paste protection, pasteboard command blocking, and AppleScript scanning. After a 24-hour grace period following initial system setup, the Terminal warning applies when the user has not opened Terminal in more than 30 days, no common developer tooling is detected, and the paste originates from a specified application such as a web browser or messaging app. XProtect can trace the process tree produced by pasted terminal commands, check associated network artifacts against Apple's Safe Browsing Service, and block behavior that matches known malware techniques. AppleScript and JavaScript for Automation executions are also inspected locally, including scripts executed directly from memory. The disclosure comes less than two weeks after Microsoft said it had confirmed more than 250 front-end domains in a macOS ClickFix campaign distributing MacSync and Atomic Stealer (AMOS) behind a server-side browser-fingerprinting gate. The August 18 report does not state that those front-end domains are the same infrastructure set as the more than 30 domains identified through the MacSync behavioral pivots.
thehackernews.comAug 19, 2026extracted
Evooo1Bot Linux Botnet Exploits Known Flaws to Turn Edge Devices Into SOCKS5 Proxies
Cybersecurity researchers have flagged a previously undocumented Linux botnet family dubbed Evooo1Bot that derives its core functionality from the Mirai botnet source code and is equipped to turn internet-facing devices into SOCKS proxies. "While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities," Fortinet FortiGuard Labs said. Evidence indicates that the botnet has been active in the wild since July 2026, exploiting known vulnerabilities in publicly-accessible devices to deliver the malware. Some of the security flaws weaponized by the botnet are below - CVE-2007-3010 - Alcatel OmniPCX Enterprise Remote Code Execution Vulnerability CVE-2016-6277 - NETGEAR Multiple Routers Remote Code Execution Vulnerability CVE-2018-14558 - Tenda AC7, AC9, and AC10 Routers Command Injection Vulnerability CVE-2019-14931 - Mitsubishi Electric Europe B.V. ME-RTU devices and INEA ME-RTU devices remote Command Injection vulnerability CVE-2020-10987 - Tenda AC1900 Router AC15 Model Remote Code Execution Vulnerability CVE-2021-46422 - Telesquare SDT-CW3B1 Command Injection vulnerability CVE-2022-37055 - D-Link Routers Buffer Overflow Vulnerability CVE-2024-29269 - Telesquare TLR-2005KSH Command Injection Vulnerability CVE-2025-10123 - D-Link DIR-823X Command Injection Vulnerability CVE-2025-55583 - D-Link DIR-868L B1 router Command Injection Vulnerability Successful exploitation leads to the execution of a loader shell script ("wget.sh") hosted on an external server ("91.92.40[.]118"), which then retrieves the botnet binary that's compatible with the device CPU architecture. The script subsequently clears Bash history to erase traces of the attack. Upon execution, the binary checks for the presence of analysis tools, sandboxes, and virtual environments, before establishing encrypted communications with a command-and-control (C2) server on port 443. The port choice is intentional as it allows the malware to blend in with expected HTTPS traffic at the network perimeter. Once the host is registered with the C2 server, it waits for further commands to take action. It supports a number of commands that allow an operator to install persistence mechanisms, update the binary, terminate the bot, upload/download files, launch an interactive shell, intercept HTTP Basic Authorization and Cookie headers, turn the host into a proxy node, launch an SSH brute-force scanner, trigger DDoS attacks over DNS, TCP, and UDP, and fire an HTTP-based exploit dispatcher for exploiting known flaws. The CVE attack module includes the ability to launch exploits for eight security flaws impacting Hikvision (CVE-2021-36260), Atlassian Confluence (CVE-2022-26134), WSO2 (CVE-2022-29464), Zyxel (CVE-2022-30525), TP-Link (CVE-2023-1389), PHP (CVE-2024-4577), D-Link (CVE-2024-10914), Kubernetes (CVE-2025-1974). The proxy component, on the other hand, transforms an infected router, firewall, IP camera, or other edge device into a SOCKS5 proxy that the threat actor can leverage as a network relay to conduct follow-on operations and evade detection. "This capability significantly increases the value of an infected host to attackers," Fortinet said. "The victim's IP address can be used to disguise malicious traffic, bypass geographic restrictions, or provide access to internal networks through an already compromised machine." "In larger botnets, the same functionality could also be used to build a distributed proxy infrastructure, enabling anonymous traffic forwarding or monetization through residential and enterprise proxy services."
thehackernews.comAug 17, 2026extracted
New Evooo1Bot Linux botnet turns routers into traffic relay nodes
A new Mirai-based modular Linux botnet malware called Evooo1Bot has been targeting internet-facing gateway devices, turning them into SOCKS5 traffic relay nodes. The malware's capabilities extend beyond turning devices into proxy nodes and include credential theft, SSH brute-forcing, and launching distributed denial-of-service (DDoS) attacks. Since at least July, Evooo1Bot has been targeting devices from Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare, and D-Link across various regions by exploiting known vulnerabilities. “While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities,” Fortinet researchers found. Newer builds include a separate vulnerability-exploitation module targeting Hikvision cameras, Atlassian Confluence, Zyxel firewalls, TP-Link routers, D-Link NAS devices, WSO2 products, Kubernetes ingress-nginx, and vulnerable PHP-CGI installations. However, Fortinet notes that some of the embedded exploits are not correctly implemented, leading to failed exploitation. When leveraging an exploit successfully, a script downloads one of the 12 available malware builds that match the host’s CPU architecture, then clears Bash history to wipe traces of the attack. Evooo1Bot uses encrypted command-and-control (C2) communications over port 443 and performs extensive checks for debuggers, security tools, sandboxes, virtual machines, containers, and honeypots before it launches on the infected device. Persistence is established through systemd, SysV init, shell profiles, and rc.local, while a cron job attempts to re-download the payload every five minutes. An interactive shell gives operators direct control over compromised systems, while file-transfer commands support uploads and downloads. The malware also features a credential sniffer module that monitors ‘/proc/net/tcp’ and attempts to capture HTTP Basic Authentication and Cookie headers. The SOCKS5 module supports direct listening and reverse-relay modes, allowing attackers to conceal malicious traffic, circumvent geographic restrictions, or potentially access networks through compromised systems. Fortinet says proxying sessions run independently, and multiple can be opened simultaneously, allowing monetization through residential proxy services if the botnet grows large enough. The SSH scanner module uses 150 username and password combinations for enterprise-oriented accounts, and performs post-login checks to avoid honeypots. Finally, the DDoS module that was inherited by Mirai supports 16 flood methods, including UDP, DNS, SYN, ACK, GRE, fragmented TCP, and an HTTP flood with customizable requests. To defend against botnet malware, keep your IoT devices’ firmware updated, replace default admin credentials, turn off remote access panels, and replace devices when the vendor no longer provides support for them. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comAug 15, 2026extracted
Who Vets AI’s Code? The Scale Challenge Facing Open Source Ingestion
By Jonny Rivera, Head of Product at ActiveState During our conversations on the show floor at Black Hat last week, one question came up in almost every discussion our team had with AppSec leads, platform engineers, and CISOs: Who is actually vetting AI’s code? Developer adoption of AI coding tools isn't slowing down. The productivity gains are real, and open source software remains the backbone of modern enterprise applications. But as AI coding assistants auto-complete third-party dependency suggestions in milliseconds, enterprise security teams and open source maintainers face a shared operational challenge: code generation has completely outpaced legacy ingestion review. When an unvetted or hallucinated dependency enters a codebase at machine speed, post-commit Software Composition Analysis (SCA) scans struggle to keep pace. Securing this pipeline doesn't mean slowing developers down or restricting open source. It requires governing what enters the environment at the point of selection, before an import ever triggers a build. The Mechanics of "Slopsquatting" and Machine Ingestion Large language models (LLMs) recommend software libraries based on statistical probability and historical code patterns, not real-time package registry verification. When a model suggests a package name that does not exist in PyPI or npm, it creates a supply-chain vulnerability known as slopsquatting (or AI package hallucination exploitation). The scale of this vulnerability vector was highlighted in a USENIX Security study analyzing sixteen popular code-generation models across 500,000+ code samples: A measurable percentage of AI-suggested package names do not exist in public registries. Of the suggested dependencies that do resolve to real packages, nearly half contain known CVEs or outdated releases. Attackers routinely monitor public LLM output patterns and developer code repositories to identify these hallucinated package names. Once identified, an adversary registers the dummy name on PyPI or npm, uploads a malicious payload, and waits for automated developer environments or CI/CD builders to fetch it. [Developer Workspace] ---> [AI Assistant Auto-completes Package Name] | v [Package Name Does Not Exist in Registry] | v [Attacker Registers Name on PyPI/npm with Payload] | v [CI/CD Pipeline Fetches Package] ---> [Compromised Build] This vector is actively being observed in wild deployment. Early in 2026, security researchers tracked a single hallucinated npm package name (react-codeshift) originating from 47 AI-generated agent skills in a single commit. The hallucination spread organically through forks to over 230 repositories before an engineer noticed a human had never explicitly selected it. The issue was not malicious intent by the developer, rather, a complete absence of ingestion controls. AI coding assistants generate software at machine speed, but unvetted dependencies expose your pipeline to slopsquatting and supply chain attacks. Powered by a secure repository of clean, built-from-source components, ActiveState lets organizations prove software provenance and build-level attestation while eliminating slopsquatting vectors at the intake step. Talk to our Team The Friction Multiplier on Open Source Review The intake challenge inside the enterprise directly impacts the broader open source ecosystem. The same AI assistants generating unvetted dependency suggestions inside enterprise networks are also generating automated pull requests submitted to community-maintained repositories. This volume of automated contributions puts unprecedented strain on human maintainers: Conflicting AI Policies: Major projects, including Kubernetes, the Linux kernel, LLVM, and Godot, have published diverging policies on AI-assisted contributions. While some ban AI-generated code outright, others permit it only if a human contributor takes full accountability for every line added. Higher Defect Density: A CodeRabbit review of 470 open-source pull requests found that AI-co-authored contributions carried 70% more defects than human-authored code, despite reading clean on the surface. When hallucinated or vulnerable packages pass through corporate ingestion, they inevitably trickle down into upstream open source PRs, forcing volunteer maintainers to spend hours validating dependencies that no human deliberately evaluated. Velocity vs. Verification: The Governance Gap Recent telemetry from Kusari’s Application Security in Practice report illustrates how far tooling deployment has outrun ingestion controls: Traditional AppSec workflows rely on scanning code after it is written or after a pull request is opened. When code is generated at machine speed, late-stage alerts simply create backlog noise that engineers ignore. Securing the Pipeline at the Point of Selection Waiting for LLM hallucination rates to drop to zero is not an AppSec strategy. The core issue is velocity, not model accuracy. To secure the development pipeline without sacrificing output, security and platform teams are moving defense left of the IDE: Restrict Direct Registry Fetching: Block developer workstations and AI agents from querying unvetted public endpoints directly during code completion. Isolate AI-Suggested Dependencies: Route newly introduced dependencies into an isolated sandbox for automated reachability and vulnerability analysis before allowing them into primary branches. Govern the Ingestion Gateway: Shift from reactive CVE counting to proactive source curation, ensuring that every package an AI model recommends is pre-vetted against malicious typosquats and slopsquatting targets. This ingestion layer is precisely where ActiveState’s Secure Open Source Library and Curated Catalog operates. Designed to function as an enterprise-grade ingestion gateway, ActiveState delivers pre-vetted, continuously remediated open source packages directly to developer workstations, CI/CD pipelines, and AI agent environments. By sitting between public package registries and developer tools, a curated catalog ensures that hallucinated package risks are intercepted at the selection boundary. Enterprise teams running on a governed ingestion source eliminate slopsquatting vectors at the intake step, reducing overall CVE exposure by roughly 95% without forcing developers to turn off their AI assistants. Conclusion Disabling AI coding tools is neither practical nor competitive. However, treating AI integration purely as a developer productivity metric, without updating software supply chain ingestion rules, leaves production builds vulnerable to automated compromise. Securing the modern development pipeline requires ensuring that every package selected by a developer or an agent is governed by default before it ever hits a build. If you’re interested in seeing how ActiveState can help secure your open source applications, schedule a demo today. About the author: Jonny Rivera is a product leader whose career spans cybersecurity, digital healthcare solutions, and developer tooling. He is a proud theatre dad to an 8th grade dynamo and has been married for 18 years to the love of his life which he met on World of Warcraft. Sponsored and written by ActiveState.
bleepingcomputer.comAug 13, 2026extracted
Agenti AI contro Taiwan: la guerra cyber entra nell’era degli attacchi autonomi
Hacker criminali legati alla Cina avrebbero colpito Taiwan con un attacco informatico “autonomo” basato sull’intelligenza artificiale senza precedenti. Secondo il Financial Times, agenti AI hanno condotto operazioni simultanee di ricognizione ed intrusione, inaugurando una nuova fase della guerra cibernetica. “Il punto non è che l’AI sappia attaccare, è che sta iniziando a farlo da sola”, commenta Sandro Sana, Ethical Hacker e membro Comitato Scientifico Cyber 4.0. Inoltre, “l’elemento più preoccupante di questa operazione non è soltanto l’automazione dell’attacco, ma il ruolo abilitante dell’AI nel trasformare capacità offensive specialistiche in uno strumento scalabile”, secondo Pierluigi Paganini, analista di cyber security e Ceo Cybhorus. Ormai “nessuna organizzazione o infrastruttura può più ritenersi,fuori dal perimetro di attacchi cyber permanenti, automatizzati e ‘quasi’ autonomi”. conferma Enrico Morisi, Ict Security Manager. Indice degli argomenti Presunti hacker cinesi sono sospettati di aver utilizzato strumenti di intelligenza artificiale disponibili al pubblico per compromettere siti web governativi a Taiwan in un inedito attacco. Gli Agenti AI all’attacco di Taiwan mettono in luce come l’intelligenza artificiale stia trasformando la guerra cibernetica. Secondo i ricercatori di Dream, un’azienda israeliana specializzata in IA che per prima ha individuato l’intrusione, gli aggressori hanno sfruttato agenti di AI open source per creare uno strumento di hacking autonomo che agiva come una squadra informatica coordinata. “A Taiwan più agenti AI hanno operato in parallelo, adattando ricognizione e attacco in funzione di ciò che trovavano: questo significa più velocità, più bersagli e soprattutto un costo dell’attacco drasticamente più basso”, spiega Sandro Sana. All’inizio di luglio, nell’arco di quattro giorni, lo strumento ha dispiegato contemporaneamente fino a otto agenti autonomi che hanno mappato 21 sistemi governativi, individuato le vulnerabilità e modificato le tattiche quando venivano bloccati. “Otto agenti possono lavorare in parallelo, analizzare i risultati, cambiare strategia e cercare nuove strade senza una supervisione umana continua. Nel contesto dell’information warfare, questo significa poter aumentare enormemente velocità, persistenza e volume delle operazioni contro governi, infrastrutture e organizzazioni strategiche”, conferma Paganini. Lo strumento ha compromesso almeno 85 account di utenti governativi, estraendo oltre 2.500 record relativi al personale prima di estendere l’attacco all’agenzia per la sicurezza nucleare di Taiwan e ad almeno sette aziende energetiche, come ha dimostrato la ricerca. “L’uso di strumenti di AI pubblicamente disponibili, facilmente accessibili e dotati di ‘guardrail’ di fatto inefficaci, l’automazione delle operation e l’autonomia tattica degli agenti AI, che comportano rapidità di attacco e di adattamento senza precedenti, a contesti caratterizzati anche da significativa variabilità, dovrebbero allertare non solo i governi, ma ogni organizzazione o infrastruttura”, aggiunge Enrico Morisi. La scoperta arriva in un momento in cui i settori dell’intelligenza artificiale e della sicurezza informatica si confrontano con la capacità dei modelli di frontiera di identificare e sfruttare le vulnerabilità del software. Come noto, Anthropic, OpenAI e Meta hanno segnalato che nuovi modelli di AI hanno sferrato attacchi informatici inaspettati durante i test. Il direttore strategico di Dream, Amir Becker, che in precedenza era a capo delle operazioni informatiche dell’Unità 8200, l’unità d’élite israeliana di intelligence dei segnali, ha affermato di non aver mai visto prima d’ora un “attacco autonomo end-to-end” di questo tipo contro un obiettivo governativo. I ricercatori di Dream hanno trovato prove dell’attacco informatico di luglio in un archivio online da 160 MB individuato nel corso di indagini condotte dall’azienda sulle attività in continua evoluzione degli autori di minacce informatiche. L’archivio conteneva 1.395 file che dimostravano come lo strumento di hacking utilizzasse due sistemi di agenti di intelligenza artificiale open source, Hermes e OpenClaw, scaricabili e in grado di consentire ai modelli di IA di svolgere compiti in modo autonomo. I ricercatori non sono riusciti a identificare quale modello di AI fosse stato utilizzato per alimentare gli agenti. Tuttavia, i dati hanno mostrato che le misure di sicurezza del modello sottostante erano state aggirate presentando l’attività di hacking come un’operazione autorizzata volta a testare le vulnerabilità del sistema. “Dobbiamo essere tutti consapevoli di questi rischi, tenendo presente che i costi per progettare un attacco sono drasticamente crollati, mentre non lo sono quelli per difendersi“, sottolinea Enrico Morisi. A sorprendere i ricercatori di sicurezza è stata il modo in cui lo strumento classificava e ridefiniva continuamente le priorità dei possibili percorsi di attacco sulla base delle prove disponibili. Quando un percorso di attacco falliva, lo strumento dispiegava un altro agente per setacciare Internet alla ricerca di informazioni e ideare un nuovo approccio. Esattamente come si comporterebbe un hacker umano. “L’AI non sostituisce necessariamente l’attaccante: ne amplifica le capacità, riducendo costi e tempi e rendendo più facile mantenere campagne lunghe e adattive“, mette in guardia Paganini. L’avvento degli strumenti di intelligenza artificiale ha reso necessario che i governi partano ora dal presupposto di essere costantemente sotto attacco informatico. “Questo deve essere il presupposto di base di ogni governo in tutto il mondo”, ha affermato Amir Becker. Una persona a conoscenza dell’attacco ha confermato che l’obiettivo era Taiwan. Dream ha dichiarato di aver informato un Paese della regione «Asia-Pacifico» della violazione, senza fare nomi e senza attribuire l’attacco a un gruppo specifico. Tuttavia i ricercatori hanno affermato che l’uso del cinese semplificato nelle comunicazioni interne collegate all’attacco indicava un’alta probabilità che l’autore fosse collegato alla Cina. Le autorità cinesi non hanno commentato l’accaduto. Ma i dati recuperati dal bersaglio erano scritti in cinese tradizionale, come avviene comunemente solo sui siti web governativi di Taiwan, Hong Kong e Macao. Un portavoce del Ministero degli Affari Digitali di Taiwan, pur rifiutando di commentare l’attacco informatico, per motivi di riservatezza, ha aggiunto che tutti gli incidenti “che coinvolgono agenzie governative o infrastrutture critiche saranno gestiti secondo le procedure di segnalazione e risposta stabilite”. Tuttavia, “i metodi di attacco degli hacker sono diventati sempre più diversificati e, negli ultimi anni, l’integrazione della tecnologia di intelligenza artificiale ha ulteriormente trasformato la natura degli incidenti di sicurezza informatica», ha spiegato il portavoce: “Gli agenti Ai hanno posto una doppia sfida alla difesa della sicurezza delle reti: gli attacchi sono automatizzati e gli stessi agenti di intelligenza artificiale diventano nuove vulnerabilità”. “Con la maggiore diffusione di questo modello, l’AI potrebbe rendere le operazioni di information warfare più rapide, persistenti e difficili da attribuire. Attacchi capaci di adattarsi autonomamente alle contromisure aumenterebbero inevitabilmente la complessità dell’attribuzione e renderebbero più difficile coordinare una risposta tempestiva“, avverte Paganini. Nel rapporto di gennaio, l’Ufficio per la sicurezza nazionale di Taiwan ha affermato che nel 2025 l’isola ha subito in media 2,6 milioni di attacchi informatici al giorno provenienti dalla Cina (+6% rispetto all’anno precedente). Pechino rivendica Taiwan come parte del proprio territorio, secondo il principio “One China”, e minaccia di annetterla con la forza qualora Taipei si rifiutasse indefinitamente di sottomettersi al suo controllo. Nelle ultime settimane anche Anthropic ha riportato un caso di un’agente AI che ha sferrato attacchi cyber non richiesti. L’evento si affianca al pericoloso precedente di OpenAI-Hugging Face, che resterà nella storia come il primo esempio di attacchi AI autonomi senza la volontà umana. Anzi, contro di essa. “Diviene quindi sempre più decisivo, per le organizzazioni, definire correttamente le priorità e destinare le (spesso poche) risorse a disposizione a ciò che sia realmente opportuno proteggere, vale a dire ciò che sostiene il ‘core business, la ‘mission’, identificando le minacce, gestendo efficacemente i rischi e svolgendo accurate analisi di impatto”, avverte Enrico Morisi. La lezione da trarre dagli incidenti di OpenAI e Anthropic è che la sicurezza tradizionale continua a rimanere il primo livello di difesa. “Senza sistemi di AI in grado di analizzare rapidamente gli attacchi, correlare gli indicatori e supportare le decisioni, i difensori rischiano di trovarsi a reagire a campagne che evolvono più velocemente della loro capacità di comprenderle e contenerle”, mette in evidenza Paganini. Segmentare la rete, applicare il principio del least privilege, effettuare la rotazione delle credenziali, isolare i sistemi di produzione, proteggere i metadata cloud, monitorare l’accesso ai cluster Kubernetes e limitare il traffico in uscita, sono tutte attività che avrebbero mitigato i rischi, ostacolando ed impedendo vari passaggi della catena di attacco. “In seconda battuta, potrebbero poi rivelarsi molto utili, a supporto, i cosiddetti Digital Twin, soprattutto se arricchiti da preziose informazioni di Threat Intelligence e sulla probabilità di effettivo sfruttamento delle vulnerabilità, e se potenziati dall’uso di tecnologie di AI, in grado di correlare tutti gli elementi a disposizione al fine di individuare possibili scenari di attacco, anche in termini di probabilità che si verifichino”, conclude Morisi. Ma “il problema è che molte aziende affrontano ancora vulnerabilità e remediation con tempi umani e processi burocratici”, evidenzia Sandro Sana: “Se l’attacco viaggia alla velocità della macchina, non possiamo continuare a difenderci con i tempi della riunione del lunedì mattina”.
cybersecurity360.itAug 13, 2026extracted
Chipmaker Patch Tuesday: Intel, AMD Fix Over 80 Vulnerabilities Combined
Intel and AMD on Tuesday announced patches for a total of more than 80 vulnerabilities across their products. Intel has published 42 new advisories covering 72 vulnerabilities. The company patched several high-severity flaws in PROSet/Wireless WiFi software that could allow an attacker to escalate privileges or conduct a denial-of-service (DoS) attack. In addition, high-severity vulnerabilities have been addressed in Xeon processors (privilege escalation), Data Center Attestation Primitives (information disclosure), Alias Checking Trusted Module for Xeon processors (privilege escalation), TDX (privilege escalation), Active Management Technology (DoS), PROSet/Wireless WiFi software (local code execution, privilege escalation and DoS), and CSME and SPS (privilege escalation). Medium-severity issues have been patched by Intel in Transfer Learning Tool, Extension for PyTorch, LLM-on-Ray, Gaudi Container Runtime, Performance Counter Monitor, vLLM Hardware Plugin for Gaudi, Approximate Bayesian Inference Framework, Hardware Aware Automated Machine Learning, EquiTriton Software, and Workload Services Framework products. Medium vulnerabilities have also been resolved in LLM Scaler, LLM Library and oneCCL Bindings for PyTorch, TDX DCAP and Guest, AI Containers, Cluster Management Toolkit for Kubernetes, Open VKL, Extension for TensorFlow, NPU Drivers, Neural Compressor, Battery Life Diagnostic Tool, Xeon and Core Ultra, UEFI Reference BIOS, AI Reference Models, CSME, and SPS products. These security holes can be exploited for privilege escalation, DoS, and information disclosure. Intel has fixed a low-severity vulnerability in Slim Bootloader. AMD published five new advisories on Tuesday to inform customers about a dozen vulnerabilities. One advisory describes five high-severity issues in the Vitis development environment. Their exploitation could lead to private key disclosure, privilege escalation, and arbitrary code execution. Arbitrary code execution issues have also been addressed by AMD in Ryzen Master Utility, SEV-SNP, and Power Design Manager. Earlier this month, the chipmaker informed customers about a Safe RET interrupt vulnerability and a recently disclosed SEV attack method dubbed PowerHooK. Related: Chipmaker Patch Tuesday: Intel and AMD Patch 70 Vulnerabilities Related: ICS Patch Tuesday: Vulnerabilities Fixed by Siemens, Schneider, Phoenix Contact Related: August 2026 Patch Tuesday: Microsoft Fixes 421 CVEs, One Exploited Zero-Day
securityweek.comAug 12, 2026extracted
Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations
Two malicious LiteLLM releases sat on PyPI for about 40 minutes in March carrying credential-stealing code capable of harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from systems that installed them. Threat intelligence firm CloudSEK now says a dataset it obtained, built from roughly 434,000 files the attackers captured, maps potential exposure to more than 2,500 organizations. Those totals are not a victim count. CloudSEK told The Hacker News the material came from confidential intelligence sources and consists of captured loot and log files it assessed as belonging to the campaign, not data gathered from the organizations it names. The files were taken, in other words. CloudSEK has published the dataset as a public lookup, searchable by name or domain and filterable by confidence. Each row gives an organization's name and domain, a count of secrets exposed, a count of runs, and a label reading High or Medium. What a high-confidence match asserts is whose systems each file came from. That verdict keys on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, and the organization's own domain has to appear before a match earns the top rating. Repository namespaces support only a medium-confidence call. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp are among the entries, and none of that establishes that stolen credentials were used, which is why both CloudSEK and LiteLLM tell affected parties to rotate rather than wait for proof. LiteLLM is an open-source AI gateway used to connect applications with multiple model providers. The project identified versions 1.82.7 and 1.82.8 as compromised and said they were live on March 24 from 10:39 UTC for about 40 minutes before PyPI quarantined them, though it tells users to treat any install that day up to 16:00 UTC as suspect. The Hacker News confirmed via PyPI on August 12 that neither version appears in the package's release history, while 1.82.6 and 1.83.0 remain available. The FBI warned in a July 2 advisory, FLASH-20260702-01, that affiliated actors are likely to weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. It told organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the relevant exposure windows. A long-lived secret copied during that window, a static cloud key, an SSH key, or a publishing token, remains usable unless it has since been rotated or revoked. That is why the bureau's guidance is scoped to credentials rather than to the package, and why both it and Aqua tell teams to move away from long-lived tokens toward temporary ones. Version 1.82.8 included a file named litellm_init.pth that Python processes at interpreter startup, so it ran whenever a Python process started in that environment, whether or not anything imported LiteLLM. The compromised packages were designed to collect environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords before encrypting and sending stolen data to models.litellm[.]cloud, an attacker-controlled domain unrelated to the project. Unit 42's campaign analysis records the payload reading environment variables that hold model API keys, including OPENAI_API_KEY and ANTHROPIC_API_KEY. That behavior inverts the usual triage question. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it, and the project's advisory notes that an unpinned transitive dependency, including one pulled in by an agent framework or orchestration tool, could deliver it without anyone choosing it. The LiteLLM incident sits inside a wider TeamPCP supply-chain campaign linked to Aqua Security's Trivy scanner. Google tracks TeamPCP as UNC6780. Aqua said attackers retained access after an incomplete credential rotation and, on March 19, force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags while publishing a malicious Trivy 0.69.4 release. The ecosystem compromise is tracked as CVE-2026-33634, added to CISA's Known Exploited Vulnerabilities catalog on March 26. The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components. Exactly how the malicious LiteLLM releases reached PyPI was disputed across the published accounts. CloudSEK's report said the poisoned build produced and published the releases, LiteLLM's own incident report pointed to a direct PyPI upload that bypassed its official CI/CD workflow, and Unit 42 described attackers targeting PyPI publishing tokens after the Trivy breach. Asked about the discrepancy, CloudSEK pushed back. "These are different stages of the same attack chain, not competing explanations," the company told The Hacker News. Its evidence covers how the credential was obtained, while the LiteLLM and Unit 42 findings cover how it was then used. PyPA's advisory for the malicious releases describes the same sequence: an API token exposed through the compromised Trivy dependency and then used to upload the two versions. BerriAI had not responded to questions about which account its own forensics support at the time of writing. Attribution inside the dataset runs through two independent checks, CloudSEK said. An index assigns each file using CI identity variables, and a separate ownership gate re-derives ownership from the fetched logs and can override that assignment. "If they disagree, the report is withheld," the company said, and the final verdict takes the lower of the two confidence levels. The 434,000 figure counts captured files and exfiltration events rather than distinct pipelines, runs, or jobs. CloudSEK said one captured file is roughly one job execution, but it does not present the total as unique jobs without independent deduplication and verification. The company declined to discuss pre-publication notifications to the named organizations, and would not say whether any disputed its inclusion. The campaign's downstream impact is confirmed even if CloudSEK's scale figures are not. Checkmarx said credentials obtained through the Trivy attack enabled unauthorized access to its GitHub repositories and the publication of malicious artifacts. Mercor said it was affected by malicious LiteLLM versions and contained unauthorized activity. CERT-EU separately assessed with high confidence that a European Commission AWS account was compromised through the Trivy supply-chain attack, with about 91.7 GB of compressed data exfiltrated. Organizations assessing exposure should take three steps: Check for LiteLLM 1.82.7 or 1.82.8 installations during LiteLLM's March 24 audit window of 10:39 to 16:00 UTC. Rotate any secrets those systems could access. Search their GitHub organizations for repositories named tpcp-docs or docs-tpcp, which the FBI lists as campaign indicators. Aqua's advisory for the CVE notes the malware created these with a tpcp-docs- prefix and uploaded stolen data as a release asset tagged data- , so an exact-name search can miss them.
thehackernews.comAug 12, 2026extracted
NCSC-2026-0287 [1.00] [M/H] Kwetsbaarheden verholpen in Microsoft Azure
Microsoft heeft kwetsbaarheden verholpen in diverse Azure componenten. Een kwaadwillende kan de kwetsbaarheden misbruiken om aanvallen uit te voeren die kunnen leiden tot de categorieën schade zoals benoemd in onderstaande tabel. De kwetsbaarheid met kenmerk CVE-2026-56162, met een CVSS score van 10.0 en de kwetsbaarheden met kenmerk CVE-2026-50516, CVE-2026-56161, CVE-2026-59115, CVE-2026-62830, CVE-2026-62873 en CVE-2026-68823, elk met een CVSS score hoger dan 9, zijn reeds centraal verholpen door Microsoft zelf en slechts opgenomen ter informatie. Hiervoor zijn geen acties vereist. De kwetsbaarheid met kenmerk CVE-2026-50481, met een CVSS score van 9.9 echter, vereist wel actie. Deze kwetsbaarheid bevindt zich in de Azure Active Directory en stelt een kwaadwillende in staat om zich verhoogde rechten toe te kennen en daarmee toegang te krijgen tot gegevens en componenten waartoe de kwaadwillende aanvankelijk niet is geautoriseerd. `` Azure Monitor Agent: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-47299 | 7.20 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Microsoft Purview eDiscovery: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-65668 | 8.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Microsoft Azure Kubernetes Service: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-50516 | 9.40 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure Entra ID: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-62869 | 8.80 | Voordoen als andere gebruiker | |----------------|------|-------------------------------------| Microsoft Entra Connect Sync: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-65673 | 7.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure SQL Database: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-63522 | 7.80 | Verkrijgen van verhoogde rechten | | CVE-2026-56162 | 10.0 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure Logic Apps: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-56161 | 9.60 | Toegang tot gevoelige gegevens | |----------------|------|-------------------------------------| Azure Active Directory: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-50481 | 9.90 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Application Insights Profiler: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-49163 | 8.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure SRE Agent: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-62830 | 9.90 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Microsoft Entra Provisioning Service (SyncFabric): |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-59115 | 9.90 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure CycleCloud: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-70340 | 8.10 | Verkrijgen van verhoogde rechten | | CVE-2026-65806 | 6.50 | Toegang tot gevoelige gegevens | |----------------|------|-------------------------------------| Azure Confidential Ledger: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-68823 | 9.10 | Uitvoeren van willekeurige code | |----------------|------|-------------------------------------| Microsoft 365 Admin Center: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-62873 | 9.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure Storage Explorer: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2026-57104 | 8.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| ``
advisories.ncsc.nlAug 12, 2026extracted
Kimwolf v7 Android Botnet Makes HTTP/2 DDoS Traffic Look Like Legitimate Browsing
Cybersecurity researchers have discovered a new version of the Kimwolf/AISURU Android and Internet of Things (IoT) botnet that comes with significant improvements to improve its operational resilience and conduct distributed denial-of-service (DDoS) attacks. The new version, tracked as Kimwolf v7, was discovered by Palo Alto Networks Unit 42 in February 2026. "Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints," researchers Asher Davila, Chris Navarrete, and Doel Santos said. "This makes attack traffic more difficult to distinguish from legitimate browsing." The botnet also aims to make its command-and-control (C2) infrastructure more resistant to takedown efforts by using a tiered mechanism that employs Ethereum Name Service (ENS) to obtain the C2 address, a hard-coded Tor .onion hidden service, and a local proxy for routing between clearnet and Tor, while removing all scanning, exploitation, and brute-force functionality. The removal of the scanner and exploit modules is an indication that the threat actors behind the operation have split the propagation pipeline from the core payload, offloading the task to an external loader for initial access, while the Kimwolf binary handles DDoS attacks and proxy relay. Kimwolf is known to target Android TV boxes since August 2025, while its Linux counterpart, AISURU, primarily focuses on Linux IoT devices. The botnet has been active since at least mid-2024. The botnet typically abuses residential proxy services to reach Android TVs that ship with Android Debug Bridge (ADB) enabled on port 5555 on local networks and install malware capable of conducting DDoS attacks and acting as a relay to ferry malicious traffic. Once launched, the malware attempts to mask itself as seemingly legitimate Android system processes (e.g., "netd_service") to fly under the radar. Some of the newly observed features in the new version are as follows - Carry out HTTP/2 flood attacks powered by the nghttp2 library and disguise the traffic by constructing Google Chrome browser fingerprints that mirror legitimate browser behavior at the protocol and header level Using legitimate public Ethereum RPC services to query ENS domain records and resolve C2 addresses A backup C2 mechanism that uses a Tor .onion hidden service ("edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion") that's hard-coded into the binary A local proxy architecture that routes all C2 traffic through 127.0.0[.]1:23075, irrespective of whether it's headed to clearnet or Tor A high-performance UDP flood function that specifically targets ARM processors found in Android TV boxes Consolidate all DDoS attack commands to 15 numbered methods, down from 43 text-named methods found in prior versions The Kimwolf operators have also been found to distribute Android APK packages that masquerade as a system service called SystemService, probe for root access, and execute a bundled ELF kernel payload inside. Eight such APK artifacts have been identified between October and December 2025. "The earliest dropped sample, targeting the x86 architecture with a Dirty COW exploit, suggests the family evolved from traditional Linux exploitation toward the current ADB-based Android propagation model," Unit 42 said. "The transition from libn[redacted]kernel.so to the less conspicuous libdevice.so filename in November 2025, followed by a revert in December, indicates active operational security adjustments." The disclosure comes as a number of new botnet malware families have been detected in recent months - AryStinger, which enlists older, vulnerable home routers into a network for distributed reconnaissance and proxying RustDuck, which hijacks home routers, IP cameras, Android boxes, and poorly secured servers to rope them into a network for conducting DDoS attacks NadMesh, which combines scanning, exploitation, and credential/AI-service intelligence harvesting into a single autonomous platform that's designed to scan for Redis, Docker, MCP, Kubernetes, ComfyUI, Ollama, n8n, Open WebUI, Langflow, and Gradio instances, drop an SSH backdoor, and harvest credentials, environment variables, account tokens, and AWS and Docker configurations Tengu, a Mirai-derived IoT malware that employs Telnet brute-force to hijack IoT devices and run instructions that allow it to launch DoS attacks, gather network configuration information, set up persistence, exfiltrate system metadata, execute commands, download additional payloads, and turn the infected node into a proxy. "Kimwolf v7 is a focused evolution of an already large-scale botnet," Unit 42 said. "Organizations should treat Android TV boxes as untrusted and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary propagation vector for this botnet."
thehackernews.comAug 11, 2026extracted
‘Ghostjacking’ Attack Uses Poisoned Logs to Turn AI Agents Bad
DEF CON – Tenet security researchers have demonstrated a novel AI hijacking attack that relies on tools trusted by the agent to deliver malicious instructions. The Israeli cybersecurity startup, which emerged from stealth mode in June to protect organizations from rogue agents, previously demonstrated how threat actors can poison data fed to AI agents to manipulate their behavior, an action it calls ‘Agentjacking’. Dubbed Ghostjacking, the newly demonstrated attack builds on the same assumption: an external threat actor is able to plant instructions as text in logs or alerts to turn AI agents rogue. The underlying issue, it says, is spread widely, as the attack targets three highly trusted platforms: Cloudflare, which routes 20% of all web traffic, Datadog, and Sentry. Cloudflare and Datadog are used by nearly half of Fortune 500 companies each, while Sentry is trusted by close to 4 million developers. The compromised agent “hijacked the domain on Cloudflare, ran code and stole cloud credentials on Datadog, and turned one AI into an insider that vouched for the attacker to the next on Sentry,” Tenet says. Cloudflare’s recommended security configuration, the startup says, exposes organizations to one of the attack vectors: a bad request is blocked by the firewall level and logged word for word, injecting the attacker’s malicious instructions as plain text in the log. When an analyst asks an agent to review the event, the AI reads and executes the instructions, altering the organization’s DNS settings to point to an attacker-controlled domain, and then reporting the issue as resolved. “It worked 9 times out of 10 against Claude Code. Every request had already been blocked. The domain was taken over anyway. […] It is Cloudflare’s managed security rule that blocks the request, and that block is what carries the attack in,” Tenet says. Another attack vector abuses a Datadog key meant for the front end, but which is routinely left in the open, as demonstrated by the over 2,700 such keys the cybersecurity firm has found on the internet. “With that key, an attacker plants a fake ‘urgent diagnostic’ alert. When an engineer asks their AI agent to check for errors, the agent reads it and runs the attacker’s command,” Tenet notes. The attack manipulated Claude Code into executing code and exfiltrating environment secrets and cloud credentials. To target Sentry, an attacker uses a crafted report that is read by Sentry’s AI agent Seer, which adopts a proposed fake fix as its own. When the fix is passed to the coding agent that trusts Seer, the attacker’s code is executed. Tenet also says it used an AI agent to devise the attack that would be carried out by another agent. “Each time the target AI refused, its refusal revealed the wording it would accept, until it ran the attack against itself. This was a controlled lab test: two separate AI sessions, one as attacker and one as target, with memory off so neither knew about the other,” the company says. Additionally, the startup found a vulnerability in Claude Desktop that could be exploited to exfiltrate data to a remote server. Anthropic has fixed the flaw without issuing a CVE, Tenet says. “Sentry, Cloudflare, and Datadog are not three separate flaws. They are the same shape. An AI reads outside data it trusts, and the same AI can also act on it. Wherever those two things meet, the door is open. The same pattern shows up far beyond these three, in setups like Splunk with a build system, or Datadog with Kubernetes,” the company notes. Related: Novel Private APN Pivot Let Hackers Sabotage Second Polish Energy Facility Related: Critical One-Click Vulnerability in Atlassian’s Rovo AI Exposed Enterprise Data Related: Rethinking AI Security: Why CASB and DLP Need an Interaction-Aware Layer Related: Podcast: Compliance Won’t Save You: The Future of Cyber Risk with Edna Conway
securityweek.comAug 10, 2026extracted
“Ghostjacking” Exploits AI Agents’ Trusted Access to Evade Firewall Controls
Half of Fortune 500 companies are vulnerable to attacks enabled by their own AI agents bypassing firewall defenses, according to new research by Tenet Security. The technique, dubbed ‘Ghostjacking’, involves the use of an organization’s own AI agents to reroute the company’s email and web traffic, opening a hidden path around its firewall. Tenet Security researchers demonstrated how a single fake bug report could hijack AI coding assistants and run an attacker’s code on a developer’s machine. The attack cannot be flagged to defenders as the agents use access they have already been granted, and while the firewall doesn’t go down it becomes irrelevant. Attackers can also exploit the flaw to leave backdoors in the agent’s configuration, memory and tools, providing them with persistent access into the victim organization for the purposes such as data and credential theft. The researchers even demonstrated one case in which they could get one AI agent to build an attack that another AI would accept, which was described as a “self-exploit” technique. This attack chain succeeds across software platforms commonly used by developers, including Cloudflare, Datadog and Sentry. The findings were presented on the main stage at DEFCON 2026 in Las Vegas on August 9. The Tenet team demonstrated that the Ghostjacking technique succeeded nine out of 10 times against the Claude Code AI agent, on Cloudflare’s own recommended set up. Among the organizations known to run the exposed Cloudflare set up are a trillion-dollar global technology company, a global payments provider and a leading AI research lab. The study noted that Cloudflare is run in 42% of Fortune 500 firms, and carries a fifth of all internet traffic, while Datadog runs in 48% of these companies and Sentry is used by four million developers. The findings further highlight the risks by organizations increasingly entrusting AI agents with full access to their code and infrastructure, with the agents unable to distinguish between a real instruction from a trap hidden in the data it reads. How One Fake Report Tricks AI Agents Tenet said that Ghostjacking is the next evolution of the ‘Agentjacking’ attack class, which involves tricking AI coding agents into executing arbitrary code on developer machines. Ghostjacking sees the company’s own security controls essentially act as the delivery system for a full domain takeover. With the Cloudflare firewall, when it prevents a bad request by a malicious actor, it records it word-for-word in the logs. This means an attacker’s planted log will be read by the AI as if it were a real finding when asked to review the blocked events by an analyst. The same AI will rewrite the company’s DNS, point the domain at the attacker and report the issue as resolved. This can allow an attacker to quietly reroute website traffic and emails. “It is Cloudflare’s managed security rule that blocks the request, and that block is what carries the attack in,” Tenet said. The Datadog platform was similarly exposed to Ghostjacking because its key, meant only for a website’s front end, is routinely left public. The Tenet researchers discovered more than 2700 of these keys. The key can be used to plant a fake “urgent diagnostic alert”, which is read by the AI agent when asked by an engineer to check for errors. With Sentry, the researchers even used the platform’s own AI, Seer, to “vouch” for them to the next agent. This is because Seer reads the fake report and attacker’s fake fix as its own conclusion, which is trusted by the coding agent, thereby running the malicious code. “Sentry, Cloudflare, and Datadog are not three separate flaws. They are the same shape. An AI reads outside data it trusts, and the same AI can also act on it. Wherever those two things meet, the door is open. The same pattern shows up far beyond these three, in setups like Splunk with a build system, or Datadog with Kubernetes,” the researchers noted. The findings were reported by Tenet to Sentry, Datadog and Cloudflare in June. Tenet recommended that companies take the following actions to reduce their exposure to Ghostjacking: Deny outbound network access by default. This alone stops the attacker’s download and the data leak Require a human to approve any command the agent wants to run Never let data an agent reads become an instruction it runs Assume any reachable token is at risk, and review every tool the agent connects to
infosecurity-magazine.comAug 10, 2026extracted
Chainloop: Open-source evidence store and policy engine for the software supply chain
Chainloop: Open-source evidence store and policy engine for the software supply chain Chainloop is an open source evidence store for the software supply chain. A command line tool runs inside a GitHub Actions, GitLab, Jenkins, or Dagger pipeline, picks up what the build produced, uploads those files to content-addressable storage, and references each one in a signed in-toto attestation. in-toto is a specification for recording who ran which step of a build, so the record can be checked afterward. Compliance and security teams get a control plane where all of it arrives, already signed, no matter which continuous integration provider produced it. The gap that closes is easy to see in a pipeline that lacks it. A build turns out a bill of materials listing every dependency in the release, a SARIF file recording what the static analyzer found, a coverage report, a container image reference, and a scan from whatever commercial tool the security group bought last year. Each file lands somewhere different. Nothing signed ties any of them to the commit that produced them, so when a customer asks six months later which version of a compression library shipped in a given release, someone is digging through build logs to reconstruct an answer they can’t verify. The contract does the enforcing A Workflow Contract declares what a build has to hand over: which materials, which build information, and the environment the workflow has to run in. Compliance and security teams write the contract, and Chainloop checks that the crafting of artifacts and attestation meets it, so a pipeline that stops emitting a bill of materials stops satisfying the contract. Rego policies, written in the language Open Policy Agent uses, attach to those same contracts. They are evaluated automatically and their results are written into the attestation before it is signed and stored, so the verdict on a build travels inside the signed record rather than sitting in a dashboard someone can edit later. Seventeen named evidence formats get first-class handling, and the full catalog runs longer than that. CycloneDX and SPDX bills of materials, OpenVEX, the four CSAF document types, SARIF, ZAP DAST results, BlackDuck SCA output, PrismaCloud Twistcli scans, GitLab security reports, JUnit results, JaCoCo XML coverage, Helm charts, and container image references are among them. Anything else goes in under one of four catch-all categories, as a custom evidence type, an approval report in JSON for instance, or as key-value metadata pairs. Signing is not tied to one method either: evidence can be signed through Sigstore or through an organization’s own PKI, including AWS KMS or Keyfactor, which matters to anyone whose keys have to stay in-house. Two audiences, one integration point Artifacts and evidence can be routed to an OCI registry or cloud blob storage, sent to Dependency-Track or Guac for bill-of-materials analysis, and announced in Jira, Discord, or Slack. Swapping the analysis backend requires no change to a pipeline, because the pipeline only ever talks to the crafting tool. Compliance and security teams define the contracts, craft the policies, wire up those integrations, and hold access to the control plane. Development teams get a different pitch. What the regulations require FedRamp, Executive Order 14028 in the United States, the EU Cyber Resilience Act, and the Digital Operational Resilience Act all turn questions about what shipped into questions someone has to answer on a deadline. The project publishes guides for the Cyber Resilience Act and for SLSA, the supply chain framework whose level 3 the single source of truth is built to satisfy. A FedRamp guide is listed as coming. The command line tool points at a hosted Chainloop instance by default, which is convenient for a trial and means the evidence leaves your infrastructure. Running the Helm chart on your own Kubernetes cluster puts the control plane back in-house. Chainloop is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
helpnetsecurity.comAug 10, 2026extracted
TeamPCP Linked To Redis Attacks Dating Back To 2020 And Later Supply Chain Campaign
A new analysis has uncovered that the threat actor tracked as TeamPCP has been active on the cybercrime scene as far back as 2020, indicating the group has been compromising internet-facing infrastructure for years before training their sights on the software supply chain. "The connection is supported by overlapping domains, malware deployment paths, staging techniques, backend infrastructure, and operational tradecraft," Oligo Security researchers Avi Lumelsky and Gal Elbaz said. This includes two campaigns observed in the second half of 2025: ShadowRay 2.0 (aka IronErn), which involved hijacking artificial intelligence (AI) infrastructure into a self-propagating botnet, and TA-NATALSTATUS, which targeted exposed Redis servers to deliver cryptocurrency miners. TA-NATALSTATUS is assessed to be an evolution of a prior campaign that was detailed by Trend Micro in April 2020 that involved targeting Redis servers to deploy malware. This suggests that the threat actor has been actively targeting internet-accessible infrastructure across Ray, Docker, Redis, and React much before it branded itself as TeamPCP. Details of the attackers first emerged towards the end of last year when they were linked to the exploitation of security flaws in React Server Components (RSC) and Next.js to facilitate the extraction of credentials and sensitive data from compromised environments. The activity was codenamed Operation PCPcat. Then, earlier this year, Flare detailed a massive campaign undertaken by the threat actor to systematically target cloud native environments as part of efforts to set up malicious infrastructure for follow-on exploitation. "The operation's goals were to build a distributed proxy and scanning infrastructure at scale, then compromise servers to exfiltrate data, deploy ransomware, conduct extortion, and mine cryptocurrency," Flare security researcher Assaf Morag noted at the time. The group has since branched into high-profile supply chain compromises, weaponizing the interconnected nature of modern software to infect developer systems en masse by poisoning popular open-source libraries through a combination of GitHub Actions and token theft abuse. "One of the strongest operational links is the overlap between the IronErn GitHub and GitLab identities observed during ShadowRay 2.0 and TeamPCP's later infrastructure," Oligo said. "Correlating GitLab authentication logs, command-and-control infrastructure, reverse-shell activity, and malware staging establishes a direct operational bridge between the ShadowRay 2.0 campaign and the actor later operating publicly as TeamPCP." The latest findings show that not only are these efforts linked, but also that the threat actor repeatedly abused known security flaws impacting React, Docker, Redis, and Ray to gain access and rely on automated and wormable exploitation techniques for self-propagation. The expansion into cascading software supply chain attacks, therefore, represents a natural evolution of this trend, allowing the threat actors to take advantage of legitimate cloud infrastructure and repurpose tried and tested methods in their efforts. These shifts have been complemented by continuous updates to its malware arsenal, including a Python script ("kube.py") that's specifically used after breaching Kubernetes environments. While earlier versions of the script focused on propagation and setting up persistence, new variants observed as recently as March 2026 began to incorporate wiper-like functionality. This destructive code path checked whether the victim system was configured for the Iran timezone and, if that's the case, fired a DaemonSet that wiped every node in the cluster via a wiper not-so-subtly named Kamikaze. On Kubernetes nodes located outside of Iran, it deployed the CanisterWorm backdoor. For non-Kubernetes Iranian systems, the malware executed a "poison_pill()" routine to erase the entire file system. "Whether this continuity reflects a direct rebrand, a shared operator set, or close collaboration between historically related actors cannot be determined with 100% certainty," Oligo said. "What the evidence does demonstrate is that TeamPCP represents the continuation of an existing operational ecosystem rather than an entirely new threat actor that appeared in late 2025."
thehackernews.comAug 7, 2026extracted
ChainDrop: Inside a Self-Propagating npm Worm
A self-propagating npm worm nicknamed ChainDrop infected over 400 packages that are collectively downloaded hundreds of millions of times each week. This includes malicious versions of widely used packages such as keyv and cacheable-request. Unit 42 has unique observations of this attack. The attackers behind ChainDrop potentially exposed developer workstations, continuous integration (CI) pipelines, cloud environments and downstream software users across a large number of organizations. Once installed, ChainDrop steals: Cloud credentials npm and GitHub tokens SSH keys Other sensitive developer data It can also extract temporary credentials from GitHub Actions runner memory and use stolen npm publishing tokens to infect and republish additional packages while preserving their legitimate functionality. We have observed active attempted operations, which were detected out of the box by our existing products. During our investigation into this attack, we identified 453 public GitHub repositories across five accounts matching the worm’s exfiltration patterns. We also detected ChainDrop execution across 10 distinct environments. At the time of publication, these repos were removed. We have deobfuscated the malware and identified: Persistence through developer and AI coding tools Blockchain-based command-and-control (C2) resolution Its ability to execute additional attacker-supplied code Additionally, late on Aug. 4, 2026, we observed the adversary silently reconfiguring the worm's entire C2 infrastructure through a single Ethereum transaction, without requiring any update to the deployed malware. This attack is the latest in a series of threats to the security of the npm ecosystem. Unit 42 recommends: Identifying installations of affected npm package versions Removing affected package versions Investigating developer workstations and CI runners for signs of compromise Reviewing unexpected npm publishing and GitHub repository activity. Revoking and rotating potentially exposed npm, GitHub, cloud, SSH and automation credentials. Removing identified persistence mechanisms Blocking both the domain-based and GitHub-based exfiltration channels The Koi Agentic Endpoint Security risk engine flagged the malicious package activity as the attack unfolded. Cortex XDR detected and alerted on the worm’s execution using out-of-the-box behavioral detections. Palo Alto Networks customers can use Koi Agentic Endpoint Security to help identify and control malicious packages across developer endpoints. The Cortex AgentiX Threat Intel agent can help allow analysts to extract, enrich, and search IoCs using natural language to quickly determine organizational impact. Cortex Cloud Endpoint Protection leverages AI-enabled analytics to help detect and prevent threats targeting Linux endpoints, containers, and associated cloud IAM policies. Cortex XDR and XSIAM provide behavioral detection, investigation and response that can help organizations address ChainDrop activity executing in development environments. Idira Secrets Manager and Secrets Hub eliminate hard-coded credentials from configure files and source code by automating zero-downtime rotation, and dynamically delivering just-in-time access to non-human identities across multi-cloud and DevOps environments. The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. We analyzed the contents from one of the infected packages to understand the full attack chain. The package contained the legitimate software development kit (SDK) code that a user would expect, including the source, dependencies and documentation. But it also contained small indicators of the ChainDrop worm: two extra top-level files and one lifecycle hook. The indicators of the worm can be subtle, as illustrated in the following example. One of the indicators is an infected npm package's package.json file containing code with the preinstall command, as shown in Figure 1. That preinstall line is the only modification the worm makes to this package's manifest. It points to setup.mjs, a dropper that checks whether Bun (a lightweight JavaScript runtime and package manager alternative to Node.js) is on PATH. It downloads Bun 1.3.13 from the legitimate Oven GitHub repository if it isn't present. Then it feeds Bun a 727 KB obfuscated JavaScript payload (math_init.js) compressed into two source lines. To be clear: Bun is not compromised. The attacker is using a legitimate runtime as a portable execution vehicle. The payload spawns a detached background process, sets _NODE_RUNTIME_INIT=1 to prevent recursive relaunch and lets the install finish cleanly. No errors. No warnings. Most developers would move on without noticing a key detail: The worm is already running. The worm detaches when it is not in CI. If it detects a CI environment it runs inline in the job instead, which means its own debug output lands in the workflow log. This is useful for defenders looking for indicators because the worm is chatty. One further gate runs before the worm engages in any collection. This gate is a locale check that, on a Russian-language host, prints “Exiting as russian language detected!” and exits cleanly. The worm spares those machines. The background payload begins a sweep of the infected machine to harvest credentials from the environment. These include the following categories: Cloud credentials: - Multiple major cloud infrastructure platforms - The worm queries metadata endpoints and token endpoints across both compute instances and container services to harvest temporary identity and access management (IAM) role credentials, extending scope to short-lived identity tokens used by automated integration runners Multiple major cloud infrastructure platforms Developer tooling: - Docker and Helm configurations - Git credentials - Mount listings - npm and GitHub tokens - Poetry and PyPI credentials - RubyGems tokens - SSH keys - Terraform state - Vault tokens AI tools: - AI-assisted coding tools - Cloud-based development platforms - Open-source coding assistant configurations and authentication artifacts Everything else: - .env files - .netrc - Application configuration scattered across the home directory - Bitcoin and Electrum wallet files - Jenkins encrypted credential material - Kubernetes service-account tokens and kubeconfigs - Shell histories ChainDrop harvests credentials, but also a wide variety of other information about the systems and environment it’s running on. Some of the information stolen is vital for the worm’s survival. The npm and GitHub tokens it finds are what it needs to keep spreading. An embedded Python helper hidden inside an encrypted blob in the payload locates the Runner.Worker process on GitHub Actions runners, opens /proc/ /maps and /proc/ /mem, and searches live process memory for OpenID Connect (OIDC) tokens and runner secrets. The flow of this GitHub Actions runner memory scraping is illustrated in Figure 2. Rather than waiting for a file to be written to disk, the worm searches memory. In the process, it captures secrets that may have been designed to vanish when a job finishes. Organizations should be aware that CI runners are credential targets and can be exfiltrated through attacks on process memory. The worm establishes several persistence mechanisms, but two of them deserve special attention: Cross-linked persistence through VS Code and Claude Code A latent capability for OS-level persistence It writes a .vscode/tasks.json file with a task labeled Environment Setup and sets it to run when the folder opens — meaning it executes automatically whenever a developer opens the project in VS Code. That task runs node .claude/setup.mjs, a copy of the dropper that is byte-identical to the setup.mjs shipped in the package itself. It also writes a .claude/settings.json file with a SessionStart command hook, meaning it executes whenever Claude Code starts a session in the project. That hook runs node .vscode/setup.mjs, a second copy of the same dropper. Figure 3 shows the cross-linked persistence through both .vscode/tasks.json and .claude/settings.json files. Neither file triggers the other. Each one runs the dropper copy sitting in the other's directory, and the actual trigger in both cases is a developer action: opening the folder, or starting a Claude Code session. Cross-referencing is a naming trick that makes each artifact look like it belongs to the other tool. The payload is only ever written as .claude/math_init.js, and setup.mjs resolves math_init.js relative to its own location. .vscode/setup.mjs goes looking for a .vscode/math_init.js that the malware never dropped. In this build, only the VS Code path reaches a payload at all. The full set of dropped files is: .claude/math_init.js .claude/settings.json .claude/setup.mjs .vscode/setup.mjs .vscode/tasks.json Deleting either directory outright breaks both paths. However, defenders should remove all five files to be sure the worm is disabled. The worm also carries an installer for a macOS LaunchAgent (com.user.gh-token-monitor) and a Linux systemd user service (gh-token-monitor.service). In this sample, the installer was decrypted but never invoked. The routine that pipes it to bash has no call site, so treat OS-level persistence as latent capability, not observed behavior. The attacker is turning a trusted developer and AI-tool configuration into execution infrastructure. These aren't files most developers think to audit. Once the worm has an npm token, it: Identifies every package the account can publish Downloads or reconstructs each package Adds preinstall: node setup.mjs to the package.json file Writes the dropper (setup.mjs) and the obfuscated payload (math_init.js) Increments the patch version Republishes the infected package as the current npm package The infected package still works. The original source code is intact. As in the sample we analyzed, the only additions are the two top-level files and the lifecycle hook. The worm also plants a .github/workflows/codeql_analysis.yml file that serializes ${{ toJSON(secrets) }} and uploads it as an Actions artifact, another path to exfiltrate repository secrets. And it creates public repositories under the victim's GitHub account with the description Shai-Hulud: Here We Go Again and Dune-themed names, using them as an additional exfiltration channel. Everything above is a relatively loud and more obvious propagation path. There is a second typosquatting method that is much quieter and it only appears in a single place. Before collecting anything, the worm checks three environment variables. If these three variables are set: GITHUB_ACTIONS GITHUB_REPOSITORY to contain /opensearch-js GITHUB_WORKFLOW_REF to contain release-drafter.yml The worm runs a static routine of republishing the repo and exits. No collection takes place. Also, If the worm is placed in a repo that contains /opensearch-js, but does not contain release-drafter.yml, it exits and steals nothing at all. It stays silent in the runs a maintainer is most likely to be reading. Inside this second method, the worm does not need a stolen npm token. It asks the runner for an OIDC token with the audience npm:registry.npmjs.org and trades it at npm's own trusted-publishing exchange endpoint for a real publish credential. The repository's legitimate release identity becomes the attacker's. Then it modifies the package, and not the way it modifies everything else. This path never touches scripts. It downloads the latest @opensearch-project/opensearch tarball, bumps the patch version and adds one line to the package.json file shown below in Figure 4. The dependency name typosquats the project's own @opensearch-project scope and points at a pinned commit of the project's own repository. In a diff it reads like an internal helper. Detections built around preinstall hooks could easily miss it. And then the worm signs the result. Before publishing, the worm: Requests a second OIDC token (audience sigstore this time) Obtains a Fulcio certificate Builds an in-toto SLSA v1 provenance statement over the tarball's SHA-512 hash DSSE-signs it with an ephemeral P-256 key Uploads the entry to the public Rekor transparency log Attaches the bundle to the publish as - .sigstore Logs the resulting search.sigstore.dev URL as it goes This is not forged provenance. The attestation says the tarball was built in that repository by that workflow, and that is true. That breaks a control many teams are currently leaning on. Given the reality of today’s npm supply chain threats, a package having valid npm provenance does not mean the package is clean. It only means the tarball came out of the workflow named in the certificate. If that workflow is running attacker code, valid provenance is what you should expect to see. Pivot on the Rekor log index and the workflow identity inside the certificate, not on whether the signature checks out. We did not observe this path execute, and it cannot execute anywhere except in release-drafter.yml inside the opensearch-project/opensearch-js workflow. But it is fully implemented, reachable from the payload's main entry point, and it names its target in cleartext once the string layers come off. This repository is not typosquatted. The typosquat is the injected dependency name @opensearch/setup, which imitates the real @opensearch-project scope. The worm doesn't contain a hard-coded C2 domain. Instead, it calls an Ethereum smart contract to ask where to send stolen data. The contract sits at 0xE1f2395ee43e45A1556EC6438a88c31B83493103. This contract is a small StringListStore with three functions: return all domains, return owner and an owner-only setter. It emits no events, so domain rotation is a silent state write. Defenders who block today's domain may not notice when the operator changes it unless they're polling the contract. The worm rotates through roughly 60 public Ethereum RPC endpoints until one answers, making it resilient to any single provider blocking the request. When the contract was first configured, the operator wrote three domains: npm-cache[.]com pypi-get[.]com js-mirror[.]com Two hours and 35 minutes later, they replaced the list with only npm-cache[.]com. As of our analysis, that's still the active C2. If contract-resolved domains fail, the worm falls back to searching GitHub commits for the marker thebeautifulmarchoftime, expecting a signed record containing a backup domain. During our query, the fallback was unarmed. No valid operator record existed. However, the mechanism is built and waiting. The primary C2 domain, npm-cache[.]com, sits behind an edge computing and reverse-proxy service, so its published addresses are shared edge addresses rather than attacker-owned hosts, so block on domain or SNI. Blocking these IP addresses will not reach the origin and will affect unrelated traffic. After sending stolen data, the worm reads the HTTP response, parses it as JSON and evaluates whatever comes back. The JavaScript code to accomplish this is shown below in Figure 5. There is no fixed second-stage payload baked into the worm. The operator chooses the next stage at request time. Because each exfiltration request includes a host-derived UUID, the response can be targeted per victim and never written to disk. During our analysis, we sent a correctly formatted synthetic envelope using the worm's exact encryption scheme with dummy data to the live C2 endpoint. The server returned an HTTP 200 OK with an empty body. No code field was served to our probe. That means the remote code execution (RCE) channel was either disarmed at test time, selectively gated on victim attributes or asynchronous. Stolen data is JSON-serialized, gzipped, encrypted with a random AES-256-GCM key and wrapped with RSA-OAEP-SHA256 using an embedded public key. The worm sends the code shown below in Figure 6. Everything goes to hxxps://npm-cache[.]com:443/router over TLS. Network capture can prove that data left the machine and estimate its volume, but recovering the plaintext requires the operator's private RSA key. Only the domain-based sender evaluates returned code. Blocking the domain prevents an arbitrary RCE stage if the functionality is enabled. But the GitHub fallback can still exfiltrate data through victim-owned repositories, which means full containment requires addressing both channels. There is a third situation that we describe in this section, and it is the strangest one. When the GitHub sender carries a stolen token, the worm Base64-encodes that token twice and makes the result the commit message, prefixed with a fixed marker: IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients A separate routine in the same payload searches GitHub's commit API for that marker, double-decodes every match and keeps any token that passes a repository-scope check. One victim's stolen credentials become a usable resource for every other running copy of the worm. Despite the claims made in the marker, defenders should grep for it. It is long enough and strange enough that a full match is highly unlikely to be a false positive. A live hit means a credential is sitting in a public commit and needs revoking. The three C2 domains were registered through one registrar within eight seconds of each other on May 22, 2026: js-mirror[.]com - 13:40:28 UTC npm-cache[.]com - 13:40:32 UTC pypi-get[.]com - 13:40:36 UTC All three use the same nameservers. Fourteen minutes and 23 seconds after the last registration, FixedFloat transferred 0.01805723 ETH to the operator's wallet (0x55F9780e…f31cD). Three days later, on May 25, the wallet deployed the Ethereum resolver contract, wrote all three domains into it, and 2 hours and 35 minutes after that narrowed the list to just npm-cache[.]com. The next morning it transferred 0.00436 ETH to a Binance-labeled deposit address. The accounting reconciles to the wei. A timeline showing the deployment of the campaign infrastructure is shown below in Figure 7. FixedFloat is a shared exchange wallet with millions of transactions. This wallet tells us the funding rail, not the operator's identity. The Binance deposit address is the strongest identity pivot. On Aug. 4, 2026, the attacker executed an on-chain transaction 0xc55920f1bd0531b6738153068a666c080ddded47e6256f1fd980d51c0b507c91 to modify the StringListStore in smart contract 0xE1f2395ee43e45A1556EC6438a88c31B83493103, rotating the active C2 domain from npm-cache[.]com to a newly registered domain, awqhnjewqjkl[.]icu. The transaction was submitted by wallet 0x55F9780ef31cD, the same wallet that originally deployed the C2 smart contract on May 25, 2026. The new domain awqhnjewqjkl[.]icu was registered via NameSilo, LLC at 15:15:26 UTC on Aug. 4, 2026, and was operationally active within the hour as the earliest observed connection observed by Unit 42 researchers occurred at 16:10:03 UTC. The domain exhibits characteristics consistent with domain generation algorithm (DGA) output: a randomized 12-character string on the .icu top-level domain (TLD), flagged as DGA by the VirusTotal community. This represents a shift from the previous C2 domain npm-cache.com, which used a naming convention that mimicked a developer ecosystem and was registered through a different registrar (Tucows/OpenSRS). Despite the change in registrar and naming convention, both awqhnjewqjkl[.]icu and npm-cache[.]com are proxied through Cloudflare's cloud delivery network (CDN) infrastructure. Both domains serve the identical Cloudflare default CDN-CGI stylesheet d30b4ea6f68456672f5abb35e9dcf7d54226372b66e9d60a7ee26b7a52568e74, confirming shared use of the Cloudflare proxy layer. The new domain was issued a TLS certificate by Google Trust Services (WE1), which is valid from Aug. 4–Nov. 2, 2026, with Subject Alternative Names (SAN) covering both awqhnjewqjkl[.]icu and *.awqhnjewqjkl[.]icu. Within approximately 19 hours of the domain becoming active, we witnessed network traffic to victim environments. The affected infrastructure spans four continents: North America, Europe, Asia and Africa. The destination IP addresses for this C2 domain include 104.21.91[.]101 and 172.67.215[.]154. The geographic and organizational breadth of these connections is consistent with the indiscriminate, worm-driven propagation model of ChainDrop. This C2 rotation demonstrates the adversary's ability to silently reconfigure the worm's entire C2 infrastructure through a single Ethereum transaction, without requiring any update to the deployed malware. Monitoring the smart contract for future setStrings() calls would provide early warning of subsequent domain rotations. Multiple indicators point to this being the Shai-Hulud toolchain documented by JFrog: The PBKDF2-based string decoder The Bun 1.3.13 pin The _NODE_RUNTIME_INIT detached-relaunch pattern The self-applied Shai-Hulud: Here We Go Again marker The npm self-propagation and GitHub exfiltration architecture However, these indicators don’t prove the same attackers are behind the campaign. Because the Shai-Hulud source was published in May 2026, the implementation can be reused by anyone. This sample also mixes characteristics that don't match any previously published variant: Public victim-owned exfiltration repositories with Dune-themed names Ethereum-based domain resolution, thebeautifulmarchoftime commit-search fallback A Russian-language exclusion check A repository-gated npm trusted-publishing path that mints genuine Sigstore provenance preinstall delivery rather than the binding.gyp technique reported in earlier waves The ChainDrop worm is clearly part of the Shai-Hulud code lineage. However, we cannot yet say whether it's operated by the group known as TeamPCP, or by another group adapting the published toolkit for their own purposes. We detected ChainDrop operations across 10 distinct environments using out-of-the-box XDR detections focused on JavaScript runtime events. In one instance, as illustrated in the process execution in Figure 8, the threat activity originated within a developer's VS Code environment. The threat actors leveraged Bun to execute the malicious payload Math_Symbol.js from within the cacheable node modules directory. This script then spawned cmd.exe to invoke gh auth token to capture the user's GitHub authentication credentials. The 727 KB payload was protected by three nested layers of obfuscation and encryption. We broke through all of them. No unexplained blob remains in the sample. Layer 1 used Base91 encoding with 73 function-specific alphabets and a 14-position array rotation. We recovered 4,613 hidden string entries. Layer 2 used a custom byte-permutation cipher built on PBKDF2-SHA256 with 200,000 iterations and seeded Fisher-Yates shuffles. We recovered 727 additional hidden strings. Layer 3 used AES-256-GCM encryption plus gzip to protect 10 large encrypted blobs. These blobs contained: Bash and Python helpers Persistence installers The GitHub Actions memory scraper Malicious workflow templates VS Code and Claude persistence files RSA public keys Additional dropper copies These three layers are shown below in Figure 9. During our analysis, at approximately 12:20 UTC on Aug. 4, 2026, we searched GitHub for public repositories matching the worm's exact exfiltration marker: the description Shai-Hulud: Here We Go Again. We found 453 public repositories across five accounts. The earliest was created on May 11. The newest had been created roughly 25 minutes before our query. The names followed the pattern that matched the worm's Dune-themed generator exactly, with combinations like sardaukar-futar-421 and harkonnen-ghola-669. These five accounts are candidate victim accounts, not confirmed victims. The 453 repository counts might be only a starting point for possible compromises. In addition to public matches, there may be private repositories compromised as well. But the naming, description and creation patterns match the worm's behavior, and new repositories were still appearing while we watched. Three accounts held most of the total repos that we discovered. The attackers are not only actively compromising repositories, they are also rapidly releasing new versions of compromised packages. We analyzed one compromised package, but then noticed that a newer version of the package had landed six minutes after the compromised package. Another landed 70 minutes after that. The threat actors are actively, and rapidly, creating new repositories, versions and patch numbers, which will propagate the worm more efficiently. Because CI/CD pipelines are often configured to pull the latest patch or version, if there are several rapid fire versions, and they are compromised, the CI pipelines are more likely to grab an infected package. Defenders may not be taking the most effective approach to removing the worm’s infection. It is critical to ensure poisoned packages and their files are fully removed from potentially compromised systems. Unit 42 researchers found that a previously compromised system was rolled back to the latest tag pointing at the latest clean version. This fixed the tagging issue. However, it didn't fix the poisoned lockfiles, caches, mirrors or tarballs already sitting in a CI image. Even after updating the latest tag to point to a secure version, machines that installed the package during the compromise will not automatically receive the fix. Because lockfiles retain the compromised version, these systems remain vulnerable until administrators actively clear the lockfiles and fetch the updated release. Assume the potential impact is wider than what we know now. The worm attempts to republish itself through packages writable by compromised npm tokens. If a developer installed an affected release, enumerate every package their npm credentials could modify. Add npm-cache[.]com, pypi-get[.]com and js-mirror[.]com to DNS and TLS SNI blocklists. Prefer sinkholing over an HTTP block page, because the worm treats HTTP 400 and 404 as a healthy C2 response. Monitor the resolver contract for domain changes. Revoke or rotate npm tokens, GitHub PATs and deploy keys, cloud credentials, Kubernetes service-account tokens, Vault tokens, SSH keys and AI-provider credentials accessible to confirmed infected hosts. Treat CI runners as potentially compromised if the worm executed there. Search accessible repositories for: .vscode/tasks.json invoking .claude/setup.mjs .claude/settings.json invoking .vscode/setup.mjs .github/workflows/codeql_analysis.yml containing toJSON(secrets) Math_Symbol.js math_init.js setup.mjs router_runtime.js Although the installer was not invoked on the analyzed main execution path, search for: ~/Library/LaunchAgents/com.user.gh-token-monitor.plist ~/.config/systemd/user/gh-token-monitor.service ~/.local/bin/gh-token-monitor.sh ~/.config/gh-token-monitor/ Look for HTTP GET or POST requests to /router on the three C2 domains, Ethereum JSON-RPC eth_call requests targeting 0xE1f2395ee43e45A1556EC6438a88c31B83493103, and GitHub commit searches containing thebeautifulmarchoftime or IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients. Search accessible repositories for commit messages containing IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients, and for the dead-drop record prefix thebeautifulsnadsoftime. A match on the first is a leaked credential requiring immediate revocation. A match on the second is a planted backup C2 domain. Compare recently published patch releases for new preinstall hooks, replaced scripts objects, setup.mjs files and large minified JavaScript bundles. Do not scope to listed packages. The worm is designed to spread to unrelated packages writable by stolen tokens. Here is a practical playbook for AppSec engineers and developers: Bind authentication to the workload: The stealer targeted HashiCorp Vault tokens alongside npm, GitHub, AWS and Kubernetes credentials. A vault does not help when the token authenticating to it is a bearer string in a dotfile. Use credentials bound to the workload itself, such as mutual TLS with a SPIFFE identity, a cloud IAM role, or a projected service account token with an audience claim, so replay from attacker infrastructure fails. Use ephemeral CI runners: Persistent self-hosted runners accumulate credentials and caches across jobs that often belong to different teams, so one poisoned install contaminates everything that runs after it. Single-use runners limit exposure to one job. Plant canary credentials: Use decoys produce high-confidence signals with low false positives. Place non-functional keys in ~/.aws/credentials, ~/.npmrc, and an .env file across build images and workstations, then enable high alert on any use. Egress filtering in CI/CD: Most npm-based malware attempts to send ~/.npmrc tokens or ~/.ssh keys to a C2 server. Apply strict egress network policies to your CI runners. Only allow connections to your private registry and known deployment targets. The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these issues across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation. ChainDrop demonstrates how a compromised open-source package can become an entry point into developer workstations, CI pipelines, cloud environments and the broader software supply chain. By stealing publishing credentials and automatically republishing infected packages, the worm can continue spreading through trusted dependencies while leaving their legitimate functionality intact. Its ability to extract ephemeral credentials directly from CI runner memory also means that investigations limited to files stored on developer endpoints may miss critical exposure. Unit 42 recommends: Identifying installations of affected npm package versions Removing affected package versions Investigating developer workstations and CI runners for signs of compromise Reviewing unexpected npm publishing and GitHub repository activity. Revoking and rotating potentially exposed npm, GitHub, cloud, SSH and automation credentials. Removing identified persistence mechanisms Blocking both the domain-based and GitHub-based exfiltration channels Palo Alto Networks customers are better protected through the products described below. Palo Alto Networks and Unit 42 will continue monitoring this campaign for changes in infrastructure, new affected packages and evidence of additional activity, and we will update this threat brief as relevant information becomes available. Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat. If you think you might 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 The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known C2 domains associated with this activity as malicious. Koi Agentic Endpoint Security is designed to help discover every AI artifact and AI agent’s activity across the agentic endpoint, assess its risk, enforce prevention & runtime controls, and remediate violations. Security analysts can use natural language to prompt the Cortex AgentiX Threat Intel agent to extract indicators of compromise (IoCs) from this threat brief. Customers can then enrich the indicators, check for sightings in their Cortex tenant and related alerts and provide a summary of the impact to the organization. Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. Specifically, we observed out-of-the-box prevention on Windows via Behavioral Threat Protection. In addition, as part of our continuous cross-platform threat research, targeted behavioral protections for macOS and Linux environments have also been deployed in content version 2370-39889. We advise customers to upgrade agents to supported versions and the latest content update to receive the best protection Cortex Cloud Endpoint Protection can help protect organizations from threats expressed within this article. Cortex Cloud 2.1 can detect and prevent malicious operations using behavioral and AI-enabled analytics to detect when Linux endpoints, including containers and virtual machines, are targeted. Additionally, it can detect when cloud platform IAM policies associated with those targeted endpoints are being misused and alert teams when assets are vulnerable to these threats. Palo Alto Networks Software Supply Chain Security, integrated into Cortex Cloud, helps provide comprehensive visibility across the entire development ecosystem by tracking developer tools, code identities, registries and SBOMs. The solution can effectively harden development pipelines, and helps enforce out-of-the-box security policies to prevent unauthorized tampering or malicious code injection. By automating compliance reporting and governance, it can better empower organizations to mitigate application risks early and deploy secure code with confidence. Idira Secrets Manager limits blast radius by dynamically injecting them into build steps or local environments at runtime via API, CLI, or container sidecars, avoiding long-lived static configuration files on disk. By pairing Idira Privilege Cloud with Idira Secrets Manager, raw credentials bypass environment variables and process memory entirely. Secretless Manager proxies outbound connections to databases, cloud APIs, and registries, injecting credentials directly into the network stream on the fly. When supply chain worms scan your build runners, there is simply nothing in memory to steal. Idira Secrets Manager, integrated with Idira Privilege Cloud, handles automated policy-based rotation of credentials and enforces short lived secrets. Secrets requested by build pipelines are dynamically generated or rotated immediately after job completion. Math_Symbol.js / math_init.js: 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc setup.mjs (First variant): 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 setup.mjs (Second variant): fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb setup.mjs.malicious (Variant of setup.mjs based on TLSH pivot): b27b82afa5f15512f3856e549fb83d873fd0049759a4b62ce64c8d7d4dc2c678 awqhnjewqjkl[.]icu - new C2 domain pulled from Ethereum contract npm-cache[.]com - active during analysis pypi-get[.]com - historical C2, returned from the Ethereum contract in the past js-mirror[.]com - historical C2, returned from the Ethereum contract in the past hxxps://npm-cache[.]com:443/router hxxp://awqhnjewqjkl[.]icu/cdn-cgi/rum? Resolver contract: 0xE1f2395ee43e45A1556EC6438a88c31B83493103 Changed C2 Transaction: 0xc55920f1bd0531b6738153068a666c080ddded47e6256f1fd980d51c0b507c91 Owner wallet: 0x55f9780e1492344b7417fa723aedc4d0b97f31cd Binance deposit pivot: 0x35477b7b2df3174B9FE8A681750A7E3fbA20F39B Getter selector: 0x53ed5143 Setter selector: 0xd3c159e5 Repository description: Shai-Hulud: Here We Go Again Commit search token: thebeautifulmarchoftime Signed record prefix: thebeautifulsnadsoftime Dune-themed name terms: sardaukar, mentat, fremen, atreides, harkonnen The sample embeds an installer for these artifacts, but we did not identify a call site on its main execution path: ~/.local/bin/gh-token-monitor.sh ~/.config/gh-token-monitor/ ~/Library/LaunchAgents/com.user.gh-token-monitor.plist ~/.config/systemd/user/gh-token-monitor.service A list of compromised packages is available at a page on our GitHub repository.
unit42.paloaltonetworks.comAug 6, 2026extracted
Automate certificates with ACME support in AWS Certificate Manager
Automate certificates with ACME support in AWS Certificate Manager Customers tell us that managing TLS certificates at scale is one of their biggest operational concerns. The Certification Authority Browser Forum (CA/Browser Forum) has mandated a phased reduction in maximum certificate validity for public certificates. By March 2027, the maximum validity drops to 100 days. By March 2029, it lasts for 47 days. For an organization managing 1,000 certificates, the final transition means roughly 30 renewal events every day. Renewal and rotations of renewed certificates at that cadence isn’t something manual processes or ticket-driven workflows can sustain at scale. We recently announced Automated Certificate Management Environment (ACME) protocol support in AWS Certificate Manager (ACM). With this launch, you can use the ACME clients your teams already know, including popular open source tools like certbot, cert-manager, acme.sh, and win-acme, to automate public certificate issuance and renewal for your infrastructure. Customers that are using third-party certificate authorities (CAs) can point their existing ACME-compatible clients at ACM instead of their current CA, with minimal reconfiguration. This applies whether it’s running on Amazon Web Services (AWS), on premises, or in a hybrid environment. Certificates created through ACME are registered in ACM, giving you a unified view of your entire certificate inventory. This post covers how the feature works, how to get started, and the controls and best practices to help you manage certificate issuance at scale. Background ACME is an open source protocol that automates the process of verifying domain ownership and issuing certificates and has become a standard mechanism for certificate automation. While ACM has long provided managed certificate issuance and renewal for AWS-integrated services such as Elastic Load Balancing (ELB), Amazon CloudFront, and Amazon API Gateway, many customers also need to automate certificates for their own infrastructure, including servers they manage in their data centers, Kubernetes clusters, Internet of Things (IoT) fleets, and hybrid environments. Until now, those customers had to turn to external providers. This launch brings the ACM automation model to that same infrastructure, using the standard ACME protocol with AWS managed certificate endpoints. How it works The feature introduces a new centrally provisioned and managed resource type: the ACME endpoint. Each endpoint is an AWS resource with a unique ACME directory URL and AWS Identity and Access Management (IAM)-based access controls. You create and manage endpoints through the ACM API or AWS Management Console, and point your existing ACME clients at the endpoint URL. Certificates issued through your endpoint are automatically registered with ACM, appearing in your certificate inventory alongside certificates created by the RequestCertificate and ImportCertificate API calls. The architecture separates into two planes. In the control plane, PKI administrators use ACM APIs to create ACME endpoints, pre-approve the domains an endpoint is allowed to issue for, and generate external account binding (EAB) credentials. In the data plane, ACME clients register with an endpoint using EAB credentials and request certificates for domains the administrator has already validated. This architecture is how we provide customers the ability to scale. Instead of each client proving domain ownership on every request, a principal with appropriate ACM permissions (typically your PKI administrator) validates domains once at the endpoint level, and then application owners don’t need DNS credentials to get a certificate. Adding to the data plane, EABs control client access to the endpoints. Each EAB is bound to an IAM role that controls what certificate operations the ACME client can perform, and credentials you generate in ACM are distributed to authorized ACME clients. An ACME client authorized for one endpoint can’t use a different endpoint. This creates security boundaries between environments. For example, a client authorized for your development endpoint can’t obtain certificates from your production endpoint. Figure 1 shows the ACME request flow through ACM. An ACME client authenticates to an ACME endpoint using EAB credentials. The endpoint routes certificate orders to Amazon Trust Services for issuance. Issued certificates are registered in ACM inventory, where Amazon EventBridge and AWS CloudTrail provide expiration alerting and audit logging. Getting started Getting started with the new ACME feature in ACM is straightforward. Use the following steps to create your first ACME-generated certificate. Prerequisites An AWS account with permissions to create and manage ACM resources An ACME client installed on your infrastructure (for example, Certbot, cert-manager, acme.sh, or others) AWS Command Line Interface (AWS CLI) installed on your device (see this blog post for the console equivalent) Amazon Route 53 hosted zone for your domain, or the ability to create a CNAME record with your DNS provider Step 1: Create an ACME endpoint Before you can use ACME clients with ACM, you need to create an ACME endpoint. This endpoint provides the URL that your ACME clients will use to request certificates. Run the following command from the AWS CLI to create an ACME endpoint: Note the endpoint Amazon Resource Name (ARN) from the response. Run the following command to retrieve the endpoint URL, replacing the ARN with your endpoint ARN: Save the output of the ACME EndpointUrl : Step 2: Pre-approve a domain Before ACME clients can request a certificate, the administrator validates the domain using DNS once at the endpoint level. Use DomainScope to control exactly which certificate patterns are allowed: Enabling only ExactDomain restricts clients to that specific name, Subdomains enabled allows names likeapi.example.com , Wildcards enabled allows*.example.com . Leave a scope disabled to block that pattern outright, even if an otherwise-valid ACME request asks for it. For a production endpoint, consider enabling only ExactDomain and Subdomains and leaving Wildcards disabled for a stricter posture. If your domain is hosted in Route 53, specifying HostedZoneId lets ACM create the required CNAME record automatically. If your domain is hosted elsewhere, omit it and create the provided CNAME record manually with your DNS provider. Validation typically completes within a few seconds after the record is in place. You will receive the following response back: Step 3: Generate EAB credentials EAB credentials authenticate your ACME clients to your endpoint. Generate a unique set of credentials for each client or environment to maintain security boundaries. Run the following command to generate your EAB credentials, adjusting your expiration to fit your organization’s risk profile: Note the response from a successful invocation of the command Run the following command to retrieve the credentials. You’ll need these values for your ACME client configuration the next step. Save the KeyId andMacKey for the next step. Step 4: Configure your ACME client With your endpoint URL and EAB credentials ready, you can now configure your preferred ACME client. The following examples show configuration for two popular clients. As a reminder, the server information was retrieved in step 1, part 4 as the EndpointUrl. acme.sh: Certbot: After the initial registration, your ACME client handles renewals. Enterprise controls Other ACME alternatives can provide certificates but don’t give the same amount of control and governance for customers that need to scale their certificate environment. The following controls are available to help reduce risk across your organization. Domain validation Customers managing large numbers of domains told us they need a way to prevent unauthorized certificate issuance across their domain space. Domain validation gives you this control. For each domain you validate, you enable the certificate patterns it should be allowed to issue, whether it’s ExactDomain, Subdomains, or Wildcards. For example, if you validate internal.example.com and enable only Wildcards, an ACME client can request *.internal.example.com but a request for internal.example.com itself or api.internal.example.com is rejected. This enforcement happens at the endpoint level, before requests reach the ACM certificate authority, and you can validate multiple domains under a single endpoint, each with its own scope. Centralized certificate visibility Certificates issued through your ACME endpoints are registered with ACM. You can use the aws acm list-certificates command to see all your issued certificates. IAM authorization, CloudTrail audit logging and observability Endpoint management operations are authorized through IAM and logged to CloudTrail. You can use IAM policies to control which principals can create endpoints, generate EAB credentials, and manage domain constraints. Best practices For customers implementing ACME certificates for the first time, consider the following best practices for your organizations. Segment endpoints along organizational or environment boundaries The endpoint serves as a useful method of isolation for larger organizations. A large enterprise can create one endpoint per organizational boundary (business unit, subsidiary, or environment) instead of a single shared endpoint company-wide. Each endpoint has its own pre-approved domains and its own set of EABs, so a compromised credential in one business unit has no path to certificates in another. However, weigh this against your operational overhead as well. A reasonable starting point is one endpoint per environment (dev, staging, andprod) within a business unit, expanding to per-business-unit endpoints only where compliance or organizational requirements call for it. Manage EAB credentials securely Anyone holding a validKeyIdandMacKeyfor an endpoint can obtain certificates for any domain pre-approved on that endpoint, so these credentials deserve the same handling you’d give an access key. Avoid hard coding theMacKey where possible by using a secret store such as AWS Secrets Manager. Distribute it only to the ACME clients that you authorize to use the endpoint. Set the expiration of the EAB to an acceptable level. While EAB supports long-lived credentials, not all scenarios require an indefinitely long EAB. When creating the role for each EAB, adhere to concept of least privilege. Creating a role per EAB, rather than sharing a role across all bindings, can help reduce risk in your AWS environment. Audit CreateAcmeExternalAccountBinding andGetAcmeExternalAccountBindingCredentials calls in CloudTrail separately. Because retrieving the actual key material is a distinct API call from creating the binding, alerting on retrieval events is a stronger signal of real credential distribution than binding creation alone. Automate how EABs are associated with clients at runtime Generate a unique set of EAB credentials for each client or environment rather than sharing one binding across multiple ACME clients. As you begin to scale with multiple endpoints, usesome of the following patterns to reduce operational toil. Name each EAB and its bound IAM role after the client it belongs to (team, application, environment), so the binding’s purpose is obvious from DescribeAcmeExternalAccountBinding output alone, without cross-referencing a spreadsheet. Store each client’s KeyId andMacKey under a secrets path scoped to that client (for example, a Secrets Manager path per team and environment), and let the client’s provisioning pipeline retrieve its own credentials. In Kubernetes, use one ClusterIssuer or namespace-scoped Issuer per EAB rather than one shared issuer across teams. This keeps the client-to-EAB association explicit in cluster config, and lets you revoke one team’s access without touching anyone else’s. For ephemeral infrastructure (build agents, autoscaled fleets), provision EAB credentials as part of your infrastructure-as-code or continuous integration and deployment (CI/CD) pipeline instead of a one-time manual handoff, so credential lifecycle tracks infrastructure lifecycle. Monitor your deployment of ACME ACME’s power is through automation, and organizations should monitor their ACME usage for anomalies. Alarm on issuance failures, not just successes. At 45-day certificate validity, a silent renewal failure gives you far less runway to react than the months of time you might be used to with longer-lived certificates. Test renewal automation before you depend on it. Force a manual renewal against a non-production endpoint and confirm your client, monitoring, and on-call runbooks behave as expected, before the CA/Browser Forum’s shortened validity windows turn a failed renewal into a disruptive event for your organization. Availability and pricing ACME support in AWS Certificate Manager is available today in all commercial AWS Regions and will be available in AWS GovCloud (US), the China Regions, and the AWS European Sovereign Cloud partitions at a later date. See the ACM pricing page for more information on ACME pricing. Conclusion The phased reduction in certificate validity can’t easily be solved without automation. ACME support in ACM gives you that automation through a standard protocol and standard tooling, while keeping the visibility and governance controls your security teams rely on from ACM. To get started, see the AWS Certificate Manager documentation or follow the getting started guide. If you have feedback about this post, submit comments in the Comments section below.
aws.amazon.comAug 6, 2026extracted
Loading 40 more…