Welcome to this week’s edition of the Threat Source newsletter.

“The darkest period of my life, so far, arrived the summer I was pregnant with my eldest son. The future was growing in me with all of its terrifying unpredictability, and I found myself anxious, unable to work and woefully at sea.” — Lauren Groff  

I doubt Lauren had this maniacal infosec news cycle in mind when she wrote about the terrifyingly unpredictable future, but honestly, she’s got our current careers down cold. Let he who is not woefully at sea cast the first water balloon? I’ll work on it.  
  
Here we are with PHP taking up every available ounce of oxygen, Node.js adding its own spice to the sauce... and here’s me, staring my screen blankly, waiting for an original thought to leak out and onto this page. Not to worry, none have. There is simply nothing novel to say because the entire internet has it covered. In triplicate. With graphs and compelling statistics and AI-generated evil bad guy images galore.  

These vulnerabilities are serious, and the remediations matter. Teams need to know what they run, find the affected systems, and get them patched and determine ways to secure systems that can’t be patched. I’m simply not going to add another dramatic headline to the stack or pretend there’s a clever new angle hiding in the margins. The thing I keep looping on is that the work underneath the headlines is familiar and it’s the real story. To defend your environment, you need a team that knows that environment, has enough time and expertise to investigate the telemetry, that can tell an anomaly from the usual benign noise, and take action. Yes, the right tools help, and without them you can’t do it — but the people doing the work are still what make those tools useful.  

Give smart people enough room to do smart people stuff. This is the entire ballgame. Read it again: Give smart people enough room to do smart people stuff. Because a good response starts way before the headline. Know what you own, who owns it, what version is running, whether it can be reached from the internet, what identities can do what task on the device, etc. When a fix is available, make sure it actually reaches the system you meant to fix. If a system cannot be updated yet, give that exception an owner and a deadline. Reduce its exposure, add monitoring, and keep checking until the fix is in place. “We’ll get to it” is not a plan.   

So, there may be nothing new to say about PHP this week, but the work is still worth talking about: Know your environment, take care of your team members, and keep paying attention when the weird thing stops being weird and starts becoming evidence. When the next headline arrives, help your teammate do the same.  

“The only thing that makes life possible is permanent, intolerable uncertainty: not knowing what comes next.” — Ursula K. Le Guin 

The one big thing  

Cisco Talos has recently discovered "NIK C2," a new command-and-control framework that integrates AI directly into its attack chain. This Go-based Windows implant allows adversaries to dump credentials, stream keystrokes, and deploy screen-locking ransomware. It also uses an integrated OpenAI model to analyze harvested data on the fly. By hijacking the victim's own API keys to fund these requests, NIK C2 collapses data collection and exploitation into a single, continuous session. 

Why do I care? 

By embedding a live AI pipeline directly into the C2 loop, NIK C2 turns a compromised host into an active operational asset rather than a passive foothold. Because it processes data and generates context-aware payloads locally, it erases the offline processing delays that historically gave defenders a critical detection window. Furthermore, by piggybacking on the victim's OpenAI account, threat actors completely mask their infrastructure, leaving no attributable trace and complicating incident response. 

So now what? 

Defenders must embrace continuous behavioral vigilance. Ensure endpoint solutions monitor for unusual local proxy routing, unexpected PowerShell executions, and unauthorized access to browser databases or crypto wallets. Update your defenses using the ClamAV signature and indicators of compromise (IOCs) provided in the full blog. 

Top security headlines of the week 

CISA gives agencies days to patch critical PHP bugs 
CISA added the two vulnerabilities in the PHP open-source scripting software to the Known Exploited Vulnerabilities (KEV) catalog Monday. (Federal News Network) 

Node2Shell: Brotli flaw triggers patching across Microsoft, Node.js, Python packages
An out-of-bounds write in Google’s Brotli decoder affects Node.js, .NET, PowerShell, and Python packages, and can lead to code execution. (SecurityWeek) 

Gheist uses stolen GitHub tokens to steal private repository secrets via Actions logs 
Each workflow sits on a new branch named ci-sync- followed by six random characters. Deleting a branch, or the run it started, does not undo the exposure. (The Hacker News) 

Japan internet giant GMO says hackers posted stolen customer data 
GMO Internet is investigating a data leak after suspected unauthorized access to its Onamae cloud desktop service, which provides virtualized desktops to financial traders. (TechCrunch) 

Third Serengeti sweep tops 1,400 arrests as investigations mature 
Interpol's annual Operation Serengeti, now on its third iteration, led to 1,462 arrests across 20 African countries and the U.S., recovering $105 million in stolen funds. (Dark Reading)

Can’t get enough Talos? 

Stealing AI secrets and breaking EDRs 
Phishing may have dropped from last quarter's highs, but ransomware engagements climbed as attackers shifted their focus toward disabling EDR systems and scraping AI credentials. The financial sector also returned as a top target. 

From federal SOCs to Talos: Ryan Fetterman on practical security research 
What does it mean to be "blue collar" for the blue team? Amy sat down with security researcher Ryan Fetterman to discuss his journey from federal agency work to his new role at Talos. 

The Guy Who Invented Pain (plus first reactions to PHP2Shell) 
David Bianco built the Pyramid of Pain, so we offered him some more. David joins the Beers with Talos crew for a conversation how AI changes about his famous model, how EvidenceForge creates simulated incidents for research and training, and why his red-team entrance exam didn’t go to plan. 

Compromised eMudhra intermediate certificates 
Cisco Talos is aware of eight compromised intermediate certificates belonging to the intermediate certificate authority. eMudhra has revoked the certificates and stopped issuing new certificates under its G3 root. 

Two critical RCEs in PHP core 
Two critical remote code execution vulnerabilities in PHP core could have implications across its wider ecosystem. This blog explains what we know so far, and details the Snort coverage available. 

Upcoming events where you can find Talos 

• SAINTCON (Oct. 26 – 30) Provo, UT 
• CYBERWARCON (Nov. 20) Arlington, VA 
• AVAR 2026 (Dec. 2 – 4) Hyderabad, India 
• Black Hat Europe (Dec. 7 – 10) London, U.K. 

Most prevalent malware files from Talos telemetry over the past week  

SHA256: 73a25ff8893260418c2271b863c567e40e842adbab3c57023cb72de590ea377d 
MD5: 0cf0271c3564881fce95f44c649bd745 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=73a25ff8893260418c2271b863c567e40e842adbab3c57023cb72de590ea377d 
Example Filename: KMSAuto++.exe 
Detection Name: HackTool:WZTeam-tpd 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: sample.exe 
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: 7fc50b69b56bfdfa9fc0a3e088ff13904587d6336a51e9edcc7919cba83d4e3f 
MD5: cca616647db9370c88998ae25da6997f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=7fc50b69b56bfdfa9fc0a3e088ff13904587d6336a51e9edcc7919cba83d4e3f 
Example Filename: cca616647db9370c88998ae25da6997f.exe 
Detection Name: Win.Tool.Kmsauto::1201 

SHA256: 58d6fec4ba24c32d38c9a0c7c39df3cb0e91f500b323e841121d703c7b718681 
MD5: f1fe671bcefd4630e5ed8b87c9283534 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=58d6fec4ba24c32d38c9a0c7c39df3cb0e91f500b323e841121d703c7b718681 
Example Filename: KMSAuto Net.exe 
Detection Name: W32.58D6FEC4BA-95.SBX.TG 

SHA256: fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f 
MD5: 207d9d891ac756b2bfad88aba5682c65 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f 
Example Filename: sample.exe 
Detection Name: W32.FED979F93B-95.SBX.TG

Phishing remained the leading initial access technique, appearing in slightly over one-third of all Cisco Talos Incident Response (Talos IR) engagements — a decrease from over 50 percent last quarter. In addition to traditional phishing links and attachments, we observed numerous threat actors conducting voice phishing (vishing) in tandem with IT desk impersonation to socially engineer the victim into allowing remote access via a legitimate remote monitoring and management (RMM) tool. Exploitation of public-facing applications was the next most common vector, accounting for one-third of Talos IR engagements. Threat actors predominantly targeted edge devices such as security gateways and remote network management interfaces. These are critical components within enterprise environments, often responsible for managing authentication, network traffic, or sensitive data. Compromising them can provide broad access to internal networks or user credentials. 

Ransomware and pre-ransomware incidents made up 27 percent of engagements in Q3 2026, an increase from a maximum of 20 percent seen in the previous four quarters. Talos responded to attacks involving prolific, technologically advanced, and well-established ransomware-as-a-service (RaaS) variants such as The Gentlemen, Qilin, and Rhysida, as well as Interlock, which operates as a closed group. Threat actors predominantly chose to disable endpoint detection and response (EDR) systems, often by exploiting vulnerable drivers or using Windows Defender Application Control (WDAC). Additionally, we observed the emerging ransomware variant VYPR, whose operator(s) tested a range of tactics, techniques, and procedures (TTPs) instead of following a standard attack method or affiliate playbook.

Salt Typhoon-affiliated threat actors exploit public-facing application vulnerabilities for cyber espionage 

Talos IR continues to see prolonged cyber espionage intrusions targeting the telecommunications sector. Talos attributed most of these intrusions with high confidence to China state-sponsored threat actors, including Salt Typhoon. The attackers in these intrusions routinely gain initial access by leveraging valid credentials and exploiting a known vulnerability (CVE-2023-20198) in publicly accessible web-based management interfaces—two of the most frequently observed initial access vectors this quarter. In one campaign, the threat actor deployed BadCandy, a malicious web shell implant known to be leveraged by Salt Typhoon, to maintain persistent and stealthy remote access. 

The adversaries continue to employ living-off-the-land (LOTL) tactics, leveraging legitimate network infrastructure features — such as VPN access, traffic mirroring, and management protocols — to establish backdoors, exfiltrate data, and conduct reconnaissance. Exploiting a vulnerability in the web-based management interface, they created privileged accounts, disabled logging to conceal their activity, and altered configurations to maintain persistence, blending their actions with normal administrative operations to evade detection.   

These intrusions revealed several security weaknesses in the victim environment, including reliance on password-only authentication without evidence of multi-factor authentication (MFA), use of legacy and weak management protocols (such as plaintext SNMP and outdated VPN encryption), and inadequate credential management practices. Attackers were able to create and abuse privileged accounts, disable logging, and manipulate configuration settings without encountering effective security barriers, enabling persistent and stealthy access. The absence of strong MFA and robust credential management are two of the most frequently observed security weaknesses this quarter. 

AI exploited as a weapon and a target 

Recent Talos IR investigations highlight the growing role of artificial intelligence (AI) in cybercriminal activity, both as a tool and a target. In one case, an internal threat actor who was hired under false credentials abused their privileged access to install AI-powered development tools, such as GitHub Copilot CLI and Anthropic Claude Code. While the investigation did not find evidence of malicious activity or data theft, the employee’s developer-level access — including cloning repositories, configuring plugins, and connecting to databases — could have enabled them to use AI tools to automate malicious actions within the organization. 

A second investigation revealed an attack chain in which a compromised macOS endpoint, infected via a trojanized application, was scripted to scrape credentials from the macOS keychain specifically associated with the Anthropic Claude Code AI assistant. This direct targeting of AI-related secrets highlights an emerging threat, where attackers seek to compromise not only traditional user and system credentials but also those tied to AI platforms, which may grant access to additional sensitive data and advanced automation capabilities.  

These incidents highlight the critical need for organizations to implement strong MFA and robust credential management practices, especially for AI platforms and development tools. 

Ransomware trends 

Ransomware and pre-ransomware incidents increased from a little over 20 percent last quarter to 27 percent in Q3, involving well-known threat groups like Interlock and the emerging ransomware VYPR. Frequently observed techniques involved deleting EDR systems and socially engineering victims into initiating remote management sessions.

Emerging ransomware variant: VYPR 

During a Talos IR engagement, we observed a ransomware variant called “VYPR” that we assess is relatively new and still operationally immature. This assessment is supported by the absence of an established data leak site (DLS), as none was referenced in the ransom note and associated DLS infrastructure was not created until after the engagement. The group also appeared to rely on older leaked Conti-derived source code with only minimal modifications, reflecting a relatively unsophisticated technical approach. Their operations further suggested experimentation rather than a refined playbook, as they took an unusually long time to exfiltrate and encrypt data while testing different exfiltration parameters and deploying multiple vulnerable drivers to disable EDR protections.  

The actor gained initial access through voice phishing (vishing); they tricked a user into initiating a Microsoft Quick Assist session, allowing remote access to the endpoint. While the exact social engineering technique was not confirmed in this case, threat actors frequently impersonate IT help desks during vishing calls to manipulate victims into establishing remote connections — a tactic observed in several other Q3 engagements.  

The actor was then able to utilize existing RMM software, which subsequently executed PowerShell commands to download and install a Microsoft Software Installer (MSI) package from a remote IP address. During the attack, the actor leveraged tools that are commonly observed during ransomware investigations, including MeshAgent, Rclone, PsExec, IP scan, and Microsoft Terminal Services Client (MSTSC). Notably, we saw exfiltration over multiple days, which is not commonly observed during ransomware investigations.   

EDR killers: Why evade detection when you can destroy it?  

We observed several instances where ransomware operators disabled EDR systems, prioritizing direct disruption of security controls. We observed Interlock ransomware actors making multiple attempts to impair endpoint detection EDR capabilities by trying to uninstall Cisco Secure Endpoint (CSE) on compromised systems and used tools such as PsExec.exe and taskkill.exe to terminate security services and integrity checkers, including cscm.exe and sfc.exe. Additionally, the adversary disabled Windows Defender real-time protection and cleared various event logs to reduce visibility and hinder forensic analysis. This is in line with previously observed Interlock activity, where they deployed a malicious WDAC policy to terminate EDR solutions. 

In the previously mentioned VYPR ransomware incident, the threat actor disabled EDR and antivirus (AV) by using Bring Your Own Vulnerable Driver (BYOVD) techniques to evade detection and execute the ransomware. BYOVD attacks take advantage of trusted but flawed drivers to gain kernel-level access, enabling threat actors to disable EDR mechanisms and carry out their operations unimpeded. While this technique is commonly observed in ransomware attacks, this actor deployed an unusually large number of vulnerable drivers in the environment, possibly to create redundancies and maximize their chances of success. 

Targeting 

Targeting of the financial industry increased from last quarter to comprise 18 percent of all engagements, tying with public administration as the most targeted sector. Although the financial industry remains a valuable target, Talos has not ranked it among the top three most impacted sectors since 2024. One possible reason is that organizations in finance can typically invest more in cybersecurity, unlike sectors such as public administration, which has consistently been among the top-targeted industries over the past year. Meanwhile, health care fell to third place after ranking as the most targeted industry for the previous two consecutive quarters.

Initial access 

While the number of engagements involving phishing as an initial access vector declined from last quarter, it remained the most common technique, appearing in 37 percent of Talos IR engagements. Exploitation of public-facing applications was the second most common initial access vector, accounting for 33 percent of engagements.

Recommendations for addressing top security weaknesses 

The most common security weaknesses observed this quarter were insufficient logging, improper credential and secret management, and absent or improperly implemented authentication and MFA. These trends closely mirror last quarter, when insufficient logging and authentication weaknesses were also prevalent.

Centralize logging and set retention requirements 

The leading security weakness was insufficient logging leading to visibility gaps, seen in over 40 percent of engagements this quarter. These gaps were in part due to the common threat actor practice of deleting logs, and in part due to insufficient log retention or configuration implemented by the customer. Talos IR recommends implementing a SIEM or centralized logging platform with a minimum of 90 days of retention, forwarding logs from servers, workstations, network infrastructure, cloud identity providers, and security appliances off-device so they survive log tampering and host rebuilds, and enabling process-creation, command-line, and cloud API (e.g., Microsoft Graph) auditing. Talos IR's Log Architecture Assessment service can identify gaps and provide a roadmap to a complete view of the environment. 

Tighten authentication and MFA controls 

Missing or insufficient authentication and MFA controls were the third most common security weakness this quarter, observed in 33 percent of engagements. The most prevalent issue was reliance on single-factor authentication, which allowed unauthorized access in several incidents. In many cases, legacy authentication protocols were still enabled, enabling adversaries to log in without any MFA requirements, and some environments failed to enforce MFA for high-privilege accounts. To reduce this risk, Talos IR recommends transitioning from push- and SMS-based MFA to phishing-resistant methods such as FIDO2/WebAuthn and hardware security keys. Organizations should also restrict self-service MFA enrollment by requiring helpdesk verification, block legacy authentication through Conditional Access, enforce number matching or verified push where phishing-resistant methods are not yet feasible, and condition access on device compliance and trusted infrastructure rather than geographic location alone.    

Safeguard credentials and secrets 

