• Cisco Talos uncovered a cluster of activity we track as UAT-10362 conducting spear-phishing campaigns against Taiwanese non-governmental organizations (NGOs) and suspected universities to deliver a newly identified malware family, “LucidRook.” 
• LucidRook is a sophisticated stager that embeds a Lua interpreter and Rust-compiled libraries within a dynamic-link library (DLL) to download and execute staged Lua bytecode payloads. The dropper “LucidPawn” uses region-specific anti-analysis checks and executes only in Traditional Chinese language environments associated with Taiwan. 
• Talos identified two distinct infection chains used to deliver LucidRook, involving malicious LNK and EXE files disguised as antivirus software. In both cases, the actor abused an Out-of-band Application Security Testing (OAST) service and compromised FTP servers for command-and-control (C2) infrastructure. 
• Through hunting for LucidRook, we discovered “LucidKnight,” a companion reconnaissance tool that exfiltrates system information via Gmail. Its presence alongside LucidRook suggests the actor operatesa tiered toolkit, potentially using LucidKnight to profile targets before escalating to full stager deployment. 
• The multi-language modular design, layered anti-analysis features, stealth-focused payload handling of the malware, and reliance on compromised or public infrastructure indicate UAT-10362 is a capable threat actor with mature operational tradecraft.

---

Spear-phishing campaigns against Taiwanese NGOs and universities 

Cisco Talos observed a spear-phishing attack delivering LucidRook, a newly identified stager that targeted a Taiwanese NGO in October 2025. The metadata in the email suggests that it was delivered via authorized mail infrastructure, which implies potential misuse of legitimate sending capabilities.

The email contained a shortened URL that leads to the download of a password protected and encrypted RAR archive. The decryption password was included in the email body. Based on this email and the collected samples, Talos observed two distinct infection chains originating from the delivered archives. 

Decoy files 

In the infection chain, the threat actor deployed a dropper that opens the decoy documents included in the bundle. One example decoy file is a letter issued by the Taiwanese government to universities in Taiwan. This document is a formal directive reminding national universities that teachers with administrative roles are legally required to obtain prior approval and file attendance records before traveling to China. An official version of this document can be found on the Taiwanese government website.

Two infection chains 

Talos identified two infection chains used to deploy LucidRook. Both were multi-stage and began with either an LNK or an EXE launcher. The LNK infection chain uses an initial dropper Talos tracks as LucidPawn. 

LNK-based infection chain

The LNK-based infection chain was observed in both the sample targeting Taiwanese NGOs (which were distributed via spear-phishing emails) and the sample we suspect targeted Taiwanese universities. Both samples were delivered as an archive, containing an LNK file with a document file with substituted PDF file icon, as well as a hidden directory in the folder, as shown in Figure 3.

The hidden directory contains four layers of nested folders designed to evade analysis. The fourth-level directory contains the LucidPawn dropper sample (DismCore.dll), a legitimate EXE file (install.exe), and a decoy file. An example folder structure is shown in Figure 4.

When the user clicks the LNK file, it executes the PowerShell testing framework script C:Program FilesWindowsPowerShellModulesPester3.4.0Build.bat, passing the path to binaries located in the hidden directory in order to launch the embedded malware. This is a known technique that leverages living-off-the-land binaries and scripts (LOLBAS) to evade detection.

The PowerShell process executes the following command:

The index.exe file is a legitimate Windows binary associated with the Deployment Image Servicing and Management (DISM) framework. It is abused as a loader to sideload LucidPawn via DLL search order hijacking.

The LucidPawn dropper embeds two AES-encrypted binaries: a legitimate DISM executable and the LucidRook stager. Upon execution, both binaries are decrypted and written to %APPDATA%LocalMicrosoftWindowsApps, with the DISM executable renamed to msedge.exe to impersonate the Microsoft Edge browser and the LucidRook stager written as DismCore.dll. Persistence is established via a LNK file in the Startup folder that launches msedge.exe. After dropping the binaries, LucidPawn launches the DISM executable to sideload the LucidRook stager.  

The LucidPawn dropper also handles decoy documents by locating files with specific document extensions (.pdf, .docx, .doc, .xlsx) in the working directory, copying them to the first layer directory, deleting the original lure LNK file, and opening the decoy using Microsoft Edge to distract the victim.

EXE-based infection chain  

The second infection chain leverages only a malicious EXE written in the .NET framework without the LucidPawn dropper.

