Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Now in Docker AI Governance: a single searchable record of every policy decision your agents trigger, streamed to the SIEM your security team already runs, so you can show what your agents did and what your policy stopped.
Today, Docker AI Governance now streams every policy decision in your organization into the SIEM your security team already runs, with a searchable record of all of it in Docker Cloud. You can see what your agents did, and what your policy stopped them from doing.
Enforcement is step one
When we launched AI Governance in May, our perspective was that controls have to live at the runtime layer where the agent actually executes, not as advisory rules a clever prompt can route around. Audit was one of the three layers we shipped on that principle, and the enforcement point has produced a structured event for every policy evaluation since day one.
Today, we’re making it easier to view and consume those events.
Why audit records matter
Security leads need to answer questions about agent behavior: what did that agent do, was it allowed, and which policy made the call.
Answering it should not require assembling evidence from machines they don’t administer. It should mean querying a system they already use. Increasingly it also comes first rather than after: security teams want a demonstrable audit record before they approve agent deployment at all.
What only the enforcement point can see
A policy decision has three outcomes. The action was allowed, it was denied, or it was held for a human.
A log collector can reconstruct the first one. Nothing outside the enforcement point can see the other two. A collector reads what an agent produced, so it never sees the tool call that was refused, the domain that was unreachable, or the credential that was requested and withheld. Those events leave no trace in output, because the process that would have produced the output never ran.
That is the difference between a record generated at the point of decision and logs gathered after the fact. A record of allowed actions shows that agents are active. A record of denials shows whether your controls are doing anything.
Audit Logs: Streamable to your SIEM tools
Audit logs are now available in Docker Cloud, and audit events can stream directly to your SIEM. Both are included with Docker AI Governance.
Audit logs in Docker Cloud. One searchable view for the whole organization, with 90 day retention and CSV export. Local disk delivery keeps working, and both modes can run at once.
Native SIEM streaming. Point Docker at your endpoint and forward audit records to the tools you already run, including Splunk, Datadog, Dynatrace, and Grafana.
Coverage
Records cover Docker Sandboxes policy decisions and sandbox session events, for users with an AI Governance license under an enforced organization policy. Other source records (MCP Gateway enforcement decisions, for example) will share records through the same schema as they become available, so coverage will expand without extra integrations on your end.
Records are metadata only. They never contain your prompt content, agent output, or parameter values.
What’s next
Records are step one.
Once every decision an organization makes about its agents lands in one place, the useful question stops being what happened and starts being what should change. That is the direction we’re building toward: a system that tells you when something is off and what to do about it. More on that soon.
Available today
Audit logs are live for organizations on Docker AI Governance with an enforced organization policy. Read more here.
AI is moving incredibly fast, and every security leader is feeling the pressure to keep up.
AI platforms like Claude, Codex and Cursor are already helping security teams write detections, investigate alerts, summarize incidents, and automate repetitive work. The conversation has evolved from whether AI belongs in the SOC, to where each type of AI delivers the most value.
With so many new AI products entering the market, it's easy to assume one tool can solve every problem. In reality, different types of AI are designed for different jobs.
Understanding that difference is what transforms AI FOMO into better security outcomes.
Attackers are already using AI to generate phishing campaigns, automate malware development, and move faster than ever before. At the same time, defenders are using AI to triage alerts, create detection rules, automate reporting, and simply reduce manual work in general.
The opportunity is enormous.
The challenge is deciding where each type of AI fits into the SOC.
Two kinds of AI, two different jobs
The easiest way to think about modern security operations is as three layers.
At the bottom are your existing security tools such as your SIEM, EDR, cloud security, identity platforms, email security, and everything else generating alerts.
In the middle is an autonomous AI SOC. Its job is to investigate every alert automatically, correlate findings across tools, apply organizational context, and most importantly, determine which alerts actually require human attention.
At the top are AI platforms like Claude, Cursor, and Codex. These are where analysts, detection engineers, and incident responders collaborate with AI to solve problems, write detections, create reports, hunt for threats, and make decisions.
These layers are all complementary and necessary for a successful SOC.
Why AI platforms like Claude shouldn't investigate every alert
AI platforms are incredibly capable, but they're designed to help people.
An analyst can ask Claude to explain suspicious PowerShell activity, summarize an investigation, draft a Sigma rule, or translate a detection into another query language. Those are excellent uses of AI.
But investigating thousands of alerts every day is a different challenge.
That kind of work needs an autonomous system that runs continuously, integrates with security tools, remembers organizational context, and investigates alerts around the clock without waiting for a human prompt.
Trying to use an AI platform as a 24/7 SOC investigator is a bit like asking a brilliant consultant to answer every phone call in a busy call center. The consultant is extremely valuable, but only when they're focused on the work that benefits from their expertise.
The tokenomics problem
There's another reason AI platforms aren't designed to investigate every security alert: economics.
Every investigation starts with context. An AI model needs endpoint telemetry, process trees, authentication logs, email history, threat intelligence, previous investigations, detection rules, and organizational knowledge before it can make a good decision.
Every piece of that context consumes tokens.
That's perfectly reasonable when an analyst asks Claude to help investigate a handful of incidents each day.
It becomes a very different equation when a SOC receives thousands of alerts every day.
Imagine using a large language model to perform a fresh investigation for every alert. Even if each investigation were relatively small, the organization would still be paying for tens of thousands of AI conversations every day, most of which would conclude that the alert is benign. As alert volume grows, the cost grows with it.
Enter the autonomous AI SOC.
Instead of treating every alert as a brand-new conversation with a large language model, a good AI SOC combines deterministic workflows, forensic analysis, organizational memory, cached context, and selective AI reasoning. Large language models are used where they add value, not for every step of every investigation.
The result is an architecture that can investigate every alert continuously while keeping costs predictable.
Using Claude to investigate every alert is a bit like using a Formula 1 car to deliver packages. It's an incredible piece of engineering, but it was designed for speed, not high-volume logistics. Enterprise SOCs need infrastructure built to handle enormous scale efficiently, with AI applied where it has the greatest impact.
The MDR reality
There's another practical challenge that often gets overlooked.
Many organizations don't operate their own SOC. They rely on a MDR provider to monitor their environment.
In those environments, the MDR typically owns the investigation workflow. They have the analysts, the case management system, the investigation history, and often the enriched telemetry collected during the investigation. The customer usually receives only the escalated incidents and periodic reports, not every piece of evidence gathered along the way.
That makes it difficult for an AI platform like Claude to independently investigate alerts, because it doesn't have access to the same information the MDR is using.
Even if an organization wanted to build its own AI-assisted investigation workflow, it would first need the raw alerts, telemetry, investigation artifacts, and historical context that often remain inside the MDR's platform.
AI platforms are incredibly valuable once information is available to them, but they can't reason over data they don't have.
This is another reason autonomous AI SOC are becoming an important architectural layer. They sit directly alongside the organization's security tools, investigate alerts as they arrive, retain organizational context, and make that knowledge available to both analysts and AI platforms.
Instead of replacing MDRs overnight, they give organizations a path toward owning their investigations, their institutional knowledge, and ultimately their security operations.
Investigating 100% of alerts?
Most security teams simply don't have the capacity to investigate every alert they receive.
As a result, they prioritize the highest-severity alerts while lower-severity alerts often receive less attention.
The problem is that severity doesn't always reflect risk.
But the answer isn't asking analysts to work harder. It's giving them more capacity.
An autonomous AI SOC creates that capacity by investigating every alert, not just the loudest ones, while escalating only the cases that truly need human judgment.
Where Claude and friends shine
Once an autonomous AI SOC has completed the investigation, AI platforms become even more valuable.
Instead of spending time gathering evidence from multiple consoles, analysts can use an AI platform to focus on higher-value work.
They can:
Ask questions about completed investigations.
Draft and refine detection rules.
Hunt for emerging threats.
Summarize investigations for stakeholders.
Generate incident reports.
Explore new hypotheses.
Make the final decisions on complex cases.
In other words, the autonomous AI SOC handles the grind of triaging endless alerts and repetitive investigation.
The AI platform helps people think, create, and decide based on everything the AI SOC has provided.
Better together
The biggest takeaway isn't that organizations need to choose between an autonomous AI SOC and AI platforms like Claude.
They need both.
One continuously investigates alerts across the environment.
The other helps security professionals work faster and make better decisions.
Together they create a model where machines handle repetitive investigation while humans focus on strategy, judgment, and continuous improvement.
Join Intezer's Co-Founder and CEO, Itai Tevet, and CMO Lital Asher-Dotan for a real conversation (not another stuffy webinar) about where AI actually fits in security operations today. With so many AI platforms competing for attention, Itai and Lital will cut through the noise and get specific about what to use where, based on real examples.
Three takeaways:
Why AI platforms like Claude are built to help people, not investigate every alert at scale
How the "tokenomics" of AI investigation change the math for high volume SOCs
Where an autonomous AI SOC and AI platforms complement each other
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/dG1Y4eS
via IFTTT
This article analyzes new attack classes against passwordless authentication, focusing on Google’s synced passkey ecosystem and the Cloud Authenticator used by desktop clients. The attacks demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts. We show how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys.
After decades of breaches and billions in losses, the attack vectors that defined the era of passwords and shared secrets are finally starting to fade. Passkeys replace passwords and traditional multi-factor authentication (MFA) with public-key cryptography, decreasing entire classes of attacks that have dominated the threat landscape for years.
With no shared secret to steal, reuse or phish, many of an attacker’s most reliable tools are becoming obsolete. This represents a significant disruption for the credential theft market.
Attackers, however, persist. They evolve, and defenders must prepare for a new generation of attacks. As passkeys become widely adopted and scale to billions of accounts, defenders must prepare for new attack surfaces, some of which we disclose in our research.
This article is part 3 in our series examining passkey adoption from a security perspective. If you haven’t read the previous parts, we recommend starting here:
Google’s synced passkey implementation is particularly instructive due to its scale and how it creates a higher standard for private key protection in two critical ways:
Private keys are generated and used within a cloud-enclave isolation environment
Hardware-backed, client-device-bound keys control access to cloud-based cryptographic operations, attesting to the user’s presence on a trusted device
This article builds on the architectural analysis from Part 1 and Part 2 of our previous articles in this series. We now shift from how passkeys are built and deployed to how attackers can misuse them.
We present three novel attacks that enable account takeover of passkey-protected accounts. Each attack challenges a different core assumption of passkey authentication security. When a client authenticates with a passkey, the following is expected:
For MFA, users must also unlock the device to verify biometric (i.e., something you are) or knowledge-based (i.e., something you know) authentication factors
Passkey private keys cannot be shared or copied
The Google documentation reflects these core assumptions, describing the passkey login process as a secure alternative to passwords (as shown in Figure 1).
Figure 1. Google documentation describes passkeys as requiring device access, device unlock, and non-shareable credentials.
Challenging these expectations is a category of attacks we've nicknamed Pass-ta-key. This playful, layered name blends the word passkey and the phrase “pass the key,” with a light nod to the concept of plate of pasta, illustrating how tangled this key implementation can get.
These attacks each expose a different weakness in practice:
Pass-ta-key attack: An attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction
Silver Pass-ta-key attack: An attacker deceives the Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication
Golden Pass-ta-key attack: An attacker can extract all synced passkeys in a form that allows them to be shared or sold on the credential black market
These attacks demonstrate how malware can exploit synced passkeys, even when providers add hardware-backed protections to secure credentials within the cloud authenticator.
Disclaimer: This research involved responsible and ethical security analysis. We responsibly disclosed all presented exploits.The cloud authenticator model is used by various passkey providers across multiple browsers and platforms. This work, however, focuses on Google Password Manager in Chrome on Windows, specifically on devices equipped with a Trusted Platform Module (TPM). All presented attacks rely on malware already existing on the victim’s device during the initial stage.
Stage Zero: Reconnaissance
Before attempting any of the attacks, the attacker needs visibility into how passkeys are used within the victim’s account. On a compromised endpoint, this visibility is readily available.
Chrome locally stores synced passkey data as part of its synchronization process. On Windows, Chrome persists this data as proto-encoded WebauthnCredentialSpecifics records, which represent synced WebAuthn credentials, within its sync database:
Accessing these records does not require elevated privileges. The records allow an attacker to enumerate where the victim uses passkeys, along with associated usernames, credential identifiers and the encrypted private key.
After identifying a service where the victim uses passkeys, an attacker can attempt to authenticate as the victim.
The primary challenge for attackers is bypassing the protection of the private key, which is used to sign authentication challenges. This private key is secured by a master key. While an encrypted version of this master key is stored on each client device, only the cloud authenticator can decrypt it.
Despite this security, the architecture remains vulnerable to exploitation. The following sections detail methods attackers could use to exploit system mechanisms, authenticate as the victim, and compromise passkey-secured accounts.
Device Identity Impersonation: The Pass-Ta-Key Attack
Our first attack is the most straightforward approach, which involves taking over a passkey-protected account by mimicking the behavior of Google Password Manager and Chrome during legitimate authentication. In a normal flow, Chrome sends a request to the cloud authenticator, signed using the device’s hardware-backed keys.
Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges.
To understand this, we focus on Chrome’s device identity key, which represents client device possession to the cloud authenticator. As previously explained (part 2:Login with Synced Passkey andDevice Key Signature), generating the required assertion involves signing data sent to the cloud authenticator using one of the device’s hardware-backed keys. This is the identity key or the user verification key (UV key).
Although both keys are hardware-bound, they are not accessed in the same way. For the identity key, Chrome creates the conditions that allow it to request a signature while running as a user without elevated privileges and without triggering device unlock protections.
On Windows, Chrome calls the NcryptCreatePersistedKey function without assigning a key name, making the TPM-backed key ephemeral and preventing it from being persisted to disk. Instead of storing the private key within the TPM, Chrome calls NcryptExportKey to export the key as an NCRYPT_OPAQUE_KEY_BLOB, which instructs the TPM to encrypt the private key using a TPM-resident key. The resulting blob is stored as wrapped_identity_private_key in the passkey_enclave_state file, making it available for future use on the same physical TPM.
Malware can extract this wrapped_identity_private_key from disk or Chrome’s memory. It can then invoke cryptographic operations using standard Windows Cryptography API: Next Generation (CNG) APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash), without elevated privileges, mimicking Chrome’s own actions.
Having established that malware can generate the required signature, we now detail the full Pass-ta-key attack flow (as shown in Figure 2). This flow allows a remote attacker with unprivileged malware on the victim’s device to authenticate as the victim.
Figure 2. Pass-ta-key attack flow.
The attack flow consists of the following phases:
After collecting the victim’s synced passkey records (Stage Zero: Reconnaissance), the attacker selects a targeted account and initiates a passkey login
The relying party responds with a fresh authentication challenge
The attacker initiates a WebSocket handshake with the Google Cloud Authenticator
Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request
The attacker sends an assertion request to the cloud authenticator, including the identity key signature
From the cloud authenticator’s perspective, the request appears to be a trusted device making a valid request, so it produces a valid assertion response
This assertion is then forwarded to the relying party, completing authentication and giving the attacker full control of the victim’s account
Video 1 demonstrates the attack as it would unfold in practice. (We have blurred the names of the relying parties to avoid naming.)
Video 1. Example of a successful Pass-ta-key attack.
As the video begins, the screen splits between the attacker's terminal and the victim's desktop. The video first shows the attacker establishing a command-and-control (C2) listener, passively waiting for victims to connect.
On the victim’s machine, the Trojan executes as a standard user, without elevated privileges. Once active, it collects the victim’s encrypted, synced passkeys and sends them back to the attacker’s C2 server. This provides visibility into the victim’s available passkeys.
The attacker selects a target, such as a messaging application account protected by a passkey, navigates to the application and chooses Login with passkey. The relying party then responds with a fresh authentication challenge.
Next, the attacker initiates communication with the Google Cloud Authenticator. After completing the handshake, the attacker triggers the Trojan to use the device’s identity key to sign the required data. Specifically, it uses the hash of the handshake combined with the hash of the serialized assertion request.
The attacker then attaches this signature to the request sent to the cloud authenticator. The cloud authenticator returns the requested assertion. The attacker forwards this valid assertion to the relying party and successfully logs in as the victim.
UV Flag: When MFA Depends on a Single Bit
The Pass-ta-key attack is effective when the relying party does not strictly require user verification. Many relying parties configure WebAuthn’s userVerification parameter as preferred rather than required to support diverse devices and user experiences, making them susceptible to this attack.
When a relying party explicitly requires user verification, one would expect the cloud authenticator to reject requests that are not signed using a key gated by PIN or biometric verification. Surprisingly, this is not the case.
The cloud authenticator returns a valid assertion regardless of whether the request was signed using the identity key or the UV key. The difference comes down to a single bit in the authenticator data, the User Verified (UV) flag.
When the assertion is signed using the UV key, this flag is set to 1. When it is signed using the identity key, the flag remains 0.
While the Pass-ta-key attack produces cryptographically valid assertions matching the relying party’s public key, our testing shows attacks typically fail when user verification is required because the UV flag remains unset. For example, when attempting the attack against a passkey-protected GitHub account, the attacker receives an error message, as shown in Figure 3.
Figure 3. Message from GitHub passkey login failure.
Although authentication is typically rejected when user verification is required, this behavior is not always consistently enforced across relying parties. In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag. This allowed the attack to succeed despite the absence of user verification.
The lack of validation effectively reduces the authentication process to a single factor. By compromising only the device identity key, the attacker is able to authenticate successfully and take over the account, even though MFA is required.
We reported this issue to the affected relying parties.
Video 2 demonstrates this behavior in practice on eBay. Although eBay sets the userVerification parameter to required, the demo recording shows a successful passkey login using the described technique, without any user interaction or additional authentication factors.
We captured this recording before eBay fixed the issue. Following our report, eBay addressed this verification gap and now properly validates the UV flag.
Video 2. Pass-ta-key attack succeeds despite the absence of user verification, even when the UV is required.
Pending Attacker: The Silver Pass-Ta-Key Attack
When an account is protected by stronger authentication requirements, such as for financial or federal identity systems, the attacker must also bypass user verification. This initially appears to be a significant challenge.
The cloud authenticator requires a message signed with the UV key to set the UV flag. Client interaction controls access to this key, as the OS validates the user via the same mechanism used for device unlock. Without escalating to system privileges or physical access to the victim device, an attacker has no apparent path to obtain such access.
Attackers can bypass this challenge through the following mechanism:
Instead of bypassing access to the UV key, the attacker invalidates the existing key registered in the cloud authenticator and registers a newly generated key under their control
Once the attacker-controlled key is registered, any message signed with it is accepted by the cloud authenticator as if the user had successfully performed device unlock
Figure 4 demonstrates the attacker-side authentication flow in the Silver Pass-ta-key attack, focusing on the authentication phase after the attacker-controlled UV key is registered.
Figure 4. Attacker-side authentication flow in the Silver Pass-ta-key attack.
This approach has important implications. It allows the attacker to fully automate authentication across all the victim’s accounts without human interaction, even where user verification is enforced. Furthermore, the attacker no longer needs live access to the victim’s device during authentication.
Unlike the previous attack, which required active malware on the victim’s device for each authentication, the Silver attack provides reusable access. This allows the attacker to access the victim’s passkey-protected accounts from their own environment, without requiring the victim’s device to be online or active. Ultimately, this enables account takeover across all passkeys associated with the victim without requiring elevated privileges.
Invalidating the Existing User Verification Key
To carry out this attack, the first objective is to invalidate the existing UV key associated with the target device. From the previous attack, we learned how an attacker can use unprivileged malware to sign attacker-controlled requests with the device identity key and send them to the cloud authenticator. The attacker can leverage this capability to issue a device/forget command on behalf of the victim. A simpler option is to directly delete the victim’s passkey_enclave_state file, as there are no built-in protections that prevent its removal.
Regardless of the method, the next time the user attempts to use a passkey, Chrome is forced to re-onboard the device. This occurs either because Chrome no longer has access to the device key or because the cloud authenticator no longer recognizes the device as registered.
Exploiting the Onboarding Flow
On Windows, device onboarding is only completed after the second use of a passkey on the same device. During the first use, Chrome begins onboarding with the cloud authenticator in the background while prompting the user to enter the Google Password Manager (GPM) recovery PIN.
If Chrome were to create the UV key at this point, it would also trigger a Windows Hello prompt, requiring the user to authenticate again using biometrics or a PIN. Since both steps may involve a PIN, presenting them back-to-back in the same flow can be confusing and lead to user errors. To avoid this, Chrome defers the creation of the UV key.
Instead, the device is initially registered in a uv_key_pending state. During this first interaction, the GPM recovery PIN satisfies user verification, and the actual UV key is only created and registered during the next passkey use, when the additional prompt is no longer needed.
After forcing the victim into this re-registration state, the attacker can exploit the uv_key_pending condition. In their own environment, the attacker generates an asymmetric key pair. They then send a device/add_uv_key command to the cloud authenticator, providing the attacker-controlled public key as the UV key.
The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware. As a result, the attacker-controlled key is stored alongside the legitimate device identity key:
devices[device_id]=
{
hw:identity_public_key,
uv:(Attacker-controlled)uv_public_key
}
From this point on, the attacker can use the forged UV key to request signatures for any passkey associated with the victim and obtain assertions with the UV bit set. This provides access to high-value accounts even when user verification is enforced and validated.
Stealing the Master Key: The Golden Pass-Ta-Key Attack
In this attack, the attacker effectively gains the cloud authenticator’s superpower, the ability to decrypt synced passkeys. This is particularly impactful because it undermines the intended protection mechanism.
The passkey’s private key is protected using a symmetric master key called the security domain secret (SDS). This master key is not directly accessible, it is stored on the device as an encrypted wrapped_secret. Only the cloud authenticator can decrypt this wrapped_secret using its device-specific key (wrapping_key) within its isolated environment, as noted in Figure 5.
Figure 5. Synced passkey decryption inside the cloud authenticator.
Figure 5. Synced passkey decryption inside the cloud authenticator.
This design aims to protect synced passkeys even if the client device is compromised. As Google noted in response to one of our vulnerability reports:
“The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available.”
The security of this model ultimately hinges on the protection of the 32-byte SDS. If an attacker is able to obtain the SDS, they effectively gain the ability to decrypt all synced passkeys for that account. This allows them to authenticate as a fully verified user and take over every service where the victim relies on passkeys.
Leaking the SDS
This secret should never be exposed to the client device, even during device loss or account recovery. However, we unexpectedly found the SDS present in Chrome’s logs during registration with the cloud authenticator, simply by opening chrome://device-log/FIDO, as noted in Figure 6.
Figure 6. The SDS (the passkey master key) is exposed in plaintext in the device log.
In the current Chrome implementation, every device joining or rejoining an account’s security domain retrieves the SDS from the recovery key store, Google’s Trusted Vault service. The cloud authenticator includes a mechanism that allows Chrome to facilitate the recovery flow where the key cannot be decrypted on the client device, however this mechanism is not used. Instead, Chrome recovers the SDS in an accessible form.
One possible explanation is needing to standardize the device join and recovery process across platforms. Unlike desktop environments, Google Password Manager on iOS and Android does not rely on the cloud authenticator and must obtain the master key to decrypt synced passkeys. As a result, Chrome appears to follow the same recovery model, even though the cloud authenticator could enable a more isolated approach.
Although Google removed this secret from Chrome’s logging output following our report, the SDS is still sent to the client and remains accessible in Chrome’s process memory. If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory.
The Golden Pass-ta-key attack allows full account takeover through the following steps:
The attacker forces Chrome to trigger a fresh onboarding using the same mechanisms as the Silver Pass-ta-key attack
The attacker monitors the system for the recreation or modification of the passkey_enclave_state
Once the file is recreated/modified, the attacker dumps Chrome’s process memory and extracts the SDS, which is temporarily present in plaintext
The attacker reads the WebauthnCredentialSpecifics records from Chrome’s sync database (Stage Zero: Reconnaissance)
Using the extracted SDS, the attacker decrypts the encrypted fields in each record and recovers the corresponding passkey private keys
The attacker uses the recovered private keys to sign the relying party’s challenge and successfully authenticates as the victim
Figure 7 shows how an attacker would use the SDS to decrypt passkeys and forge a valid authentication response.
Figure 7. Flow of the Golden Pass-ta-key attack.
Video 3 shows how an attacker uses the stolen SDS to log in to a high-value account (in this case, a crypto exchange).
Video 3. How an attacker uses the stolen SDS to log in to a high-value account.
The Golden Pass-ta-key attack has a significantly broader impact. Beyond the reusable access from the attacker’s environment, the SDS allows the attacker to decrypt all existing passkeys as well as any future passkeys created for the account.
While the Silver attack is mitigated by unregistering or re-enrolling the device, the Golden attack provides strong persistence. Even if a compromise is detected, remediation is limited. In Google’s current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key.
Mitigations
Enforce Strict User Verification (UV) Validation
Relying parties should require userVerification = required and validate the UV flag in all authentication responses. Failure to enforce this check can reduce authentication to a single factor. Figure 8 below shows the authenticator data layout.
Credential managers should verify the origin and attestation of newly registered device keys, including UV and identity keys. Accepting arbitrary keys without validation allows unauthorized key registration and bypass of user verification requirements.
Harden Recovery and Device Re-Registration Flows
Credential manager recovery PIN prompts are typically associated with onboarding or account recovery, not routine passkey authentication. Unexpected or repeated prompts during normal passkey usage may indicate re-triggering of onboarding or recovery, potentially due to phishing attempts or local manipulation of passkey state.
These flows are security-sensitive because recovery operations can re-establish device trust and restore access to synced credentials. In the scenarios from our research, triggering recovery enabled registration of new verification keys or exposure of key material used to decrypt synced passkeys.
Monitoring agents should detect and restrict unnecessary re-triggering of onboarding and recovery flows, especially after deletion or modification of local passkey state files. Additional verification should be required before re-establishing device trust or recovering synced credentials.
Prevent Exposure of Sensitive Key Material on the Client
Sensitive material such as the master key should not be exposed to the client, including through memory or logs. Instead, credential managers should use designs where cryptographic operations are performed on behalf of the client, without transferring the underlying key material to the client environment.
Restrict Access to Local Passkey Data
Access to passkey-related storage, such as Chrome’s sync database and local state files (e.g., passkey_enclave_state), should be limited to the browser process and protected through platform access controls. This reduces the ability to enumerate credentials, manipulate onboarding state or access device-bound key material from a compromised endpoint.
Improve Detection of Abnormal Passkey Usage
WebAuthn defines a signature counter (signCount) mechanism intended to help relying parties detect cloned or unexpectedly reused credentials. In traditional authenticators, the counter increases with each authentication operation and can provide a signal of abnormal credential usage.
In synchronized passkey systems, authentication assertions commonly contain a constant signCount value. As a result, relying parties and credential providers have limited visibility into unauthorized use of synced credentials, including scenarios where passkeys are extracted or reused from unexpected environments.
Google noted that globally consistent signature counters are difficult to implement in synchronized passkey systems that operate across multiple devices and platforms, particularly when assertions originate from independent clients.
Credential managers that centrally coordinate authentication operations should consider implementing coordinated signature counter mechanisms that account for synchronization and multi-device consistency challenges. Such mechanisms can improve visibility and detection of unexpected credential usage or passkey reuse across environments.
Conclusion
Passkeys represent a meaningful step forward in authentication security. By eliminating shared secrets, they reduce entire classes of attacks that have historically led to widespread account compromise. This changes the economics of credential theft and forces attackers to adopt new techniques.
The attacks presented in this research do not break the underlying cryptography. Instead, they exploit gaps between design assumptions and real-world implementations. These gaps include:
Trust placed in client devices
Inconsistencies in relying party validation
Weaknesses in onboarding and recovery flows
When combined with malware on the endpoint, these gaps enable account takeover scenarios that bypass the guarantees passkeys are expected to provide.
A central takeaway is that endpoint compromise remains a critical part of the threat model. When authentication decisions rely on signals from the user’s device, an attacker with access to that device can manipulate those signals in ways that are difficult to detect. Hardware-backed keys, secure enclaves and cloud isolation significantly raise the bar, but they do not fully eliminate this risk.
Passkey deployments should be treated as one layer in a broader security strategy. Relying parties must enforce strict validation, including proper handling of the user verification signal. Platform providers should continue hardening onboarding and recovery flows, and organizations should invest in protections against malware and memory access on endpoints.
As adoption continues to grow, so will attacker interest in this space. Understanding these emerging attack paths is essential to ensuring passwordless authentication delivers its intended security benefits in real-world conditions.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud Identity Security
Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) and Identity Threat Detection and Response (ITDR). It provides clients with the necessary capabilities to improve their identity-related security requirements by providing visibility into identities, and their permissions, within cloud and container environments. This helps accurately detect misconfigurations and unwanted access to sensitive data. It also allows real-time analysis surrounding usage and access patterns.
Idira Threat Detection and Response
Idira Threat Detection and Response (TDR) enables security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats.
Idira Endpoint Privilege Manager
Idira Endpoint Privilege Manager (EPM) enables enterprises to reduce risk, satisfy compliance, and streamline operations. It helps implement least privilege via policy-driven elevation and removal of standing admin rights, and blocks risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence and unified identity governance. Automation and consolidation improve efficiency and support Zero Trust strategies, strengthening security without slowing the business.
Idira Privilege Access Management
Idira Privilege Access Management unifies 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.
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.
The Police National Legal Database (PNLD) has confirmed that police, government and customer contact information was compromised and published on the dark web.
The data included names, organisations and work email addresses belonging to police officers, police staff, criminal justice professionals, government partners and customers.
The incident, identified on July 26, also exposed some names and email addresses belonging to people who had submitted questions through Ask the Police. That exposure could make phishing messages targeting named officers appear more convincing, according to UK government guidance.
PNLD said, "There is no evidence to suggest that passwords or other security credentials have been compromised." The service provides legal information, products and services to UK police forces and criminal justice organisations. It is not the Police National Computer or the Police National Database, is not a crime-recording system, and does not hold confidential information about victims, witnesses or offenders.
PNLD says it contacted all affected organisations and provided them with further information and guidance. Affected Ask the Police users have already received an email with more information and guidance. It notified the Information Commissioner's Office (ICO) and is working with the National Crime Agency (NCA) and specialist cybersecurity organisations.
As of August 3, 2026, it had not publicly disclosed how many people were affected, when the intrusion began, how long access lasted, or how much information was taken.
PNLD's official breach notice describes the exposed fields but provides no victim total. PNLD reported 108,429 police registrations and support for all 43 Home Office police forces in its 2025-26 annual summary. That is a user-base figure, not a breach-victim count.
PNLD said in its 2023-24 annual summary that the database uses Microsoft Power Platform technology. The Hacker News confirmed on August 3, 2026, that the breach-notice page referenced assets hosted on Microsoft's content.powerapps.com domain. That corroborates the platform connection but does not show how the attacker obtained the data.
VenariX reviewed samples associated with 11 of ExfilSquad's 15 claimed victims and found Dataverse-consistent structures across all 11. In the Houston case, it confirmed that a public portal returned records without authentication and that those records were consistent with data published by the group.
VenariX assessed the likely campaign-level path as a public Power Pages site with broad Anonymous Users access to Dataverse tables. The path also required an enabled Power Pages Web API or legacy OData feed.
Microsoft's documentation says granting the Anonymous Users role access to a table makes its data visible to anyone visiting the site. Its Web API documentation says the /_api interface follows the table permissions attached to each web role.
VenariX said the evidence "does not yet confirm that every organization was affected through an exposed Power Apps portal or the same configuration issue." As of August 3, 2026, neither PNLD's notice nor VenariX's report identified a PNLD-specific endpoint, permission setting, API route, or supporting log.
At this stage, the Power Pages link remains a hypothesis to test rather than an explanation of the PNLD breach.
Microsoft provides a tenant-level governance control that blocks unauthenticated users from reading Dataverse data while still allowing public form submissions.
VenariX recommends that Power Pages operators also review Anonymous Users table permissions, Web API settings, and legacy OData feeds, then validate access from an unauthenticated browser session. Those measures address the configuration pattern identified by VenariX, not a confirmed PNLD root cause.
ExfilSquad listed PNLD on its leak site on July 26, but PNLD has not attributed the incident to the group. VenariX found no evidence of ransomware deployment, malware use, lateral movement or exploitation of a software vulnerability in the campaign material it examined.
PNLD has not publicly disclosed the exact access route, the number of unique people affected or the full volume of data published.
from The Hacker News https://bit.ly/454XFe7
via IFTTT
Thermo Fisher Scientific has patched a flaw in select Applied Biosystems human identification software that could allow data files to be altered before analysis software loads them.
The vendor's July 31 security bulletin says nearly undetectable changes to .fsa and .hid outputs could occur if laboratory controls are circumvented.
Thermo Fisher tracks the issue as CVE-2026-17583 and rates it High with a CVSS v4.0 score of 8.2. Five supported product lines have received updates that add digital signatures, while three end-of-life data collection products will receive no vendor update.
Thermo Fisher credits Nathan Adams, Kevin Dyer and Laura Gaydosh Combs, together with the U.S. Cybersecurity and Infrastructure Security Agency, with identifying the issue and coordinating disclosure.
Thermo Fisher urged customers to install the applicable updates. For customers unable to implement the updates or use another third-party analysis platform, the company recommends controls covering file custody, storage, access, privilege and network connectivity.
The public bulletin does not address exploitation, but Thermo Fisher separately told The Wall Street Journal that it knew of no instances in which the vulnerability had been exploited.
In its security bulletin, Thermo Fisher says the files can be modified before analysis software loads them. The updates implement digital signatures that, moving forward, help customers verify that data files have not been changed.
The Journal reported that Nathan Adams, a systems engineer at Forensic Bioinformatics, tested the issue using a public data set. Adams said his first successful file modification using Anthropic's Claude took about 45 minutes.
In a demonstration viewed by the Journal, his code combined scans from two individual DNA profiles into a new file that appeared untouched since 2015. The modified file raised no warning in analysis software used by many laboratories.
Thermo Fisher's bulletin does not specify the access required. The researchers told the Journal that an attacker would need local or remote access to a laboratory's servers and enough knowledge of how DNA testing works.
The updates cover five Applied Biosystems human identification product lines:
3500/3500xL Series Data Collection Software 4.0.2 and earlier, fixed in 4.0.3
3730/3730xL Series Data Collection Software 5.0.2 and earlier, fixed in 5.0.3
SeqStudio Genetic Analyzer Data Collection Software 1.2.5 and earlier, fixed in 1.2.6
SeqStudio Flex Series Instrument Software 1.2.0 and earlier, fixed in 1.2.1. Labs using SeqStudio Flex with security, audit, and electronic signature (SAE) enabled must first install the latest SAE profile on the SAE Admin Console
GeneMapper ID-X Software v1.7.3 and earlier, fixed in v1.7.4
Three older lines get nothing: 3130 Series Data Collection Software 4.1 and earlier, ABI PRISM 3100/3100-Avant Data Collection Software 2.0 and earlier, and ABI PRISM 310 Data Collection Software 3.1 and earlier. Thermo Fisher says each has reached end of life and will receive no update.
Thermo Fisher's recommended measures for customers unable to implement the updates or use another third-party analysis platform include maintaining chain of custody, storing files on encrypted and password-protected media, restricting access, applying least privilege on instrument and analysis systems, and limiting internet connectivity to trusted sources.
As of August 3, 2026, exact-identifier checks by The Hacker News found Thermo Fisher's bulletin but no separate CVE.org or National Vulnerability Database detail page for CVE-2026-17583.
Thermo Fisher says the signatures will help customers verify files "moving forward." The bulletin does not explain whether files generated before the updates can be validated retroactively or how laboratories should validate them. The Hacker News found no public primary source linking altered casework to the flaw as of August 3, 2026.
The researchers told the Journal that the vulnerability likely existed in digital files produced by crime-lab machines since 1995 and that they had not found a way to detect prior tampering if it occurred.
hermo Fisher's bulletin does not confirm that historical scope. The reported weakness affects digital records generated from DNA testing, not the underlying physical DNA samples.
from The Hacker News https://bit.ly/4pYbyVg
via IFTTT
Three high-severity security flaws have been disclosed in Hugging Face's Diffusers library that could allow crafted model repositories to stealthily execute arbitrary code on machines that load it, opening the artificial intelligence (AI) supply chain to security risk.
"These vulnerabilities are bypassing trust_remote_code, the safeguard designed to stop unreviewed code from running in the custom pipelines loading process," Zafran Labs researchers Gal Zaban and Ido Shani said in an analysis published last week.
The shortcomings have been collectively named FaceHugger.
With Hugging Face becoming the "GitHub of the AI era" and its libraries and repositories prevalent in enterprise environments, vulnerabilities in libraries like Diffusers can grant attackers extensive access owing to how the library is embedded into production pipelines, CI/CD systems, and container images.
Diffusers is a Python package that serves as a library of state-of-the-art (SOTA) pretrained diffusion models for generating videos, images, and audio. According to statistics shared on pepy.tech, the package has been downloaded more than 8.1 million times in July 2026.
One of the key capabilities of the library is to locally load a model from a Hugging Face hub repository via the DiffusionPipeline API, which, in turn, makes use of a configuration file to initialize specific pipeline and component classes, along with custom pipeline code.
The "trust_remote_code" parameter in Diffusers is a security safeguard that controls whether custom Python code hosted inside a model repository is allowed to execute during "from_pretrained()" loading. Setting it to "True" permits custom code execution, while "False" or omitting it blocks unverified code from running.
"The root cause of all different RCE variants [...] is that the trust check lives entirely in the first phase," Zafran explained. "Therefore, any method that makes the loader see custom code that the gate did not, allows bypassing the trust_remote_code mechanism."
Each variant has been traced back to a case of Time-of-Check to Time-of-Use (TOCTOU), with the model download designed as two sequential, non-atomic HTTP requests instead of one a "single atomic operation" and the "trust_remote_code" security gate configured to run only against the first.
The vulnerabilities are listed below -
CVE-2026-44827 (CVSS score: 8.8) - A code injection vulnerability that allows arbitrary code to be loaded through the custom_pipeline flow from a Hub repository by means of a crafted pipeline with the name "None.py" despite passing trust_remote_code=False (or omitting it, which is the default).
CVE-2026-45804 (CVSS score: 7.5) - A race condition vulnerability that allows arbitrary code to be introduced to a repository by modifying the configuration between the hf_hub_download and snapshot_download HTTP calls to the Hub, leading to code execution.
CVE-2026-44513 (CVSS score: 8.8) - A code injection vulnerability that allows arbitrary code to be loaded through the custom_pipeline flow from a Hub repository despite passing trust_remote_code=False (or omitting it).
Following responsible disclosure, the vulnerabilities were addressed in Diffusers version 0.38.0, released in early May 2026. Any user who invokes "DiffusionPipeline.from_pretrained" with custom pipelines is impacted.
"The underlying problem is that artifacts pulled from AI repositories are frequently treated as passive data, when configuration files, loaders, and custom pipeline code can quietly cross into executable code and turn a routine model load into an initial-access vector," the researchers added.
If immediate patching is not an option, the project maintainers have recommended the following workarounds -
Only call from_pretrained with pretrained_model_name_or_path, custom_pipeline, and local snapshot directories from fully trusted sources that have been audited.
Do not pass custom_pipeline= pointing at a Hub repository different from the primary pretrained_model_name_or_path before reading its pipeline.py.
Before calling from_pretrained on a local snapshot, inspect the snapshot for unexpected *.py files, especially under component subdirectories (unet/, scheduler/, etc.) and at the snapshot root.
"These vulnerabilities underscore the critical need to treat AI model repositories as untrusted code, particularly as enterprise reliance on platforms like Hugging Face continues to grow," Zafran said. "A routine model download can easily become a vector for arbitrary code execution if security boundaries like trust_remote_code are bypassed."
from The Hacker News https://bit.ly/4pQYC3r
via IFTTT
SUMMARY: Brian Gracely (@bgracely), Aaron Delp (@aarondelp) and Brandon Whichard (@bwhicard) discuss the biggest AI news stories from the month of July 2026.
An attacker drained 1,196 Bitcoin addresses in 41 minutes on July 30, taking 1,082.65 BTC worth about $70.2 million at the time. Galaxy Research mapped the sweep and tied it to a firmware flaw in Coldcard, the Bitcoin-only hardware wallet made by Canadian firm Coinkite.
A March 2021 firmware integration error routed seed generation to a deterministic software pseudorandom number generator (PRNG) instead of the STM32 hardware random number generator (RNG).
Block says an attacker who can determine or sufficiently constrain the device UID, timer state, and prior RNG-call history can reproduce candidate output streams offline without accessing the device. Candidate seeds can then be checked by deriving their addresses and comparing them with public blockchain data.
Coinkite shipped emergency firmware for every affected model and release track on July 31, but installing it does not repair an existing seed. Coinkite tells owners with exposed seeds to generate a new one on patched firmware and move their coins.
Restoring the old seed to updated firmware or another wallet carries the weakness forward. No public report has reconstructed a victim's seed and matched it to a drained address.
Block traced the fault to Coldcard's production config, which defines MICROPY_HW_ENABLE_RNG as zero because Coinkite supplies its own hardware-RNG wrapper. The libngu library checked whether the macro existed rather than whether it was enabled, binding the build to MicroPython's Yasmarang fallback. The MicroPython fallback was initialized from the chip's unique ID and timer registers and collected no fresh entropy after initialization.
Coinkite estimates effective entropy at roughly 40 bits on the Mk3 and about 72 bits on the Mk4, Mk5 and Q, against 128 bits for a 12-word BIP-39 seed. Block does not give one practical figure. It sets conditional ceilings below 240.7 and 273.3 and warns that the latter is not equivalent to 73-bit cryptographic security. It published no brute-force benchmark.
Image Source: Galaxy Research
The later-model reseed raises the number of candidates, but Block says practical cost depends on available UID information, boot timing, prior RNG calls and derivation cost.
Exposure depends on the firmware running when the seed was created, not the version installed now:
Mk2 and Mk3: Coinkite lists Mk3 versions 4.0.1 through 4.1.9, fixed in 4.2.0, and does not name Mk2. Block places both Mk2 and Mk3 versions 4.0.0 through 4.1.9 on the vulnerable path.
Mk4 and Mk5: anything before 5.6.0.
Q: anything before 1.5.0Q.
Edge builds: before 6.6.0X for Mk4 and Mk5, before 6.6.0QX for Q.
Coinkite says a seed built with at least 50 fair, independent, private dice rolls is not at risk from this bug alone. If the number or privacy of the rolls is uncertain, Coinkite says to migrate. A strong, unique BIP-39 passphrase creates a separate wallet the seed words cannot reach on their own, but the company still recommends replacing the seed.
Multisig helps only when the quorum is not built entirely from affected devices. TAPSIGNER, OPENDIME and SATSCARD use different codebases and are unaffected.
No one has named the attacker. Galaxy, which mapped the 1,196-address sweep, said it found no other Bitcoin transactions in the previous 30 days with the same 30 sat/vB, no-change signature.
It warned that the pattern identifies the operator, not the theft, because a sweep "looks the same as if a coin owner chose to move coins."
The disclosure follows Coinspect's Ill Bloom research in early July, a separate weak-PRNG flaw in older software wallets tied to more than $5 million drained from addresses across Bitcoin, Ethereum, Tron, Rootstock and Polygon since May.
from The Hacker News https://bit.ly/3U8C5D9
via IFTTT
Bitsight says some cheap Android TV boxes have shipped with apps that rewrite their hardware identity to mimic Samsung, Huawei, Xiaomi, or Vivo phones, then click ads on websites run by the same operators.
Researchers named the operation Fuyao and attributed it to Zhejiang Fengwo IoT Technology Co., Ltd., a mainland China company founded in 2019.
The same apps have a second job. When a box detects an HDMI signal, it usually switches to relaying other people's traffic through the owner's broadband line as a SOCKS5 exit node. With HDMI off, it goes back to waiting for ad-fraud tasks.
Bitsight found the operation by registering an expired domain used as a factory backdoor and telemetry collector. Most identifiable devices reported the model name H96_MAX_V11, though Bitsight said its sinkhole view was skewed toward older models from one brand and did not establish a complete affected-model list.
In one day, after filtering for devices carrying the Fuyao apps, the sinkhole received 65,957 reports from about 38,000 unique MAC addresses. Most reports described the devices as phones. That is not a confirmed device count because the system can rotate spoofed identifiers.
The report separately shows Fengwo advertising more than 120,000 "AI digital humans," but does not establish what that marketing term counts. These figures are not interchangeable, and none establishes the physical fleet size. For owners, guidance remains generic: verify Play Protect certification and disconnect suspicious devices from the network.
The command-and-control (C2) server pushes complete phone profiles to each device, merging a base configuration with a per-model diff and deleting chipset properties that would expose a Rockchip, Amlogic, or Allwinner board underneath.
Fuyao uses machine vision inside its automation workflow to locate ads. The Script app carries a YOLOv8s object-detection model named lourui_2, trained on 12 screen elements, including generic banner regions and Taboola widgets. The app combines the model with Android accessibility data and Google ML Kit optical character recognition.
Operators assemble campaign logic in a custom editor built on Blockly, Google's drag-and-drop programming framework. They export each fraud routine as JavaScript, upload it to S3, and send it to the box for execution.
Across four test devices, Bitsight captured about 40 fraud tasks, 21 unique campaigns, and 166 unique modules. A recovered developer comment said the template system let a small group of skilled engineers support less-skilled campaign operators, cutting costs.
Fuyao's payout chain runs through a publishing network. Bitsight mapped 144 operator-owned domains across seven beneficiary clusters. At least 84 of them loaded a Taboola tag on the homepage. The researchers said they used Taboola's public sellers.json file to connect the domains to revenue-collecting entities in Hong Kong and Singapore. Bitsight modeled gross returns at $1.25 per device per day, or about $47,500 daily if 38,000 devices were active.
It separately estimated annual revenue could reach $40 million at the advertised fleet size, citing 30-40% fraud flagging and a 70% ad-fill rate, but did not show the full calculation. Those are estimates, not observed revenue.
Attribution to Fengwo rests on Bitsight, which cited shared TLS certificate data, exposed wiki files, reused email addresses, revenue links, and patents.
Public Chinese patent records independently identify Zhejiang Fengwo as the assignee of related digital-human execution and monitoring technologies. CN117421142B, granted in November 2024, covers execution-flow tracking for digital-human behavior modules, while CN117478834A describes monitoring remote screens through cloud-hosted thumbnails and keyframe comparison. Neither filing describes advertising, and the records do not establish that the company operated Fuyao or engaged in ad fraud.
The sources checked also do not establish who installed the apps or at what point in the device supply chain they appeared.
As of 7:48 p.m. IST on July 31, 2026, Bitsight's blog index still listed only the July 30 overview for Fuyao, and The Hacker News could not find either promised technical follow-up in exact-title site searches. The material checked still lacked a complete list of affected packages, firmware builds, and network indicators. Fuyao-specific identification guidance therefore remains incomplete.
After months of dormancy, the attackers behind the XCSSET malware released version 40 (v40), targeting the macOS ecosystem. This version’s advanced architecture hides its core logic in memory space, reducing its digital footprint.
V40 further enhances its detection evasion capabilities by combining polymorphic payload generation with fileless persistence and dynamic in-memory execution, while weakening a number of security mechanisms on the affected machine.
Since early April 2026, the malware has spread through supply chain attacks by hiding itself in the Xcode projects of dozens of legitimate applications with thousands of active users. Xcode is Apple’s integrated development environment (IDE) for building apps for its various operating systems.
XCSSET’s author enhanced the threat’s ability to spread through open-source projects on GitHub and upgraded its worming capabilities. It can now infect all existing Xcode projects on a compromised system for maximum impact.
The author used a multi-layered cipher shift to conceal the threat’s internal functions. In response, our researchers leveraged advanced AI and pattern-matching algorithms to de-obfuscate the malware's logic.
This article:
Explores XCSSET’s updated stealth practices
Examines the new operational modules
Reveals findings regarding the attackers' rotating command-and-control (C2) infrastructure
Provides mitigation strategies to detect and prevent this threat
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
XCSSET is a modular macOS malware family that primarily targets software developers within the Apple ecosystem, spreading through Xcode projects. Threats in this family download task-specific modules from a C2 server, giving it capabilities including:
Browser hijacking
Credential theft
Clipboard monitoring
Data exfiltration
XCSSET’s initial discovery was by Trend Micro in 2020. Security researchers at Microsoft analyzed and documented two subsequent versions in March and September 2025. These updates indicate that the attackers were enhancing their codebase.
In mid-April 2026, we started tracking a new version of XCSSET. We saw a secondary wave of attacks in early May 2026 that introduced an expanded suite of operational modules.
In this new version, we observed a heightened volume of attacks targeting developers across South Asia, which is consistent with Trend Micro's initial 2020 reporting,
While the threat actor has named this latest iteration XCSSET v40, the security community has historically identified only a handful of intermediary versions, none of which featured formal version labels.
Infection Chain Analysis
In this section, we provide a high-level overview of XCSSET v40’s infection chain. The threat’s authors restructured its execution framework to be more stealthy and modular. We provide a complete step-by-step breakdown of each phase in Appendix A.
The malware injects an initial downloader script into benign project files in Xcode projects and vulnerable Git repositories. While the attack lifecycle begins with the infected codebase, the endpoint infection is triggered only when the developer builds that project locally.
The malware scrambles its payload generation at compile time, switching between nested layers of different encryption mechanisms. Figure 1 shows a benign infected Xcode project on GitHub with two separate XCSSET payloads.
Figure 1. Infected Xcode project on GitHub.
The XCSSET v40 infection chain consists of four distinct stages prior to final payload execution:
The initial loader script establishes C2 communication
The second stage collects basic fingerprinting information on the system and downloads further modules
The third stage includes a temporary staging applet that is dropped onto the system to load the final stage into volatile memory space
The fourth stage is the core module logic
The moment this memory-resident core module loop becomes active, the malware terminates its staging processes and deletes all installation files from the disk. The goal of the core-module (internally called boot) is to execute and load additional, specialized modules into memory, such as keyloggers, clipboard hijackers or browser hijackers.
Figure 2 describes XCSSET v40’s infection chain.
Figure 2. XCSSET v40 full infection chain.
New Module Breakdown
Our analysis of XCSSET v40 uncovered 17 distinct modules, each designed for a different goal. The modules were delivered via a dynamic C2 infrastructure and executed in memory.
We found that the operators have enhanced several of its legacy modules while introducing two new components. These include a Chrome hijacking backdoor and a Telegram trojanizer.
We provide the full list of XCSSET v40 modules in Appendix B.
Chrome Hijacking Backdoor via Chrome DevTools Protocol (CDP) Protocol
The Chrome hijacking module controls the browser by misusing a legitimate Chromium feature, the CDP.
For the CDP-based hijacking to work, the malware must redirect how the user interacts with the browser. It does this by wrapping the benign Google Chrome binary in a malicious persistence script. When a victim launches Google Chrome, the wrapper executes a three-step chain:
The orchestrator check: First, it restarts the main XCSSET orchestrator module (boot) every time Google Chrome is initialized, ensuring the malware's core process remains active
CDP execution: It then launches the legitimate Google Chrome application with specific command-line arguments that activate the CDP on a pre-defined local port, exposing the browser's internal engine
chrome_remote backdoor: Finally, it drops and launches a specialized Chrome hijacking binary (chrome_remote). This binary connects to the opened CDP port, allowing the attackers to execute arbitrary JavaScript, manipulate active browser sessions and extract cookie tokens invisibly.
Figure 3 illustrates the module’s infection and execution chain.
The chrome_remote binary dropped by the browser hijacking module establishes a persistent WebSocket connection to the C2 server to pull down real-time JavaScript payloads. Leveraging CDP's ability to inject code before a page even loads allows the malware to force the browser to evaluate and execute these remote scripts on every new tab or document the user opens.
Once injected into a webpage, the malware’s dynamic scripts override critical browser APIs to manipulate the user's active session for the following goals:
Traffic interception: Hooks placed on window.fetch and XMLHttpRequest monitor to exfiltrate sensitive data streams, credentials and API tokens
Crypto wallet manipulation: Intercepting MetaMask's Ethereum provider allows the malware to alter cryptocurrency wallet addresses or manipulate decentralized application (dApp) transactions
This module is able to pivot from a browser hijack to full host-level compromise, operating within the context of the legitimate Google Chrome process. The binary monitors active tabs for specific browser console logging events. If the operator wants to run a local system command on the infected machine, they execute a standardized string such as a console.log prefixed with a specific delimiter.
The chrome_remote binary intercepts this console event, strips the delimiter and passes the remaining payload to the host's underlying shell handler (exec.Command). The resulting shell output is then packaged and routed back through the active CDP WebSocket to the C2 server, establishing a stealthy, fileless reverse shell.
We reported the information about this threat to Google. This behavior is protected against in Windows, and Google is currently working on expanding the same protections to macOS.
Telegram Trojanizer
We identified a new Telegram Desktop trojanizer module in May 2026 that was absent from the April 2026 deployment. The delayed introduction of this module demonstrates that the threat actor was actively refining XCSSET v40 after it was already deployed in the wild.
This new module performs the following activities:
Downloading a pre-built malicious Telegram.app ZIP
Wiping the legitimate copy
Dropping the C2-supplied replacement in its place
Ad hoc code-signing the fake Telegram app
Issuing a kill command to the original Telegram process so the victim relaunches the trojanized copy
This module was updated with a custom AES-encrypted configuration from a dedicated endpoint (/w?tr). We have observed this security mechanism in other modules in earlier iterations of the XCSSET malware family.
The decrypted configuration is written to ~/.tr, and a companion ~/.tr_map file tracks state. Whenever the SHA-1 of .tr changes, .tr_map is cleared. Both files are then uploaded back to the C2 as base_tr_file.txt and base_tr_map.txt.
Because the configuration blob itself was not captured during our collection window, we could not verify its exact contents. However we assess that this is how XCSSET’s operators kept server-side track of which Telegram-related markers existed on each infected host.
This is not the first time XCSSET has been seen targeting Telegram. The original 2020 generation of XCSSET featured dedicated telegram / telegram_lite data-stealing modules. The 2025 XCSSET iteration included the data_folders_finder module that exfiltrated Telegram's chat history, cached files and local encryption keys.
The newest Telegram trojanizer represents a meaningful escalation in the attacker’s access to the app. Rather than a one-time copy of Telegram-related data, the attacker now replaces the application binary itself, giving them an in-process foothold.
The Invisible Malware: New Tactics, Techniques and Procedures (TTPs) Breakdown
When analyzing v40, it became clear that XCSSET went through architectural changes and made core changes to its TTPs.
The attackers behind the malware enhanced its stealth practices to sabotage detection and thwart analysis, while also adding new persistence and data theft methods. This section highlights the recent TTPs observed in v40 illustrated in Figure 4, including:
Multi-layered encryption
Polymorphism
New fileless persistence
Impairing defenses
Virtual machine (VM) evasion
Figure 4. New XCSSET v40 TTPs.
Multi-Layered Polymorphism and Encryption
The architectural hallmark of XCSSET v40 is its defense-evasion framework, combining overlapping layers of polymorphism and a dual-key encryption scheme. Rather than relying on a single defensive trick, the malware implements a multi-tiered cryptographic gauntlet across its binaries, network payloads and internal source code. Figure 5 describes the XCSSET v40 evasion stack:
Figure 5. Layers of polymorphism and encryption in XCSSET v40.
Binary and Network-Level Polymorphism
The malware leverages polymorphism to rotate its digital fingerprints and evade detection. The loader binary, which is responsible for executing the core modules in memory, is recompiled on the C2 server every few hours. During analysis, we observed eight distinct hashes delivered to a single endpoint within a 24-hour window.
The functional modules streamed to the orchestrator are polymorphic. Each component is encrypted via AES-256-CBC using a per-build key and a randomized Initial Vector (IV) prepended to the ciphertext. Because the IV shifts with every single transmission, even two identical modules served seconds apart will result in two different encrypted blobs. Figure 6 illustrates the encrypted payload injection process into osascript as detected in Cortex XDR.
Figure 6. Encrypted module payload injected to XCSSET v40’s loader.
Network Level Dual-Key Architecture
While previous versions of XCSSET protected their C2 communications using a single, hard-coded plaintext key, v40 introduces a dual-key architecture that separates inbound and outbound encryption.
Unlike its predecessors, XCSSET v40 embeds its inbound key within the compiled AppleScript loader. As a result of this compartmentalized key placement, defenders who retrieved the outbound key from network telemetry will not be able to decrypt and access the core logic of the malware.
Module Source-Code Obfuscation and String-Literal Ciphers
The malware applies a third layer of polymorphism at the structural code level. Every internal string literal is dynamically encoded using a per-module keyed Caesar cipher featuring a randomized 52-character alphabet and variable shift values. As a result, no two builds of the same module share common string signatures.
XCSSET v40’s developers also implemented a pre-compilation substitution cipher for all internal module, function and variable names. Because this obfuscation takes place on the C2 server before distribution, the decryption mapping is absent from the host endpoint. This absence means that analysts cannot reverse a local execution routine to reveal the original code structure.
Figure 7 includes a scrambled source-code module with decrypted string literals.
Figure 7. Encrypted function names in the boot module.
By leveraging advanced pattern matching and LLM assistance, we broke the identifier substitution cipher. This allowed us to trace the obfuscated module and function names back to their original, operator-assigned names. This allowed us to dive into the malware’s core logic.
XCSSET adopted new technologies to scale their operations. This can also be a reminder for the threat intelligence community that defenders can harness those same capabilities to neutralize this threat.
New Fileless Persistence
Beyond introducing polymorphic capabilities, XCSSET v40 also added a new fileless persistence to its TTPs. In addition to its usual persistence through Git hooks, Launch Daemons and trojanized applications, v40 adopted another method that misuses the macOS defaults configuration system.
Defaults is the macOS counterpart to the Windows Registry, which is a built-in mechanism for managing user preferences and application settings.
Historically, macOS malware families like NetWire and FruitFly have misused the defaults utility to store state data. XCSSET v40 instead uses this utility to shift from predictable, disk-resident persistence to a fileless re-infection loop.
Rather than dropping additional scripts on disk between cycles, XCSSET v40 writes a Base64-encoded staging payload into a preferences domain it generates per host. Inside the domain, the malware writes the payload under keys that are meant to seem random, like mpirv_eahpi_apm or ychax_muwch_ucy. When a victim launches a trojanized or hijacked application, the threat runs a one-liner to retrieve and decode the payload:
The decoded blob re-infects the host, with the SRC tag identifying which infection vector (e.g., hijacked browser, infected Xcode project or trojanized application) is responsible for triggering the re-arm.
Beyond standard persistence, XCSSET v40 uses the defaults system during initial infection to store and query system information. Misusing defaults as an operational configuration cache is uncommon in the macOS malware landscape.
Impairing Defenses
XCSSET v40 also introduces significant defense-evasion techniques that were not observed in prior campaigns. In this multi-part effort to thwart Apple’s defenses, XCSSET v40:
Disabling the SoftwareUpdate Configuration Channel
XCSSET v40 executes the following commands to hinder the machine’s ability to receive security updates:
Setting these values to false prevents the endpoint from automatically retrieving updates to crucial macOS signature databases like:
XProtect
MRT
TCC
This also prevents access to Apple's Rapid Security Response channel, which delivers emergency patches between full macOS releases.
Termination of Cloud Telemetry Mechanisms
XCSSET v40 runs a constant loop that hinders the endpoint’s ability to send security-related data through the CloudTelemetryService process. This evasion method blocks the transmission of local security telemetry to Apple, ensuring that the operator's tooling is not sampled into subsequent XProtect signature releases.
Exclusive File Lock on the XProtect Signature Database
The malware spawns a Perl process that tries to acquire and hold access to the endpoint's YARA-rule database (XPdb). This exclusive file lock on the XProtect signature database ensures that if the endpoint does receive a security update, its content could not be written to disk.
TCC Database Reset Upon Denial of Permissions
Prior XCSSET versions terminated module execution when the user denied AppleEvents automation prompts. XCSSET v40 instead invokes tccutil resetAppleEvents, which clears the user's TCC decision database for the AppleEvents service. It then reloads a TCC prompt, masquerading as System Settings or Xcode to trick the user into re-granting automation permissions to the malware's bundle ID. The subsequent automation request is treated as a first-time prompt, redisplaying the consent dialog.
Anti-VM Reporting
XCSSET v40 also attempts to avoid running on VMs. Upon execution of the stats module (one of the first modules downloaded to the machine), the module generates a set of checks on the machine’s CPU and hardware metadata. This check is to determine whether or not the infected endpoint is a VM.
Once the module performs those checks, it calculates a final verdict ("Model Identifier suggests VM: false", "Result: likely physical") and ships the results over to the C2. Hosts reporting a virtual environment receive no further module deliveries, ensuring that automated sandboxes do not analyze XCSSET’s core logic.
C2 Infrastructure Analysis
By analyzing XCSSET v40’s Uniform Resource Identifier (URI) structure and domain registration strategies, we were able to learn more about the timeline of the most recent campaign. We even found several operational security (OPSEC) failures that provided insights into the attacker’s strategies and capabilities.
Endpoint URL Breakdown
XCSSET v40 shows a clear pattern of URL endpoint structure throughout the campaign, assigning distinct functionality to each URI endpoint as shown in Table 1.
Loader and stager retrieval during initial infection
/s/<rotated_module_name>
GET <Base64- + AES-encrypted payload>
AppleScript module retrieval (executed in-memory)
/l
POST -d <Base64 payload>
Status and log reporting
/u
POST -F m=<Base64 payload>
File exfiltration
/p
POST -d t=…&u=…&s=…
Heartbeat
/w?<cmd>
GET
Server-side dynamic configuration retrieval (e.g., /w?cbp for clipboard, /w?tr for telegram)
/e
POST
Browser-hijack events
Table 1. XCSSET v40 URI endpoint breakdown.
Domain Registration and Staging Strategy
XCSSET v40's C2 infrastructure reveals a distinct domain registration strategy. In early 2026, the attackers registered about 40 different domains in at least four short bursts across a small pool of IP addresses. The operator staged and aged these domains months before launching the attack wave, to bypass detection of newly registered domains.
Geographically, the attackers’ targeting parameters and naming conventions have also evolved. While the 2025 campaigns relied on [.]ru (Russia) domains masquerading as legitimate content delivery networks (CDNs) and tech properties, the 2026 attack wave introduced [.]in (India) names registered alongside identical [.]ru siblings. This geographic infrastructure pivot aligns with recent victimology, matching our observations of XCSSET v40 targeting developers across South Asia.
OPSEC Failures
Despite mitigating detection risks by aging their domains, the attackers compromised their own campaign through poor OPSEC. Specifically, they cross-contaminated the IP addresses hosting those domains across different XCSSET campaigns.
Furthermore, all four operator IP addresses are linked by a single shared SSL thumbprint (6e480d648fa1b70612f5d198a66875e28847547d), reused SSH keys and a shared self-signed remote desktop protocol (RDP) certificate.
Mitigation Strategies
Defending against XCSSET v40 requires defenders to use real-time behavioral enforcement to flag runtime irregularities. Unit 42 suggests the following mitigations to detect and prevent this threat:
Implement AI-enhanced process anomaly detection capable of flagging runtime irregularities, specifically monitoring for abnormal AppleScript instances
Monitor browser launcher paths and block unauthorized file-write activity
Identify and block the creation of abnormal local system defaults domains and their modification through the defaults utility
Track ad hoc signed applications and untrusted local code signers, immediately isolating binaries that bypass native Apple Gatekeeper requirements
Implement automated supply-chain dependency scanning to intercept poisoned open-source repositories before they are pulled into internal developer pipelines
Conclusion
The latest XCSSET version demonstrates a persistent and specialized threat within the macOS landscape. Rather than relying on conventional delivery methods, the framework turns legitimate developer workstations into automated, self-propagating supply chain vectors.
The discovery and analysis of XCSSET v40 reveals a modular framework for exfiltrating data, subverting system security and performing persistent browser hijacking.
While the malware's historical reliance on AppleScript and bash stagers remains consistent, v40 introduces a significant technical evolution in defense evasion. By adopting a largely memory-resident and polymorphic architecture, XCSSET v40 leaves a minimal disk footprint.
Because adversaries are now using AI-enhanced pipelines to generate polymorphic code on the fly, defenders must shift to AI-driven behavioral analysis to identify unusual or suspicious process chains and flag anomalous use of built-in detection mechanisms.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR and XSIAM
At the endpoint level, Cortex XDR blocks XCSSET on macOS hosts using Behavioral Threat Protection (BTP) to terminate fileless, in-memory execution chains—including suspicious osascript calls, multi-pass base64/xxd decoders, and process spawning from infected .xcodeproj build phases—while Advanced WildFire inspects and blocks payloads on disk.
At the Security Operations level, Cortex XSIAM correlates these host-level detections with developer repository, network, and identity telemetry, providing SOC analysts with a unified attack narrative and automated playbooks to stop cross-environment supply-chain propagation.
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.
Appendix A - XCSSET v40 Infection Lifecycle Breakdown
The infection lifecycle of XCSSET v40 can be categorized into four phases, as detailed below.
Phase 1: Initial Compromise and Execution
The infection lifecycle begins when a developer opens a poisoned Xcode project, typically downloaded from GitHub or built internally:
The moment the developer builds the project locally, a malicious run-script phase executes silently in the background
The malware dynamically scrambles its payload generation at compile time, switching between nested layers of Hex- and Base64-encoding
This decoded script initiates contact with the attacker’s C2 infrastructure by executing a curl request to the /a with basic execution context (p=xcode_phase) to retrieve the next stage
Phase 2: Host Reconnaissance and Staging
The retrieved staging payload runs a second, specialized curl command that collects and exfiltrates primary host metadata
The payload queries the operating system type (uname -s) and the current username (whoami), transmitting these details back to the C2 endpoint
Phase 3: Loader Wrappers and Binaries
If the C2 approves the host profile, it returns a bash script obfuscated via a custom substitution cipher. This script handles the high-risk task of staging the main loader while covering its tracks:
The bash script performs deeper hardware fingerprinting, matching the host's serial number against targeted profiles
It then pulls the primary malware loader to /tmp/r and compiles an accompanying AppleScript wrapper as /tmp/p.app on the fly
To eliminate forensic evidence, the loader wrapper is executed in memory by osascript, which in turn downloads the main orchestrator module and its AppleScript loader
After execution, the malware terminates osascript and deletes both /tmp/r and /tmp/p.app from the disk to minimize its forensic footprint
Phase 4: Orchestrator and Core Logic Modules
Once it erases its disk footprint, the malware transitions to a mostly fileless execution:
The main orchestrator module named “boot” by the developers runs and retrieves additional module payloads from https://<C2>/s/<encoded_module_name>
Finally, the orchestrator pipes the payloads to the AppleScript to decrypt and execute the modules in memory
Appendix B - XCSSET V40 Module Breakdown
This appendix maps the 17 modules identified in XCSSET v40. We correlated the canonical XCSSET v40 module names recovered through our decryption efforts with the terminology used in the three prior public reports.
Please note that since XCSSET has gone through major architectural changes in v40, some modules’ logic may be expanded or split into different modules. It is also worth noting that previous reports of XCSSET did not decrypt the original module names, and therefore they appeared as jumbled strings.
Module Name
Previously Recorded Names
Functionality
boot
boot, bootstrap
Main orchestrator, module-dispatch loop
stats
vexyeqj, seizecj
Initial reconnaissance on the infected endpoints, exfiltrates existing browser extensions, performs anti-VM checks
logic previously existed in dfhsebxzod and replicator modules
Split out in v40 from replicator_finder. Recursively traverses user directories to identify and infect Xcode projects present in .zip archives.
data_folders_finder
finder, txzx_vostfdi, neq_cdyd_ilvcmwx
C2-driven folder finder and data exfiltrator
firefox_data
iewmilh_cdyd
Infostealer targeting Firefox
notes_app
cozfi_xhh
Apple Notes exfiltrator
settings_app
xmyyeqjx
LaunchDaemon-based persistence using a fake Settings.app, defense evasion by blocking XProtect features
finder_app
finder_app, vectfd_xhh
TCC permission misuse and reset, creates trojanized app that mimics Finder/ Xcode/ Terminal/ Reminders/ SimulatorTrampoline
persist
hfdieiz, some of the logic previously existed in xmyyeqjx
.zshrc and Dock-app based persistence
browser_remote
chrome_remote, firefox_remote, opera_remote, yandex_remote, brave_remote, edge_remote, 360_remote (one module per browser, each downloads a backdoor masquerading as browser from the server; uses an exploit to hijack the actual browser)
Unified browser-hijack dispatcher checks for existing browser on the endpoint and dispatches different hijacking modules
safari_remote
safari_remote
Browser hijacker
chrome_remote
new module (v40)
Browser backdooring and hijack through CDP protocol
Note: Trend Micro’s 2020 report mentions a module named chrome_remote, but v40’s module has different functionality