Improper credential and secret management was the second most common security weakness seen in 33 percent of engagements this quarter, reinforcing the importance of security awareness training and consistent security hygiene for every user. Observed security issues included unsafe storage and handling of credentials, such as saving passwords in browser stores, poor control mechanisms like permitting autofill for browser-stored credentials, and credential reuse and sharing. Effective secret management begins with a formal process that covers passwords, API keys, tokens, certificates, and other sensitive credentials. By requiring unique passwords for every account and encouraging the use of password managers, organizations reduce the risks associated with credential reuse and sharing. Storing secrets securely, with encryption and access restricted to only those who need them, further strengthens protection. When credentials are no longer necessary or are suspected to be compromised, they should be promptly revoked and replaced. Regular reviews of access to privileged credentials, combined with thorough logging, help detect unusual activity. Equipping staff with training on safe handling and clear reporting procedures ensures that accidental disclosures are addressed quickly and effectively.

Tales from the Frontlines: An exclusive briefing on Q3 incidents

On November 12, Talos incident responders will be hosting an exclusive, unrecorded 30-minute webinar to review the most high-impact incidents our customers faced in Q3. Designed for security professionals of all levels, this is a candid discussion of what happened, how we handled it, and what it means for your organization.

Registration is required to attend. Don't miss this chance to hear real-world stories from the frontlines of cyber defense, directly from the team who lived them.

MITRE ATT&CK appendix 

The table below represents MITRE ATT&CK techniques and tools observed in this quarter’s IR engagements, including relevant examples. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic based on the way they were leveraged. Please note that this is not an exhaustive list.

Key findings from the MITRE ATT&CK framework include:

• The rise of phishing and the frequent use of valid accounts for initial access and lateral movement both highlight how attackers continue to rely on methods that have remained consistently effective year over year.
• Attacker success consistently reflects basic weaknesses in enterprise security posture, with persistent exploitation of known vulnerabilities — especially in internet-facing applications — demonstrating that adversaries continually scan for and opportunistically target unpatched systems.
• The most used techniques to maintain persistence were deploying web shells and creating scheduled tasks, demonstrating that attackers prioritize stealthy, reliable access by leveraging legitimate system components that blend in with normal operations. These techniques enable threat actors to maintain long-term control and quickly re-establish their presence even if some signs of compromise are removed.

NIK C2 implant: AI-integrated remote access tool

The NIK C2 implant is a Go-based, 64-bit Windows remote access tool that grants persistent control over compromised hosts using a resilient dual-channel C2 architecture. It communicates over TLS-secured WebSockets on port 443 alongside an HTTP fallback polling loop every 250 milliseconds, protecting all traffic with AES-256-GCM encryption derived from a hardcoded seed. To survive takedowns, the implant routes traffic across three prioritized C2 tiers, which are runtime-updated URLs, an embedded encrypted server list, and a hardcoded fallback address. Beyond standard operations, the implant features surveillance, theft, lateral movement, and evasion capabilities, including credential dumping, RDP session hijacking, process hollowing, and a C2-driven screen lock ransomware module. 

Notably, the NIK C2 implant embeds a fully integrated OpenAI API client via its ai_generate command, allowing operators to route arbitrary prompts to the OpenAI Chat Completions API directly through the infected host. The NIK C2 implant manages API key resolution, request assembly, and response parsing locally, returning the encrypted generative AI results to the actor's C2.

The observed NIK C2 implant samples in the wild contains an embedded build path (/opt/nik_panel/data/build_52b79724a1fc4b8f/main.go), which identifies the project as "nik_panel" and indicates that the implant was cross compiled for Windows from a Linux development environment. Furthermore, the embedded eight-byte hex token matching the build identifier highlights that the threat actor's infrastructure actively tracking and versioning the implants. 

NIK C2 implant evolution timeline 

Talos observed that the NIK C2 implant development trajectory spans at least three distinct versions. All binaries observed in the wild were compiled with Go 1.23.4 (which was released in December 2024), placing the entire sample set compiled no earlier than late 2024. The actor has Zeroed PE TimeDateStamp fields and near-epoch filesystem timestamps (manifesting as Nov 29, 1979) are applied consistently across all samples.  

We developed a timeline based on the initial sighting dates of NIK C2 implant variants in OSINT. 

The pace of capability addition across the three versions indicates a technically proficient team with prior malware operations experience is actively expanding NIK C2 towards a full-service adversarial framework. 

Active NIK C2 server seen in the wild  

During our research, we observed that a threat actor hosted the NIK C2 framework on a server at IP address “87.120.196[.]120”, resolving the domain “total-sitevv[.]lol”. The C2 server hosted an SSL/TLS certificate (serial number 7d16381a9de823943b5a0987dbd0f26edf22052b and jarm:"28d28d28d00000000042d42d0000001f361a1bf80ed39a1e352adeb016a07b" ) with the Common Name (CN) set to nik-panel. This CN value matches strings embedded within the implant binary. Observing the NIK C2 infrastructure active in the wild allowed us to assess with moderate confidence that NIK C2 is not merely a proof of concept, but a fully functional, AI-integrated C2 framework. 

NIK C2 implant integrates OpenAI’s API 

AI integration is one of the most architecturally distinct features of NIK C2 implant. It constructs a fully formed HTTP request to OpenAI’s production inference endpoint, transmits it from the victim machine IP address, parses the JSON response, and returns the AI-generated text to the actor’s panel. The entire operation from receiving the actor prompt to returning the large language model (LLM) reply is executed synchronously with a 60-second timeout. 

The implant begins by extracting three fields from the command payload received from the C2. The first field, identified by the key prompt, is the text the actor wants to send to the AI model. If the prompt string has zero length, the handler immediately constructs an error response and returns without making any outbound network call. The second field, identified by the key api_key is the OpenAI API key to use for authentication. The third field, identified by the key model, specifies which OpenAI model to use.  

After extracting the three parameters, the implant checks whether the actor supplied an API key. If not, it calls the operating system's environment variable reader with the string OPENAI_API_KEY and uses the victim’s API key.  This fallback is not a backup mechanism for API key resolution. It is a deliberate design with significant operational implications. If the victim has configured an OpenAI account on their machine, that account's API key will be used to fund the actor's AI inference. OpenAI's billing system will charge the victim's payment method, and OpenAI's access logs will show the victim's API key as the one that made the requests, allowing no trace attributable to the threat actor.  

If the actor does not specify a model name, the implant falls back to a five-character default string stored in the binary data section. Decoding the five-character value showed gpt-4 confirming that GPT4 is the default when no model is specified. The actor can override this by passing any valid OpenAI model identifier in the command payload, allowing selection of newer models as they become available without requiring a binary update.  

The implant builds the OpenAI API request body by constructing a map with four fields. The first field uses the key model and contains the resolved model name. The second field uses key messages and contains a two-element array of message maps. The third field uses the key temperature and contains a floating-point value read from a constant in the binary data section. The fourth field uses the key max_tokens and contains an integer value also read from binary. 

The message array is constructed in the order that the OpenAI Chat Completions API expects. The system message is first followed by the user message. The system message map has the role system and a content string that is exactly 68 bytes long hardcoded in the binary. This 68-byte string is the implant's behavioral instruction to the AI. It defines the model's operational role and response style for the duration of the session. The user message map has the role user and contains the actor's prompt text verbiage. The complete map structure is then serialized to JSON. The JSON message is sent to the URL https:// api.openai.com/v1/chat/completions, the OpenAI Chat Completions endpoint, through an HTTP POST request. 

When the HTTP response arrives with a 200 status code, the handler uses Golang's JSON decoder to parse the response body directly into a generic map structure without defining a typed schema. It then navigates the decoded map by string key lookups in the sequence that the OpenAI Chat Completions API response structure defines. The outermost map is queried for the key choices which in a successful response contains an array. The implant checks that this array is non-empty, then accesses its element keys message and content. The string value at key content is the AI model-generated text response.  

After successfully extracting the AI-generated content, the handler assembles a result map with four entries. The key status is set to a constant string that reads as generated. The key code is set to the AI model's response text, so that the actor receives the full content of the model’s replies. The key model is set to the resolved model name that was used for the request, confirming which model produced the output. The key usage is set to the raw usage object from the OpenAI response, which contains the prompt token count, completion token count, and total token count. This usage data allows the actor to track how many tokens are consumed per request. The completed result map is ultimately transmitted to the C2 server over WebSocket or through the HTTP fallback C2 address. 

Dual execution modes of NIK C2 implant

Upon execution, the implant inspects its command-line arguments to determine its execution path. The argument watchdog activates supervisory monitoring to relaunch the core process if terminated, the copywatchdog tracks file copy operations, and the absence of either defaults execution to primary agent mode.  

In primary mode, it uses a named mutex to enforce single-instance execution, logs a message reading [NIK] Starting, generates a 32-byte cryptographic session key if uninitialized, decodes its obfuscated C2 address, and sets its masquerade name to “svchost.exe” or “simvol.exe”. 

After initial setup, the binary records its process ID (PID) in the victim's temporary application folder and executes its persistence and evasion routines. These routines include copying to %appdata%/Roaming/Microsoft/Network with modified access controls, configuring Windows autostart registry entries, and masquerading its process. Finally, it starts the local proxy server, initiates the WebSocket communication loop in a separate goroutine, and enters a continuous heartbeat polling loop on the main thread. 

Implant’s C2 command surface overview 

The implant command dispatcher module facilitates over 52 commands that are directed by the C2 panel. The dispatcher module uses byte-level string matching to map the associated modules that are launched as concurrent goroutines, allowing multiple operations to run in parallel.  

The following table shows the NIK C2 implant’s command categories: 

Implant deploys screen-locking ransomware  

The ransomware module of the implant operates as a multi-stage attack controller that the actor runs in sequence to prepare, deploy, and retract a screen-locking ransomware payload.  

At first, it executes PowerShell to execute a raw disk copy command that reads directly from the physical drive device path (“\\.\PhysicalDrive0”) and writes the first sector, which is Master Boot Record (MBR), to a file named “mbr_backup.bin” in the Windows temporary directory.  

Next, the module constructs a complete self-contained HTML lock screen code entirely at runtime from a hardcoded format string, parameterized with actor supplied Bitcoin and USDT wallet addresses, prices, contact email, timer duration, and custom text from the C2 command message, allowing the actor to fully customize the ransom demands. 

After generating the HTML code, the binary writes it to the file “lock_screen.html” in the system temporary directory. It then generates a Windows batch script that calls mshta.exe with the path to the HTML file, followed by an infinite loop construct with a five-second timeout between iterations, ensuring that if the user somehow closes the window it reopens within five seconds. This batch file is written to the temp directory as “lock_start.bat”. 

The implant then runs a reg add command that writes a registry Run key named “SystemLock” under the current user's autostart path, pointing to a cmd /c invocation of the batch file, so the lock screen is executed on every user's logon. Additionally, a background goroutine is spawned that continuously monitors and relaunches the lock screen process. Finally, the module sends a confirmation response to C2 with the path of the deployed HTML file and the timer value. 

The design of this ransomware module is notable for several reasons. It does not encrypt any files, which means it leaves no forensic trail of file modification timestamps or encryption markers. It relies entirely on a screen lock, which is considerably faster to deploy than a file encryption ransomware. The persistence via registry Run key and a self-healing loop ensures the screen lock survives user attempts to dismiss it and survives a system restart.  

Implant’s bootkit preparation feature 

The bootkit preparation module of the implant is designed to survey the victim machine's boot firmware environment and then stage a bootkit payload file.  

It executes bcdedit /enum, the Windows Boot Configuration Data editor, with the output flag that enumerates all boot entries while hiding the console window. The implant reads the full output and searches for three specific substrings in sequence including EFI, Windows Boot Manager, and Windows Legacy OS Loader. If any of these are found, the boot type is classified as UEFI. The binary also searches for ntldr, the legacy Windows NT loader used by BIOS-mode systems as a fallback. Based on which string was matched, the boot type is recorded as either "UEFI" or "BIOS" as a string of the appropriate length. Separately, the binary runs a PowerShell command invoking Confirm-SecureBootUEFI, which is a built-in PowerShell command that returns to the current Secure Boot state. The output is searched for the string True to detect an enabled Secure Boot and for False to detect an explicitly disabled Secure Boot.  If neither is present, the value is recorded as unknown. The result is sent back to the C2, a map containing the boot type classification and the Secure Boot status string. 

Then the implant writes a 16-byte placeholder file named “bootkit.bin” to the system temporary directory. The bytes written spell out "NIK_BOOTKIT_PREP" in ASCII, which serves as a staging marker rather than an actual bootkit binary. This placeholder confirms that the target path is writable by the current process, establishes the file location that subsequent operations will reference, and can be overwritten by the actual bootkit binary delivered through the implant's file-upload or file-write command handlers. The path to the staged file is returned to the C2 in response.  

Implant’s theft functionality  

When the actor issues the theft category commands from the C2, the implant executes the associated goroutines to collect the targeted data into a result map space in the victim machine memory: 

WiFi password theft (wifi_steal) 

The implant executes netsh commands directly via Go’s exec.Command function by passing arguments as discrete tokens rather than through a shell string. Harvested results are formatted under specific labels: plaintext Wi-Fi passwords appear under Key Content:, saved network names are cataloged under WiFi Profiles: (with missing entries flagged using the per-entry format [%s] not found), and execution failures or absent interfaces return standardized error strings such as [WiFi] no wireless adapter or access denied and No WiFi profiles found. 

netsh wlan show profiles 
netsh wlan show profile name="" key=clear  

Browser credential extraction (passwords, quick_steal) 

The implant stages targeted browser database files into an archive alongside the Local State file, which contains the AES master key protected by Data Protection Application Programming Interface (DPAPI). The implant imports and executes the CryptUnprotectData Windows API to unwrap the AES key and decrypt the databases locally. Otherwise, it exfiltrates the raw encrypted databases to the C2 server for offline extraction. 

Targeted browser database files are shown in the table: 

Token and cookie theft (token_grab, quick_steal) 

The implant extracts Discord tokens and session cookies from the levelDB store on the victim machine. The extracted outputs are labelled as === Discord Tokens === and DISCORD TOKENS. The browser session cookies (Discord_Cookies) are extracted from the copied Cookies database.  

Cryptocurrency wallet theft (crypto_steal, wallet_export) 

Victim’s desktop-based wallets are collected directly from the wallet storage paths. Browser extension wallets are extracted from chromium LevelDB stored by extension ID. 

Desktop based wallet storage paths targeted are listed below: 

• /AppData/Roaming/Exodus/exodus.wallet 
• /AppData/Roaming/Electrum/wallets 
• /AppData/Local/Electrum/data/wallets 
• /AppData/Roaming/Ethereum/keystore 
• /AppData/Local/LedgerLive 
• wallet.dat (Bitcoin Core) 
• /AppData/Roaming/atomic (Atomic Wallet) 
• Electrum\wallets 

Browser extension wallets targeted: 

Seed phrase, private key file, and system reconnaissance 

The implant performs two regular expression patterns to search on the entire filesystem of the victim machine. These two regular expressions are designed to scan file names for sensitive cryptographic assets and credentials, functioning as case-insensitive patterns ?i. The first expression targets cryptocurrency recovery materials and wallet backups by matching keywords like "seed," "mnemonic," or "wallet" paired with common plain-text and data file extensions (.txt, .md, .csv, .dat), while the second seeks out asymmetric private keys and general secrets using terms like "private," "privkey," or "secret" paired with both text files and standard cryptographic key containers (.key, .pem). Because both patterns use unanchored, greedy matching (.*) without start (^) or end ($) boundary anchors, they capture any file where these sensitive terms precede the target extensions. Matched data are collected under the label of seed candidates and archived into “browserdata.zip”.   

(?i)(seed|phrase|mnemonic|recovery|backup|wallet).*(\.txt|\.md|\.csv|\.dat) 
(?i)(private|privkey|secret).*(\.txt|\.md|\.key|\.pem) 

The implant also performs victim machine reconnaissance by executing the following commands and uses chcp 65001 prefix to force the output in UTF-8 format.  

chcp 65001 >nul 2>&1 & systeminfo 
chcp 65001 >nul 2>&1 & wmic os get lastbootuptime /value 
chcp 65001 >nul 2>&1 & wmic /namespace:\\root\SecurityCenter2 path AntiVirusProduct get displayName 2>nul 
chcp 65001 >nul 2>&1 & Get-Process | Select-Object Id, ProcessName | ConvertTo-Json -Compress 

After all collection paths are complete, the implant assembles all collected data into a single document that looks like a formatted report with clearly labeled sections for each data category such as === CRYPTO ===, === WIFI ===, === BROWSER ===.  

Keylogger: Keystrokes livestreamed to C2 

The keylogger module of the implant uses a persistent background goroutine that polls all 256 Windows virtual key codes, detecting keypresses via dynamically resolved API calls, and transmits the captured input. When a compromised victim presses a valid key on the keyboard, it is simultaneously streamed live as an AES-256-GCM encrypted JSON payload over WebSocket to C2 and also appends to an in-memory buffer capped at 10,000 entries and halved when full to prevent memory leaks. On an actor's dump command, this buffer is concatenated into a single string and returned to C2 via WebSocket or HTTP fallback, ensuring complete data transfer even during network interruptions. 

Stolen data exfiltration to C2 

Once the archive is assembled, the entire result map is handed to the result transmission routine of the implant. That routine constructs a new JSON object containing five specific fields. It includes the command identifier echoed back from the original command. It also contains the agent's persistent identifier, formatted as ag_<16 hex chars>. The type field is set to the string quick_steal_response. Finally, the data field holds the complete result map. 