Talos observed the EXE-based infection chain in samples uploaded to public malware repositories in December 2025. The samples were distributed as password protected 7-Zip archives named “Cleanup(密碼：33665512).7z”. Based on the Traditional Chinese language used in the archive filename, the language shown in the malicious dropper, and the geographic context of the sample upload locations, we assess with moderate to high confidence that the campaign was intended to target Taiwanese entities.

The 7-Zip archive contains a single executable file named Cleanup.exe. The extracted binary masquerades as Trend Micro™ Worry-Free™ Business Security Services, using a forged application name and icon to impersonate a legitimate security product. In addition, the binary contains a compilation timestamp that is clearly falsified (2065-01-12 14:12:28 UTC).

The executable is a simple dropper written with the .NET framework. It embeds three binary files as Base64-encoded data within its code and, upon execution, decodes and drops these files into the C:ProgramData directory. The dropped files include a legitimate DISM executable, the LucidRook stager, and a LNK file placed in the Startup folder to establish persistence.

After execution, the program displays a decoy message box claiming that the cleanup process has completed.

LucidRook Lua-based stager 

LucidRook is a sophisticated 64-bit Windows DLL stager consisting of a Lua interpreter, embedded Rust-compiled libraries, and Lua bytecode payload. The DLL embeds a Lua 5.4.8 interpreter and retrieves a staged payload (in our sample named archive1.zip) from its C2 over FTP. After unpacking and validating the downloaded stage, the implant loads and executes the resulting Lua bytecode on the compromised host. Embedding the Lua interpreter effectively turns the native DLL into a stable execution platform while allowing the threat actor to update or tailor behavior for each target or campaigns by updating the Lua bytecode payload with a lighter and more flexible development process. This approach also improves operational security, since the Lua stage can be hosted only briefly and removed from C2 after delivery, and it can hinder post-incident reconstruction when defenders recover only the loader without the externally delivered Lua payload.  

Due to the embedded Lua interpreter and stripped Rust-compiled components, the DLL is complex to reverse engineer. The binary is approximately 1.6MB in size and contains over 3,800 functions, reflecting the amount of runtime and library code bundled into a single module. Execution is initiated via the DllGetClassObject export; however, the sample implements no COM functionality and uses the export solely as an entry point.

Upon execution, the malware’s core workflow is twofold. First, it performs host reconnaissance, collecting system information that is encrypted, packaged, and exfiltrated to the C2 infrastructure. It then retrieves an encrypted, staged Lua bytecode payload from the C2 server, which is subsequently decrypted and executed on the compromised host.

Lua interpreter embedding implementation 

LucidRook embeds a Lua 5.4.8 interpreter directly inside the DLL and uses it to execute a downloaded Lua bytecode stage. Before handing the stage to the VM, the loader verifies that the decrypted blob begins with the standard Lua bytecode magic (x1bLua), indicating the payload is a compiled Lua chunk rather than plaintext script.

The Lua runtime is also wrapped with additional controls. Notably, the malware implements a non-standard “safe mode” that disables package.loadlib (as shown by the unique error string “package.loadlibis disabled in safe mode”), which prevents Lua payloads from loading arbitrary external DLL-based modules via the standard require/loader pathway. Additionally, in the library initialization flow observed, the malware opens common standard libraries (e.g., io, os, string, math, package) but does not open the debug library, which would normally provide powerful introspection primitives; this omission is consistent with an anti-analysis hardening choice.

String obfuscation scheme 

The LucidRook samples employ a sophisticated string obfuscation scheme. The obfuscation was applied to almost all the embedded strings including file extensions, internal identifiers, and C2 addresses. This transformation increases the difficulty of analysis and detection.

The deobfuscation follows a structured two-stage runtime process: 

1. Address calculation: Rather than using direct offsets, the malware calculates the memory address of an encrypted string through a unique series of arithmetic operations for each string. This design prevents cross-referencing encrypted data blocks to their use-sites for reverse engineering.  
2. Runtime key reconstruction and XOR decryption: Each 4-byte chunk is decrypted using XOR with a key that is not hardcoded directly. Instead, the key is reconstructed at runtime by combining a constant seed value (ending in 0x00) and a single-byte mask read from a parallel lookup table: Plaintext = Ciphertext ^ (Seed | Mask)

The use of a parallel lookup table for masks significantly complicates the creation of automated “unpacking” scripts, as the relationship between the encrypted string and its corresponding mask is obscured by the flattened control flow.

Host reconnaissance 

