Affected Platforms: Microsoft Wi 2026-6-11 13:0:0 Author: feeds.fortinet.com(查看原文) 阅读量:11 收藏
Affected Platforms: Microsoft Windows
Impacted Users: Any organization
Impact: Attackers gain control of the infected systems
Severity Level: High
As AI adoption continues to grow, threat actors have wasted no time exploiting the trend. FortiGuard Labs recently observed a campaign delivering malicious files disguised as AI-related documents, with titles such as "AI-Ready PostgreSQL 18: Building Intelligent Data Systems" and " A Guide for Thinking Marketers in the Age of AI."
These lures are designed to target users actively seeking AI-related learning resources. The attack chain behind these files is remarkably complex, using multiple staged scripts to hide activity before ultimately deploying AutoHotkey-based loaders that reflectively inject a .NET remote access trojan and AsynRAT into memory for command-and-control communication and follow-on execution. Notably, several intermediate-stage scripts make heavy use of Simplified Chinese variable names and exhibit a highly structured coding style, suggesting the threat actor likely leveraged AI assistance during development. This article walks through each stage of the infection chain in detail.
Figure 1: Attack chain
The Initial ZIP with LNK
The malware was distributed inside a compressed archive disguised as a technical resource titled Agentic Coding with Claude Code, The everyday developer’s guide to agentic coding with Claude Code.7z. At first glance, the archive appears harmless. Its visible contents are limited to a shortcut file, but it actually contains two other files named 3th.pdf and 4th.pdf with a Hidden attribute. The archive was intentionally designed to appear harmless. The archive does not distribute a straightforward executable. Instead, it delivers a carefully staged intrusion chain in which each phase exists primarily to reveal the next.
Figure 2: LNK and hidden files in the archived file
Once the victim opens the LNK file, the shortcut executes an obfuscated command sequence built from native Windows components such as cmd.exe, more, type, and findstr. The LNK treats 3th.pdf not as a document, but as a data container. It enumerates the file line by line, extracts a narrow range of lines (26004, 26005, 26006, and 26007), and executes only that extracted content. The attacker doesn’t place their payload in a single obvious script or executable. Instead, they use a single file as a multi-zone storage container, with each phase knowing only how to retrieve the next phase at a specific offset.
Figure 3: Command in LNK file
The Embedded PowerShell Script
The first extracted block from 3th.pdf is not the final payload either. It is a short staging script that again reads from 3th.pdf, but this time skipping deep into the file and selecting another limited line range before piping the result directly into PowerShell. The PowerShell stage is invoked with “-windowstyle hidden” to suppress any visible console window, -NoProfile (-nop) to prevent interference from user profile scripts, and -ExecutionPolicy Bypass (-ep Bypass) to circumvent the system's script execution restrictions.
Figure 4: Targeted batch script in 3.pdf
The PowerShell script contains cryptographic logic. It searches 3th.pdf for data wrapped between markers m1 and m2 (-----BEGIN PGP PRIVATE KEY BLOCK----- and -----END PGP PRIVATE KEY BLOCK-----), filters out header-like lines, concatenates the remaining content, and decodes it from Base64. The script uses a fixed password of "1" and derives keys through PBKDF2 before decrypting the payload with AES-CBC. The plaintext is interpreted as a PowerShell script saved at %APPDATA% as Cache_{GUID}.ps1 and immediately executed.
Figure 5:Extracting data from 3.pdf
Figure 6: The encrypted data in 3.pdf
Figure 7: Dropping decrypted data as Cache_{GUID}.ps1
The Dropped PowerShell Script
Once the decrypted script runs, the role of 3th.pdf expands further. The file contains not just one hidden stage but several distinct embedded data regions. The script first builds a working directory under %LOCALAPPDATA%\Packages\Microsoft.WindowsSoundDiagnostics, a path clearly chosen to resemble a benign Windows audio or diagnostics component. It then searches 3th.pdf for === SoundEffects X === markers, concatenates the hex data between them, strips out non-hex characters, converts the result back into bytes, and writes the output as a file named Subtitles.
Figure 8: Extracting data from 3.pdf and saving it as "Subtitles”
The script then performs two additional extraction routines against 3th.pdf, scanning for fields named Name and KasKos, decoding their Base64-encoded payloads using a custom XOR-based decryption routine keyed to the hardcoded string Realtek2025, and writing the results to the same staging directory as RealtekAudioService64.ps1 and RealtekAudioService64.bat.
Figure 9: Extracting a PowerShell and batch script from 3.pdf
After the payload extraction, the script establishes persistence by registering a scheduled task named CheckRealtekAudioVersion, disguised as a Realtek audio service and configured to execute the dropped RealtekAudioService64.bat via cmd.exe. The task employs privilege-aware configuration and dual triggers to ensure the batch file is reliably invoked shortly after infection and at each subsequent user logon. Finally, it extracts the clean decoy 4th.pdf, a clean, benign decoy document presented to the victim as a distraction, creating the illusion of a legitimate file opening while the malicious components continue to execute silently in the background.
The coding style and inline annotations suggest the script was likely developed with assistance from a generative AI tool. The presence of a Simplified Chinese comment (# 静默任务创建脚本 - 无输出版本) alongside an emoji-annotated line (# 🔥 REMOVE EVERYTHING NOT HEX) within an otherwise English language script indicates that the threat actor's native language inadvertently surfaced in AI-generated output that was not fully sanitized before deployment. This is consistent with a workflow in which the overall attack logic was designed by a human operator, with AI tooling used to accelerate code implementation.
Figure 10: Persistence setting
Figure 11: Decoy PDF
Dropped Scripts “RealtekAudioService64”
RealtekAudioService64.bat serves as a stealthy launcher for the PowerShell stage. It first checks whether it was invoked with the hidden argument. If not, it immediately relaunches via PowerShell with -WindowStyle Hidden to suppress any visible console window before exiting the original instance. Once running in a hidden state, the string powershell.exe is reconstructed by concatenating three split variables rather than being referenced directly, a simple but effective technique to evade string-based static detection. The script then creates a timestamped log file in the staging directory with a versioned name (ver0x0000000000000003_) designed to blend in as a legitimate diagnostic artifact, before invoking RealtekAudioService64.ps1 with the -NoProfile, -WindowStyle Hidden, and -ExecutionPolicy Bypass flags to ensure silent and unrestricted execution. Finally, the log file is deleted to remove any trace of execution, leaving minimal forensic evidence.
Figure 12: Executing a PowerShell script in a batch file
RealtekAudioService64.ps1 represents a more sophisticated stage of the infection chain, employing multiple layers of obfuscation throughout its execution. Most notably, all PowerShell built-in cmdlets such as Test-Path, Join-Path, New-Item, and Out-Null are reconstructed at runtime from character arrays and stored entirely under Simplified Chinese variable names, i.e., $测试路径, $连接路径, $新建项目, and $输出空值.
This deliberate use of Chinese-language identifiers serves a dual purpose: it renders the script largely unreadable to analysts unfamiliar with the obfuscation pattern, and it bypasses signature-based detection rules that rely on recognizable English cmdlet strings. Directory paths and binary filenames are further concealed as Base64-encoded strings, which are decoded at runtime, ensuring that sensitive indicators do not appear in plaintext in the script body.
Figure 13: Defining variables in the PowerShell script
It opens the previously dropped Subtitles file as a GZip-compressed stream and decompresses it using a custom record structure. Each entry includes a relative path, a type field indicating whether it is a file or directory, and for file entries, a length followed by raw data. Before writing each file to disk, RealtekAudioService64.ps1 applies a byte transformation equivalent to subtracting 3 modulo 256, which serves as a lightweight decryption layer. The recovered directory tree is written to the path %LOCALAPPDATA%\Packages\Microsoft.WindowsSoundDiagnostics, where it deposits the real components that drive later execution stages, including AutoHotkey-based loaders, AHK scripts, and batch files.
Figure 14: Decoding and extracting " Subtitles”
After extraction, it registers two scheduled tasks: one targeting RealtekAudioEnhancements64.exe in the ConfigureSoundSettings subdirectory, and another targeting RtkNGUI64.exe in the Cache directory, registered under the task names RealtekAudioEnhancements64 and CheckRealtekAudioVersion, respectively. Both tasks are configured with multiple triggers covering user logon, system startup, and, where privileges permit, a daily trigger firing at noon, establishing robust and redundant persistence across reboots and user sessions.
Figure 15: Raw data of decoded "Subtitles"
Figure 16: Persistence setting
AutoHotkey Loader
One of the most important findings at this stage is that two of the recovered executables are not custom malware binaries. Their hashes match AutoHotkey.exe, even though they are named to resemble Realtek-related audio components. This indicates that the attackers are abusing AutoHotkey as an execution engine. The visible executable is benign, and the malicious logic resides in *.ahk scripts. This is an effective design choice. It reduces the need to deliver many custom compiled executables and shifts more logic into script layers that are easier to mutate and harder to classify based solely on PE characteristics.
Figure 17: The extracted data from "Subtitles"
From here, the chain splits into two major branches. The more substantial branch is driven by RtkNGUI64.ahk. That script imports four additional modules and then calls routines that reveal its true purpose. One helper selects a legitimate .NET Framework executable from C:\Windows\Microsoft.NET\Framework\v4.0.30319\, choosing randomly among binaries such as AddInProcess32.exe, AppLaunch.exe, and aspnet_compiler.exe. Another helper reads the file RtkLoggingManifest.man line by line, extracting integers from strings of the form System metric code = <number> and converting them into a byte array. In other words, the so-called manifest file is actually a disguised PE payload encoded as numeric text. After a brief delay, the script passes those bytes and the chosen host process path to an Execute() function implemented in RtkDiagService.ahk.
Figure 18: RtkNGUI64.ahk for path definition and the loading of four additional modules
Figure 19: RtkDeviceConfigure64.ahk for file reading
Figure 20: RtkCplApp.ahk for choosing targeted executables
That Execute() implements a full process hollowing workflow. The script creates a legitimate .NET process in a suspended state, parses the PE structure of the reconstructed payload, retrieves the target thread context, optionally unmaps the original image, allocates memory within the remote process, writes the payload’s headers and sections to the new memory region, repairs the execution context, and finally resumes the suspended thread.
The underlying API calls follow a classic injection sequence that includes CreateProcess, GetThreadContext, WriteProcessMemory, VirtualAllocEx, ZwUnmapViewOfSection, SetThreadContext, and ResumeThread. Rather than launching the payload directly from disk, this branch reconstructs a hidden PE from text-based data and injects it into a legitimate .NET Framework process.
What makes this implementation particularly unusual is its extensive use of identifiers drawn from Chinese mythology and philosophy throughout the script. Rather than directly referencing Windows APIs, the malware maps them to symbolic aliases such as “九天玄女“ (CreateProcess), “乾坤袋“ (VirtualAllocEx), and “起死回生“ (ResumeThread). Additional layers of abstraction are introduced through grouped naming schemes based on concepts such as “三界六道“ (Three Realms and Six Paths) and “五行八卦“ (Five Elements and Eight Trigrams).
These identifiers serve little functional purpose beyond obscuring the actual execution flow and complicating manual analysis. The naming style is highly unconventional for malware development and differs significantly from the short English variable names commonly seen in commodity loaders. Combined with the repetitive structural patterns and heavily templated code style observed across the scripts, the implementation strongly suggests the actor intentionally used culturally themed semantic abstraction to reduce readability and potentially evade simplistic pattern-based detection or analyst triage.
Figure 21: RtkDiagService.ahk for injection
The content derived from RtkLoggingManifest.man is a .NET executable. Although it has been obfuscated, we can still tell it is a clay_Client with RAT capabilities. We will discuss it in a later section.
Figure 22: RtkLoggingManifest.man containing the decoded data
Figure 23: Decoded executable from RtkLoggingManifest.man
The second branch, centered on RealtekAudioEnhancements64.ahk, is initially simpler but ultimately proves equally revealing. This script primarily serves as a wrapper that silently launches RealtekAudioEnhancements64.bat. The batch file then repeats the architectural theme seen earlier: it does not directly contain the next PowerShell payload, but instead reads another disguised container named RealtekAudioEnhancements64.assets, skips a fixed number of lines, extracts a narrow segment, and pipes that segment into PowerShell. The .assets file therefore functions as yet another stage container, with a malicious script buried within a much larger body of otherwise irrelevant or decoy content.
Figure 24: RealtekAudioEnhancements64.ahk for running “RealtekAudioEnhancements64.bat”
Figure 25: RealtekAudioEnhancements64.bat for executing a script in .assets file
The PowerShell recovered from .assets performs a different type of work. Before launching subsequent payloads, it attempts to weaken host defenses and normalize the environment for follow-on execution. It uses an elevated PowerShell process with runas to call Add-MpPreference, adding C:\ to Microsoft Defender’s exclusion paths and adding powershell.exe to Defender’s excluded processes. This is an overt defense-evasion step. The same script then launches two additional PowerShell files: RealtekAudioEnhancements64.ps1 and RealtekAudioEnhancements32.ps1.
Figure 26: RealtekAudioEnhancements64.assets
The 32-bit script is not a payload in the traditional sense. It serves as an environmental repair tool. It checks whether Windows Script Host has been disabled in the registry, re-enables it if necessary, and restores .vbs file associations to wscript.exe. If the required registry edits require elevated privileges, it relaunches itself with those privileges. This behavior is unusual but tactically significant. The malware is not merely hoping the system can execute VBS. It actively ensures that VBS execution is restored if the host has been hardened against it.
Figure 27: RealtekAudioEnhancements32.ps1
The 64-bit companion script uses the repaired scripting environment to establish an additional persistence layer. It writes a scheduled-task XML definition and a VBS file named ResetRealtekAudioSettings64.vbs, then creates a scheduled task called ResetRealtekAudioSettings64. That task does not call a PowerShell script directly. Instead, it invokes wscript.exe to run the VBS in background mode, and the VBS in turn launches another batch file with the following content:
On Error Resume Next
Set shell = CreateObject("WScript.Shell")
localAppData = shell.ExpandEnvironmentStrings("%LOCALAPPDATA%")
docPath = localAppData & "\Packages\Microsoft.WindowsSoundDiagnostics\Cache"
shell.Run """" & docPath & "\ResetRealtekAudioSettings64defualt.bat""", 0, False
This shows the actor layering persistence to reduce reliance on any single launcher. By this point, the malware has already used Task Scheduler once, but it now adds a VBS-mediated task chain on top of the earlier mechanisms.
Figure 28: Created XML file
The next batch file again acts as a line-range extractor, this time using a file named ResetRealtekAudioSettings64.Realtek as its container. It skips roughly 1,000 lines, extracts a specific block, and passes it to PowerShell. The .Realtek file is therefore another disguised payload archive, like 3th.pdf and .assets before it. The PowerShell block pulled from this file contains two important embedded objects. One is a long hex-encoded PE starting with MZ, followed by a valid PE header and .NET-specific imports such as mscoree.dll and _CorDllMain, confirming that it represents a 32-bit .NET executable or DLL. The second is another .NET assembly that is loaded reflectively in memory using Assembly.Load. The script then uses reflection to locate a public static method in that loader assembly and supplies two critical inputs: the path to C:\Windows\Microsoft.NET\Framework\v4.0.30319\cvtres.exe and the reconstructed .NET payload bytes.
At this point, PowerShell is no longer the primary executor. It is simply a mechanism for reflectively loading a .NET loader, which then prepares another .NET payload to run under a legitimate .NET utility. This aligns with the broader theme of operating within trusted execution surfaces and pushing malicious behavior deeper into memory-resident components.
Figure 29: ResetRealtekAudioSettings64.Realtek
Final Payload RAT
The final recovered .NET file from ResetRealtekAudioSettings64.Realtek is a modular RAT. It has been obfuscated and string encoded to increase the difficulty of analysis. It first creates mutex IDG5FUAM3PSONBSInGIGSWSD to prevent repeated execution.
Figure 30: .NET executable
After sleeping for a while, it decodes the strings for the C2 list: shampobiskworld.nl, shampoolagtto.com, and shamppocosmaticso.com. Once it contacts its C2 server, it extracts basic information from victims and uploads it to a remote server, including win32_processor, Environment.UserName, SOFTWARE\Microsoft\Windows NT\CurrentVersion for the OS version and build number, Win32_Processor.deviceid for the CPU, the security appliance from query root\SecurityCenter2, and the system time in the format yyyy-MM-dd HH:mm:ss.
Figure 31: Sets up C2 connection
The main class functions as the RAT’s command handler. It receives encrypted instructions from the C2 server, decrypts and deserializes them into an object array, and then uses the command value to determine which capability to execute.
Figure 32: Handling commands from the C2
The command sets have the following categories:
1. System Control Commands: these instructions manage the implant's state, persistence, and presence on the victim’s machine.
| Command | Technical Behavior & Impact |
| ClientShutdown | Kill Switch: Gracefully shuts down the communication socket (SocketShutdown.Both) and invokes Environment.Exit(0) to immediately kill the process |
| ClientDelete | Self-Deletion: An uninstallation routine designed to wipe traces of the malware from the disk and registry to obstruct forensic analysis |
| ClientUpdate | Remote Update: Drops a newly received payload binary into the %TEMP% directory, executes it quietly, and optionally triggers the self-delete mechanism on the older version |
| Ping | Heartbeat: A keep-alive mechanism to signal to the C2 panel that the infected node remains active and ready for instructions |
2. Surveillance and Remote Monitoring Commands: These capabilities grant the attacker real-time observation and interactive capability over the user's desktop environment.
| Command | Technical Behavior & Impact |
| RemoteDesktopOpen | Reconnaissance: Queries the system monitor topology using Screen.AllScreens.Length and exfiltrates screen dimensions back to the handler |
| RemoteDesktopSend | Screen Exfiltration: Captures screenshots using Graphics.CopyFromScreen, scales and compresses the frame into a JPEG format via specified encoder quality parameters to preserve bandwidth, and sends the raw bytes back to the C2 |
| mousemove | Input Mocking: Provisioned to parse mouse coordinates and simulate user input |
3. Advanced Execution & Evasion: This category represents the highest risk score within the payload, leveraging the .NET framework's modularity to bypass traditional Endpoint Detection and Response (EDR) solutions.
| Command | Technical Behavior & Impact |
| Reflection | Fileless Assembly Loading: Leverages Assembly.Load to dynamically parse a .NET DLL byte array directly into memory and call its EntryPoint. Because the payload never touches the physical disk, it effectively evades traditional static file scanning |
| RunPE | Process Hollowing: Injects malicious code blocks into a legitimate, trusted system process space (e.g., explorer.exe or svchost.exe). This masks the malicious network connections and resource usage behind a trusted Windows process image |
The communication layer is equally revealing. The malware serializes outbound objects, encrypts them using RijndaelManaged in ECB mode, and derives its encryption key from MD5. Inbound payloads are decrypted using the same static-key mechanism. Outbound data is prefixed with a custom length header and then written asynchronously to a socket. This confirms a stateful RAT architecture with custom serialization, encrypted transport, and persistent client-server interaction rather than a series of disconnected download events.
Another .NET file from RtkLoggingManifest.man is AsyncRAT with a C2 address of 107[.]172[.]10[.]190.
Figure 33: AsyncRAT
Conclusion
This attack chain functions as a fully realized multi-stage intrusion framework, purpose-built for stealthy payload delivery, modular execution, and long-term remote access, ultimately culminating in the deployment of a feature-rich .NET Remote Access Trojan.
Notably, several characteristics of the intermediate-stage scripts suggest AI-assisted development. The use of Simplified Chinese variable names throughout the PowerShell components, combined with an unsanitized Simplified Chinese comment and an emoji annotation left in the staging script, indicates that AI-generated output was deployed without adequate review or cleanup. While the overall attack logic reflects deliberate human design, these overlooked artifacts indicate a workflow in which generative AI tooling was used to accelerate implementation.
Users are strongly advised to exercise caution when handling shortcut files (.lnk), compressed archives, or documents from untrusted sources. Regularly auditing startup entries, scheduled tasks, and registry keys for unauthorized modifications, as well as monitoring for anomalous PowerShell execution and unexpected outbound network connections, are essential defensive measures.
Fortinet Protections
The malware described in this report are detected and blocked by FortiGuard Antivirus as:
LNK/Agent.MQOEQT!tr
MSIL/Agent.CDW!tr
POWERSHELL/Agent.CA!tr
The FortiGuard AntiVirus service engine is integrated into FortiGate, FortiMail, FortiClient, and FortiEDR. Customers running these products with up-to-date signatures are protected against the malware components described in this report.
The FortiGuard Web Filtering Service blocks the C2 server.
Organizations seeking to strengthen foundational security awareness may also consider completing Fortinet Certified Fundamentals (FCF) training in Cybersecurity. This module is designed to help end users learn to identify and protect themselves from phishing attacks.
The FortiGuard IP Reputation and Anti-Botnet Security Service proactively blocks infrastructure associated with this campaign by correlating malicious IP intelligence collected from Fortinet’s global sensor network, CERT collaborations, MITRE, trusted industry partners, and other intelligence sources.
If you believe this or any other cybersecurity threat has impacted your organization, contact our Global FortiGuard Incident Response Team for assistance.
IOCs
IP
107[.]172[.]10[.]190
Domains
Shampobiskworld[.]nl
shampoolagtto[.]com
shamppocosmaticso[.]com
Hashes
LNK
61b7fa5a7186cbf73dbc1f03e6e6f6819f5eb1e630a001059d381114bda2f974
POWERSHELL
7d6ee3c6ff8f70b1817aaec82aff1d2babe0b62cafef3975262644743afc0cb8
EXE
96b486bd7308ef3d6771360800f4c9b48b10697bd4cb69a8589b97b039377ecb
如有侵权请联系:admin#unsafe.sh