Once constructed, this object is forwarded to the encryption routine. The routine serializes the object into JSON. It then generates 12 fresh random bytes to serve as a nonce. Next, it encrypts the serialized JSON using AES-256-GCM with a static key derived from a hardcoded seed. It concatenates the nonce, the ciphertext, and the 16-byte authentication tag and Base64-encodes the entire payload. The encrypted payload is placed in a wrapper object under the "e" key alongside the plain-text agent ID, and the wrapper is JSON marshaled into the final payload. 

This encrypted payload is then delivered through an available transmission path. The sending routine first checks whether the WebSocket connection is live. If it is, the payload is written directly into a WebSocket text frame on the existing connection, reaching the actor's panel with minimal latency. If the WebSocket is not currently connected, the routine falls back to an HTTP POST request to the endpoint path /api/c2/result on the C2 server, using the same encrypted body format. This dual-path design ensures stolen data is delivered even during WebSocket interruptions, as the HTTP channel remains functional independently of the WebSocket state. 

Implant’s C2 protocol 

The implant C2 architecture is designed for two independent, simultaneously operating communication channels. The primary channel is a persistent WebSocket connection over TLS. The secondary channel is an HTTP polling loop that posts to a fixed API endpoint at regular intervals. 

With the primary channel, the connection begins with a TCP dial to the C2 server address with an eight-second timeout. If the port is not explicitly present in the configured address, port 443 is appended automatically. Once the TCP socket is established, it is wrapped in a TLS session using a custom certificate configuration that pins to a specific certificate rather than validating against the system's certificate authority store. This prevents standard TLS interception proxies from observing traffic. 

Immediately after a successful WebSocket handshake but before any command is received, the implant transmits a full system registration message. The implant collects victim data such as the machine hostname, the local LAN IP address, the Windows username from the environment, a user security identifier, the local reverse-proxy port number that was assigned when the embedded proxy server was started, and the detected upstream proxy configuration derived from the Windows registry proxy settings. All of this is assembled into a JSON object and encrypted and sent to the C2.  

The HTTP polling channel runs independently. Every approximately 250 milliseconds, the agent collects a fresh snapshot of victim state hostname, watchdog status, local IP, username, current timestamp, and system uptime encrypts it in the same wire format and posts it to the /api/c2/update endpoint on the C2 server.  

Below table shows the C2 endpoints that the implant communicates: 

Every message on both channels, in both directions, uses the same symmetric encryption scheme. A hardcoded seed value stored in obfuscated form in the binary data section is decoded at startup and produces a 32-byte AES key. 

Decoded AES seed: d791dd0ff3228ed29a8d7333d4567be829159c5632ea347780992006f91c5295 
32-byte AES key: 4887AFC0A574E9419A9695EF083460F58E4EF9A1C40793523CE112251273BDF9 

The C2 server then responds with an encrypted payload, whose inner map contains a command array identical in structure to those delivered over WebSocket. Commands received through HTTP are dispatched through the same logic. If the HTTP POST fails, the agent rotates to the next server address before retrying. 

The result transmission to the C2 is performed by the implant when a command handler completes its operation, the result is packaged into a response envelope containing the original command's identifier, the implant's own identifier, a type string formed by appending _response to the command name, the result data payload, and a top-level type marker of "result". This object is encrypted and delivered through either directly over the WebSocket connection if it is active, or via an HTTP POST to /api/c2/result. 

Implant’s defense evasion and anti-analysis techniques 

The NIK C2 implant deploys a layered set of defense evasion measures that activate immediately at startup and operate across the full compromise session. On launch, It hides its console window via API ShowWindow, renames the binary to “csrss.exe” in the Windows temp directory to impersonate a legitimate system process, disables Windows Recent Documents telemetry through a registry write action, and applies a critical-process flag via API NtSetInformationProcess with the parameter value 0x1D for  ProcessBreakOnTermination that causes a Blue Screen of Death if any attempt is made to terminate the process through Task Manager or taskkill actions.  

Alongside these, two anti-debug checks IsDebuggerPresent and CheckRemoteDebuggerPresent run silently and call os.Exit(0) on detection, leaving no exception record or crash evidence. When directed by the C2, the implant can also escalate privileges without a UAC prompt using the fodhelper.exe COM hijack, which writes the implant path into HKCU\Software\Classes\ms-settings\Shell\Open\command, triggers elevation, and cleans the registry key within two seconds. 

The implant bypasses the Antimalware Scan Interface (AMSI) by executing a hardcoded, embedded PowerShell script that patches memory inside “System.Management.Automation.dll”. Specifically, it overwrites the AmsiInitFailed field with a six-byte stub (MOV EAX, E_INVALIDARG; RET), forcing initialization to report failure and disabling content inspection for the remaining of the PowerShell session. 

Conclusion 

The emergence of NIK C2, an AI-enabled command-and-control framework, underscores a critical shift in modern malware design: the transition from static intrusion toolsets to dynamic, modular implants that adapt on demand. By embedding a live AI pipeline directly into the C2 loop, the compromised host is no longer a passive foothold but an autonomous operational asset. Operators can dynamically generate context-aware lure material, execute localized deception, synthesize operational intelligence, and craft targeted payloads directly on the compromised hosts — all while lowering the technical barrier which was traditionally required for such sophisticated tradecraft. 

Coverage 

The following ClamAV signature detects and blocks this threat:  

 Win.Trojan.GoDiscorder-10060526-0 

Indicators of compromise (IOCs)

IOCs for this research can be found at our GitHub repository here.

Talos assesses with high confidence that UAT-11473’s operating infrastructure overlaps considerably with Volt Typhoon’s “Silent Train” covert access network.

KeyDrift is a custom malware framework that is designed to operate in Cisco SD-WAN controller environments. Talos assesses with high confidence that the framework is designed to provide long-term persistent access and automated exfiltration of sensitive keying material. KeyDrift operates inside SD-WAN control-plane processes and is capable of intercepting decrypted control traffic, extracting control-session metadata and data-plane keying material, and staging or transmitting the collected material using encrypted records.

The framework's primary component is PolyFlame, a memory-resident module deployed through modified runit service paths. PolyFlame is injected into legitimate running vdaemon processes, and it can also masquerade as a packed “aaamgrd” loader variant. Once resident, PolyFlame interposes socket, DTLS, and runtime-linker behavior through functions such as recvfrom, sendto, getpeername, dlopen, dlsym, mprotect, and “/proc/%d/maps” parsing. This gives KeyDrift access to SD-WAN control-plane traffic from inside legitimate controller daemon execution rather than through a conventional endpoint beacon.

LittleFilch, another component of the KeyDrift framework, provides the collection and exfiltration capability identified in the framework. The module hooks “SSL_read” inside vdaemon, inspects decrypted control-plane buffers, extracts keying material for a list of predefined edge nodes, and stages the data locally in encrypted format for exfiltration.

Talos assesses with high confidence that KeyDrift's intended operational purpose is Cisco SD-WAN control-plane collection: persistent controller residence, in-band traffic access, key-material extraction from decrypted control messages, and encrypted staging or exfiltration of the recovered material. Observed variations of the KeyDrift modules and deployment mechanisms suggest active development of the framework’s capabilities.

KeyDrift analysis

KeyDrift uses Cisco SD-WAN runit service paths as its primary execution anchor. In the PolyFlame sshd deployment, the actor modifies the service run script, remounts /rootfs.rw executable, launches a malicious script “conf_sshd” in the background, and then starts the legitimate sshd service. The loader script enumerates running vdaemon PIDs, records them in “/tmp/system-vdaemon”, and invokes the injector component “rsshd” to inject PolyFlame (“libdssl.so”) into each process.

Recovered conf_sshd logic uses the same control flow across reviewed samples:

Runit launchers

The observed sshd runit launcher preserves normal Cisco SD-WAN sshd startup logic while adding two malicious lines before service execution, which remount “/rootfs.rw” executable and background execution of conf_sshd, which then drives rsshd injection into vdaemon.

The recovered aaamgr runit launcher from an affected vBond appliance uses a parallel service-wrapper pattern, but it executes the packed aaamgrd PolyFlame loader directly. The deletion of the writable-overlay PAM configurations for sshd and login before remounting “/rootfs.rw” executable if part of the legitimate script, along with the invocation of the aaamgrd daemon via Python:

PolyFlame

PolyFlame is the primary operational module in the KeyDrift framework. PolyFlame operates at the socket and DTLS control-plane layer. PolyFlame serves two primary purposes:

• Command execution via a TinyShell-styled backdoor
• Intermediate C2 that can forward commands to and from the C2 to other peers

PolyFlame is primarily injected into the vdaemon process, providing operational obfuscation and access to all in-process state: DTLS session keys, vEdge topology, OMP routes, and policy tables. No hardcoded IPv4 addresses, binding ports, callback domains, URLs, host headers, or polling interval were recovered from the analyzed PolyFlame samples. PolyFlame is designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon.

This implant is meant to serve as a hook of the recvfrom() API call. The original recvfrom is replaced by a malicious subroutine in the vdaemon process. When recvfrom is called in the vdaemon process, the malicious subroutine will first execute the real/legitimate recvfrom() API to obtain the C2 IP address info for communicating with it in the future.

PolyFlame’s time check

The recvd data from the C2 consists of the MD5 value of a specific DATE. PolyFlame will calculate the local time on the device in format “%Y-%m-%d" and calculate its MD5 hash. If the MD5 calculated by the device does not match with the one sent by the C2, the implant will stop further execution. Otherwise, the implant then uses an “administrative code” from the C2 and performs an action.

PolyFlame’s tasking

PolyFlame contains an administrative mode that processes the admin code sent by the C2, that defines operations — it's one of the first flags checked in the backdoor:

• Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
• Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
• Code = 3: Set up the command handler for the intermediate C2.
• Any other code value: Check the implant type flag currently set. Based on the implant type flag, either send the accompanying data to TinyShell or the intermediate C2 component for processing.

PolyFlame’s command execution

PolyFlame contains a backdoor that matches the capabilities of TinyShell: file read, file write, and arbitrary command execution, but not interactive shell. This backdoor component’s implementation is quite similar to TinyShell, but the command codes differ. PolyFlame handles the following command codes:

• Code = 0x100: Execute command using “/bin/sh -c <command>”
• Code = 0x200: Write file to disk.
• Code = 0x300: Read file from disk and send to the C2.

PolyFlame as an intermediate C2 component

The intermediate C2 component is a one-to-many handler (somewhat like a one-to-many multiplexer) — meaning the implant can connect to only one C2 but can connect to many peers who can be served by the intermediate C2 component. Similar to the TinyShell-backdoor component, the intermediate C2 component also accepts and processes specific command codes from the C2:

• Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
• Code = 0x404: Send data recvd from the C2 to a connected peer.
• Code = 0x405: Remove a peer from the list of active connections.
• Code = 0x407: Send a response recvd from a peer, back to the C2.
• Code = 0x408: Set a specific value in memory.

PolyFlame variant: aaamgrd

 Talos has observed a distinct PolyFlame variant that masquerades as the aaamgr service. The legitimate Cisco aaamgr component is a Python package; it does not normally appear as a compiled ELF runit service. This PolyFlame variant is executed by a malicious runit service under “/etc/sv/aaamgr/” with aaamgrd and a modified run launcher.

aaamgrd is a statically linked ELF64 executable with no section headers, a single RWE loader segment, and an RC4-encrypted embedded ELF payload. The loader uses direct syscalls including ptrace, fork, wait4, kill, tgkill, mmap, and mprotect. It performs an anti-debug check by deobfuscating /proc/%d/status and TracerPid: and exits if a tracer is present.

The observed staging sequence was:

Figure 4. PolyFlame staging sequence.

Note that in addition to the implant execution staging, there are also indications of timestomping.

LittleFilch: libcommon.so TLS interception module

LittleFilch is a control-session interception module positioned to collect data-plane keying material from control sessions visible to the injected vSmart process.

LittleFilch installs an SSL_read hook inside vdaemon. The hook calls the original SSL_read, then processes returned buffers only when the returned size is greater than 0x18F, the first decrypted byte is 0x07, and three marker patterns are checked for presence. These marker bytes are followed by the actual artifacts that LittleFilch aims to record:

LittleFilch records the extracted keying material and RSA-encrypts it before writing the output to “/var/tmp/vdaemon.bin”. It can then send the encrypted content over UDP in a DTLS 1.2 application-data style record.

LittleFilch expects its configuration file — located at “/var/tmp/vdaemon.conf” —  to contain two host port lines: one local bind IP/port and one remote destination IP/port. It deletes “/var/tmp/vdaemon.conf” after reading it. Talos has not been able to recover the “vdaemon.conf” file.

KeyDrift components

MITRE ATT&CK techniques 

Recommendations

Cisco has released patches for CVE-2026-20127 and published a hardening guide for Cisco Catalyst SD-WAN deployments available here. Organizations are strongly advised to prioritize the application of these patches and follow the guidance provided.

Following the identification of UAT-11473 activity, Talos strongly recommends that organizations monitor their systems for indicators of post-compromise activity. Should any signs of unauthorized activity be detected, organizations should immediately activate their incident response frameworks. Contact the Cisco Technical Assistance Center (TAC) for support by initiating a TAC request.

Coverage

Snort SIDs are already available for CVE-2026-20127: 65938, 65958.

Snort SIDs for the malicious artifacts illustrated in this blog:

• Snort v2: 67387 through 67416
• Snort v3: 7:44 through 7:73

What does it mean to be "blue collar" for the blue team? Amy sat down with security researcher Ryan Fetterman to discuss his journey from federal agency work to his new role at Talos. He shares the realities of detection engineering — including the creative, often frustrating ways attackers evolve their tactics to stay one step ahead of traditional defenses.

Beyond the technical grind, Ryan shares his philosophy on building a career in security without burning out. From the value of project-based learning to the importance of finding time to step away from the keyboard, here's Ryan's take on what it really means to navigate today's cybersecurity industry.

Amy Ciminnisi: Tell me a little bit about the journey that has taken you to Talos, from early on in your career through to now. How did you get here? I actually don't know that much about it.

Ryan Fetterman: I've been doing security about 15 years now, and my career was largely shaped by where I started in the DC area. I spent about a decade there. I started out in consulting and then pivoted over to research, but that was a great place to get started.

I got a lot of great experience in federal agencies and government consulting, continued my education down there, got trained up, got certifications and things like that. And that was where I got my first exposure to doing actual security operations, which is what I really stuck with. It was my first exposure to Splunk.

Querying lots of log data and building visualizations and analytics in Splunk was the first time in my career that I felt it was kind of my natural inclination. It seems like it should have been more obvious to me looking back on it, but it's something that I try to explain to people a lot. When you first get into security, there's a desire to kind of find your specialization and start working towards it. But in my experience, it's just not something that you can rush.

I met the people connected with that space, which eventually led to me going to work for Splunk. I worked on the Splunk research team, SURGe. And then after the Cisco acquisition of Splunk, I ultimately became reorganized into Talos.

AC: I'm sure there have been so many challenges, so many obstacles in your way as you're trying to do this research. Can you share one that you've faced and how it shaped your perspective on cybersecurity?

RF: Something that stuck with me was actually my first advanced persistent threat (APT) incident. Now, you can look this up. It's called Pandora Song if you search for the C2. I was in the DC area working in a federal SOC, and I was doing some of the first host-based analytics at the time, which have now become kind of the concentration of a lot of detection. Engineering and analytics are host-based, so this was kind of pioneering at the time.

I was looking at a lot of host-based sensors and writing analytics in Splunk, actually, and we had been tipped off to this incident by a third party. I was looking through the details of the incident and how the attacker was carrying out the progression of their attack...

Want to see more? Watch the full interview, and don’t forget to subscribe to our YouTube channel for future episodes of Humans of Talos.

Welcome to this week’s edition of the Threat Source newsletter. 

Here for the latest on the PHP vulnerabilities? Head on down to ‘The One Big Thing’. Talos has published a blog to explain what we know so far, and details the Snort coverage available, including rules in the Community Ruleset. 

But if you want a bit of levity, here’s what I wrote before everything kicked off yesterday: 

Ever feel like the world is moving too fast to keep up? Well, I bring you scientific proof that it’s not just you. 

For millions of years, the moon has been slowing down the Earth’s rotation. But over the past decade, we’ve been speeding up (I KNEW I was aging faster than before). Apparently, changes in the Earth’s core are involved (either that, or the 1978 Superman film was a documentary). 

This is all causing massive headaches for the people responsible for keeping time. They’re officially called “The International Bureau of Weights and Measures”, but I’m going to call them “The Time-Keepers”. For nerd reasons).  

The issue is that the atomic clocks that power so many of our systems, and the rotation of our planet, don’t always agree. Atomic clocks keep extremely consistent time, while each Earth day is rarely the same length as the next. Atomic timekeeping absolutely cannot stand that level of flexibility (have a watch of our “The Light We Keep” documentary to see the importance that accurate clocks have on critical infrastructure).  