The malware collects several system information including user account name, computer name, driver information, user profile directory, installed applications, running process, and so on. The collected information is stored into three files (named 1.bin, 2.bin, 3.bin) with two layers of encryptions: RSA and a password-encrypted ZIP archive. The BIN files are encrypted with an embedded RSA public key (DER hash ab72813444207dba5429cf498c6ffbc69e1bd665d8007561d0973246fa7f8175) and then compressed into a ZIP file encrypted with password !,OO5*+ZEYORE%&.K1PQHxiODU^RA046. With these encryptions in place, the exfiltrated data can only be decrypted by the threat actor. The decrypted RSA public key used to encrypt exfiltrated data is:

-----BEGIN RSA PUBLIC KEY----- 
MIIBCgKCAQEA3YeM0FbZO8QB3/ctZd2+oS8weSUwmgp33c5lVJ8InJx5yJJnXF+8 
qLL+nzwcItVQyAQbZBymN9ueIgkNRBQuRJgZOxLHG2cbNIWXMImKb5zkkyIUfCz1 
hLprvBu4i2IIeWTFyTLfIpwZ/rUn+lARRmIeWTmJezOaSh5QvVaF6Oqk5qoTXk9A 
MivxKnfFiMhlBh3/V6S4+gTzqy7IwgSuPv8IL6n5LF+N8DmIvAVCck1e2KIYMu54 
UT7ef16N60LVksADJsnk+E5CSOeD4FzSTjS9G9c3sZFP/7r7xAbr5CbKvaBvJ+49 
7OlzJjaq1H+M7aOAPKaf/hyewEHIr+W1EQIDAQAB 
-----END RSA PUBLIC KEY----- 

The encrypted data is archived into a file named archive4.zip and uploaded to the C2 FTP server using authenticated credentials obfuscated and embedded in the stager. 

C2 communication 

The LucidRook stager communicates with the abused/compromised FTP servers to not only upload the collected system information but also to download and execute Lua bytecode payload to achieve remote code execution. 

FTP servers with publicly exposed credentials 

LucidRook uses plaintext FTP for both staging and exfiltration. In the observed captures, the implant authenticates with embedded credentials, switches to binary mode (TYPE I), enters passive mode (PASV), and uploads the exfiltrated information in an archive named archive4.zip via STOR before closing the session. It then establishes a second FTP session and attempts to retrieve archive1.zip (payload) via RETR.

The LucidRook samples connect to C2 infrastructure that appears to abuse FTP servers with exposed credentials to retrieve staged payloads. Talos identified two such C2 servers, both located in Taiwan and operated by printing companies. Initially, it was unclear why the threat actor selected this infrastructure; however, further investigation revealed that both companies publicly listed FTP credentials on their official websites as part of a “file uploading service”. We observed that this practice is common among local printing companies and effectively creates a pool of publicly accessible, low‑cost infrastructure that can be repurposed by threat actors as low-cost C2 staging servers.

Stealthy payload protections 

Besides what we previously mentioned about the encryption for the exfiltrated data, the threat actor also employed stealthy protection for the downloaded payload. The LucidRook sample Talos obtained (edb25fed9df8e9a517188f609b9d1a030682c701c01c0d1b5ce79cba9f7ac809) uses the password ?.aX$p8dpiP$+4a$x?=0LC=M>^>f6N]a to decrypt the archive when it’s protected and requires that an index.bin file be found within the ZIP archive. After decryption, it uses a different RSA private key (DER hash 7e851b73bd59088d60101109c9ebf7ef300971090c991b57393e4c793f5e2d33) embedded and encrypted inside the malware to decrypt the payload. The corresponding public key (DER hash a42ad963c53f2e0794e7cd0c3632cc75b98f131c3ffceb8f2f740241c097214a) for this private key is:

-----BEGIN PUBLIC KEY----- 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ9deG1+FiOgxT2eX78n 
3Ni/PmrV/V6iuf+bc+ii+9wD6Pyc7QyicaZODr2YlKifwJabJuDsIcANRIQGBLf2 
8j0yG3x25rP4XTnavTyPB6s+fJgNebmB9Hhgx3AY25ufJvNAelnmXnPn/xp6tZ/V 
kup72tiwKWeBVJOZYW3qYno4n5hffdNqTFIgUZDDLhqa+nT1gD6LZ6W/BidIM70O 
gn2h8ppc8aKc893FkfvNYwhgubiDFv9rgvSVvxt0uTVERtBsCyAScD1MMvswEyK6 
LrgnyTz7KwOv5wyPfE3BPs8lpMQIyi/jcIIroyk9uLarfV/XIbgTOqEYf5/9bDSs 
iQIDAQAB 
-----END PUBLIC KEY----- 

