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.
A SharePoint Server vulnerability that Microsoft initially classified as a spoofing flaw with a CVSS score of 6.5 actually enables authenticated remote code execution, according to full technical details published today by Viettel Cyber Security researcher Dinh Ho Anh Khoa.
The flaw, CVE-2026-65660, affects SharePoint Server 2016, 2019, and Subscription Edition. Patches have been available since the August 11 security updates, and the National Vulnerability Database scores it 8.8.
Microsoft's advisory describes CVE-2026-65660 as allowing an authorized attacker to perform spoofing and assigns no impact to integrity or availability. The CVE record that Microsoft publishes separately, updated on September 11, titles the same flaw a remote code execution vulnerability and says it allows an authorized attacker to execute code.
Both records assign CWE-94, a code-injection weakness. Defenders who triaged CVE-2026-65660 based on the advisory saw a moderate spoofing flaw, not a code-execution vulnerability with a near-maximum score.
Khoa is the researcher who demonstrated the original ToolShell exploit chain against SharePoint at Pwn2Own Berlin in May 2025. That chain was later exploited by Chinese state-backed groups and triggered emergency patches from Microsoft.
The researcher has since disclosed several other SharePoint flaws, including CVE-2026-55040, an authentication bypass that attackers exploited shortly after its details became public in August.
The latest vulnerability sits in how SharePoint checks whether server-side controls are on the SafeControls list, a filter that prevents dangerous classes from loading. When the ToolPane component processes web-part markup, it reconstructs Register directives by writing attribute values between double quotes without escaping quotes inside them.
An attacker can inject additional directives through the unescaped quotes, registering arbitrary .NET classes after the type check runs but before the control is loaded.
With arbitrary class loading, the attacker uses XamlServices.Parse() to trigger code execution through deserialization. The writeup includes a working in-memory webshell payload that avoids the registry permission failures other deserialization methods encounter, Khoa said.
The researcher also demonstrated that the flaw can be chained with a separate, already-patched authentication bypass to reach pre-authentication remote code execution on servers configured to allow anonymous page access. Khoa says the bypass was fixed in a June 9 patch, and servers that applied the fix are not exposed to the pre-authentication path.
No exploitation of CVE-2026-65660 has been reported in the wild, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. Microsoft's advisory rates exploitation as unlikely, though the full exploit markup is now public. Khoa says he has used the exploit in penetration testing engagements.
The August 11 patch fixes the flaw and turns off the vulnerable function by default, according to the researcher.
Khoa says the flaw also affects SharePoint 2013, though Microsoft's advisory lists only 2016, 2019, and Subscription Edition. SharePoint 2013 has been out of support since April 2023 and receives no security updates.
from The Hacker News https://ift.tt/eLZfgyO
via IFTTT
A cairn is a marker left behind on a trail, a deliberately placed stack of stones that helps hikers find their way when the path is unclear. Attackers building AI-integrated malware unintentionally (and inevitably) leave behind markers of their own: prompt templates, provider endpoints, API keys, jailbreak terms, and other artifacts embedded throughout their tooling.
When we consider these strings as cognitive artifacts, or vestiges left behind from AI integration, we can enable a new, metadata-first hunting methodology for AI-integrated malware that is fast and scalable. These artifacts can be extracted, related, and classified without ever touching the underlying binary.
Today, Cisco Talos is releasing this methodology in the form of CAIRN (Cognitive Artifact Intelligence Research Network), a research toolkit for hunting, classifying, and tracking emerging AI-integrated malware. Over time, we will share the full contents of our initial findings, starting today with CLOSEDQUORUM.
Figure 1. CAIRN explorer connects malware binaries by metadata attributes like submitter, import hash, domain or AI provider. Run cairn explorer to launch the graph.
CAIRN contains functionality for identifying AI-integrated malware; in our definition, that is malware that functionally operationalizes, explicitly targets, or exploits AI systems and their ecosystems — spanning functional integration into attack chains, credential and infrastructure compromise, and ecosystem-level abuse. These binaries are classified based on pre-defined AI-usage archetypes, and reporting findings in a structured way.
CAIRN has an explorer layer, which creates a structured graph of cognitive artifact relationships to help defenders identify related malware families, infrastructure, and threat actors.
Figure 2. The CAIRN processing pipeline extracts AI-integration artifacts from metadata, classifies and constructs unique representations for all samples, and clusters and graphs the sample relationships.
Metadata-first architecture
CAIRN operates entirely from metadata — no binary downloads or execution required. It combines rule-based detection, semantic clustering, and relationship graph traversal to identify AI-integrated malware through cognitive artifacts such as embedded prompts, provider endpoints, orchestration logic, API key prefixes, and AI-analysis evasion strings.
CAIRN discovers candidate samples through up to 24 acquisition filters, each targeting a different type of AI-related artifact. Instead of relying solely on filenames or hashes, these filters search across metadata including extracted strings, sandbox behavior, and antivirus (AV) detection labels.
provider-api-integration searches for LLM provider endpoint strings in file metadata. For example:
api.openai.com
api.anthropic.com
api.deepseek.com
Generativelanguage.googleapis.com
Any file whose binary content, URL extraction, or sandbox behavior surfaces one of these domains becomes a candidate.
python-ai-scripts targets Python files matching AI framework import patterns. For example:
langchain
litellm
openai
This pulls in scripts that interact with the AI ecosystem at the code level, not just the network level.
ai-analysis-evasion searches for text strings explicitly addressed to AI analysis systems — the kind of comment an actor might embed when trying to tell an LLM sandbox "there's nothing to see here."
local-llm-runtime searches for strings indicating local model inference (ollama, llama.cpp, vllm, gguf, safetensors). This surfaces files that may be running inference on the endpoint rather than calling a hosted API.
agentic-tooling looks for tool-call syntax (tool_call, tool_calls, function_call) co-occurring with offensive capability terms.
Results from the acquisition filters are stored in a SQLite corpus with YARA run automatically on import, using a three-layer ontology:
Tier 1 (T1) Primitive AI Artifacts (e.g., API endpoints, tool calling syntax) establishes that AI-related artifacts are present.
Tier 2 (T2) Behavioral Context (e.g., AI analysis evasion, known C2 methods) adds behavioral context by identifying combinations of artifacts that suggest operational use of AI.
Tier 3 (T3) Operational Families (named AI-enabled malware family) performs family attribution using confirmed operational fingerprints.
Analysis methods with CAIRN
CAIRN is set up with a detailed CLI and works well for an analyst or as an agent-driven workflow. The skills published support a standardized reporting structure when using an agent.
CAIRN uses four distinct analysis strategies; each suited to a different phase of investigation. In practice, a hunt session combines several of them: surface expansion to find unknowns, pivoting to map what's related, and corpus analysis to find structure in what's been collected.
1. Acquisition filters for sample corpus expansion
Discover previously unseen samples using acquisition filters. This type of hunt produces candidate samples that are introduced into the CAIRN database.
Figure 3. Acquisition filters can be viewed and edited from within the CAIRN explorer.
2. Relationship-based pivoting
Once a sample of interest has been identified, CAIRN expands outward through metadata relationship graphs to identify related malware, shared infrastructure, and other artifacts connected to the same campaign.
These relationships help analysts answer questions such as:
Are there additional variants of this malware family?
What infrastructure (e.g., domains, IPs, certificates, C2 servers) does this malware share with other samples?
What loaders, companion payloads, or adjacent malware are part of the same campaign?
By following these connections, analysts can move beyond a single malware sample and begin reconstructing the broader operational ecosystem behind it.
3. YARA-based triage and classification
CAIRN's YARA rules operate on scan text derived from sample metadata in a three-tier structure (T1 artifacts, T2 behaviors, T3 confirmed families). The same text document that feeds the embedding pipeline in the next method, Semantic Discovery, is used for YARA matching.
Traditional YARA rules are written after reverse engineering (RE). They anchor on the artifacts reverse engineering surfaces, particularly the low-level implementation details that most precisely fingerprint a family. Those are the best classifiers you can write, but they presume you hold the binary. A CAIRN rule must fire on what VirusTotal already exposes as metadata: printable strings, import names, resource and version-info fields, and certificate identities — so the discriminator must survive the trip from disassembly up to the surface of the file. The RE finding tells you what makes the family unique; the metadata rule is the projection of that finding onto the subset of it that's observable without a download.
Tier 3 rules are used to assign logic to identify known operational families. This produces a YARA rule for confirmed attribution of a family of samples.
Figure 4. YARA rules serve to identify which specific artifacts and behaviors a given sample exhibits.
This is the constant tension in a T3 rule: The sharpest signal from low-level RE is exactly the signal you can't hunt on. As a result, the discipline is to pin down the family by RE, then ask which string- or metadata-accessible trait travels alongside that mechanism. Build the rule from those, treating the deep implementation detail as the thing the rule is a proxy for rather than the thing the rule matches.
After any rule change, cairn rescan re-applies all three tiers offline against the full corpus without any API calls or re-downloading. This means a new T3 rule for a confirmed family will immediately surface any previously-acquired samples that match, retroactively attributing earlier hits to the new family.
4. Semantic discovery
YARA finds what you already know to search for. Embedding models can identify samples that are semantically similar even when they share no obvious string overlap. CAIRN therefore treats semantic clustering as a complementary discovery mechanism rather than a replacement for YARA.
For each sample, CAIRN assembles a scan text document from:
All AV engine detection label strings
URL and domain objects extracted by VirusTotal's PE static analysis engine
Content-search hex-dump snippets (VirusTotal's preview of matched content at a file offset)
ExifTool PE resource strings (CompanyName, FileDescription, OriginalFilename)
Figure 5. UMAP in the CAIRN explorer shows groups of samples based on the similarity of their metadata fingerprint, facilitating hunting of a known malware’s nearest neighbors, or distinct clusters of uncategorized samples.
This approach produces candidate families and reveals outliers and novel clusters. This view is exposed in the CAIRN explorer through the UMAP toggle, which presents an unsupervised pass over the full existing corpus using HDBSCAN and UMAP. Cluster co-membership is a weak similarity signal, not a strong attribution signal. It generates leads, not conclusions. Every interesting cluster still requires per-sample inspection to confirm the AI angle is real and not a false neighbor.
Findings summary
Talos' initial hunts with CAIRN have targeted active malware development since July 2025, when the first AI-integrated samples were reported in the wild (LAMEHUG, CERT-UA). Looking across our collection of samples and relationships, we can make a few interesting initial observations:
AI-specific tradecraft is being taught and spread. An AI-analysis evasion technique, embedding natural-language suppression text addressed to LLM sandboxes was traced to a named red team instructor and appeared in independent actor samples, within 12 months of its first confirmed in-the-wild use. This suggests the technique is circulating broadly enough to reach actors with no connection to the original course or malware sample and has crossed from interpreted scripts into compiled malware.
Mandatory “No free lunch,” “Not a silver bullet” statement. T1/T2 hits without genuine AI integration are common. For example, PyInstaller bundles expose the developer's entire virtual environment as YARA-visible strings regardless of what the application imports; Tauri-framework apps and certain Go PE structures accumulate detection signatures from structural similarity alone. Analysts running AI artifact hunts should expect elevated noise from these patterns specifically.
We may be in a fleeting window to observe AI transition. AI integration is becoming commonplace in all software. As this integration increases, our filters will need to shift from an emphasis on presence of AI strings, toward purpose of their integration. The current approach emphasizes T2 YARA to sharpen behavior classification over the presence of AI indicators alone. Final verdicts for all findings still need validation through reverse engineering.
Conclusions
It’s too soon to tell whether AI-integrated malware will conclude as an experimental era, or usher in new paradigms for modern attack operations. Adversaries are increasingly incorporating LLMs into operational tooling, and researchers need methodologies and frameworks that scale beyond manual reverse engineering to keep pace with the changes. Metadata-first hunting provides a scalable complement to traditional reverse engineering, and by open-sourcing CAIRN, Talos hopes to refine filters, rules, and reporting via community-driven improvements.
CAIRN is a research effort, not a pure active threat signal. However, for the security community, the insights gleaned from studying this landscape and its progression form a valuable signal to inform our detection, intelligence, and operational strategies.
Take a brief tour of CAIRN with our demo video:
from Cisco Talos Blog https://ift.tt/7vUJK0u
via IFTTT
A malicious npm package named "indexed-btree" has been observed hiding its malicious behavior within application code rather than using lifecycle scripts, indicating that threat actors are likely shifting tactics in response to recent security controls.
"Indexed-btree is a malicious npm package mimicking the legit sorted-btree package, an ordinary B-tree/indexing utility," Checkmarx said. "Unlike the common attacks we've seen in the supply chain space, this package does not rely on preinstall / postinstall at all. Instead, it runs entirely from application code at runtime."
To make matters worse, the campaign may have generated illicit profits for the threat actor, earning them around €230,933.57 in cryptocurrency (i.e., 109 ETH).
The development comes as npm version 12 introduced a security change to prevent automatic execution of lifecycle scripts such as preinstall or postinstall, which is one of the most common ways malware is executed through packages distributed through the repository.
"Legitimately, these are often used for compiling necessary code, seeding data, or setting up essential configurations," Checkmarx said. "For threat actors, however, this is frequently exploited to automatically execute malicious code without user consent during the installation of a malicious package."
The latest findings from the software supply chain security company show that bad actors are shifting tactics in response to the change, eschewing install hooks in favor of incorporating the malicious code directly within the library.
In this case, the malware loader is concealed inside a "BTree.prototype.set()" method, which then triggers "sharedLoad.min.js," a JavaScript payload that embeds the obfuscated first stage of the malware.
The malware is designed to fingerprint the host, beacon the details to a hard-coded Slack channel and Telegram bot, uses the EtherHiding technique to pull next-stage, encrypted blobs from a smart contract deployed on Sepolia testnet, and finally merge them to form the second-stage payload.
The final step involves deleting the malicious artifacts and removing the trigger from the package code to cover up the tracks.
Checkmarx said indexed-btree is one of the many npm packages tied to the same operation, all of which have since been removed from npm -
ordered-kv-index
btree-leaderboard
priority-slot-queue
btree-range-store
btree-core
btree-time-index
btree-lru-cache
neighbor-key-map
sliding-score-window
mutex-forge
To counter the threat, developers are recommended not to stick only to install-time scanning and blocking lifecycle scripts alone, but also employ runtime behavior analysis.
"What makes this campaign particularly important is that it shows attackers adapting almost immediately to stronger software supply chain defenses," Ensar Seker, CISO at SOCRadar, said in a statement shared with The Hacker News. "Npm has improved install time security by restricting dependency lifecycle scripts, but this campaign demonstrates that attackers can simply move malicious execution into legitimate-looking runtime functionality instead."
"The broader lesson is that security controls change attacker behavior rather than eliminate the underlying threat. Blocking lifecycle scripts is an important improvement, but attackers will continue searching for alternative execution paths. Defenders, therefore, need layered controls capable of detecting malicious behavior before installation, during execution, and after deployment."
PolinRider Resurfaces on Packagist
The disclosure comes as Socket said it deleted malicious code in the "dev-main" version of "visanduma/nova-two-factor," a Packagist package with over 700,000 cumulative downloads, as part of an ongoing North Korea-linked malicious cyber campaign dubbed PolinRider.
A defining trait of PolinRider is the threat actor's pattern of compromising developer accounts to inject malicious content into source code repositories and employ routine developer actions, such as cloning a repository or opening it in an integrated development environment (IDE), as triggers to activate the infection chain.
This often entails rewriting Git history, concealing payloads within configuration or font files, setting up malicious VS Code auto-run tasks, and relying on takedown-resistant techniques like EtherHiding and its stealth-focused successor, NullReceiver, for staged-payload delivery via the blockchain.
"Analysis of the Visanduma GitHub organization indicates that its repositories have been compromised since mid-June 2026," Socket security researcher Karlo Zanki said. "The malicious changes were introduced through the LaHiRu developer account."
One notable shift observed in the latest iteration is the direct insertion of heavily obfuscated JavaScript into "index.php" and its execution through PHP's "shell_exec()" function. This approach, besides allowing a PHP entry point to invoke the JavaScript infection chain, suggests the threat actors are adapting their execution methods based on the compromised project instead of using a fixed delivery path.
"The activity reinforces a defining characteristic of PolinRider: package-registry compromise is often a consequence of a broader Git-based intrusion rather than the campaign's primary objective," Socket said. "The operators use ordinary source-code collaboration to reach developer environments, spread into additional repositories, and maintain access over time."
"Compromised source repositories give the operators opportunities to infect contributors, access private projects, and propagate through normal development workflows. Package publication becomes an additional distribution path when a compromised repository produces a new release."
from The Hacker News https://ift.tt/MqiLb4K
via IFTTT
The threat actor known as SideCopy has been observed using spear-phishing lures to target academic institutions in India, expanding their strategic focus beyond government entities.
"SideCopy campaign operations typically initiate through spear-phishing campaigns that leverage the abuse of mshta.exe to execute malicious scripts and circumvent standard security protocols," Trellix researchers Boggavarapu R S S Srinivas Gupta and Ravishankar N C said in a technical report.
"This delivery mechanism facilitates the deployment of a remote access trojan (RAT), which serves as the central pillar of their offensive infrastructure."
Active since at least 2019, SideCopy (aka TAG-140) is an advanced persistent threat (APT) group that originates from Pakistan, and shares overlaps with the Transparent Tribe cluster. Historically, the threat actor has primarily targeted Indian defense forces and government officials.
In a report published in June 2026, Seqrite Labs attributed SideCopy to a spear-phishing campaign targeting Afghanistan's Ministry of Finance with an open-source remote access trojan called Xeno RAT.
The latest attack chain documented by Trellix uses spear-phishing to deliver a weaponized ZIP archive, within which exists a Windows shortcut (LNK) with a spoofed PDF icon and a .DOCX extension ("commskll.docx.lnk") to make the malicious file look legitimate.
The LNK file is used to fetch an obfuscated HTML Application (HTA) from a remote server ("docsportal[.]in") and execute it using "mshta.exe," which then proceeds to reflectively load a DLL payload. The malware makes use of an anti-forensic self-deletion routine that deletes the HTA file once the subsequent stage is initialized.
The DLL serves as a dropper for three embedded components -
appT.bat, a batch script that's launched by means of a Windows Registry Run Key to execute "startT.hta" using "mshta.exe" without requiring user interaction
startT.hta, a secondary exploit stage that contains the obfuscated final payload
commskl.docx, a decoy document
"The obfuscated code within startT.hta executes a multi-stage deobfuscation routine to reconstruct a two-part XAML payload directly in memory," Trellix explained, adding it's responsible for reflectively loading an embedded DLL ("ioluegnt.dll").
"To evade disk-based detection, the malware decodes its core payload into volatile memory space, transitioning from a Base64-encoded string to an active, in-memory process via .NET Deserialization."
The DLL is a remote access trojan named ReverseRAT, which has been put to use by SideCopy since early 2021 to facilitate data exfiltration, remote execution, and persistence. It's equipped to gather system metadata, a list of installed software, screenshots, passwords, and clipboard content; perform file operations; run commands; set up persistence via Registry; upload files; and spawn a shell session.
The command-and-control (C2) traffic is encrypted using a hard-coded cryptographic key ("NMXIKS09?:709,!~lnsYUS"). The harvested data is exfiltrated via port 5863 to "dns.educationportals[.]biz," which resolves to the IP address "45.61.157[.]22."
"The current activities of SideCopy underscore a disciplined and highly strategic approach to intelligence collection," Trellix concluded. "While their historical focus has been on Indian government entities, their recent pivot toward academic institutions highlights an expanding set of strategic priorities."
"By continuously refining their infection stages, most notably through the heavy abuse of mshta.exe and complex, multilayered obfuscation, they remain a formidable and adaptive adversary for regional security."
from The Hacker News https://ift.tt/ykzXD2R
via IFTTT
Malware already running on a Mac can quietly take over Meta's Muse assistant and use the broad access its owner granted the app, security researcher Patrick Wardle has shown in a proof-of-concept released on September 21.
It works by changing a hidden setting so that when the user taps the microphone and dictates a prompt, the words go to the attacker instead of Meta.
The flaw is in the Mac version of Muse, and it only works if an attacker can already run code as the logged-in user. It is not a way to remotely break into a Mac.
Muse is the personal AI agent Meta launched this month in the United States. Once a user turns it on, it can work across their files, email, messages, calendar, shopping and smart-home apps, using whatever access the person chooses to give it.
That access is the point, Wardle says. He urged people not to install Muse, calling it "trivial to turn Muse into the ultimate backdoor."
macOS normally prevents one app from accessing another app's files, microphone, camera, or saved logins, so ordinary malware is limited in what it can access. An attacker who can quietly steer Muse instead gets everything the user allowed the app to do.
Wardle also warns that security software may not notice, because the commands come from Muse, a normal signed app, rather than from something that looks like malware.
The setting he found is undocumented and decides where Muse sends dictation. It is stored in the Mac app's preferences under the name endo_voyager_dictation_endpoint, and any program running as the logged-in user can point it at an address the attacker controls, without needing extra permissions.
After that, the dictation no longer goes to Meta. When the user speaks a prompt, the audio and the text go to a small program the attacker is running on the same Mac.
From there, Wardle showed three things an attacker can do: read what the user dictated, add extra instructions that Muse trusts and acts on, and take the token that identifies the user's Muse session and use it to control the assistant directly.
Because a Muse account can be signed in on multiple devices, the attack does not stop at the Mac. Using a stolen session, Wardle directed the Muse app on his own iPhone to report its exact location, run a Bluetooth scan of nearby devices, and list the smart-home commands it could send. In his tests, the assistant only drafted messages rather than sending them on its own.
Wardle also pointed to what the attack does not do. It does not defeat the part of macOS that stops one app from reading another app's saved passwords. Instead of stealing Muse's stored login tokens, it makes Muse itself act, using access the app already has. And it does not show that Meta's cloud system, which the company built to keep each user's agent walled off, was broken.
What Mac Users Can Do Now
With no patch available, a Mac user can only limit the exposure:
Quit Muse, or remove it, until Meta fixes the problem.
Review the apps and permissions Muse holds, and revoke any it does not need, so there is less for an attacker to access.
If the Mac may already be compromised, treat the connected accounts as exposed and change their passwords.
Because the attack needs the user to dictate, avoid Muse's voice input, which closes the exact path shown.
Meta has put a lot of weight on Muse's security. It built the agent to run in a separate cloud system that keeps each user's data apart from others, with a checking layer meant to approve the actions Muse takes. This flaw sits in the Mac app instead, not in that cloud design.
Wardle argues Meta created the weak point itself by building its own way to handle dictation that sends the audio off the device, rather than using Apple's dictation, which runs on the Mac.
from The Hacker News https://ift.tt/1LXHa5m
via IFTTT
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday added a now-patched security flaw impacting Zyxel GS1900 series switches to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.
The vulnerability, tracked as CVE-2026-7273 (CVSS score: 8.8), is a stack-based buffer overflow vulnerability that could result in arbitrary operating system (OS) command execution.
"A stack-based buffer overflow vulnerability in the CGI program of the Zyxel GS1900 series switch firmware could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request," Zyxel said in an advisory released in June 2026.
The issue has been addressed in the following versions -
GS1900-8 2.90(AAHH.1)C0 and earlier - Fixed in 2.90(AAHH.2)C0
GS1900-8HP 2.90(AAHI.1)C0 and earlier - Fixed in 2.90(AAHI.2)C0
GS1900-10HP 2.90(AAZI.1)C0 and earlier - Fixed in 2.90(AAZI.2)C0
GS1900-16 2.90(AAHJ.1)C0 and earlier - Fixed in 2.90(AAHJ.2)C0
GS1900-24 2.90(AAHL.1)C0 and earlier - Fixed in 2.90(AAHL.2)C0
GS1900-24E 2.90(AAHK.1)C0 and earlier - Fixed in 2.90(AAHK.2)C0
GS1900-24EP 2.90(ABTO.1)C0 and earlier - Fixed in 2.90(ABTO.2)C0
GS1900-24HPv2 2.90(ABTP.1)C0 and earlier - Fixed in 2.90(ABTP.2)C0
GS1900-48 2.90(AAHN.1)C0 and earlier - Fixed in 2.90(AAHN.2)C0
GS1900-48HPv2 2.90(ABTQ.1)C0 and earlier - Fixed in 2.90(ABTQ.2)C0
CISA hasn't disclosed who was behind the exploitation efforts, when they started, how many organizations have been targeted, how many of them have been successful, and what attackers did once inside the vulnerable service.
Zyxel credited Lei Gu, Jun Cao, Zhiqing Rui, Jingzheng Wu, and Tianyue Luo from ISCAS for discovering and reporting the vulnerability. As of writing, the company has yet to revise the alert to confirm active exploitation.
In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are required to apply the fixes by September 24, 2026, for optimal protection.
Active Exploitation of Veeam Agent for Windows Flaw
This disclosure comes as Arctic Wolf warned of active exploitation of CVE-2026-32996 (CVSS score: 7.3), a local privilege escalation vulnerability in Veeam Agent for Microsoft Windows that allows an attacker with local access to obtain SYSTEM-level control of affected endpoints.
"The issue stems from the Veeam Endpoint Backup service's handling of elevated client sessions over the local gRPC named pipe \\.\pipe\Veeam\VAW\ServiceConnectionPipe," the company said. "The service caches an elevated administrator principal against a client-controlled session UID that is not bound to the requesting user or connection."
"Because elevated session UIDs are written to C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, which standard users can read, an attacker can obtain a valid UID and abuse it to execute commands as SYSTEM. The public GitHub PoC demonstrates this by running whoami and writing the output to a file."
from The Hacker News https://ift.tt/BGIQse4
via IFTTT
A fake LastPass Authenticator installer offered on GitHub installs a Windows kernel driver that shuts off antivirus and other security software before a password stealer runs if a victim downloads and runs it, researchers at LastPass and Delphos Labs said on September 17.
Microsoft's own hardware-compatibility program signs the driver, scored zero detections on VirusTotal when researchers checked it in August, and was not on Microsoft's list of blocked drivers. LastPass says none of its own systems, services, or customer vaults were touched, and that the attackers only borrowed its name.
The lure is a fake GitHub page (github.com/LastPass-Authenticator) that ranks in search results for terms like "LastPass Authenticator download" and looks like a real LastPass product page.
Clicking the download button sends the visitor through several GitHub pages to an attacker server, which serves a large ZIP file. The real LastPass Authenticator comes from lastpass.com and the official app stores, not GitHub.
Inside the ZIP is a renamed copy of a real Microsoft debugging tool, vsdbg.exe, placed next to a malicious file named vsdbg.dll. When the fake installer runs, Windows loads the attacker's DLL from the same folder, a trick called DLL side-loading. The loader then tries three ways to gain administrator rights, reaches SYSTEM, the highest level on a Windows machine, and installs the kernel driver as a service.
The archives seen were 148 MB and 127.9 MB, padded with junk files so that scanners with size limits skip them.
What the driver does, and why Windows trusts it
A kernel driver runs below the level where antivirus and endpoint detection and response (EDR) tools operate. This one, which the researchers named Alinubx.sys, carries a list of 145 antivirus and security process names and terminates each one it finds running.
It does this from the kernel, below the level where security software runs, so those user-mode tools cannot block or see the kill. Loading a legitimately signed but abusable driver to gain that access is a known technique called bring your own vulnerable driver, or BYOVD, which The Hacker News has covered before.
The driver is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing date of March 2023, years before this campaign. As the researchers put it, "Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe."
The kill list is the only part of the driver that ran here. Its code can also hide files, inject into other programs, and reroute web traffic, but those need a configuration file the attackers did not include, so they stayed off.
What it did do is enough. With security software down, the stealer collected saved passwords from more than two dozen browsers, cryptocurrency wallet files, and login sessions for Discord, Steam, and Telegram, along with the contents of Windows Credential Manager and files named like "password," "seed," or "recovery."
For Chrome and Edge, which use Google's app-bound encryption to stop exactly this, the stealer injects code into the browser and asks the browser's own service to decrypt the passwords. The data is packed into a ZIP and sent to an attacker server.
Why nothing caught it
The driver is a renamed copy of CcProtect.sys, a driver from the Chinese disk-encryption product CnCrypt that is already listed on the LOLDrivers catalog as a process killer, with public proof-of-concept code. The two share the same product name, version, and submitter; only the file name and description changed.
That change dropped the file's antivirus detections: the known original showed 7 of about 70 engines flagging it in August, while the renamed driver showed zero.
The blocklist is a different matter. Microsoft's vulnerable driver blocklist, on by default since the Windows 11 2022 update, stops listed drivers from loading. Delphos checked it on August 20 and found neither the renamed driver nor the known original on it. The rename did not slip past the blocklist, because the original was never on it either.
The blocklist matches known file hashes, and a renamed or recompiled driver produces a new hash that the list does not carry. At the September 17 report, Alinubx.sys was still not on the blocklist.
Delphos reported the driver to Microsoft on August 19. Microsoft responded that the behavior does not meet its definition of a security vulnerability, because the driver is not a Microsoft component, and pointed the researchers to the separate channel that considers drivers for the blocklist. Delphos resubmitted there the same day.
If you ran the fake installer
Treat every password saved in the browser on that machine as stolen, along with any cryptocurrency wallet files, Discord, Steam, and Telegram sessions, and anything in Windows Credential Manager. The stealer copies these out before the driver work begins.
Change those passwords from a separate, clean device, not the affected one, and review account activity for anything you did not do. The driver stays loaded, re-kills security tools, and re-runs the stealer on every reboot, defeating the tools that would normally clean it up.
A machine that ran this payload should be treated as a kernel-level compromise and, where possible, given a kernel-level forensic check or rebuilt.
What defenders can hunt for
The researchers say to hunt for the driver's lineage and behavior rather than one file name, because the operators can change the name again as they did here. Signs to watch for:
Service: a service created as NvFsFilter
File: a driver written to C:\Windows\System32\drivers\nvfsflt64.sys
Signer: a driver whose signing details name Henan Dafeng Software or contain "CnCrypt"
Device: the path \\.\Alinubx
Behavior: a driver load followed by security processes being killed
A community detection for the exact driver is published on LOLDrivers, though it matches by hash and so shares the same weakness once the file changes. Full indicators are in the joint report.
Where it came from
The LastPass page was one of many lures. The attacker server was serving impersonation pages for at least 40 brands, LastPass said, and a near-identical second fake page for a "macOS LastPass" product was taken down before the team could examine it.
Delphos assesses with high confidence that the loader was built with the Cruciferra crypter, a paid tool whose default kill list also holds 145 names and whose driver is interchangeable, and with moderate confidence that the stealer, which LastPass calls Rapuncel, is a relative of BoryptGrab rather than the same build. How many people were infected is unknown; the report provides no victim count.
from The Hacker News https://ift.tt/1vDB8TF
via IFTTT
The North Korean threat actors behind the Contagious Interview campaign have compromised at least 30,000 devices located in more than 100 countries and siphoned funds or account credentials from over 7,000 cryptocurrency wallets, according to a new joint cybersecurity advisory.
The primary targets of the campaign are individual web designers, engineers, and specialists in cryptocurrency, blockchain, and Web3 technologies. In all, the threat actors are estimated to have plundered at least $10.71 million worth of cryptocurrency from victims.
The alert comes courtesy of cybersecurity and intelligence agencies from Japan, the U.S., Australia, and Germany. The activity is tracked by the broader cybersecurity community under the monikers CL-STA-0240, DeceptiveDevelopment, DEV#POPPER, Famous Chollima, Gwisin Gang, PurpleBravo, Tenacious Pungsan, UNC5342, Void Dokkaebi, and WaterPlum.
The cyber threat group "conducts cyber attacks by infiltrating unsuspecting job seekers' computer networks, harvesting sensitive information, and stealing cryptocurrency," the alert said.
It's suspected that both WaterPlum and some North Korean IT workers (aka PurpleDelta or Wagemole) operate under the 313 General Bureau of the Munitions Industry Department, corroborating a June 2025 assessment from DTEX. What's more, the two clusters are said to be deeply intertwined, in some cases using the same IP addresses when accessing laptop farms and applying for positions at Japanese cryptocurrency exchanges.
Contagious Interview, first exposed by Palo Alto Networks Unit 42, is a long-running campaign that has been underway since at least 2022, targeting software developers and IT professionals across the wild by posing as prospective employers and recruiters, and approaching them on social media platforms like LinkedIn under the pretext of lucrative job offers.
The backdoor access afforded is then abused by the adversary to deliver remote access trojans for enabling persistent access and data exfiltration.
"Some WaterPlum actors also operate as North Korean IT workers performing web system design and development tasks on corporate web systems for clients," the agencies said, adding a laptop farm operated by a facilitator in Japan has been identified and dismantled.
Furthermore, WaterPlum has been observed using online chat platforms to communicate with U.S. and Japanese developers, while employing enablers in Japan, the U.S., and other countries to set up and manage laptop farms for remote device management.
"Beyond immediate credential theft, successful infections provide WaterPlum actors opportunities to infiltrate organizations employing targeted developers, enabling espionage, intellectual property theft, and additional lateral movement in corporate environments," the agencies noted. "Stolen ID images can also be used by North Korean IT workers to impersonate victims and generate foreign currency."
IT Worker Threat Expands to Discord for Recruiting Proxies
Complementing North Korea's offensive cyber capabilities is the infamous IT worker scheme, which is tasked with generating illicit revenue for the regime by landing jobs in Western companies and elsewhere under false identities. The operation is also known for increasingly relying on artificial intelligence (AI) to craft fictitious identities and expand its activities globally.
Sekoia, in its overview of North Korea's cyber operations, described the IT worker program as an adaptation of an established practice that involved the "dispatch of North Korean labor abroad to earn foreign currency dates to the 1960s and 1970s, beginning with logging in the Soviet Far East before broadening into construction, textiles and restaurant services across Russia, China, the Gulf and Africa."
According to a July 2026 analysis of the internal infrastructure linked to the threat, Kudelski Security said the primary targets appear to be the U.S. and Japan, with the threat actors using VPN services like Astrill VPN and Mullvad to obtain exit nodes in these countries.
In a report published last week, Silent Push said it identified a North Korean IT worker spreading a fake job recruitment scam via a Discord server named "Mouse Review," specifically hiring individuals based in the U.S., the E.U., and Latin America to act as proxies and attend job interviews so as to get around sanctions, geographic blocks, and compliance checks.
The AI-generated job advertisement claims: "YOUR ROLE IS SIMPLE, BUT CRUCIAL. You handle communications and interviews. I handle all technical work behind the scenes. You get paid consistently for your communication."
Facilitators who end up securing a job are eligible for anywhere between $3,000 and $5,000, the ad continues. "For live coding challenges, I can remotely access your screen and complete coding tasks while you continue the conversation smoothly."
"The North Korean IT worker's primary goal is proxy hiring, using Western or Latin American (LATAM) citizens as the 'face' and legal identity to bypass sanctions, KYC (identity verification) controls, and regional hiring restrictions," Silent Push said. "The job ad scam offers a financial incentive split (35% to the proxy, 65% to the North Korean IT Worker) to incentivize foreign nationals to serve as financial and identity mules."
from The Hacker News https://ift.tt/FervXuC
via IFTTT
Google has been fined €403 million for breaking the EU's data protection law, the GDPR, in the way three of its features handled people's location data from May 2018 to February 2020.
Ireland's Data Protection Commission (DPC), Google's lead regulator in the EU, also ordered the company to make its processing comply with the law within 6 months. The DPC has not said publicly which processing the order covers, and it says its full decision will be published later.
The three features are Web & App Activity, Location History and Location Accuracy.
Web & App Activity is a Google account setting that, when turned on, lets Google process data about a user's activity on its sites and apps. That data can include location. Location History, which users must opt in to, keeps track of where they go with their signed-in mobile devices, even when they are not using a Google service.
For both cases, the DPC found that Google breached the GDPR's rules on lawful and fair processing and on transparency, and that it retained location data longer than necessary.
Location Accuracy is an Android feature that works out a device's location more precisely than GPS alone, and it is available to Android users with or without a Google account. The DPC's findings for this feature are narrower.
Google broke the transparency rules and the GDPR's accountability rules because it could not demonstrate that this processing was lawful, fair and transparent.
DPC Deputy Commissioner Graham Doyle said these failures meant people could have been unaware that their location was being used, for example, to influence them with ads or to infer their interests. They could also lose control of their personal data, and keeping it for so long made that worse.
At €403 million, the fine is the fourth-largest the DPC has issued. It cannot be collected yet, because a DPC fine becomes payable only after an Irish court confirms it. Google can appeal to the High Court within 28 days of receiving formal notice of the decision.
In a statement reported by the Associated Press, Google said the case "centers around historical policies that have since been updated" and that it has changed its practices significantly since 2019.
In May 2019, during the period the DPC examined, Google announced auto-delete controls for Location History and Web & App Activity. They let users have that data deleted automatically after 3 or 18 months. In June 2020, Google made 18-month auto-delete the default for Web & App Activity on new accounts and for anyone turning on Location History for the first time.
In December 2023, Google announced that Timeline, the Google Maps feature that shows Location History on a map, would keep its data on users' devices. Auto-delete would also default to 3 months for anyone turning on Location History for the first time.
The DPC has not publicly said whether these changes are sufficient to meet its order.
The DPC opened its inquiry in February 2020 after complaints from European consumer groups, including BEUC, the European Consumer Organization. BEUC's member groups had filed the complaints with national data protection authorities in November 2018. The period the DPC examined ends on 4 February 2020, the day it announced the inquiry.
The decision came more than 6.5 years after the inquiry opened. In comments reported by NewsIreland.EU, BEUC director general AgustÃn Reyna welcomed it but criticized how long it took. "Late enforcement can be as harmful as no enforcement at all," he said.
from The Hacker News https://ift.tt/ixzRZyj
via IFTTT
Cybersecurity researchers have disclosed details of a new campaign dubbed TASK#STOMP that delivers a PowerShell backdoor designed to harvest sensitive data from compromised hosts.
The backdoor "automatically harvests and exfiltrates business documents, watches the filesystem for new files in real time, steals Wi-Fi passwords and clipboard contents, takes screenshots, and accepts arbitrary remote commands through two redundant, token-authenticated C2 servers," Securonix researchers Akshay Gaikwad and Aaron Beardslee said in a report shared with The Hacker News.
The starting point of the infection chain is the use of "wscript.exe" to execute an encoded Visual Basic Script (VBScript) file staged on the victim's desktop ("95c9050t66.vbs"). The exact initial access pathway used to deliver the payload is unclear, although it's possible that it may have been via email-based phishing or social engineering.
By giving it a completely random file name, it's suspected that the intention may have been to evade file name-based detection mechanisms. The VBScript functions as the orchestrator for establishing persistence on the host using scheduled tasks and launching subsequent stages.
The tasks are given the names Local Credential Manager, Network Audio Service, Windows Display Manager, and Device Credential Handler so as to blend in with regular operating system activity and avoid raising any red flags.
The VBScript installer also sets up a backup persistence method that uses the Windows Startup folder to launch another script payload ("msdiag.vbs") every time the user logs in to the system. In the next phase, the malware executes PowerShell commands to forcibly terminate previously running instances and ensure there exists only one active session
These strategies, paired with deliberate timestamp modification (aka timestomping), hidden execution, and cleanup behavior, suggest a deliberate effort to get around superficial administrative reviews and complicate forensic analysis. The use of redundant persistence methods guarantees continued execution even if one of them fails or is detected and removed.
The next phase involves running a pair of hidden PowerShell commands -
sys_loader.ps1, which decodes "diag_pack.dat" and initiates the document-stealing, surveillance, and remote-access
payload to steal system metadata, business documents, Wi-Fi passwords, and clipboard content, monitor for newly modified files, take screenshots, and execute arbitrary PowerShell commands
win_conn.ps1, which decodes "win_conn_cfg.dat" and sets up a secondary, persistent C2 channel with command execution and collection capabilities
"Running the modules as separate processes provides functional separation and operational redundancy: failure or termination of one branch does not immediately remove the other," Securonix said.
Both the modules communicate with the same C2 infrastructure ("corecloudfileshare[.]xyz" or "attachmentsharingdrive[.]xyz"). Interestingly, the two components incorporate a mutual-watchdog relationship in which "diag_pack.dat" checks if "win_conn.ps1" is running, and restart it if not, and vice versa.
The end goal of the attack is to provide a pathway for continuous document collection, credential and clipboard theft, screenshot capture, redundant C2 communications, and arbitrary code execution, while leveraging an array of techniques to fly under the radar.
In the final stage, the VBScript orchestrator opens Google Chrome in a maximized window and opens a specific URL from "irantenders[.]com," which hosts a searchable database of all tenders and contracts issued by government departments and local authorities in Iran. The purpose behind this user-facing web action is unknown.
Also launched is a batch script ("purge.bat") that invokes a two-second delay and likely performs a clean-up to erase traces of the malicious activity. That said, what this batch script does is unknown as its contents have not been recovered.
"Threat actors routinely abuse Windows Script Host, PowerShell, Task Scheduler, and the .NET toolchain to blend malicious execution with legitimate administrative activity," the researchers said.
"TASK#STOMP demonstrates this approach through a VBS-controlled framework that installs multiple persistence anchors and delegates follow-on functionality to PowerShell and dynamically compiled C# code. By relying almost entirely on native Windows components, the operation reduces its dependence on conventional executable payloads and makes individual events more difficult to distinguish from benign system activity."
from The Hacker News https://ift.tt/hd6KzNY
via IFTTT
This article explores how AWS mitigates the security risks associated with publicly exposed Identity and Access Management (IAM) access keys through its AWSCompromisedKeyQuarantine managed policy. We discuss the evolution of the different versions of this AWS managed policy. We also show how the managed policy AWSCompromisedKeyQuarantine evolved over time to protect organizations by relating it directly to new cloud attacks against AWS environments.
Additionally, this article provides background to the partner integration between GitHub's secret scanning program and AWS. Our research details how the managed policy automatically gets attached with a step-by-step timeline of a real-world exposure test.
Finally, the article highlights practical monitoring strategies for security teams to detect quarantine events within their own logging environments to ensure rapid incident response.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
When organizations face attacks against their AWS environments, misuse of AWS IAM user access keys continue to account for a large majority of initial attack vectors. These long-term access keys pose security risks to organizations if the permissions associated with the IAM users do not follow the principle of least privilege.
Access keys and their associated secrets become exposed in many different ways, commonly through publication in public code repositories or exposure in environment variable files. If AWS receives notifications about access keys and secrets exposed in public GitHub repositories or through other notices, it promptly secures those credentials and notifies the owners.
AWS secures the exposed credentials using automated processes, which allows it to quickly support victim organizations and limit their exposure. This automated process has been around for many years and was documented by cloud security researcher Pawel Rzepa in the AWS Access Keys Leak in GitHub Repository and the Some Improvements in Amazon Reaction posts.
Before delving into the importance of the AWSCompromisedKeyQuarantine managed policy and its purpose, we will first discuss how managed policies work within AWS environments.
The AWS IAM service offers various features for configuring identities within an AWS account. In particular, AWS provides a policy feature that aggregates permissions into an object for attachment to a principal.
Policies encompass a wide range of types, but this article focuses on identity-based policies. Identity-based policies specifically attach to an identity, while other policy types attach to resources or define permission limitations, such as a permission boundary.
These policies consist of managed (AWS-managed and customer-managed) and inline policies. Managed policies include three sub-types:
Figure 1. Breakdown of IAM features in relation to main IAM service.
AWS-managed policies exist to assist organizations with IAM permission management. They also enable organizations to configure permissions to stand up resources within an AWS account swiftly and securely. Of the AWS-managed policies, AWSCompromisedKeyQuarantine specifically helps protect an IAM user in case of an exposed AWS IAM access key and secret. Access keys grant long-term command line interface (CLI) access to an IAM user.
AWS created the AWSCompromisedKeyQuarantine managed policy on Aug. 11, 2020, later releasing V2 on April 21, 2021, and V3 on Aug. 21, 2024. According to the V3 managed policy description, this policy:
“Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly. The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources. Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event.”
We will cover the evolution of the policy permissions and the implication of those changes in the Managed Policy Permission Evolution section of this article.
Analyzing this policy in detail matters because AWS automatically attaches it upon locating exposed credentials in public code repositories or external exposure notifications. The AWSCompromisedKeyQuarantine managed policy proactively assists customers during access key exposures to minimize potential damage from attackers. Once attached, the managed policy limits the scope of permissions associated with the IAM user by denying various permissions commonly misused by threat actors.
GitHub Secret Scanning Partner Program
Long-term access keys can be exposed in many different ways. For example, it could be due to them being included in publicly accessible environment variable files and or public code repositories.
The GitHub secret scanning partner program allows it to scan public surfaces across GitHub, including repositories and public npm packages for specific sequences to identify exposed credentials. These scans occur by default within public repositories. Administrators and owners can also enable scanning on private repositories. Service partners can work with GitHub to create specific sequences for scanning and then provide an HTTP endpoint for GitHub to alert the service provider to exposed credentials in public repositories.
This alert allows the service provider to then proactively notify their customers about exposed credentials, and in some cases, the service providers take steps to secure the secret by revoking or quarantining the exposed secret. GitHub documentation lists more than 500 detectors across over 200 service partners, such as AWS. The checkbox in GitHub’s documentation notes when GitHub has an agreement to share compromised secret leaks with the respective issuer.
Managed Policy Attachment and Notification Process
When AWS first released the AWSCompromisedKeyQuarantine managed policy, the notification process differed from the current iteration. The original process entailed emailing the AWS account owner of the exposure. The process evolved to also attach the managed policy to the IAM user associated with the exposed access key and secret. The process has evolved again to include a support ticket generated within the AWS account containing the exposed access key.
We performed a test exposing an access key with a public GitHub repository in the main branch to track the response time and notification process. During the test scenario, AWS attached the AWSCompromisedKeyQuarantineV3 managed policy within 10 seconds of the access key exposure. A second later, GitHub generated a notification. This was followed shortly by AWS generating various Health and Support tickets.
The timeline below details each step of the testing process with commentary about what actions appear in the default AWS CloudTrail logs. The CloudTrail service, enabled by default for 90 days, records all management events occurring within an AWS account. During the test, we did not enable any additional CloudTrail data events so all the events in the timeline appear in the default CloudTrail logs. All times listed below are in Coordinated Universal Time (UTC).
Dec. 19, 2025 17:28:39 - CreateUser - CloudTrail logs showed the creation of the initial IAM user with the arbitrary username TestUser
Dec. 19, 2025 17:29:44 - CreateAccessKey - CloudTrail logs showed the creation of the new access key associated with the newly created IAM user
Dec. 19, 2025 17:34:23 - GetCallerIdentity - CloudTrail logs showed the initial test of the access key with aws sts get-caller-identity
Dec. 19, 2025 18:46:57 - When trying to push a new text file into the GitHub repository, GitHub push protection noted that it identified an access key and secret, as noted below in Figure 2. Both the access key and the secret each generated a pop-up asking whether the push with the credentials was purposeful.
Figure 2. GitHub notification of an AWS access key.
Dec. 19, 2025 18:50:05 - Access key and secret successfully pushed to public GitHub Repository
Dec. 19, 2025 18:50:15 - CloudTrail logs show the attachment of the AWSCompromisedKeyQuarantineV3 managed policy with the AttachUserPolicy event as noted in Figure 3. The CloudTrail log did not indicate this was an AWS automated action. Instead, the userIdentity JSON field, which identifies the action's performer, listed the IAM user's name (TestUser as shown in Figure 4) even though TestUser did not perform this action.
Figure 3. AWSCompromisedKeyQuarantineV3 managed policy attached.Figure 4. JSON entry from the CloudTrail log.
Dec. 19, 2025 18:50:16 - GitHub also sent out an email notification stating that it identified the sensitive access key and secret. Figure 5 shows the body of this email notification.
Figure 5. Content from the GitHub email notification.
Dec. 19, 2025 18:50:17 - In the AWS console, a notification appeared noting that an AWS Health alert was created with the name Risk IAM quarantine, as noted below in Figure 6. This action did not generate an event in the CloudTrail logs.
Figure 6. AWS console showing the Health alert.
Dec. 19, 2025 18:50:26 - AWS also sent out an email notification, shown below in Figure 7. This contained the same information as a Support ticket created seconds later in the AWS console.
Figure 7. Content from the AWS email notification.
Dec. 19, 2025 18:50:59 - In the AWS console, a Support case was also created with details of the exposed access key and IAM user. Figure 8 shows the details of this case. Creating a Support case also did not generate an event in the CloudTrail logs.
Figure 8. Details of the Support case in the AWS console.
Figure 9 shows the high-level chain of events from the timeline illustrated in Figures 2–8.
Figure 9. Access key and secret exposure test scenario high-level timeline.
Within some organizations, the cloud engineering teams monitor emails regarding an AWS account and the security team is unaware of these emails. To prevent these communication gaps, security professionals can leverage AWS Systems Manager Explorer which helps aggregate AWS Support cases. The security team can also proactively enable alerting in the tool of their choice, based on the attachment event in the CloudTrail logs.
Within the CloudTrail logs, when any version of the AWSCompromisedKeyQuarantine managed policy gets attached to an IAM user, the event name AttachUserPolicy with the event source of IAM will be generated. The name of the managed policy will be present within the requestparameters subfield PolicyArn. This helps security teams proactively stay on top of exposed credentials and quickly begin investigating the access key in question.
Managed Policy Permission Evolution
After the initial release of the AWSCompromisedKeyQuarantine managed policy on Aug. 11, 2020, AWS has continued to update the policy to keep protecting their customers from new threats. AWS performs two types of version updates for managed policies. In minor updates, AWS makes changes to the permissions in the policy and updates the policy version without changing the managed policy name. In major updates, AWS creates a new managed policy and appends vX with the new version number to the end of the policy name.
Originally, the permissions of AWSCompromisedKeyQuarantine v1 focused on limiting 28 actions for the following five services:
However, with each new version of the managed policy, those permissions have evolved and expanded.
The code snippet below from the AWSCompromisedKeyQuarantine v1 managed policy JSON permissions details the full JSON permissions associated with the first version of this managed policy. Unlike traditional managed policies, this specific policy contains a Deny effect on permissions. After identifying an exposed access key, AWS does not need to modify the existing permissions associated with the IAM user to protect the identity from exploitation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Deny",
"Action":[
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:CreateInstanceProfile",
"iam:CreateLoginProfile",
"iam:CreateRole",
"iam:CreateUser",
"iam:DetachUserPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy",
"iam:UpdateAccessKey",
"iam:UpdateAccountPasswordPolicy",
"iam:UpdateUser",
"ec2:RequestSpotInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"organizations:CreateAccount",
"organizations:CreateOrganization",
"organizations:InviteAccountToOrganization",
"lambda:CreateFunction",
"lightsail:Create*",
"lightsail:Start*",
"lightsail:Delete*",
"lightsail:Update*",
"lightsail:GetInstanceAccessDetails",
"lightsail:DownloadDefaultKeyPair"
],
"Resource":[
"*"
]
}
]
}
Simply attaching these AWSCompromisedKeyQuarantine policies with the Deny component helps limit unauthorized usage of the key. When interpreting IAM user permissions, AWS dictates that explicit Deny overrides explicit Allow. So even if the IAM user permissions contained iam:CreateUser with an Allow for the effect, the AWSCompromisedKeyQuarantine managed policy containing iam:CreateUser with a Deny for the effect will override the Allow.
If the IAM user had completely different permissions than those listed below, then the purpose of the identity would not be impacted by these permission limits. Since the attachment of this specific managed policy occurs automatically, AWS wants to balance operational impact with securing the exposed credentials.
Another policy exists, AWSDenyAll, which denies all actions. However, this has a significant impact on any processes using the access key and secret. The AWSCompromisedKeyQuarantine policy limits the majority of risky threat actor activity while also allowing normal business operations.
AWS purposefully denies specific actions rather than completely disabling the compromised access key or user password. However, this decision allows advanced threat actors to use the exposed credentials for any actions the policy does not explicitly deny.
With AWSCompromisedKeyQuarantineV2, released on April 21, 2021, the permissions evolved to include the Amazon Simple Storage Service (S3) service with 11 permissions and 16 additional permissions to the original five services. Throughout the five versions of AWSCompromisedKeyQuarantineV2, AWS ultimately added a total of 61 permissions to the Deny list across 17 services.
When reviewing the different JSON permissions within v1 and v2 of AWSCompromisedKeyQuarantineV3, we identified that it replicated the additions to AWSCompromisedKeyQuarantineV2 v4 and v5 and added no additional permissions. Tables 1–3 detail the modifications made throughout each version of the managed policy.
Managed Policy Version
Version Release Date
Permissions changed
v1
2020-08-11 18:04:13
N/A
Table 1. AWSCompromisedKeyQuarantine permission changes per version.
Table 2. AWSCompromisedKeyQuarantineV2 permission changes per version.
Managed Policy Version
Version Release Date
Permissions changed
v1
2024-08-21 17:36:49
Same as AWSCompromisedKeyQuarantineV2 v4
v2
2024-10-02 16:52:27
Same as AWSCompromisedKeyQuarantineV2 v5 AWSCompromisedKeyQuarantineV3 v2 created 11 minutes after AWSCompromisedKeyQuarantineV2 v5
Table 3. AWSCompromisedKeyQuarantineV3 permission changes per version.
After releasing a new version, AWS stops attaching older policies to the exposed IAM users. Starting with AWSCompromisedKeyQuarantineV2, the Support service contains the support ticket with the attachment details as outlined in Table 1.
Cloud Attack Transition Based on Policy Updates
The evolution of the AWSCompromisedKeyQuarantine managed policy reflects how threat actors have changed their attacks against AWS environments. This section discusses an example permission added to the various versions of the managed policy and illustrates how various attacks might have caused that addition.
Let’s start with iam:CreateRole and lambda:CreateFunction in the AWSCompromisedKeyQuarantine v1 managed policy. This AWS Security Blog discusses how AWS uncovered a cryptomining campaign. Part of the attack involved creating a new IAM role to attach to the threat actor-created Lambda function. Once attached, the AWSCompromisedKeyQuarantine managed policy would have prevented this threat actor from creating a Lambda function and role.
The AWSCompromisedKeyQuarantineV2 v1 managed policy contains the s3:DeleteObject action. As discussed in an InfoRisk Today article, threat actors delete data from S3 buckets after exfiltration to maximize impact and encourage payment of extortion fees. Once again, if attached, the managed policy would have prevented the threat actor from successfully deleting all the data from the S3 bucket.
To counter malicious activity targeting the Amazon Bedrock service, AWS expanded v5 of the AWSCompromisedKeyQuarantineV2 managed policy to restrict five Bedrock permissions. This update was directly influenced by research from Permiso, which exposed how attackers exploit Bedrock to run unauthorized API calls like InvokeModel. Due to these policy enhancements, the attack methods uncovered by Permiso can now also be blocked.
GitHub Validity Checks for Detecting Secrets Exposure
GitHub has also created validity checks as part of its GitHub Secret Protection program (a subprogram of the GitHub Advanced Security program, or GHAS). When enabled, these checks periodically verify the validity of a detected credential by testing it against API endpoints provided by that service provider.
A list of supported secret scanning patterns can be found within the GitHub support secret scanning patterns documentation. Once GitHub identifies a secret, the platform proactively checks with various service providers to determine whether the exposed secret remains active or inactive, or whether it cannot be confirmed. GitHub also performs GET requests with the exposed credentials to confirm the credential’s validity and filters out dummy data.
After exposure of long-term AWS access keys in GitHub repositories, these GET requests take the form of performing the AWS Security Token Service (STS) API call GetCallerIdentity. This API event subsequently appears in the CloudTrail logs for the specific AWS account containing the exposed access key. Our testing triggered the newer push protection features that assist with catching secrets before they’re pushed to repositories.
A note of caution: There are some scenarios where push protection may will not scan a code push or alert on all identified secrets:
In one scenario, push protection does not detect secrets in the event of an overly large code push (e.g., pushing thousands of files or a public repository exceeding 50 MB)
In another scenario, if a single code push contains more than five exposed secrets, only five will generate alerts
These scenarios could result in an identification gap. Security teams should monitor for these potential cases to ensure additional scanning occurs on those code pushes, preventing any missed secrets.
Our testing generated CloudTrail logs that contain IP addresses, which resolve to the GitHub Autonomous System Number (ASN). The user agent present within the logs identifies the API event as originating from an automated testing process.
In early October of 2025, GitHub updated the user agent associated with AWS credential checks from:
Note: The above user agent strings use an asterisk (*) as a wildcard value for the version numbers.
Organizations need strong internal relationships between teams managing the organization’s GitHub repositories and cloud environments to promptly address exposed credentials. To circumvent organizational inefficiencies and issues between teams, security teams can also monitor for these exposed access keys by creating alerts specifically around GitHub ASN IP addresses with the above user agents performing GetCallerIdentity. This helps security teams proactively monitor exposed credentials and quickly begin investigating the access key before a potential attacker can misuse it.
Conclusion
The creation of the AWSCompromisedKeyQuarantine managed policy has proactively secured many organizations against unknowingly exposed IAM access keys and secrets. As the managed policy evolves, it reflects how attackers change their tactics when targeting cloud environments. Using the attachment of the managed policy and the presence of the GitHub validity check user agent, organizations can quickly address an exposure and investigate potential unwanted activity.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
Idira Privilege Access Management (PAM) can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.
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: 00080005045107
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.
![A screenshot of an email alert from AWS Support. The subject is "[Action Required] Your AWS Access Key is Exposed for AWS Account." It includes a table with customer and account details, and a detailed message advising actions to secure the exposed AWS access key. The message outlines steps for rotating the access key and includes links for additional resources.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/09/word-image-286681-186917-8.png)