To keep Coordinated Universal Time (UTC), which is based on atomic clocks, aligned with Earth’s rotation, we introduced a “leap second” in 1972. This system allows for an extra second to be added, or taken away, when we stray too far from atomic time. 

A few days ago, The Time-Keepers voted to officially abolish the leap second. Why? Well, there’s a few parts to it. 

For the past 54 years, we’ve never once had a second removed from our lives. They’ve always been added (27 of them to be precise). I myself have experienced 20 of these extra seconds. If I’d have known that, I’d have used them more wisely. Like thinking before saying, “Love you too!” to the post-person this morning. 

That added time, while it seems nice to have on the surface, can wreak havoc with our modern technology systems. In 2012, the extra second caused so much confusion that it crashed Reddit, among other systems. 

The recent speeding-up of the Earth’s rotation complicates things further. If we keep going at this rate, it could result in the world’s first ever “negative second”. If you thought our technology systems struggled with added time, there are a lot of sciency brains who are very worried about the impact of taking time away. One of those concerns being… it’s never been done before.  

So, what’s The Time-Keeper’s solution? Invent more time! Woooo. 

Starting next May, the leap second will be replaced with a "leap hour," allowing UTC to diverge from Earth's rotation by up to an hour before a correction is made.  None of us will get to experience that extra hour in our lifetimes, but our Great, Great, Great, Great, Great, Great, Great, Great, Great, Great, Great grandchildren are going to have one hell of a party. 

For us current mortals, we’re all getting a little less time, and we’re hurtling through space a little faster. Happy Thursday! 

But I guess I do want to make the point that I’m glad the risk has been thoroughly assessed ahead of, ahem, time. The Time-Keepers have decided that the world’s infrastructure should not have to find out how it handles a missing second by collectively experiencing one.  

And I don’t even want to think about how all the AIs would cope with a negative second… 

There’s something here for incident response planning. “It’s never happened before” is an excellent reason to test whether you’re ready for it. Run the exercise. Find out which part of your plan depends on something that, in this scenario, is also broken. Preferably before an adversary gets to supervise the practical demonstration. 

Now, if only the Time-Keepers can abolish Daylight Savings Time next... 

The one big thing  

Two unauthenticated remote code execution (RCE) flaws were discovered in PHP, rocking the internet. Dubbed "php2shell" and triggered by a simple HTTP request, this vulnerability affects every build since 5.4. Talos assesses that all industries running PHP applications are at risk for exploitation if systems remain unpatched.

Why do I care? 

PHP runs WordPress, Drupal, Magento, Shopware, WooCommerce, and many other ubiquitous internet staples, so the possible blast radius is enormous. Older branches are end of life (EOL) and will not receive patches; these could account for around 50% of use cases.

So now what? 

Cisco customers are covered with the Cisco Talos Network Intrusion Prevention (SNORT®) signatures 67359 and 67360. If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older. See the article for more specific coverage and detection guidance.

See an interview with Nick Biasini on php2shell defense:

Top security headlines of the week 

'PHP2Shell' Bugs Signal Red Alert for Security Industry
Security teams are scrambling to remediate two critical PHP vulnerabilities following leaked details and reports of exploitation attempts. (Dark Reading)

INC and The Gentlemen Ransomware Affiliates expose 8,257 AI messages
SOCRadar has found seven exposed servers linked to INC and The Gentlemen ransomware affiliates, holding AI chats, stolen credentials and 46 encryptor builds. (Hack Read) 

The AI hacking apocalypse is not inevitable
While large language models present real risks to society, experts say they can be tested and largely controlled using well-worn cybersecurity and policy choices. (Cyberscoop)

‘Context Bombs’ Cut AI Attack Success by Misleading Agents With Fake Targets
Deceptive prompts lure AI agents into decoys and dead ends, cutting attack success by up to 91% in tests and raising the cost of a successful attack 23-fold.(SecurityWeek) 

Can’t get enough Talos? 

Compromised eMudhra intermediate certificates
Cisco Talos is aware of eight intermediate certificates belonging to the intermediate certificate authority, eMudhra.

Parasitizing trust: How legitimate infrastructure becomes a delivery pipeline for attackers
Adversaries are turning the tools businesses trust into delivery mechanisms for malicious activity. Cisco Talos observed abuse of more than 25 legitimate platforms over the past year, exploiting the built-in trust of collaboration, file-sharing, payment and other services to reach their targets.

There's only so much code: the rise in vulnerability numbers
The September Microsoft Patch Tuesday release included 975 vulnerability advisories. This month, 1,415 vulnerabilities were just dropped. Compared to a pre-June average of 100 a month, that increase is staggering. Where did they come from? And what does the future look like?

Upcoming events where you can find Talos 

• CAMLIS (Oct. 21 – 23) Arlington, VA 
• SecurityOnion Conference (Oct. 23) Augusta, GA 
• BsidesAugusta (Oct. 24) Augusta, GA 
• SAINTCON (Oct. 26 – 30) Provo, UT 
• CYBERWARCON (Nov. 20) Arlington, VA 
• AVAR 2026 (Dec. 2 – 4) Hyderabad, India 
• Black Hat Europe (Dec. 7 – 10) London, U.K. 

Most prevalent malware files from Talos telemetry over the past week  

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507
MD5: 2915b3f8b703eb744fc54c81f4a9c67f
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507
Example Filename:sample.exe
Detection Name: W32.9F1F11A708-100.SBX.TG

SHA256: 7fc50b69b56bfdfa9fc0a3e088ff13904587d6336a51e9edcc7919cba83d4e3f
MD5: cca616647db9370c88998ae25da6997f
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=7fc50b69b56bfdfa9fc0a3e088ff13904587d6336a51e9edcc7919cba83d4e3f
Example Filename:cca616647db9370c88998ae25da6997f.exe
Detection Name: Win.Tool.Kmsauto::1201

SHA256: 985c3972712218c62d2418b41056dba5fe883ca5104d8ec12041f8611db344f9
MD5: 485055033bcddfde56325c0d2feea4f2
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=985c3972712218c62d2418b41056dba5fe883ca5104d8ec12041f8611db344f9
Example Filename:485055033bcddfde56325c0d2feea4f2.exe
Detection Name: Win.Tool.Kmsauto::1201

SHA256: d921fc993574c8be76553bcf4296d2851e48ee39b958205e69bdfd7cf661d2b1
MD5: 0c883b1d66afce606d9830f48d69d74b
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=d921fc993574c8be76553bcf4296d2851e48ee39b958205e69bdfd7cf661d2b1
Example Filename:d921fc993574c8be76553bcf4296d2851e48ee39b958205e69bdfd7cf661d2b1.exe
Detection Name: Win.Worm.Zard::95.sbx.tg

Cisco Talos is aware of eight compromised intermediate certificates belonging to the intermediate certificate authority, eMudhra. Rather than possessing the mandatory 384 bits of pseudo-random security, several private keys evaluated single-digit and double-digit integers. This misconfiguration allows an attacker with the private key of any of the compromised intermediate CAs to impersonate any website or service. Six of the TLS certificates, trusted by Chrome, Mozilla, and Apple have been blocked by these vendors already. Two other certificates, used for codesigning by Microsoft, have also been blocked. Talos expects there will be additional patches available across a variety of technologies as software applications work to remediate the certificates’ exposure.

Following the disclosure, eMudhra has revoked the compromised certificates and stopped issuing new certificates under its G3 root.

Compromise details

The cause of this issue, originated during an April 30, 2025 key generation activity conducted by eMudhra under its emSign Root TLS CA - G3 and cross-signed Comodo AAA Certificate Services.  During a key generation ceremony for 24 subordinate CAs, a flaw in eMudhra’s key generation process created a second set of weak P-384 keys during a wrap/unwrap step. Those keys were mistakenly used for eight intermediate CA certificates. This flaw took the encryption from 384 bytes of entropy down to 3 – 8, making recovering the private keys trivial. The following are the impacted certificates, as illustrated in Mozilla’s bug report:

EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
SHA-256 E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
serial c7c41efe92d825f05eae841a4a82c1, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
SHA-256 98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
serial 6cada367fb1c100088120ea202d568, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
SHA-256 42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
serial a4aee678f23362b4c0e460b772f214, issuer emSign Root TLS CA - G3

EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
SHA-256 432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
serial 8009928a64107601af05fa2f19f109, issuer emSign Root TLS CA - G3

EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
SHA-256 CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
serial 296926c227a3a1526392b19482a504, issuer emSign Root TLS CA - G3

EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
SHA-256 0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
serial 588b2e3c2bb8cda13e1a1209254321, issuer emSign Root TLS CA - G3

EM OV CS CA - G3B (eMudhra BV), CCADB A012306
SHA-256 9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
serial 7818933f8f85b4619a2b35fba83d0a, issuer emSign Root CS CA - G3

EM OV CS CA - G3C (eMudhra Inc), CCADB A012298
SHA-256 4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
serial 544b7f922c31ae220a4a922916f6e6, issuer emSign Root CS CA - G3

CVE-2026-111943 

Unlike languages that defer entirely to external dynamic system libraries (like OpenSSL), the Go programming runtime implements its own X.509 chain verification engine in the standard library (crypto/x509). While Go usually queries platform certificates, several platforms or static container environments rely on embedded or legacy root certificate pools where certificate revocations are ignored. 

To eliminate exploitation across the entire cloud-native ecosystem including Docker, Kubernetes, Terraform, and Prometheus, the Go team designated the compromised certificates as a vulnerability, CVE-2026-111943, and released Go versions 1.27.3 and 1.26.10. 

 The fixed versions filter out chains containingthe SHA-256 hashes of the SubjectPublicKeyInfo (SPKI) for all eight compromised eMudhra intermediate certificates.

Impact

These compromised certificates could allow adversaries to impersonate servers and intercept or modify traffic. The impact of their exposure is far more than just web browsers. Other programs that check for TLS certificates might still be impacted since they may not check revocation lists. One clear example is related to virtual private networks (VPNs); these technologies will likely require software updates to mitigate the issue. Based on this guidance, Talos strongly recommends users update software using and handling TLS certificates as fixes become available.

Talos is actively monitoring the impact of these compromised certificates and has not seen any malicious incidents involving them in the wild yet (as of October 21, 2026 14:00 UTC / 10:00 a.m. ET).

Significance of this breach  

Public key infrastructure relies on trust being delegated through certificate chains: root CAs authorize intermediate CAs, which can issue certificates within the scope of their authority. An attacker who obtains an intermediate CA’s private key may be able to issue fraudulent certificates that clients accept, subject to the intermediate certificate’s constraints and each client’s validation controls. In this incident, six compromised intermediates were for TLS and two were for code signing.

 For TLS, an attacker able to intercept or redirect a connection could use a fraudulent certificate to impersonate a server and potentially read or modify traffic if the client still trusts the affected key and no applicable protection blocks it. Protections such as revocation, key distrust, certificate transparency enforcement, and certificate pinning can prevent or expose such an attack. Browser vendors have blocked the affected TLS keys, but other applications may rely on separate trust stores or validation paths:

Enterprise infrastructure and VPNs

Organizations should assess TLS-using software and appliances, including proxies, reverse load balancers, VPN clients, and gateways. Exposure depends on the certificate chain being validated and the trust store and revocation behavior in use. A stale or separately managed trust store may need an application, operating-system, firmware, or trust-bundle update; verify the required action for each product.

Software supply chains and CI/CD

Build runners and package managers may be exposed if they fetch content over TLS while still trusting an affected key and an attacker can intercept the connection. A fraudulent TLS certificate could enable registry impersonation, but it would not by itself bypass separate package integrity checks, such as lockfile hashes, checksums, signatures, or provenance controls. Assess the actual package-manager configuration and dependency path.

Industrial IoT and embedded systems

Review devices that use bundled or independently managed CA stores, especially where certificate revocation or trust-store updates may be limited. Some devices may require a vendor update or compensating control, but the necessary action depends on each device’s validation and update mechanisms.

Talos recommends updating affected software and trust stores as vendor fixes become available.

Coverage

The following SNORT® SIDs provide coverage for this threat: 67363 - 67374.

Talos would like to highlight the efforts of Chris Morrison for providing emergency coverage and mitigations for this threat.

Update 10/22: Added section detailing observations of in the wild exploitation and associated IOCs.

Cisco Talos is tracking the disclosure of two unauthenticated remote code execution (RCE) flaws in PHP core, dubbed “php2shell”, triggered by a plain HTTP request and exploitable before any application code runs, affecting every PHP build since 5.4. Based on the entities involved in the disclosure, artificial intelligence and associated technologies played a key role in the discovery of these vulnerabilities — yet another example of how these technologies are forcing change across the landscape, most notably on patching processes for organizations because of the wave of vulnerabilities being disclosed. 

Cisco customers are covered with the Cisco Talos Network Intrusion Prevention (SNORT®) signatures 67359, 67360, and 67375. These rules are also available in the Community Ruleset for open-source customers. Splunk Enterprise Security customers have an Enterprise Security Content Update with detections available. Please refer to the following recommendations, detection, and coverage guidance for more information.

Details

CVE-2026-109618 and CVE-2026-109619 are both critical vulnerabilities with a CVSS v4.0 score of 9.2.

• CVE-2026-109618 occurs when out-of-memory handling interrupts PHP while internal request data is only partially initialized. Request cleanup may then treat invalid data as valid.
• CVE-2026-109619 occurs when a stale internal state is reused after its backing memory has already been freed, before normal initialization resets it.

Impact

The potential blast radius is enormous and extends across the PHP ecosystem. The vulnerability sits in PHP core, so applications running affected versions — including WordPress, Drupal, Magento, Shopware, WooCommerce, and Laravel, plus PHP sites hosted through cPanel or Plesk — may be exposed. Note that many older branches will no longer receive fixes, so customers are urged to upgrade to a supported version as soon as possible.

Talos regularly investigates threat actor exploitation of vulnerabilities. State-sponsored and affiliated threat actors, as well as ransomware and other financially motivated groups, all employ tactics to exploit RCE. Talos assesses that all industries running PHP applications are at risk for exploitation if systems remain unpatched.

PHP 8.1 and older are end of life (EOL), and PHP 8.2 security support ends Dec. 31, 2026. Talos’ initial estimates based on open-source intelligence show a significant corpus of PHP systems that will not receive a patch (~50%). If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older.

Talos is actively monitoring the impact of these CVEs and has not seen them being exploited in the wild yet (as of October 21, 2026 14:00 UTC/10:00 a.m. ET).

Observed Exploitation 

Cisco Talos began observing exploitation attempts within hours of the vulnerabilities’ disclosure. So far, most of the activity is scanning, along with some uncoordinated attempts to deliver various payloads. This is expected: scanning or basic exploitation with public proof-of-concept (PoC) code takes far less effort than integrating a vulnerability into an actor’s own tooling. We expect exploitation volume to grow in the coming days, and campaigns to become more sophisticated and coordinated as more capable groups finish updating their tooling and begin deploying it. 

Recommendations and detection guidance

Talos strongly recommends all PHP users to upgrade to the available fixed releases. There are no intermediate or temporary controls that provide comprehensive protection; however, PHP advises that the following measure may reduce exposure to specific attack paths:

CVE-2026-109618

• Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
• Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

CVE-2026-109619

• Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool, or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors, or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing, and cleanup.

This is another vulnerability that owes its discovery to AI and its associated technologies. As we move through 2026, the wave of vulnerabilities and related patches is building. Talos advises organizations to work on a triaged process for prioritizing vulnerabilities with a specific focus on public-facing systems and vulnerabilities that are under active exploitation. The glaring need to prioritize vulnerabilities along with a streamlined process for rolling out patching strongly indicates that the historic trend of “baking in” patches before deployment is not going to survive the AI era.

The true impact of this vulnerability will take time to evaluate. These types of vulnerabilities that impact core technologies tend to cascade into other platforms and applications as they evaluate impact and provide associated patching, harkening back to the waves of exploitation that we saw after Log4J.

Coverage

SNORT® SIDs covering these vulnerabilities for subscribers: 67359, 67360, 67375. Free community rules are live through our Community Ruleset.

Splunk has released an Enterprise Security Content Update (ESCU) related to the ongoing PHP2Shell activity with additional detections. Splunk Enterprise Security customers are urged to download and apply.

Talos would like to highlight the efforts of Ankur Tyagi, Dalton Schaadt, Brandon Stultz, and Matt Killion for providing emergency coverage and mitigations for these threats.

In this video, Talos’ Nick Biasini explains what the vulnerabilities allow adversaries to do, how to assess your exposure, and what defenders should prioritize.

Indicators of Compromise (IoCs) 

5.191.140[.]240 
158.69.113[.]75 
94.154.43[.]149 
143.246.223[.]124 
45.198.224[.]169 
85.11.167[.]243 

Order notification abuse 

Talos recently analyzed two order notification campaigns abusing Staples and Dell transactional email pipelines. Together, these campaigns accounted for roughly 1,400 messages observed by Talos. 

The malicious element was not the outer sender identity, like a simple forged sender or lookalike domain. It was the content of the legitimate order notification workflow rendered. The suspicious content appeared inside the notification itself, in fields that would normally contain shipping information. The attacker’s objective was to use a trusted retail pipeline to create urgency around a high-value purchase and push the recipient toward an attacker-controlled phone number. 