During investigation, Talos obtained a payload from a private source which matched the index.bin file structure. However, the password from the LucidRook sample we got was not able to decrypt the archive. We also obtained another version of the payload from the FTP C2 server, but this payload includes four files that does not match the version of LucidRook sample we analyzed as shown in Figure 16.

Based on this information, we suspect that the threat actor is generating different payloads using different sets of passwords for different targets, even though they share the same C2 server. The files inside the payload also suggest it potentially leverages different modules for different capabilities for the stager. 

LucidPawn dropper 

The LucidPawn dropper shares some similarity with LucidRook, including the same COM DLL masquerade technique, obfuscation scheme, and Rust-compiled code. 

Leveraging an OAST service 

Upon execution, the LucidPawn dropper sends a DNS request to a domain “D.2fcc7078.digimg[.]store”. The domain “digimg[.]store” redirects to “dnslog[.]ink”, a public Chinese Out-of-band Application Security Testing (OAST) service. It is widely used by security researchers, penetration testers, and threat actors to verify network connectivity and vulnerability exploitation. By using this service, LucidRookoperators receive confirmation once the exploitation succeeds without setting up their own infrastructure. It is worth noting that the same service domain has been leveraged in other targeted campaigns; however, because the service is publicly accessible and can be used by any threat actor, Talos avoids making attribution based solely on this linkage.

Geo-targeting anti-analysis 

LucidPawn implements a geo-targeting anti-analysis execution gate by querying the host’s Windows UI language via the GetUserDefaultUILanguage() API. Execution continues only when the system UI language matches Traditional Chinese environments associated with Taiwan.

The implementation compares a masked LANGID against 0x0404 (zh-TW). The mask and 0xF7FF clears bit 0x0800, causing only 0x0404 (zh-TW) and 0x0C04 (zh-HK) to normalize to the same value and satisfy the check. As a result, the sample exits early on most analysis sandboxes, which commonly use 0x0409 (en-US). This control reduces exposure by limiting execution to the intended victim geography and suppressing behavior in common analyst environments.

The LucidKnight reconnaissance tool 

While hunting for additional LucidPawn samples, we identified a variant of LucidPawn (d8bc6047fb3fd4f47b15b4058fa482690b5b72a5e3b3d324c21d7da4435c9964). This sample shares the same geo-targeting anti-analysis logic observed in other samples used to deliver LucidRook. Compared with the LucidPawn samples associated with LucidRook delivery, however, this variant omits the callback to the out-of-band interactive service domain and functions solely as a dropper, deploying the reconnaissance tool LucidKnight (aa7a3e8b59b5495f6eebc19f0654b93bb01fd2fa2932458179a8ae85fb4b8ec1) after execution.

Like other malware in the Lucid family, LucidKnight is a 64-bit Windows DLL that contains embedded Rust-compiled components to implement various functions. The malware also uses a string obfuscation scheme similar to those observed in LucidPawn and LucidRook to conceal its C2 configuration.