In the first campaign, the message appeared as a Staples order confirmation from "support@orders.staples.com” with the subject line, “Here’s your Staples order #9939818875. Thanks for shopping with us.” The body displayed a plausible purchase for an Apple iPad, including order number, delivery timing, pricing, billing information and standard Staples footer content. The suspicious element was embedded in the order details: “Helpline 806 283 7712,” “Order Confirmed,” and the Staples corporate address appeared in fields normally associated with shipping or billing information. 

The structure of the message matters. The attacker was not trying to persuade the user to click a crude phishing link. Instead, the message created the impression that an expensive order had already been placed and that the fastest way to resolve it was to call the embedded “helpline.” The desired user action was a phone call. Once the victim moved from email to voice, the attacker could continue the scam through social engineering, payment manipulation, credential theft, or remote assistance fraud. 

The headers reinforced the trust problem. The Staples message showed DKIM alignment for “orders.staples.com” and DMARC passed for the visible Staples domain. The message also passed through forwarding and re-encapsulation paths, including Proton Mail, Microsoft 365, and downstream enterprise mail infrastructure. These hops complicate provenance analysis, but they do not change the core issue: Authentication helped establish that the outer message was credible, while offering no assurance that the phone number or transaction context was legitimate.  

The second campaign used the same pattern in a Dell order received notification. The message was sent from “Dell | Order Received <received@order.dellcom>” with the subject line, “We have your order | Dell Purchase ID: 2009829958247.” The body presented a purchase for Microsoft Project Standard 2024, totaling $736.09. As with the Staples example, the suspicious content appeared in transaction fields. The “Ship To” and “Bill To” sections included “Confirmed Order,” “Helpline 808 232 6397,” and “Call Our Sales Team”. 

The Dell message used the same psychological lever: an unexpected high-value purchase, a legitimate-looking order template, and a phone number positioned as the path to resolution. The attacker did not need the recipient to trust a new domain or unfamiliar brand. The message borrowed credibility from Dell’s order pipeline and redirected the recipient toward attacker-controlled contact information. 

Authentication results showed DKIM passing for Dell-related infrastructure and DMARC passing for “order.dell.com”. As with the Staples sample, forwarding artifacts and SRS-style return paths appeared as the message moved through Microsoft and enterprise mail infrastructure. But the malicious intent did not live in an obviously forged sender. It lived inside the rendered order content. 

These campaigns illustrate the same trust-boundary failure described in our earlier research on platform-as-a-proxy (PaaP) abuse. In those cases, attackers placed malicious content into SaaS fields that trusted platforms later rendered into notifications. Here, the same concept appears in commerce infrastructure, in the retailer’s order pipeline. The attacker supplies the intent, while the trusted system performs the delivery.  

From a defensive perspective, sender authentication is necessary, but it is not sufficient. SPF, DKIM, and DMARC help answer whether a message came from expected infrastructure. However, they do not answer whether the transaction was legitimate, whether the rendered fields make business sense, or whether the user is being pushed toward an attacker-controlled action. 

Order notifications should be treated as sensitive content. Any field reflected into a transactional message — shipping name, billing name, address line, company name, order note, support field, or fulfillment instruction — can become a delivery vehicle if it is not validated before rendering. Retailers and security teams should correlate order notification content with account history, payment state, shipping context, and known support channels. Transactional templates should reject or flag unexpected phone numbers, URLs, urgency language, and support instructions when they appear in fields where they do not belong. 

In both campaigns, the wrapper was legitimate enough to inherit trust. The payload was attacker-influenced. That distinction is the center of this attack class. 

The abuse of commerce pipelines is merely one manifestation of a broader, systemic vulnerability. Whether the attacker initiates a fake purchase or a fraudulent account sign-up, the root cause remains the same: Platforms are implicitly trusting data that enters their systems from untrusted sources, only to render that data into high-reputation, automated notifications. This same mechanism of reflection — where input is echoed back into an email to a third party — is the engine behind an evolution in list bombing, moving the attack from simple denial-of-service to a sophisticated vehicle for content delivery.  

List bombing: From inbox disruption to content delivery 

List bombing is an abuse technique in which attackers submit a victim’s email address to numerous legitimate registration, subscription or notification workflows, flooding the inbox with automated messages. While this vector is traditionally viewed as a denial-of-service or distraction tactic designed to bury critical alerts in a flood of junk, Talos has observed a subset of cases where this behavior is being repurposed as a delivery vehicle for malicious content. This abuse occurs when an attacker identifies public-facing registration, profile, or project-naming forms that lack sufficient input validation. By inputting a "hostile string" — such as a cryptocurrency-themed lure — into fields intended for a name, company, or title, the attacker forces the platform to treat this data as legitimate user information. When the service reflexively incorporates this input into its automated welcome, verification, or notification templates, the system acts as an unintended carrier, delivering the attacker’s content inside a high-reputation, system-generated email that can pass standard authentication checks. 

The attacker’s objective in these cases is to bypass the security perimeter by laundering their malicious content through the brand reputation of a trusted service provider. While this is not yet a broad industry shift, it represents a calculated abuse of a platform's trust boundary. By embedding their lure in an automated notification, the adversary ensures that the message arrives with the appearance of administrative legitimacy, significantly increasing the likelihood that the recipient will trust the content. The goal is to reach the target's inbox with enough platform authority that the message may be evaluated as routine notification traffic rather than attacker-controlled content. 

Beyond the risk to the individual recipient, this vector creates a significant brand liability. When a service provider’s infrastructure is used to broadcast fraudulent content, the resulting user complaints and bounce-backs can degrade the platform's own sender reputation, potentially triggering blocklisting that impacts their legitimate business communications. 

Bounce abuse: When delivery reports carry the lure 

The final vector moves the abuse pattern into the mail system itself. Instead of relying on a retailer, SaaS platform, or registration workflow to generate the message, the attacker attempts to make a delivery status workflow carry attacker-controlled content. 

Bounces, formally known as delivery status notifications (DSNs) or non-delivery reports (NDRs), are generated when a message cannot be delivered. Under normal conditions, a mail system sends the delivery report back to the original SMTP envelope sender. Depending on the implementation, that report may include the original headers, portions of the message body, URLs, attachments, or an encapsulated copy of the failed message. That returned content creates the abuse opportunity.  

In one example Talos observed, a mail delivery system notification carried a WeTransfer-themed file-sharing lure. The administrative wrapper made the message look like routine mail-system noise, while the nested content asked the recipient to engage with what appeared to be a file transfer workflow. The attacker’s goal was to make the phishing lure feel less like an unsolicited external message and more like part of a technical delivery failure that required review. Users are conditioned to view system errors as benign and are far more likely to engage with an "administrative" fix than a suspicious, standalone phishing email.  

There are several ways this kind of message can reach a victim. In opportunistic backscatter, an attacker sends mail using the victim’s address as the forged envelope sender. If an intermediate system accepts the message and later fails to deliver it, the resulting DSN may be sent back to the forged sender. If the DSN includes enough of the original message, the bounce itself can carry the lure. 

 A second possibility is intentional bounce abuse, where the attacker uses an authenticated, compromised, or otherwise controllable sending context to trigger a delivery failure that returns attacker-influenced content. This differs from an outright forged NDR, where the attacker simply fabricates the bounce message and sends it directly. From the recipient’s mailbox, however, these cases can look similar: A delivery-failure wrapper contains content the attacker wants the user to trust. 

This distinction matters for defenders. A DSN’s administrative appearance does not validate the content inside it. The outer message may be a legitimate delivery report, while the returned or encapsulated content may still contain a phishing link, credential harvesting page, malicious attachment, or social engineering prompt. 

The content-trust gap: A defensive imperative 

Across these vectors, the defensive failure is consistent: Trusted infrastructure is being treated as a shortcut for trusted content. 

Sender authentication remains essential. SPF, DKIM, DMARC, reputation, and infrastructure analysis help determine whether a message came from an expected source. But these controls do not answer a separate and increasingly important question: What was that trusted system instructed to carry? 

Order notifications, registration workflows and delivery reports all create opportunities for attacker-influenced content to appear inside messages that users and security tools are conditioned to trust. In the Staples and Dell campaigns, the suspicious content was a phone number placed into transactional fields. In list bombing and registration abuse, the lure can appear inside reflected account or profile data. In bounce abuse, the malicious content may sit inside returned message data or a nested MIME object. 

Defending against this requires content-aware validation at multiple points in the delivery chain. Platform owners should treat any user-controlled value rendered into an email template as untrusted data. Fields used for names, addresses, company names, project titles, order notes or support instructions should be validated before storage and again before rendering. Phone numbers, URLs, markup, line breaks, and urgent support language should be rejected or flagged when they appear in fields where they do not belong.  

Security gateways should inspect the fully rendered message, not only the sender or template. That includes HTML, text, URLs, redirects, attachments, personalization fields, and nested MIME content. For transactional email, defenders should also evaluate whether the message content aligns with the workflow that produced it. An order notification containing unexpected support numbers, cancellation instructions, or high-urgency language should be treated differently from a routine receipt. 

For delivery reports, recursive MIME inspection is especially important. Gateways should parse DSN containers, extract returned messages or message fragments, and apply normal phishing, malware, and URL analysis to the nested content. A bounce should explain a delivery failure, not provide a blind path for untrusted payloads. 

The broader lesson is that attackers are no longer only exploiting technical vulnerabilities in infrastructure. They are exploiting the assumptions built into business processes. When legitimate systems render attacker-influenced data into trusted notifications, the result can pass authentication checks and still deliver malicious intent.  

Defenders should therefore treat sender trust and content trust as separate but complementary signals. The wrapper can explain where a message came from. It cannot prove that the payload is safe. 

Acknowledgments 

Special thanks to Eric Peterson, Dev Shah, and Adam Katz for their professional guidance and input during the development of this research. 

The September Microsoft Tuesday release included 975 vulnerability advisories. This month, 1,415 vulnerabilities were just dropped. Compared to a pre-June average of 100 a month, that increase is staggering. Where did they come from? 

As of April, frontier models came onto the scene more fine-tuned than ever toward vulnerability detection, particularly with the introduction of Mythos. The deluge brings a lot of questions: 

• If these numbers are real, why hasn’t the internet collapsed? 
• Are these vulnerabilities a new breed, and if not, why didn’t analysts find them in code that is sometimes decades old? 
• Is the coordinated disclosure model still relevant in an era of this kind of speed? 
• How in the world do defenders deal with those numbers? 
• Should we go home, kiss our spouses, and prepare for the end? 

The answer to many of these questions boils down to this: The majority of these vulnerabilities are coming from repositories of old code from large-profile products and systems; and disclosure does not equal weaponization. 

Where is it from? 

AI is chewing through a backlog of technical debt in libraries and tools used as the dependable, best-practice lynchpins of so many environments. These models have a new perspective, an ability to "think" without some of the hangups or assumptions of human defenders, and they are thorough in listing those vulnerabilities. 

Entrenched older tools have always been prime targets because of their predictability; attackers know those tools and all their secrets, and they know what is likely to be present in a network with them. Multi-exploit attacks can be deployed with little variability.  

Pre-Mythos threat actors exploited log4j (CVE-2021-44228) to immense success. The library was ubiquitous, included in nearly every environment, but not a component that got cataloged in visibility scans. A combination of scale and low visibility meant defenders were blindsided, scrambling to find out if they even used the log4j library before starting to concoct a mitigation plan. 

Talos has ongoing relationships with some of the largest technical vendors (such as the Microsoft Active Protections Process (MAPP) agreement). Organizations share additional information—detection guidance or maybe a POC — for vulnerabilities that are most likely to be exploited, to enable Talos to provide adequate coverage when the advisories are announced.  "Microsoft believes it is important for us to provide detection content, based on their guidance," as Yves Younan, Director of Talos Vulnerability Discovery, Detection, and Testing, says.  

Talos has needed to invest more resources to get coverage in on time for critical vendors like Microsoft to keep up with notifications coming in fast and often on staggered or out-of-band timelines. 

For larger vendors, the pressure is handleable for now. However, open-source projects are getting flooded. Some projects have a trusted group that can combine to tackle patches, and some share with the full community for immediate assistance, but it is up to the project. The internet runs on open-source work. 

The pace of discovery presents a challenge for the traditional coordinated disclosure system vulnerability hunters have been using for years, and some are calling it into question.  

Security vulnerabilities should be reported, to enable an informed defender base and regular patching, and vendors responsible for vulnerable code need time to create coverage. A timed disclosure model where notifications are sent to a vendor, who then has a set period of time (typically 90 days) to provide coverage before the disclosure is released publicly, has created a more secure online environment for decades.  

Now, many practitioners are releasing advisories publicly without a disclosure period beforehand. The reasoning is that if one AI can find a weakness, any other could, so the vulnerability is already, effectively, released.  

This conversation is actively changing expectations around vulnerability disclosure, and guidance is in flux. 

Will it stay this high? 

No one knows the future, but we can always look to the past for insight.  

Numbers of vulnerabilities jump drastically when a new bug class is identified, as their possibilities are explored to the fullest. Then the discoveries plateau and drop off. 

When format string vulnerabilities were discovered as a new bug class in 2000, the initial influx of discoveries ramped up and up, until reaching a peak in 2005 and then slowly declining over the next couple of years. Format string vulnerabilities are still discovered, but they are a smaller overall fraction of the number of CVEs discovered in a year.  

Theoretically, AI-assisted vulnerability discovery could go the same way.  

While frontier models have not discovered a new vulnerability class, they are more efficient at discovering known types of software vulnerabilities. Given that a lot of vital software has a long history of code releases, there’s plenty of code to mine for weaknesses. But there’s only so much code… right? 

Old and commonly used tools are often under the highest scrutiny, lending them one kind of safety: Because of their popularity, utility, and stability, when popular tools have vulnerabilities, they are discovered fast and patched promptly. 

As the historical backlog of essential systems is turned over by AI, vulnerabilities will be found and patched. New code will ideally be run through AI bug-checkers that will prevent new vulnerabilities from being introduced. The rate of new vulns should level off and drop accordingly.  

There are some caveats. In the past, as vulnerability disclosures increased through coordinated disclosures, we saw increased adoption of mitigations. Exploitation became significantly harder. Attackers often need to chain together 3 or more vulnerabilities to successfully exploit a system.  

However, more awareness of vulnerabilities often leads to more exploitation. Attackers often use vendor patches meant to protect customers to discover where vulnerabilities might exist. The frequency of patching has delayed human attackers via parsing bottlenecks, but AI can eliminate that problem.  

Are the numbers the real issue? 

The volume is certainly up.  

Fresh as this blog is being finished, the October Patch Tuesday dropped almost 500 more than last month. 

With refinement, any vulnerability could become a link to a path of effect. But... not all vulnerabilities are exploitable. Some are wildly impractical for attacker use. In fact, the percent of Known Exploited Vulnerabilities (KEVs) is vastly smaller than the found vulnerabilities.  

Of the 975 vulnerabilities Microsoft reported in September, there were only three in-the-wild exploits detected. When viewed by percentage, vulnerabilities versus KEVs tell a different and perhaps reassuring story. 

Compared with the same period last year, additions to the known-exploited vulnerability list increased by 37%, while published CVEs increased by 105%. However, we wouldn't necessarily expect those figures to grow in proportion. Adversaries only need enough useful vulnerabilities to compromise their targets, and the same vulnerabilities can be reused against many organizations. The KEV count tracks distinct vulnerabilities known to be exploited, not the number of attacks or successful compromises. 

AI helps ingest code, advisory reports, and attack surfaces with inhuman speed, but it cannot currently make judgment calls about the value of a weakness. 

For defenders, the question remains the same: Which vulnerabilities provide a viable path into their environment, and how do you close those paths?  

What do we do now? 

The undeniable danger here is in exploitation time going down rapidly, while the vulnerabilities that could become exploits is still going up. The biggest hurdle for a defender is determining what is a real vulnerability for their environment, and what is not.  

Different defenders have different forms of control depending on their role.  

For those who are writing code, the new standard validation chain should include AI evaluation by models at least as up to date as those being used to hunt for vulnerabilities. It is relatively cheap to run new code through AI, but very expensive to run a cumbersome backlog of old code through. Bite it off in chunks. 

For those whose role involves keeping the tools ready: Upgrade ASAP.  Don't stop there.  

• For Cisco customers, implement LiveProtect to mitigate vulnerabilities between advisory release day and patching, to give time for that patching. Do this for everything you own. 
• Move beyond static domain blocking and implement behavioral detection that alerts on anomalous traffic patterns directed toward automation platforms. 
• Hone your focus to the vulnerabilities with the highest exploitability in your environment. KEVs are far less common among the sea of advisories, and their numbers have not risen proportionally with the AI-assisted deluge. 
• Focus on building defense-in-depth. Employ multiple protection systems, to cover for delays in patching. Implement interim mitigations (such as LiveProtect), create custom IPS/Snort triggers to block pre-patched traffic using SnortML, deploy behavioral anomaly detection, and integrate current AI evaluation models in software build chains. 

Dive deeper into this conversation with the latest TTP interview with Yves Younan and vulnerability researcher Bella Fusari.

For more numbers and advice for defenders: 

• Don't swing at everything 
• Threat Source Newsletter: Discovery ≠ Exploitation 

Welcome to this week’s edition of the Threat Source newsletter. 

I've been following a lot of (sometimes heated) threads and discussions lately about the current vulnerability landscape. I learned new words/phrases such as Summer of Hell (although I'm writing this with 1°C/34°F outside), Vulnpocalypse, Bugmageddon, Bugpocalypse, Breachpocalypse... 

Let's look at some numbers:

We crossed the 70k mark, and it's only the end of September. This has never been seen before — I think we can agree this number is skyrocketing. Also, CVE numbering organically grew into the six-digit range. Check your tooling. Some might say we broke that barrier already in 2014 (CVE-2014-125110), or even hit seven digits in 2015 (CVE-2015-1000013), but those were allocated artificially. (History note: Before 2014, 9999 was the highest possible identifier.) 

So that could be seen as the apocalypse argument. On the other hand, we have the KEV numbers:

They didn't explode... yet? Counting by sheer volume, YoY, CVEs increased by 105%, while KEV only grew 37%. Sounds huge at first, but following a 30% increase from 2024 to 2025, that's less dramatic — a counter-argument of sorts.

CVEs from 2025 or older still account for 33%. In other words, a good third of the KEVs are suggesting there is a patch gap. Looking at the 2026 CVEs, the share where the publication date matches the date added to KEV is 29%, which is only 2% more than (all of) 2025. Acknowledging this "math" is not the whole ball of wax, but it still tells me we are not living in a zero-day apocalypse right now. There’s also a slight uptick in networking gear-related CVEs, to 27%.

This is the second time I'll ask you to check your tooling. A new column, “forensicTriage,” was added to the KEV to flag which high-risk vulnerabilities require mandatory forensic triage and incident response workflows. You can read more about it in BOD 26-04, or the Implementation Guidance. 

So where does that leave us? The CVE numbers alone — that +70k mark, now that Q3 is behind us — make a decent case for Vulnpocalypse, or whichever name you prefer. That part of the story is real. But discovery isn't exploitation, and that gap is exactly what the KEV numbers remind us of. Vendors seem to be keeping pace too, at least partially — KEV is growing, just not nearly at CVE's speed, which on its own would almost be good news. 

Where the story breaks down is on the practical side. More than a third of actively exploited vulnerabilities still trace back to 2025 or earlier. Patch debt doesn't care how many new apocalypse-themed hashtags we invent. 

So, panic? I still don't think so. Relax? Definitely not either. Somewhere between the two is where the real work sits — chipping away at that backlog, one legacy system at a time. Maybe by next quarter it'll feel less like Bugmageddon and more like business as usual. Or maybe I won't even need a warmer jacket for the upcoming "Winter of Hell."

The one big thing  

Cisco Talos and Recorded Future’s Insikt Group are disclosing new espionage activity from UAT-6275 targeting government and critical infrastructure across the Commonwealth of Independent States (CIS). Thanks to the threat actor's own operational security lapses, researchers gained direct visibility into their infrastructure and malware development. We observed four distinct infection chains delivering custom reverse shells via macro-enabled documents, GitHub-hosted scripts, and a WinRAR vulnerability. 

Why do I care? 

Regional government and critical infrastructure entities are actively being targeted for diplomatic and economic intelligence. UAT-6275 is consistently evolving its tradecraft, abusing legitimate platforms like GitHub to host payloads and deploying lightweight reverse shells. Furthermore, recovered tooling suggests the group is preparing to expand its reach into Linux hosts and internet-facing appliances. 

So now what? 

Defenders in targeted regions and sectors should monitor for unexpected PowerShell activity and payload downloads originating from public services like GitHub. It is also critical to watch for suspicious scheduled tasks and unauthorized changes to the Windows Startup folder, which this group uses for persistence. Finally, ensure archive utilities are fully patched to prevent exploit-assisted delivery. ClamAV signatures and indicators of compromise (IOCs) to detect this threat can be found in the full blog post. 

Top security headlines of the week 

Hackers heat supermarket fridges to 50°C in France cyber attack 
The attack began overnight from Sunday to Monday. The unknown attackers reportedly abused the defrosting function in older control software, setting some equipment to heat continuously, with temperatures said to have reached 50°C. (Hack Read) 

Ivanti zero-day chain gave attackers root access to fully patched VPN 
CVE-2026-104935 affects Ivanti Connect Secure and it can be exploited for unauthenticated remote code execution with elevated privileges. (SecurityWeek) 

U.S. arrests two in crackdown on North Korean IT worker laptop farms
As part of the scheme, which allegedly ran between 2019 and July 2025, the two housed and configured laptops issued by victim U.S. companies so ITWs would appear to work from the U.S. (SecurityWeek) 

Canadian cybersecurity executive arrested in U.S. federal extortion case 
While the FBI did not publicly announce Dubrovsky’s arrest, the case appears to align with actions taken in the wake of the ShinyHunters’ attack on the FBI’s IT systems, which exposed personal data about thousands of bureau employees. (CyberScoop) 

Maximum-severity SSRF flaw in SonicWall SMA devices under attack 
The vulnerability, which SonicWall assigned a maximum 10 out of 10 CVSS score, stems from an "unintended alternate access path," according to the vendor's advisory. (Dark Reading) 

Can’t get enough Talos? 

You've got to lurk before you can smirk 
How do you get under a cybercriminal’s skin? Sometimes you expose their operations. Sometimes you make every step through a network painfully slow. And sometimes, if you’re Azim, you join a dark web forum where they’re insulting you, and help them to do it. 

Microsoft Patch Tuesday for October 2026 
Microsoft has released its monthly security update for October 2026, which includes 1,415 vulnerabilities affecting a range of products, including 85 that Microsoft marked as "critical." 

One breach, please, and make no mistakes 
The cybersecurity community has seen examples of autonomous agents, built inside AI labs, attacking public infrastructure. How you prepare for agentic threats is what makes the difference during real incidents. 

Upcoming events where you can find Talos 

• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 
• SecurityOnion Conference (Oct. 23) Augusta, GA 
• BsidesAugusta (Oct. 24) Augusta, GA 
• SAINTCON (Oct. 26 – 30) Provo, UT 
• CYBERWARCON (Nov. 20) Arlington, VA 
• AVAR 2026 (Dec. 2 – 4) Hyderabad, India 
• Black Hat Europe (Dec. 7 – 10) London, U.K. 

Most prevalent malware files from Talos telemetry over the past week  

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: sample.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: 73ac1bbfaee6c76c34f655ac0477a4cd930f2aa55e658c8e312ff81aac9a741f 
MD5: 63f3351cfdf618bec6045f60203e7978  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=73ac1bbfaee6c76c34f655ac0477a4cd930f2aa55e658c8e312ff81aac9a741f 
Example Filename: f_00478d.exe 
Detection Name: W32.PUP:PulseBrowser.29kh.in12.Talos 

SHA256: 58d6fec4ba24c32d38c9a0c7c39df3cb0e91f500b323e841121d703c7b718681 
MD5: f1fe671bcefd4630e5ed8b87c9283534 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=58d6fec4ba24c32d38c9a0c7c39df3cb0e91f500b323e841121d703c7b718681 
Example Filename: KMSAuto Net.exe 
Detection Name: W32.58D6FEC4BA-95.SBX.TG 

SHA256: fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f 
MD5: 207d9d891ac756b2bfad88aba5682c65 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f 
Example Filename: sample.exe 
Detection Name: W32.FED979F93B-95.SBX.TG 

This research was conducted jointly with Julian-Ferdinand Vögele of Recorded Future’s Insikt Group. Details of the joint research and presentation are available here.

• Cisco Talos identified UAT-6275 (TAG-193 by Recorded Future) activity targeting government organizations across the Commonwealth of Independent States (CIS). Recovered artifacts show additional interest in water resources and energy. This focus is consistent with intelligence collection and may reflect the regional effects of the Russia–Ukraine war. 
• In activity observed from June 2025 through August 2026, Talos identified four infection-chain types that use macro-enabled documents, PS2EXE downloaders, GitHub-hosted PowerShell, and a crafted WinRAR archive exploiting CVE-2025-8088. The recovered payloads include several custom reverse shells that provide interactive remote access. 
• Three publicly accessible staging directories and GitHub repository history exposed payload builds, tool inventories, and changes to command-and-control (C2) infrastructure. These operational security lapses gave us direct visibility into the group's recent activity. 
• The files recovered from the exposed infrastructure suggest preparation for post-compromise operations and potential activity against Linux hosts and internet-facing appliances.  
• Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus, based on infrastructure access, language artifacts, sample submissions, working hours analysis, and regional targeting interests.

Background 

Cisco Talos and Recorded Future Insikt Group jointly investigated UAT-6275 activity targeting government organizations across the Commonwealth of Independent States (CIS). The investigation uncovered three publicly accessible staging directories and a previously unreported GitHub repository used to host malicious scripts and payloads. These exposed assets provided visibility into the threat actor's malware development, infrastructure changes and preparations for additional intrusion activity. 

Talos tracks this activity as UAT-6275, while Recorded Future tracks it as TAG-193. It overlaps with Silent Lynx (first reported by Seqrite) and sits within a broader set of campaigns connected to YoroTrooper, which we first reported in 2023. Subsequent research on Tomiris (Kaspersky), ShadowSilk (Group-IB), Cavalry Werewolf (BI.ZONE), and Hydra Saiga (VMRay) identified overlapping indicators across these reported clusters. We assess that UAT-6275 and YoroTrooper likely belong to the same broader activity cluster. However, we continue to track them separately because we have not observed direct indicator or toolset overlap between the two.

This post summarizes our joint Virus Bulletin 2026 white paper, “Break the silence: tracking Silent Lynx through exposed infrastructure” which contains the full technical analysis and indicators of compromise (IOCs).

Victimology 

UAT-6275's targeting is concentrated in Central Asia and the wider CIS region. Across the reviewed campaigns, observed victims and lure themes span nine countries: Kazakhstan, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan, Armenia, Azerbaijan, Russia, and Belarus.

Government and diplomatic affairs 

UAT-6275 targets government institutions responsible for diplomacy, economic development, agriculture, and environmental management. These organizations hold information that can inform bilateral negotiations, economic planning, and regional security decisions.

Our network flow analysis identified activity involving a Tajik government entity shortly after treaty discussions with Kazakhstan in March 2026 and a Belarusian government entity ahead of a bilateral meeting in April. This timing may indicate an interest in regional diplomatic developments.

The decoy documents we recovered also suggest an interest in diplomatic relations, international trade, and aviation. Examples include a diplomatic letter addressed to Armenia’s Ministry of Foreign Affairs.

Water security and resource management 

The group’s interest in regional resources spans environmental management and energy. Talos observed activity involving an Armenian government entity responsible for environmental matters and Uzbekistan’s Smart Forestry initiative, consistent with earlier reporting on Silent Lynx targeting water resource organizations across Central Asia. 

Energy-themed decoys included a cooperation proposal between Turkmenistan’s state oil company, Turkmennebit, and Russia’s Orsk Oil Refinery, used in an August 2025 sample. The refinery supplies petroleum products to Kazakhstan and later shut down after a Ukrainian drone strike in August 2026, with repairs expected to take up to six months. These ties suggest a possible intelligence interest in regional fuel supplies and the war’s implications for Kazakhstan’s energy security.

Campaign timeline 

Since Seqrite first reported Silent Lynx in January 2025, we have identified at least eight campaigns across the region through May 2026. These include malware delivery targeting Russia, Turkmenistan, and Uzbekistan; a credential-harvesting site impersonating Azerbaijan’s State Agency for Public Service; and lures referencing the China–Central Asia Summit and Russian energy infrastructure. In 2026, we also observed activity involving government entities in Tajikistan, Armenia, and Belarus, as well as Uzbekistan’s Smart Forestry initiative in May. 

Infrastructure and malware delivery 

Talos identified three publicly accessible staging directories containing malware and tools of UAT-6275. One sample led to the previously unreported GitHub repository, where the group hosted PowerShell scripts and payloads. Its commit history allowed us to track infrastructure changes and malware development.

The group relies on lightweight reverse shells, including Chvost, Laplas, and PickleShell, to issue commands on compromised systems.

We also recovered Linux-compatible tooling and a publicly available proof-of-concept exploit for FortiWeb CVE-2025-25257 from UAT-6275 infrastructure. These findings suggest interest in expanding the group’s operational capabilities. 

Four infection chains 

UAT-6275 used malicious documents, executable downloaders, and shortcuts to deliver malware, and later incorporated a WinRAR exploit. Talos categorized the recovered samples into four infection chains, A – D, based on how they retrieve and execute their payloads.

The first Chain A samples, observed in June 2025, used macro-enabled Word documents to download and execute a second-stage binary. In July 2025, we observed Chain B downloaders built with PS2EXE, a tool that packages PowerShell scripts as standalone Windows executables. These downloaders retrieved reverse-shell payloads and created scheduled tasks for persistence. 

We first observed Chain C in October 2025. A malicious shortcut launches PowerShell to retrieve and execute a GitHub-hosted script that provides remote shell access. Later samples also downloaded PickleShell and placed it in the Windows Startup folder for persistence.

In April 2026, we identified a RAR archive that exploited CVE-2025-8088 in WinRAR to place PickleShell in the Windows Startup folder (Chain D). The payload runs at the next user sign-in. This was the first vulnerability exploit we observed in UAT-6275’s malware delivery.

Kazakhstan nexus assessment 

Talos assesses with medium confidence that UAT-6275 has a Kazakhstan nexus. Supporting evidence includes Russian-language artifacts, apparent malware-testing submissions from Kazakhstan shortly after compilation, and operator activity consistent with UTC+5 working hours.

Looking ahead 

UAT-6275’s sustained activity and adoption of new delivery techniques suggest the group will continue pursuing access to government organizations across Central Asia and the CIS. Its interest in environmental agencies, economic ministries, and energy infrastructure reflects the intelligence value of regional diplomacy and resource management. 

Defenders in these sectors should monitor unexpected PowerShell activity and payload downloads from public services such as GitHub, alongside scheduled tasks and Startup-folder changes. Keeping archive utilities patched can help reduce exposure to the exploit-assisted delivery observed in this campaign. 

For further details on this research and our accompanying presentation, see “Break the Silence: Tracking Silent Lynx Through Exposed Infrastructure” on Virus Bulletin’s website, as well as Recorded Future’s related blog post.

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.PickleShell-10060602-0 
• Win.Backdoor.Chvost-10060603-0 
• Win.Malware.Generic-10060604-0 
• Win.Malware.LAPLAS-10060605-0 
• Win.Malware.LAPLAS-10060606-0 
• Win.Proxy.Generic-10060628-0 

The following Snort rules cover this threat: 

• Snort 2: 1:11192, 1:15306, 1:46983, 1:47398 
• Snort 3: 1:46983, 4:16 

IOCs

IOCs for this research can be found at our GitHub repository here. 

Microsoft has released its monthly security update for October 2026, which includes 1415 vulnerabilities affecting a range of products, including 85 that Microsoft marked as "critical."

Microsoft notes that 1 of the vulnerabilities disclosed this month have been exploited in the wild

CVE-2026-96951 is a security feature bypass vulnerability that affects Windows Shell. The shared weakness is Improper Neutralization of Special Elements used in a Command ('Command Injection'). The vulnerability has a CVSS base score of 8.8.

Out of 85 "critical" vulnerabilities, 67 are remote code execution (RCE) vulnerabilities.

Microsoft considers exploitation of the following vulnerabilities more likely.

CVE-2026-70229 is a remote code execution vulnerability that affects Windows Active Directory Domain Services. The shared weakness is Incorrect Authorization. The vulnerability has a CVSS base score of 8.1.

CVE-2026-70571 is a remote code execution vulnerability that affects Microsoft Exchange Server. The shared weakness is Stack-based Buffer Overflow. The vulnerability has a CVSS base score of 8.1.

Microsoft considers exploitation of the following vulnerabilities less likely.

CVE-2026-105733, CVE-2026-102214, and CVE-2026-108399 affect Windows Hyper-V. CVE-2026-105733 has an impact of remote code execution; involves Incorrect Initialization of Resource; has a CVSS base score of 8.8. CVE-2026-102214 has an impact of remote code execution; involves Use After Free; has a CVSS base score of 8.8. CVE-2026-108399 has an impact of elevation of privilege; involves Heap-based Buffer Overflow; has a CVSS base score of 7.2.

CVE-2026-100202 is a remote code execution vulnerability that affects Windows Message Queuing Queue Manager. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 9.8.