Upon execution, LucidKnight collects system information including the computer name, OS version, processor architecture, CPU usage, running processes, and installed software. The collected data are written to four TXT files, encrypted with an embedded RSA public key, and packaged into a password-protected ZIP archive named archive.zip using the password xZh>1<{Km1YD3[V>x]X>=1u(Da)Y=N>u. The embedded RSA public key (DER hash 852a80470536cb1fdab1a04d831923616bf00c77320a6b4656e80fc3cc722a66) is shown below:

-----BEGIN RSA PUBLIC KEY----- 
MIIBCgKCAQEAuvXyx+rPGjS/bI6cvl8LIVVatwD6JU19EvJPlBWlmPqVm/se+3QS 
9av+X8PFgwoGXJZTEanAY4JhOMXKYSbErwrLktbEY2tFi7w3/WyPPcB6/I6zD2yU 
Mqcoqy1Z3+4CsLz4D/LZtOst4alSGOgTDeKtrWKHCyigFvndfds4pdCy78KBRtQb 
kV3UUlKQZm/37tP0CPXkKwxQ1n/+DTh265gRaVrhr4+VUagNmYta1faMLsvM8O3F 
Lu2tQiOxeSZC21z6V3kcifYiBLT0khx11JqD3jTfA41OcngZfwWYHbitDBZF7rpL 
26ZSitNxMAq1O6DrXzI5wdVn0fZgSXNEbwIDAQAB 
-----END RSA PUBLIC KEY----- 

Unlike LucidRook, which uploads collected system information to a compromised FTP server, LucidKnight exfiltrates reconnaissance data via email using the embedded Rust lettre crate, which provides SMTP message creation and delivery functionality.

Specifically, the malware constructs an email with the Traditional Chinese subject “運動資訊平台” (“Sports Information Platform”) and includes the collected data as a MIME attachment. It then resolves “smtp.gmail.com”, authenticates to the Gmail account “fexopuboriw972@gmail.com” with an embedded application key, and sends the data to the temporary email address “crimsonanabel@powerscrews.com”. The following email shows an example of the content crafted by LucidKnight:

From: fexopuboriw972@gmail.com 
To: crimsonanabel@powerscrews.com 
Subject: =?utf-8?b?6YGL5YuV6LOH6KiK5bmz5Y+w?= 
MIME-Version: 1.0 
Date: Tue, 17 Feb 2026 02:05:49 +0000 
Content-Type: multipart/mixed; 
 boundary="vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd" 
--vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd 
Content-Type: text/plain; charset=utf-8 
Content-Transfer-Encoding: base64 
5oKo6KqN54K65Y+w54Gj55uu5YmN5Zyo6Jed5paH5rC457qM55m85bGV55qE5pS/562W5LiK5pyJ 
5ZOq5Lqb5YW36auU55qE5oiQ5Yqf5qGI5L6L5oiW5YC85b6X5pS56YCy55qE5Zyw5pa577yf 
--vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd 
Content-Type: application/zip 
Content-Disposition: attachment; filename="archive.zip" 
Content-Transfer-Encoding: base64 
UEsDBDMAAQBjALgQUVwEOkfvkhkAAHEZAAAFAAsAMS50eHQBmQcAAQBBRQMIAEF/fb/F6o3HptX3 
(redacted)

The discovery of LucidKnight suggests that the actor maintains a modular toolkit and may select components based on the operational context of each target, rather than deploying a fixed infection chain. LucidKnight may be used independently when lightweight reconnaissance is sufficient, or as a precursor to assess targets before committing the more complex LucidRook stager. 

The bottom line 

Based on the tactics, techniques, and procedures (TTPs) and the level of engineering investment observed across these infection chains, we assess with medium confidence that this activity reflects a targeted intrusion rather than broad, opportunistic malware distribution. Delivery via spearphishing, combined with LucidRook’s sophisticated design, suggests a sophisticated threat actor prioritizing flexibility, stealth, and victim-specific tasking.

Although Talos has not yet found a decryptable Lua bytecode payload executed by LucidRook, we are publishing these findings to make early detection possible and encourage community sharing, with the goal of uncovering additional indicators that may facilitate stronger clustering and attribution in the future.

Coverage 

The following ClamAV signature detects and blocks this threat:

• Win.Backdoor.LucidRook-10059729-0  
• Lnk.Tool.UAT-10362-10059730-0  
• Win.Dropper.UAT-10362-10059731-0  
• Win.Tool.CobaltStrike-10059732-0 

The following SNORT® rules cover this threat:  

• Snort2 Rules: 66108, 66109, 66110, 66111 
• Snort3 Rules: 301447, 301448 

Indicators of compromise (IOCs)  

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

d49761cdbea170dd17255a958214db392dc7621198f95d5eb5749859c603100a (malicious 7z) 

adf676107a6c2354d1a484c2a08c36c33d276e355a65f77770ae1ae7b7c36143 (malicious archive) 

b480092d8e5f7ca6aebdeaae676ea09281d07fc8ccf2318da2fa1c01471b818d (Forged EXE dropper that drops LucidRook) 

c2d983d3812b5b6d592b149d627b118db2debd33069efe4de4e57306ba42b5dc (Forged EXE dropper that drops LucidRook) 

6aba7b5a9b4f7ad4203f26f3fb539911369aeef502d43af23aa3646d91280ad9 (LucidPawn, DismCore.dll) 

bdc5417ffba758b6d0a359b252ba047b59aacf1d217a8b664554256b5adb071d (LucidPawn dropper, DismCore.dll) 

f279e462253f130878ffac820f5a0f9ac92dd14ad2f1e4bd21062bab7b99b839 (malicious LNK) 

166791aac8b056af8029ab6bdeec5a2626ca3f3961fdf0337d24451cfccfc05d (malicious LNK) 

11ae897d79548b6b44da75f7ab335a0585f47886ce22b371f6d340968dbed9ae (LucidRook stager, DismCore.dll) 

edb25fed9df8e9a517188f609b9d1a030682c701c01c0d1b5ce79cba9f7ac809 (LucidRook stager, DismCore.dll) 

0305e89110744077d8db8618827351a03bce5b11ef5815a72c64eea009304a34 (LucidRook stager, DismCore.dll) 

d8bc6047fb3fd4f47b15b4058fa482690b5b72a5e3b3d324c21d7da4435c9964 (LucidPawn dropper dropping LucidKnight) 

aa7a3e8b59b5495f6eebc19f0654b93bb01fd2fa2932458179a8ae85fb4b8ec1 (LucidKnight, DismCore.dll) 

fd11f419e4ac992e89cca48369e7d774b7b2e0d28d0b6a34f7ee0bc1d943c056 (archive1.zip download from C2)

1.34.253[.]131 (abused FTP server) 

59.124.71[.]242 (abused FTP server) 

D.2fcc7078.digimg[.]store (DNS beaconing domain) 

fexopuboriw972@gmail.com 

crimsonanabel@powerscrews.com 

Cisco Talos Blog – ​Read More

Join Amy and Pierre Cadieux as they unpack the ransomware and vulnerability trends that defined 2025. From the persistent ransomware threats targeting the manufacturing sector to the rise of stealthy living-off-the-land tactics, we break down what these shifts mean for your defense strategy.

Why are attackers are increasingly targeting your management infrastructure? How do you spot the difference between a system admin and a threat actor? Tune in to hear Talos’ insights on how to move beyond reacting to threats and start building a more resilient, proactive security posture for the year ahead.

View the 2025 Year in Review here.

Cisco Talos Blog – ​Read More

By Diana Brown

• Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
• These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
• By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
• In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved. 
• During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity. 

Platform abuse, social engineering, and SaaS notification hijacking 

Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos’ analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering. 

The PaaP model 

The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform’s own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a “seal of approval” that few security gateways are configured to challenge. 

Anatomy of GitHub campaign: Abusing automated notification pipelines 

The GitHub vector is a pure “notification pipeline” abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.  

By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page. 

The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.  

The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the “invoice” lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set. 

Abusing workflow and invitation logic (Jira) 

The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a “pipeline” of activity, but an abuse of the collaborative invitation feature.  

Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious. 

In this example, the attacker sets the “Project Name” to “Argenta.” When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees “Argenta” as the sender or the subject, which the platform has verified as the project name. 

The attacker placed their malicious lure subject into the “Welcome Message” or “Project Description” field. They use the “Invite Customers” feature and input the victim’s email address. Atlassian’s backend then generates the email. Because the system is designed to be a “Service Desk,” the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.  

Strategic implications 

The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform’s own reputation to launder their malicious content. 

How do we fundamentally change the trust model? 

Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.  

Identity and instance-level verification: We must move from “global domain trust” to “instance-level authorization.” Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization’s internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action. 

Upstream API-level monitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform “precursor activities” within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a “Project Creation” event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack. 

Semantic intent and behavioral profiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional “Communication Baseline.” GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect “semantic discontinuity,” when the content of a notification (e.g., urgent financial billing) is incongruent with the platform’s primary utility. Any notification that deviates from the expected functional profile should trigger an automated “Suspicious” banner or be routed for manual review, regardless of its technical validity. 

Mitigating cognitive automation fatigue: PaaP attacks exploit “automation fatigue,” where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the “reflexive trust” that attackers rely on. This ensures that the platform’s “seal of approval” is validated by a deliberate human action. 

Automated takedown orchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable. 

By adopting this framework, the security posture evolves from “Is this email authenticated?” to “Is this platform activity authorized and consistent with our business logic?” This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline. 

Acknowledgements 

Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors. 

Indicators of compromise (IOCs) 

IOCs for this threat can be found on our GitHub repository here. 

Cisco Talos Blog – ​Read More

In the span of just a few weeks, we have observed a dizzying array of major supply chain attacks. Prominent examples include the malicious modification of Axios, a popular HTTP client library for JavaScript, as well as cascading compromises from TeamPCP, a “chaos-as-a-service” group that injected malicious code into hijacked GitHub repositories for open-source projects, including Trivy, an open-source security scanner.

The impact of these supply chain attacks can be vast. Axios receives 100 million downloads weekly and innumerable organizations rely on the frameworks and libraries compromised by TeamPCP. The headache they pose to organizations and their security personnel is considerable as well; affected utilities can be integrated so deeply that it may be difficult to fully catalog, let alone remediate.

Although the timing, scale, and severity of these attacks can be shocking, this is not a new phenomenon. The supply chain has remained an attractive target for some time because of its fragility and the fact that a successful compromise can lead to countless additional downstream victims.

Findings from the recently published Talos 2025 Year in Review illustrate these long-standing trends. Nearly 25% of the top 100 targeted vulnerabilities we observed in 2025 affect widely used frameworks and libraries. Digging deeper into the list reveals additional insights. The React2Shell vulnerability affecting React Server Components became the top-targeted vulnerability of 2025 despite being disclosed in December, reflecting the speed at which these supply chain attacks can reach massive scale. The presence of Log4j vulnerabilities shows how deeply embedded these utilities can be and therefore how difficult it can be to reduce the attack surface. Although these particular examples represent extant vulnerabilities that can be weaponized by numerous adversaries versus a deliberate attack carried out by a single adversary, they show how impactful and disruptive threats to the supply chain can be. Follow-on attacks can range from ransomware to espionage, which is reflective of the broad swath of adversaries that carry them out — from sophisticated state-sponsored groups to teenage cyber criminals.

If we are all building on such shaky foundation, what can we do to keep safe? After all, it certainly seems dire when a tool such as Trivy that we could normally use to scan for supply chain vulnerabilities becomes compromised itself. But there are concrete steps we can take to improve our security posture.

As highlighted in the Year in Review, protecting identity is key. This includes securing CI/CD pipelines to prevent these types of compromises from occurring in the first place, as well as limiting the impact and lateral movement of an adversary should they obtain access to a downstream victim.

In addition, organizations must try to the best of their abilities to inventory the software libraries and frameworks they employ, stay informed of security incidents, and respond rapidly to implement patching and other mitigations.

Just as supply chain attacks are evergreen, so too is the efficacy of security fundamentals, such as segmentation, robust logging, multi-factor authentication (MFA), and the implementation of emergency response plans.

As trust continues to break down, the only viable solution may be to double down on vigilance. Since this recent spate of attacks represents a trend that will likely only grow in intensity and breadth, the time for action and planning is now.

Coverage

Below, find a sample of the some of the recent coverage we offer to protect against these threats:

ClamAV:
Txt.Trojan.TeamPCP-10059839-0

Txt.Trojan.TeamPCP-10059839-0

Behavioral Protections:
LiteLLM Supply Chain Compromise – alerts during installation of compromised packages

Cisco Talos Blog – ​Read More

As we already talked in a previous post, modern software development is practically unthinkable without the use of open-source components. But in recent years the associated risks have become increasingly diverse, complex, and numerous. When, first, vulnerabilities affect a company’s infrastructure and code faster than they’re remediated; second, data is unreliable and incomplete; and third, malware may be lurking within popular components, it’s not enough to simply scan version numbers and toss fix-it tickets at the IT team. Vulnerability management must be expanded to cover software download policies, guardrails for AI assistants, and the entire software build pipeline.

A trusted pool of open-source components

The main part of the solution is to prevent the use of vulnerable and malicious code. The following measures should be implemented:

• Having an internal repository of artifacts. The sole source of components for internal development needs to be a unified repository to which components are admitted only after a series of checks.
• Performing rigorous component screening. These include checks of: known versions of the component, known vulnerable and malicious versions, publication date, activity history, and the reputation of the package and its authors. Scanning the entire contents of the package, including build instructions, test cases, and other auxiliary data, is mandatory. To filter the registry during ingestion, use specialized open-source scanners or a comprehensive cloud workload security solution.
• Running dependency pinning. Build processes, AI tools, and developers mustn’t use templates (such as “latest”) when specifying versions. Project builds need to be based on verified versions. At the same time, pinned dependencies must be regularly updated to the latest verified versions that maintain compatibility and are free of known vulnerabilities. This significantly reduces the risk of supply chain attacks through the compromise of a known package.

Improving vulnerability data

To identify vulnerabilities more effectively and prioritize them properly, an organization needs to establish several IT and security processes:

• Vulnerability data enrichment. Depending on the organization’s needs, this is needed either to enrich information by combining data from NVD, EUVD, BDU, GitHub Advisory Database, and osv.dev, or to purchase a commercial vulnerability intelligence feed where the data is already aggregated and enriched. In either case, it’s worth additionally monitoring threat intelligence feeds to track real-world exploitation trends and gain an insight into the profile of attackers targeting specific vulnerabilities. Kaspersky provides a specialized data feed specifically focused on open-source components.
• In-depth software composition analysis. Specialized software composition analysis (SCA) tools allow for the correct navigation of the dependency chain in open-source code to fully inventory the libraries being used, and discover outdated or unsupported components. Data on healthy components also comes in handy to enrich the artifact registry.
• Identifying abandonware. Even if a component isn’t formally vulnerable and hasn’t been officially declared unsupported, the scanning process should flag components that haven’t received updates for more than a year. These warrant separate analysis and potential replacement, much like EOL components.

Securing AI code and AI agents

The activities of AI systems used in coding must be wrapped in a comprehensive set of security measures — from input data filtering to user training:

• Restrictions on dependency recommendations. Configure the development environment to make sure that AI agents and assistants can only reference components and libraries from the trusted artifact registry. If these don’t contain the right tools, the model should trigger a request to include the dependency in the registry, rather than pulling something from PyPI that simply matches the description.
• Filter model outputs. Despite these restrictions, anything generated by the model must also be verified to ensure the AI code doesn’t contain outdated, unsupported, vulnerable, or made-up dependencies. This check should be integrated directly into the code acceptance process or the build preparation stage. It doesn’t replace the traditional static analysis process: SAST tools must still be embedded in the CI/CD pipeline.
• Developer training. IT and security teams must be intimately familiar with the characteristics of AI systems, their operating principles, and common errors. To achieve this, employees should complete a specialized training course tailored to their specific roles.

Systematic removal of EOL components

If a company’s systems utilize outdated open-source components, a systematic, consistent approach to addressing their vulnerabilities should be taken. There are three primary methods for doing this:

• Migration. This is the most organizationally complex and expensive method, involving the total replacement of a component followed by the adaptation, rewriting, or replacement of the applications built upon it. Deciding on a migration is especially daunting when it demands a massive overhaul of all internal code. This frequently affects core components — it’s impossible to migrate away from Node.js 14 or Python 2 easily.
• Long-term support (LTS). A dedicated support-services market exists for large-scale legacy projects. Sometimes this involves a fork of the legacy system maintained by third-party developers; in other cases, specialized teams backport patches that fix specific vulnerabilities into older, unsupported versions. Transitioning to LTS generally requires ongoing support costs, but this can still be more cost-effective than a full migration in many cases.
• Compensatory controls. Based on the results of detailed analysis, a set of wraparound security measures to mitigate the exploitation risk for the vulnerabilities within the legacy product can be made. Both the effectiveness and economic viability of this approach depend on the role of the software within the organization.

Security, IT, and business must work together to choose one of these three paths for every documented EOL or abandoned component, and reflect the made choice in the company’s asset registries and SBOMs.

Risk-based open-source vulnerability management

All of the measures listed above reduce the volume of vulnerable software and components entering the organization, and simplify the detection and remediation of flaws. Despite this, it’s impossible to eliminate every single defect: the number of applications and components is simply growing too fast.

Therefore, prioritizing vulnerabilities based on real-world risk remains essential. The risk assessment model must be expanded to account for the characteristics of open source, answering the following questions:

• Is the vulnerable code branch actually executed in the organization’s environment? A reachability analysis for discovered vulnerabilities should be performed. Many defective code snippets are never actually run within the organization’s specific implementation, making the vulnerability impossible to exploit. Certain SCA solutions can perform this analysis. This same process permits evaluating an alternative scenario: what happens if the vulnerable procedures or components are removed from the project entirely? Sometimes, this method of remediation proves to be surprisingly painless.
• Is the defect being exploited in real-world attacks? Is a PoC available? The answers to these questions are part of standard prioritization frameworks like EPSS, but tracking must be conducted across a much broader set of intelligence sources.
• Has cybercriminal activity been reported in this dependency registry, or in related and similar components? These are additional factors for prioritization.

Considering these factors allows the team to allocate resources effectively and remediate the most dangerous defects first.

Transparency is the new black

The security bar for open-source software is only going to keep on rising. Companies developing applications — even for internal use — will face regulatory pressures demanding documented and verifiable cybersecurity within their systems. According to the estimates of Sonatype experts, 90% of companies globally already fall under one or more requirements to provide evidence of the reliability of the software they use; therefore, the experts deem transparency “the currency of software supply chain security”.

By controlling the use of open-source components and applications, enriching threat intelligence, and strictly monitoring AI-driven development systems, organizations can introduce the innovations the business craves — all while clearing the high bar set by regulators and customers alike.

Kaspersky official blog – ​Read More