CVE-2026-100209, CVE-2026-100210, CVE-2026-100211, CVE-2026-97739, CVE-2026-97745, CVE-2026-97755, CVE-2026-97759, CVE-2026-97765, CVE-2026-97778, CVE-2026-97741, CVE-2026-97742, CVE-2026-97753, CVE-2026-97756, CVE-2026-97758, CVE-2026-97761, CVE-2026-97767, CVE-2026-97776, and CVE-2026-97780 are remote code execution vulnerabilities that affect Microsoft Office Excel. Each has a CVSS base score of 8.8. CVE-2026-100209, CVE-2026-100211, CVE-2026-97745, and CVE-2026-97759 involve Use After Free. CVE-2026-100210, CVE-2026-97765 , CVE-2026-97756,  CVE-2026-97758, CVE-2026-97776, and CVE-2026-97780 involve Heap-based Buffer Overflow. CVE-2026-97739 involves Heap-based Buffer Overflow and Integer Underflow (Wrap or Wraparound). CVE-2026-97755 involves Out-of-bounds Read. CVE-2026-97778 involves Integer Overflow or Wraparound. CVE-2026-97741 involves Heap-based Buffer Overflow and Off-by-one Error. CVE-2026-97742 involves Stack-based Buffer Overflow. CVE-2026-97753 involves Heap-based Buffer Overflow and Integer Overflow or Wraparound. CVE-2026-97761 involves Stack-based Buffer Overflow. CVE-2026-97767 involves Double Free and NULL Pointer Dereference.

CVE-2026-100215 is a remote code execution vulnerability that affects Microsoft Graphics Component. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 7.8.

CVE-2026-100219 and CVE-2026-105016 are remote code execution vulnerabilities that affect Microsoft QUIC. Each has a CVSS base score of 9.8. CVE-2026-100219 involves Use After Free. CVE-2026-105016 involves Heap-based Buffer Overflow.

CVE-2026-100220 is a remote code execution vulnerability that affects Windows Media Video Decoder. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.

CVE-2026-102211, CVE-2026-88074, CVE-2026-108130, CVE-2026-108471, and CVE-2026-96914 are elevation of privilege vulnerabilities that affect Windows Virtualization-Based Security (VBS) Enclave. CVE-2026-102211 involves Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') and Use After Free; has a CVSS base score of 7.0. CVE-2026-88074 involves Integer Overflow or Wraparound; has a CVSS base score of 7.8. CVE-2026-108130 involves Heap-based Buffer Overflow; has a CVSS base score of 7.8. CVE-2026-108471 involves Untrusted Pointer Dereference; has a CVSS base score of 8.8. CVE-2026-96914 involves Heap-based Buffer Overflow and Integer Overflow or Wraparound; has a CVSS base score of 8.8.

CVE-2026-102225 and CVE-2026-97814 are remote code execution vulnerabilities that affect Windows Text Shaping. CVE-2026-102225 involves Numeric Truncation Error and Out-of-bounds Read; has a CVSS base score of 8.8. CVE-2026-97814 involves Heap-based Buffer Overflow; has a CVSS base score of 9.8.

CVE-2026-102855, CVE-2026-102856, and CVE-2026-102857 are remote code execution vulnerabilities that affect Microsoft Office Visio. The shared weakness is Heap-based Buffer Overflow. Each has a CVSS base score of 8.8. CVE-2026-102856 involves Integer Overflow or Wraparound. CVE-2026-102857 involves Off-by-one Error.

CVE-2026-102866 is an elevation of privilege vulnerability that affects Microsoft Office SharePoint. The shared weakness is Improper Verification of Cryptographic Signature. The vulnerability has a CVSS base score of 8.1.

CVE-2026-62840 is an elevation of privilege vulnerability that affects Linux Kernel. The shared weakness is Time-of-check Time-of-use (TOCTOU) Race Condition. The vulnerability has a CVSS base score of 7.0.

CVE-2026-69802 is a remote code execution vulnerability that affects Network Device Enrollment Service (NDES). The shared weakness is Weak Authentication. The vulnerability has a CVSS base score of 8.1.

CVE-2026-70147, CVE-2026-70153, and CVE-2026-108467 are remote code execution vulnerabilities that affect Microsoft PostScript Printer Driver. The shared weakness is Heap-based Buffer Overflow. CVE-2026-70147 has a CVSS base score of 9.8. CVE-2026-70153 has a CVSS base score of 9.8. CVE-2026-108467 has a CVSS base score of 8.8.

CVE-2026-70187 is a remote code execution vulnerability that affects Windows Remote Desktop Services. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 8.1.

CVE-2026-70250 is a remote code execution vulnerability that affects Windows DHCP Client. The shared weakness is Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') and Use After Free. The vulnerability has a CVSS base score of 8.8.

CVE-2026-83934 is a remote code execution vulnerability that affects Windows GDI+. The shared weakness is Stack-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.

CVE-2026-88073 is an elevation of privilege vulnerability that affects Windows Graphics Kernel. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 8.8.

CVE-2026-88117, CVE-2026-88119, CVE-2026-88120, CVE-2026-88171, and CVE-2026-96934 are remote code execution vulnerabilities that affect Windows DHCP Server. CVE-2026-88117, CVE-2026-88119, and CVE-2026-88120 involve Use After Free; each has a CVSS base score of 8.1. CVE-2026-88171 involves Double Free; has a CVSS base score of 8.1. CVE-2026-96934 involves Use After Free; has a CVSS base score of 9.8.

CVE-2026-96222 and CVE-2026-108131 are spoofing vulnerabilities that affect Active Directory Federation Services (AD FS). CVE-2026-96222 involves Improper Certificate Validation; has a CVSS base score of 7.4. CVE-2026-108131 has a CVSS base score of 7.5.

CVE-2026-96913 is an elevation of privilege vulnerability that affects Windows Kernel. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.

CVE-2026-96952 is a remote code execution vulnerability that affects Microsoft Windows Media Foundation. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.

CVE-2026-105718 is a remote code execution vulnerability that affects Microsoft Excel. The shared weakness is Improper Input Validation and Out-of-bounds Read. The vulnerability has a CVSS base score of 8.8.

CVE-2026-108400 is a remote code execution vulnerability that affects HEVC Video Extensions. The shared weakness is Integer Overflow or Wraparound. The vulnerability has a CVSS base score of 8.8.

CVE-2026-108457 is a remote code execution vulnerability that affects Microsoft Windows PDF. The shared weakness is Out-of-bounds Write. The vulnerability has a CVSS base score of 8.1.

CVE-2026-108460 is a remote code execution vulnerability that affects Windows Message Queuing. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 8.1.

CVE-2026-70215, CVE-2026-88144, CVE-2026-88178, and CVE-2026-88207 are remote code execution vulnerabilities that affect Microsoft Office PowerPoint. CVE-2026-70215 and CVE-2026-88144 involve Use After Free; has a CVSS base score of 8.8. CVE-2026-88178 involves Use After Free; has a CVSS base score of 9.8. CVE-2026-88207 involves Heap-based Buffer Overflow; has a CVSS base score of 7.5.

CVE-2026-70242, CVE-2026-70291, CVE-2026-88156, CVE-2026-97016, and CVE-2026-97749 are remote code execution vulnerabilities that affect Microsoft Office Outlook. Each has a CVSS base score of 9.8. CVE-2026-70242, CVE-2026-70291, and CVE-2026-97016 involve Heap-based Buffer Overflow. CVE-2026-88156 involves Stack-based Buffer Overflow. CVE-2026-97749 involves Double Free.

CVE-2026-70269 and CVE-2026-70300 are remote code execution vulnerabilities that affect Microsoft Office Word. CVE-2026-70269 involves Heap-based Buffer Overflow and Integer Overflow or Wraparound; has a CVSS base score of 8.1. CVE-2026-70300 involves Untrusted Pointer Dereference; has a CVSS base score of 9.8.

CVE-2026-83917 is an elevation of privilege vulnerability that affects Windows ALPC. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 7.0.

CVE-2026-94510 is an elevation of privilege vulnerability that affects Microsoft Bookings. The shared weakness is Authorization Bypass Through User-Controlled Key. The vulnerability has a CVSS base score of 9.9.

CVE-2026-96202 and CVE-2026-96943 are remote code execution vulnerabilities that affect Windows Raw Image Extension. The shared weakness is Heap-based Buffer Overflow. Each has a CVSS base score of 8.8. CVE-2026-96943 involves Integer Overflow or Wraparound.

CVE-2026-96207 is an elevation of privilege vulnerability that affects Microsoft Partner Center. The shared weakness is Improper Certificate Validation. The vulnerability has a CVSS base score of 10.0.

Microsoft considers exploitation of the following vulnerabilities unlikely.

CVE-2026-69789 is a remote code execution vulnerability that affects Windows Reliable Multicast Transport Driver (RMCAST). The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 7.5.

CVE-2026-88174 is a remote code execution vulnerability that affects Windows Deployment Services. The shared weakness is Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). The vulnerability has a CVSS base score of 8.1.

CVE-2026-88185 is a remote code execution vulnerability that affects Microsoft Office Word. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.1.

Other critical vulnerabilities

CVE-2026-69435 is an elevation of privilege vulnerability that affects Azure SRE Agent. The shared weakness is Server-Side Request Forgery (SSRF). The vulnerability has a CVSS base score of 9.6.

CVE-2026-77900 is a remote code execution vulnerability that affects Azure App Service. The shared weakness is Missing Authentication for Critical Function. The vulnerability has a CVSS base score of 9.8.

CVE-2026-83943 is an information disclosure vulnerability that affects Azure API Center. The vulnerability has a CVSS base score of 8.7.

CVE-2026-83947 is a spoofing vulnerability that affects Azure Event Grid. The shared weakness is Missing Authorization. The vulnerability has a CVSS base score of 7.7.

CVE-2026-88131 is a remote code execution vulnerability that affects Microsoft Dataverse. The shared weakness is Deserialization of Untrusted Data. The vulnerability has a CVSS base score of 9.8.

Talos would also like to highlight the following "important" vulnerabilities as Microsoft has determined that their exploitation is "more likely:"

CVE-2026-100214: Microsoft Dynamics 365 Business Central Remote Code Execution Vulnerability

CVE-2026-102217: WebDAV Elevation of Privilege Vulnerability

CVE-2026-69673: Windows Update Elevation of Privilege Vulnerability

CVE-2026-69718: Windows Update Elevation of Privilege Vulnerability

CVE-2026-69733: Windows Update Elevation of Privilege Vulnerability

CVE-2026-69783: Windows Update Elevation of Privilege Vulnerability

CVE-2026-69882: Windows Update Elevation of Privilege Vulnerability

CVE-2026-69923: Windows AI Elevation of Privilege Vulnerability

CVE-2026-69926: Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-70054: Windows NetBIOS Elevation of Privilege Vulnerability

CVE-2026-70060: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70076: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70104: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70108: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70117: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70132: Windows Portable Device File System Driver Elevation of Privilege Vulnerability

CVE-2026-70144: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70156: Microsoft Windows Search Component Elevation of Privilege Vulnerability

CVE-2026-70218: Windows StateRepository API Elevation of Privilege Vulnerability

CVE-2026-70223: Windows Console Driver Elevation of Privilege Vulnerability

CVE-2026-70233: Windows Common Log File System Driver Elevation of Privilege Vulnerability

CVE-2026-70236: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70237: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

CVE-2026-70241: Windows Kerberos Elevation of Privilege Vulnerability

CVE-2026-70245: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

CVE-2026-70249: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70253: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70255: Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-70271: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70273: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70286: Windows Graphics Component Elevation of Privilege Vulnerability

CVE-2026-70303: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-72955: Windows Application Compatibility Cache Elevation of Privilege Vulnerability

CVE-2026-81971: Windows NTFS Elevation of Privilege Vulnerability

CVE-2026-83505: Windows Setup Files Cleanup Elevation of Privilege Vulnerability

CVE-2026-83509: Windows Setup Files Cleanup Elevation of Privilege Vulnerability

CVE-2026-83510: Windows Setup Files Cleanup Elevation of Privilege Vulnerability

CVE-2026-83580: Windows Client-Side Caching (CSC) Service Elevation of Privilege Vulnerability

CVE-2026-83669: Windows Error Reporting Elevation of Privilege Vulnerability

CVE-2026-83699: Windows Client-Side Caching (CSC) Service Elevation of Privilege Vulnerability

CVE-2026-83704: Microsoft Windows Search Component Elevation of Privilege Vulnerability

CVE-2026-83717: Windows Installer Elevation of Privilege Vulnerability

CVE-2026-83724: Windows Management Instrumentation Elevation of Privilege Vulnerability

CVE-2026-83732: Win32k Elevation of Privilege Vulnerability

CVE-2026-83735: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-83738: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

CVE-2026-83750: Windows Error Reporting Elevation of Privilege Vulnerability

CVE-2026-83761: Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability

CVE-2026-83763: Windows Input System Elevation of Privilege Vulnerability

CVE-2026-83768: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-83769: Microsoft OpenSSH for Windows Elevation of Privilege Vulnerability

CVE-2026-83793: Windows Update Orchestrator Service Elevation of Privilege Vulnerability

CVE-2026-83830: Windows COM+ Event System Service Elevation of Privilege Vulnerability

CVE-2026-83834: Windows Kernel-Mode Drivers Elevation of Privilege Vulnerability

CVE-2026-83840: Windows Error Reporting Elevation of Privilege Vulnerability

CVE-2026-83842: Windows TCP/IP Elevation of Privilege Vulnerability

CVE-2026-83848: Windows COM+ Event System Service Elevation of Privilege Vulnerability

CVE-2026-83867: Windows Push Notifications Elevation of Privilege Vulnerability

CVE-2026-83886: Windows Update Orchestrator Service Elevation of Privilege Vulnerability

CVE-2026-83896: Windows Direct Composition Elevation of Privilege Vulnerability

CVE-2026-83899: Windows Installer Elevation of Privilege Vulnerability

CVE-2026-83902: Windows Direct Composition Elevation of Privilege Vulnerability

CVE-2026-83921: Windows Search Service Elevation of Privilege Vulnerability

CVE-2026-84014: Windows Device Association Service Elevation of Privilege Vulnerability

CVE-2026-85355: Windows Common Log File System Driver Elevation of Privilege Vulnerability

CVE-2026-85791: Windows Encrypting File System (EFS) Elevation of Privilege Vulnerability

CVE-2026-85802: Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability

CVE-2026-85804: Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability

CVE-2026-85832: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability

CVE-2026-85843: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability

CVE-2026-85848: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability

CVE-2026-85849: Windows AppX Deployment Service Elevation of Privilege Vulnerability

CVE-2026-85850: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-85855: Windows DWM Core Library Elevation of Privilege Vulnerability

CVE-2026-85870: Windows Common Log File System Driver Elevation of Privilege Vulnerability

CVE-2026-85901: Windows Graphics Component Elevation of Privilege Vulnerability

CVE-2026-85908: Windows Graphics Component Elevation of Privilege Vulnerability

CVE-2026-85941: Windows Installer Elevation of Privilege Vulnerability

CVE-2026-85945: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-88118: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability

CVE-2026-88133: Windows Portable Device Enumerator Service Elevation of Privilege Vulnerability

CVE-2026-88147: Windows Secure Socket Tunneling Protocol (SSTP) Elevation of Privilege Vulnerability

CVE-2026-88152: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability

CVE-2026-88159: Windows Background Intelligent Transfer Service (BITS) Remote Code Execution Vulnerability

CVE-2026-88191: Microsoft Windows Search Component Elevation of Privilege Vulnerability

CVE-2026-96858: Windows Security Account Manager Tampering Vulnerability

CVE-2026-96911: Microsoft Windows Search Component Elevation of Privilege Vulnerability

CVE-2026-96929: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-96940: Microsoft Exchange Server Elevation of Privilege Vulnerability

CVE-2026-69452: Windows Enterprise App Management Elevation of Privilege Vulnerability

CVE-2026-69880: Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-69918: Windows Core Messaging Elevation of Privilege Vulnerability

CVE-2026-70103: Windows Error Reporting Elevation of Privilege Vulnerability

CVE-2026-70106: Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-70151: Windows Direct Composition Elevation of Privilege Vulnerability

CVE-2026-70176: Windows Win32k Elevation of Privilege Vulnerability

CVE-2026-70279: Microsoft Exchange Server Spoofing Vulnerability

CVE-2026-83785: Windows COM+ Event System Service Elevation of Privilege Vulnerability

CVE-2026-83927: Windows Registry Elevation of Privilege Vulnerability

CVE-2026-85884: Windows Health and Optimized Experiences Service Elevation of Privilege Vulnerability

CVE-2026-85902: Windows Direct Composition Elevation of Privilege Vulnerability

CVE-2026-85906: Windows Direct Composition Elevation of Privilege Vulnerability

CVE-2026-88093: Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-96939: Servicing Stack Updates Elevation of Privilege Vulnerability

CVE-2026-97798: Windows Error Reporting Service Elevation of Privilege Vulnerability

CVE-2026-97799: Windows Audio Service Elevation of Privilege Vulnerability

CVE-2026-97800: Windows Mobile Broadband Elevation of Privilege Vulnerability

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.

In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

Snort 2 rule coverage: 1:67210 - 1:67273, 1:67276 - 1:67279, 1:67282 - 1:67311, 1:67313 - 1:67316, 1:67319 - 1:67322

Snort 3 rule coverage: 1:301663 - 1:301694, 1:301696, 1:301702 - 1:301703, 1:301705 - 1:301706, 1:301709, 1:301711, 1:301717 - 1:301718

Welcome to this week’s edition of the Threat Source newsletter. 

My name is Pierre Cadieux, and I’ll be helping contribute to these newsletters. A little about me: I’ve been working in the cybersecurity industry in many roles over the past 20+ years, first focusing on endpoint security, policies, and firewalls, then moving to risk management and compliance, disaster recovery, and investigations. I spent about 15 years as a consultant working across many well-known consultancy firms and eventually moved to Cisco where I spent time doing security operations center (SOC) design and assessments as well as segmentation before moving to the Talos IR team. I spent many years there, first as an Incident Commander and then a manager of our excellent team of global IR consultants and investigators. My current role is with the Talos Threat Intelligence and Interdiction team, where I’m focused on intelligence efficacy — how we can do better with the data we have, how we can get more data, and what our customers want from our intelligence products. 

Since it’s Cybersecurity Awareness Month, I wanted to take a few minutes to collectively thank all of the defenders out there for the hard work you do each day. The work you do may not always be visible, but it matters.  

I remember one job I had many years ago when I was in charge of security for a financial institution. I spent time learning each of the business processes that we had so I could understand each of the moving parts, what was essential, and what was on the horizon for change. I even spent a couple days meeting with the folks who handled printing. Yeah, printing — but not reports or internal documents. These were the people that created the checks that our institution used to pay other institutions, and more importantly (to me) our customers. 

I recall there being many out-of-patch compliance boxes in this area of the company, so I, being the diligent Director, decided to find out why. It turns out the software being used to print these business essential checks would not run on the current operating systems, and the physical printer cards used to connect to these non-network printers also required older hardware ports. As one of the people I interviewed said, “We don’t want to be the reason someone’s grandma doesn’t get her check and can’t go to the grocery store.” 

There were (at the time) no other alternatives that we could deploy, and the environment had zero tolerance for downtime. The solution I proposed was to isolate these devices into their own network, which blocked access to and from the internet for these devices, and also reduced the likelihood that these devices would be identified during an adversary’s internal reconnaissance or mapping. It didn’t patch the vulnerable devices, but it went a long way to reducing the likelihood of a bad thing happening to these devices due to their out-of-date OS and software. 

This story is especially appropriate today, as we face ever-increasing numbers of vulnerabilities announced by software vendors, and can only expect this volume to continue to increase. Do what you can to make sure the checks still get printed, while managing your risks intentionally. 

The one big thing  

Cisco Talos is disclosing new findings from our CAIRN research that show malware authors are embedding natural-language instructions into their code to evade AI-assisted analysis. We classify this growing trend as "A3: AI-Analysis Evasion." Over the past 18 months, we've tracked techniques ranging from simple comments telling an AI to ignore a file, to advanced "template spraying" designed to trick specific large language models (LLMs).  

Why do I care? 

Attackers expect AI to be in your analysis pipeline, and they’re developing cheap methods to manipulate those systems. While we found these prompt-injection techniques only steer the AI's verdict in the attacker's favor about 35 percent of the time, they are being adopted across all levels of malware sophistication. A3 families like MANTLEMAZE also pair these AI deceptions with serious underlying threats, such as abusing vulnerable drivers to disable EDR from kernel space. 

So now what? 

Because these evasion instructions must be written in plaintext, defenders have a highly stable detection surface to monitor. Security teams should flag imperative language addressed to analysis systems within binaries as a suspicious signal. Most importantly, anyone building or using AI-assisted pipelines must ensure that text extracted from a sample is strictly treated as evidence, never as a system directive. Read the full blog for more information on these techniques and a list of sample hashes. 

Top security headlines of the week 

Citrix NetScaler security snafus get even worse amid more zero-day reports 
This latest vulnerability, tracked as CVE-2026-88779, is a memory overflow bug that leads to denial of service attacks. (The Register) 

Hackers steal 8 million citizens’ records from Danish government database 
The Danish government would not say who is behind the breach, which happened in September but was discovered on October 2. However, it said the unauthorized access was obtained by “abusing a Danish company’s lawful access to search for information in the CPR system.” (TechCrunch) 

Google narrows open-source bug bounty amid wave of invalid automated reports 
Google has temporarily closed its Open Source Software Vulnerability Reward Program (OSS VRP) to product vulnerability submissions. According to Google, it has no impact on the program’s supply chain reports or on any pending reports. (SecurityWeek) 

Warlock ransomware hits large Spanish, Portuguese orgs 
In the last two months, researchers observed Warlock attacks against four victims: a water utility, a telecommunications provider, a regional government body, and a university. (Dark Reading) 

U.S. Senate passes health care cybersecurity bill after 190 million impacted by Change Healthcare breach 
The Health Care Cybersecurity and Resiliency Act of 2026 was passed by unanimous consent last week, potentially expanding federal cyber requirements for health care organizations. (The Record) 

Can’t get enough Talos? 

One breach, please, and make no mistakes 
The cybersecurity community has seen examples of autonomous agents, built inside AI labs, attacking public infrastructure. How you prepare for agentic threats is what makes the difference during real incidents. 

Talos Takes: Honey, I Trapped the Adversary 
It’s time to start having fun and messing with your attackers. For Cybersecurity Awareness Month, Martin Lee joins Amy to discuss the fine art of making life on your network a complete nightmare for adversaries. 

The Fine Art of Frustrating the Adversary 
What really frustrates an adversary? Eight Cisco Talos researchers share practical ways to make their next move slower and riskier, from deception and behavioral detection to breaking attack dependencies. 

Upcoming events where you can find Talos 

• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 
• SecurityOnion Conference (Oct. 23) Augusta, GA 
• BsidesAugusta (Oct. 24) Augusta, GA 
• SAINTCON (Oct. 26 – 30) Provo, UT 

Most prevalent malware files from Talos telemetry over the past week  

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: sample.exe 
Detection Name: W32.9F1F11A708-100.SBX.TG 

SHA256: fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f 
MD5: 207d9d891ac756b2bfad88aba5682c65 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=fed979f93bcaf4e73ebd25748093a92095d5109cbd01d55f97bdc50ce509ad2f 
Example Filename: sample.exe 
Detection Name: W32.FED979F93B-95.SBX.TG 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
MD5: 38de5b216c33833af710e88f7f64fc98 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe 
Detection Name: W32.9896A6FCB9-95.SBX.TG 

SHA256: 73ac1bbfaee6c76c34f655ac0477a4cd930f2aa55e658c8e312ff81aac9a741f 
MD5: 63f3351cfdf618bec6045f60203e7978 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=73ac1bbfaee6c76c34f655ac0477a4cd930f2aa55e658c8e312ff81aac9a741f 
Example Filename: f_003914.exe 
Detection Name: W32.PUP:PulseBrowser.29kh.in12.Talos 

SHA256: 58d6fec4ba24c32d38c9a0c7c39df3cb0e91f500b323e841121d703c7b718681 
MD5: f1fe671bcefd4630e5ed8b87c9283534 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=58d6fec4ba24c32d38c9a0c7c39df3cb0e91f500b323e841121d703c7b718681 
Example Filename: KMSAuto Net.exe 
Detection Name: W32.58D6FEC4BA-95.SBX.TG

In mid-2026, Talos observed an APT spear-phishing campaign targeting Taiwan-based research organizations. The threat actor appeared to reuse legitimate or plausible public event information, then embedded a hyperlink to actor-controlled infrastructure, while the displayed URL appeared benign. Several invitation emails exhibited nearly identical syntactic structures despite discussing different geopolitical topics, suggesting the content was generated from a reusable prompt template rather than independently authored. While Talos cannot conclusively determine whether the emails were fully generated by a large language model (LLM), the campaign demonstrates strong evidence of AI-assisted content production and personalization. 

Spear-phishing mail 

Based on the phishing emails we observed, the threat actor impersonated legitimate institutions in Taiwan such as Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute. Below is a deep analysis of the mail contents.

An email recipient contacted the organizations concerned to verify the purported senders. However, none of the organizations could confirm that the three senders were employees or representatives of the institutions named in the emails. This suggests that the threat actor fabricated the sender identities while using legitimate organizational names and publicly available event information as cover.

All three emails follow a highly consistent, three-part structure, indicating the use of a common template. The opening section provides a polished (but overly elaborate) description of the geopolitical or policy context. It relies heavily on grandiose yet vague expressions such as “the global strategic landscape,” “reshaping the great-power order,” “three-dimensional analysis,” “forward looking and in-depth analysis,” and “high intensity professional dialogue” to create an impression of academic authority and subject matter expertise. Although the language is generally fluent, the excessive use of policy jargon and abstract strategic terminology makes the content appear formulaic.

The second section is customized for the recipient and uses targeted flattery to encourage engagement. Similar phrases including “admiration,” “authoritative perspective,” “highly perceptive,” and “key practical dimensions” appear across the three messages. These compliments are broadly applicable and contain few verifiable details about the recipient’s actual work, suggesting that the actor personalized a reusable template using publicly available professional information. References to exclusive participation, reserved VIP seating, or the recipient’s supposedly unique expertise further exploit professional recognition and status to reduce suspicion.

The final section presents event logistics, including the topic, date, venue, and registration instructions. Although much of this information appears to have been copied from legitimate institutional websites or public event announcements, its accuracy does not validate the email or the sender. Instead, the actor appears to use authentic event details as a form of legitimacy laundering. The registration links embedded in the emails do not direct recipients to the legitimate event registration pages they seem to represent. For example, one hyperlink displays a legitimate-looking Google Forms URL, while its underlying href redirects the recipient to a deceptive phishing site hosted on a third-party platform. This mismatch between the visible link text and the actual destination demonstrates a deliberate attempt to conceal the phishing infrastructure and exploit the recipient’s trust in a familiar service.

Taken together, the reuse of an almost-identical narrative structure, rhetorical style, personalized flattery, institutional impersonation, and deceptive registration mechanism strongly suggests a coordinated and carefully targeted spear-phishing campaign rather than three independent invitations. The messages also exhibit characteristics consistent with AI-assisted content generation such as grammatically fluent but formulaic prose, excessive use of grandiose and abstract policy terminology, interchangeable praise, repetitive sentence patterns, and rapid customization for different recipients, institutions, and geopolitical topics. Although these linguistic indicators alone cannot conclusively prove the use of generative AI, their consistency across all three emails suggests that the threat actor likely used an AI-assisted template to produce and personalize the phishing lures at scale. The legitimate event details and visible Google Forms URLs were then combined with disguised hyperlinks leading to actor-controlled phishing pages, making the emails appear credible while concealing their actual destination. 

Quishing in the poster 

We also observed the threat actor attaching event posters to several phishing emails. While the poster designs were scraped from legitimate websites, the embedded QR codes were maliciously altered. This modification indicates a calculated physical world attack vector. The actor may have anticipated that recipients might print and display these posters on office bulletin boards, thereby tricking other individuals into scanning the malicious QR code to register for the event. By doing so, the threat actor expands their attack vector beyond traditional email phishing to include quishing (QR code phishing), and broadens their reach within the targeted entities.

Phishing kit used by UAT-11985 

Phishing page’s impersonation 

These three phishing email attacks use the same tactics, techniques, and procedures (TTPs) which include a phishing page impersonating a legitimate Google Form and appearing visually identical to the authentic service. However, aligned with the threat actor's primary objective of credential theft, the malicious form forcibly redirects the user to a spoofed Google login page.

Talos observed that the spoofed Google login panels only support Simplified Chinese (zh-CN), Traditional Chinese (zh-TW), and English locales, with region detection based on the victim's browser “navigator.languages”, strongly suggesting targeting of Chinese-speaking users.

We also observed that this phishing page revealed a hidden HTML <section> designed to simulate a successful Google authentication event. Within this structure, the threat actor embedded an iframe (ID: google-success-frame) configured to load a locally hosted asset (/google-login-assets/operation-success.html). Notably, the iframe includes the sandbox="allow-scripts" attribute. We will discuss JavaScript in the next section.

Attack summary  

The attack chain initiates when a victim clicks a malicious URL delivered via a phishing email. Upon access, the victim is presented with a pixel-perfect replica of the Google sign-in page, which covertly hosts an obfuscated JavaScript payload. Operating as an adversary in the middle (AitM), the threat actor positions their infrastructure between the victim's browser and legitimate Google authentication servers. This allows them to seamlessly forward credentials and dynamically control the victim's user interface step-by-step via a persistent WebSocket connection.

To evade detection and complicate analysis, the malicious JavaScript is embedded at the end of the HTML document and relies on advanced string rotation obfuscation. The script leverages a large, static array of Base64 encoded strings coupled with control flow obfuscation. By utilizing a while(!![]) { push/shift } shuffle loop mechanism, the array rotation is resolved dynamically at runtime, effectively thwarting automated static deobfuscation tools.

Talos’ analysis of the phishing kit's client-side JavaScript indicates, with moderate confidence, that the user interface localization was authored by a native Simplified Chinese speaker. The strongest indicator is the kit's localization architecture:  

1. The base translation object (T) is written entirely in Simplified Chinese and is directly assigned as the zh-CN locale, while the Traditional Chinese (zh-TW) and English (en) locales are derived from it at runtime via an override or merge function (v(T, {...})).  
2. This structure demonstrates that the interface was originally composed in Simplified Chinese and subsequently translated into Traditional Chinese and English, consistent with Simplified Chinese being the developer's primary working language.
3. This assessment is reinforced by lexical choices characteristic of mainland Chinese usage rather than Taiwanese, Hong Kong, or Southeast Asian conventions. For example, the text uses Simplified Chinese forms such as “账号” for “account,” whereas Traditional Chinese environments would more commonly use “帳號” or related variants. Similarly, terms such as “计算机” for “computer,” “邮箱” for “email/mailbox,” “无痕浏览窗口” for “incognito browsing window,” and “访客模式” for “guest mode” reflect terminology commonly seen in mainland-oriented Simplified Chinese software localization. In Taiwanese or Hong Kong contexts, these concepts are typically rendered with Traditional Chinese characters and often different localized wording, such as “電腦,” “電子郵件/信箱,” or “無痕式視窗.” This linguistic pattern is further supported by the ternary-fallback ordering throughout the code, which consistently places Simplified Chinese as the default branch.

Operator-driven phishing page 

Following the deobfuscation and analysis of these JavaScript payloads, Talos identified an advanced, real-time AitM phishing kit targeting Google accounts. Unlike fully automated phishing kits, this framework appears optimized for operator-driven authentication orchestration. This kit impersonates the Google sign-in interface across three locales (zh-CN, zh-TW, en) and employs a dual-channel architecture including HTTP POST and WebSocket to synchronize Google's authentication state in real time. This mechanism effectively bypasses multi-factor authentication (MFA) to harvest complete, authenticated session tokens.

The threat actor deliberately employs a split communication channel architecture to optimize both data exfiltration and real-time command and control (C2) efficiency. For the outbound data exfiltration, the threat actor utilized HTTP POST for stateless, event-driven data transmission. The phishing page actively pushes captured data to the C2 server, including initial browser fingerprints, credential and challenge submissions during user interaction, and periodic heartbeat polls to maintain synchronization. Each call completes independently.

The threat actor uses WebSocket to provide a low-latency, persistent connection. The C2 server streams real-time instructions to the phishing page via this channel, dictating exactly which MFA challenge screen to render. Cisco Talos has also recently published a report on a different phishing campaign where similar WebSocket techniques were observed in a phishing kit used by a Chinese-speaking actor. However, the strategies employed by that phishing kit differ from those in this case.

The following diagram illustrates the real-time AitM relay architecture.

At the beginning phase, the threat actor collects device and browser information, including the locale, user agent, screen dimensions, and mobile-device status. This data is sent to the actor’s HTTP C2 server through a google_login_start request. After the server creates a session, the JavaScript establishes a WebSocket connection with the actor’s C2 infrastructure and receives a snapshot containing the current session state.

The victim enters an email address or phone number into the fake Google login page. The phishing page sends the identifier to the actor’s HTTP C2 server using the google_input_identifier event. The actor’s server then relays the identifier to the real Google authentication service to verify whether the account exists and determines whether a passkey-based flow is enabled. Based on Google’s response, the actor instructs the phishing page through WebSocket state updates to display either the password-entry page or a passkey prompt.

When the victim submits a password, the phishing page sends the password, account identifier, and browser user-agent information to the actor’s HTTP C2 server through a google_login_check request. The actor’s server forwards the credentials to the real Google authentication service. If the credentials are accepted and Google requires additional authentication, the server returns the MFA challenge type and layout. The actor then advances the victim’s interface to the appropriate MFA step through a WebSocket update.

By deliberately splitting one-shot uploads with POST requests from low-latency state updates with WebSocket connection, the threat actor has engineered a seamless credential-harvesting relay. This allows the threat actor to mirror Google's dynamic authentication state in real time, ultimately achieving full account takeover without raising the victim's suspicion.

Coverage  

The following ClamAV signatures detect and block this threat:  

• Html.Phishing.UAT11985-10060614-0 

The following SNORT® rules (SIDs) detect and block this threat:   

• Snort2: 1:67198
• Snort3: 7:31

Indicators of compromise (IOCs)  

The IOCs can be found in our GitHub repository here.