Agenda Ransomware Group Adds SmokeLoader and NETXLOADER to Their Arsenal

Key Takeaways

This blog entry details research on the Agenda ransomware group’s use of SmokeLoader and a new loader, which we named NETXLOADER. The new loader poses an increased risk of sensitive data theft and device compromise to targets due to its stealthy behaviour.
In the first quarter of 2025, Agenda ransomware activity has been observed in healthcare, technology, financial services, and telecommunications sectors across the US, the Netherlands, Brazil, India, and the Philippines.
Trend Vision One™ detects and blocks the malicious components, including Agenda ransomware, SmokeLoader, and NETXLOADER, used in the campaigns discussed in this blog. Trend Vision One customers can also access hunting queries, threat insights, and threat intelligence reports to gain rich context and the latest updates on Agenda ransomware.

The Agenda ransomware group, known as Qilin, has been an active and evolving threat since its discovery in July 2022.The group has shown a remarkable ability to adapt and enhance its capabilities over time. The Agenda ransomware has transitioned from being developed in the Go programming language to Rust, incorporating advanced features such as remote execution, enhanced propagation within virtual environments, and sophisticated evasion techniques that bypass security measures.

Based on Trend Micro threat intelligence data from the first quarter of 2025, Agenda ransomware activity was primarily observed in healthcare, technology, financial services, and telecommunications sectors across the US, the Netherlands, Brazil, India, and the Philippines.

In November 2024, we observed a campaign involving Agenda ransomware and SmokeLoader, which utilised a newly identified.NET compiled loader we've named NETXLOADER. The name reflects its role as a.NET-based malware loader that initiates the "next stages” of the attack. This loader is protected with.NET Reactor 6, significantly complicating reverse engineering efforts.

In this report, we present a comprehensive analysis of NETXLOADER, shedding light on its intricate mechanisms and the threat it poses. We will also detail how the loader is used in campaigns involving Agenda ransomware and SmokeLoader.

Technical analysis of NETXLOADER

NETXLOADER is a new.NET-based loader that plays a critical role in cyberattacks. While hidden, it stealthily deploys additional malicious payloads, such as Agenda ransomware and SmokeLoader. Protected by.NET Reactor 6, NETXLOADER is difficult to analyse. This section explains its complex workings and the threats it presents, offering important insights into the advanced tactics used by cybercriminals.

The emergence of NETXLOADER is tied to a sprawling infrastructure of malicious domains and a deliberate strategy to evade detection through deceptive file naming conventions. Threat actors have leveraged disposable, dynamically generated domains to host payloads, often mimicking benign blog-related services to avoid suspicion. Domains such as bloglake7[.]cfd, mxbook17[.]cfd, and mxblog77[.]cfd, amongst dozens of others, follow a distinct pattern: they combine words with randomised numbers and low-reputation top-level domains (.cfd,.xyz) to create transient hosting platforms. These domains act as ephemeral distribution hubs, cycling through payloads and disappearing before defenders can fully map their infrastructure.

Figure 1. Graphical representation of malicious domains resolving to a single IP address and the extensive array of executable files they deliver, illustrating the infrastructure used for malware distribution.

The malware is distributed under file names designed to blend into normal network traffic, such as rh10j0n.exe or ldx39iy.exe, which at first glance appear randomly generated. However, closer inspection reveals a systematic renaming strategy post-deployment. Once on a victim’s system, the executables are stripped of their pseudo-random suffixes and simplified to a standardised format: a two to three-letter prefix (e.g., rh, km, skx, ldx, mtx, pex) followed by 111.exe. For example:

rh10j0n.exe → rh111.exe
·ldx39iy.exe → ldx111.exe

This naming convention serves two purposes. First, it creates a false sense of legitimacy—generic names like mtx111.exe or ldx111.exe are less likely to raise alarms compared to overtly suspicious file names. Second, it decouples the payload’s identity from its filename. While our analysis identified rh111.exe delivering Agenda ransomware and ldx111.exe deploying SmokeLoader in one campaign, these prefixes are not exclusive to specific malware families. The same naming structure could be reused in future attacks to distribute entirely different payloads, depending on the attacker’s objectives.

The.NET compiled loader dynamically loads an assembly from a decrypted resource. It then iterates through its types, and attempts to invoke a method with obfuscated name using reflection:

This highly obfuscated loader employs gibberish method names and hidden MSIL codes, making static analysis nearly impossible. Its complexity is further enhanced by the utilisation of JIT hooking techniques. Specifically, it hooks into the compileMethod() function of the clrjit.dll library. This allows it to dynamically replace placeholder methods with actual MSIL bytecode at runtime, effectively evading traditional detection mechanisms and complicating the analysis process for security researchers.

Figure 3. Obfuscated loader using gibberish method names and JIT Hooking to evade detection.

The reason for this highly obfuscated code is due to its packing with.NET Reactor version 6. This protector employs advanced techniques such as control flow obfuscation, anti-tamper, and anti-ILDASM, making reverse engineering extremely challenging.

Figure 4. Detect It Easy (DiE) scan showing a.NET Reactor-protected 32-bit DLL with anti-tamper and anti-disassembly features.

To deobfuscate this complex code, we utilised NETReactorSlayer, an open-source deobfuscator and unpacker specifically designed for files protected with Eziriz.NET Reactor. By employing this tool, we were able to overcome the sophisticated obfuscation techniques and gain insights into the loader's true functionality.

Figure 5. Graphical user interface (GUI) of Net Reactor Slayer used to deobfuscate NETXLOADER

By deobfuscating the sample, it reveals the real MSIL bytecode.

Figure 6. Obfuscated method with hidden code.

Figure 7. Deobfuscated method showing the real MSIL bytecode.

To begin its routine, it retrieves a resource that will be used to decrypt the payload:

Figure 8. Code snippet showing the retrieval of a resource stream for payload decryption.

Then, it turns a list of Windows APIs into delegates, making the analysis difficult:

Figure 9. Code snippet showing the conversion of Windows API functions into delegates

For this sample, the NETXLOADER harvests the following APIs:

Delegate 0	kernel32.SleepEx
Delegate 1	kernel32.OpenProcess
Delegate 2	kernel32.DeleteProcThreadAttributeList
Delegate 3	kernel32.InitializeProcThreadAttributeList
Delegate 4	kernel32.UpdateProcThreadAttributeList
Delegate 5	kernel32.CreateProcessA
Delegate 6	kernel32.GetThreadContext
Delegate 7	kernel32.GetThreadContext
Delegate 8	kernel32.ReadProcessMemory
Delegate 9	ntdll.ZwUnmapViewOfSection
Delegate 10	kernel32.VirtualAllocEx
Delegate 11	kernel32.WriteProcessMemory
Delegate 12	kernel32.SetThreadContext
Delegate 13	kernel32.SetThreadContext
Delegate 14	ntdll.NtResumeThread
Delegate 15	kernel32.CloseHandle
Delegate 16	kernel32.VirtualAlloc
Delegate 17	kernel32.VirtualProtect
Delegate 18	kernel32.VirtualProtectEx
Delegate 19	kernel32.CreateThread
Delegate 20	kernel32.WaitForSingleObject
Delegate 21	ntdll.NtAllocateVirtualMemory
Delegate 22	ntdll.NtCreateThreadEx
Delegate 23	ntdll.NtWriteVirtualMemory
Delegate 24	psapi.GetModuleInformation
Delegate 25	kernel32.GetModuleHandleA
Delegate 26	msvcrt.memcpy
Delegate 27	kernel32.GetCurrentProcess
Delegate 28	kernel32.FreeLibrary
Delegate 29	kernel32.CreateFileA
Delegate 30	kernel32.CreateFileMappingA
Delegate 31	kernel32.MapViewOfFile
Delegate 32	kernel32.DuplicateHandle
Delegate 33	kernel32.CheckRemoteDebuggerPresent

Table 1. List of Windows API functions harvested by the NETXLOADER sample, each assigned to a delegate for obfuscation purposes.

The table includes a variety of functions from kernel32.dll, ntdll.dll, psapi.dll, and msvcrt.dll that facilitate process manipulation, memory allocation, and other system-level operations. It then creates a decryptor for the payload using AES decryption:

Figure 10. Code snippet illustrating the creation of an AES decryptor for the payload

The decryption process involves setting the initialisation vector (IV) and key, then creating an ICryptoTransform object to perform the decryption. The loop structure and conditional cheques ensure the proper setup and execution of the decryption routine. The result is a Gzip binary with a prepended binary size:

Figure 11. Hexadecimal view of the decompressed payload, which is a Gzip binary with a prepended binary size. The highlighted sections indicate the 'magic bytes' that identify the file as Gzip-compressed and the binary size used as a reference after decompression.

It decompresses the binary using the GZipStream decompression class. The GZipStream is initialised with the MemoryStream, set to CompressionMode.Decompress, and managed within a loop to handle the decompressed data correctly.

Figure 12. Code snippet demonstrating the decompression of the binary using the GZipStream class.

The result is the actual payload binary which will be executed by NETXLOADER:

Figure 13. Hex view of the memory containing the actual payload binary, which is delivered and executed by NETXLOADER.

The loader allocates a memory in the address space using Delegate 16 (VirtualAlloc) and copies the payload binary into the allocated memory:

Marshal.Copy copies data to another memory

Then it calls the Delegate 17 (VirtualProtect) to change the protection of the memory region of the payload into PAGE_EXECUTE_READWRITE allowing the payload to execute after modification.

Figure 15. Class3.delegate17_0 as VirtualProtect

Then it calls the Delegate 19 (CreateThread) to spawn a new thread and immediately execute the function pointed on the payload:

Figure 16. Class3.delegate19_0 as CreateThread

Using Delegate 20 (WaitForSingleObject), it waits indefinitely until the thread terminates.

Figure 17. Class3.delegate20_0 as WaitForSingleObject

Lastly, it terminates itself:

Figure 18. Terminates its current process

After execution, it decrypts and deploys its payload—modular malware capable of functioning as ransomware, infostealer, or other malicious tools—directly into memory. This allows it to evade detection through dynamic API calls and memory manipulation. In the case above, it deploys both Agenda ransomware and SmokeLoader malware.

Agenda ransomware, SmokeLoader, and NETXLOADER

The figure below illustrates how Agenda ransomware operators used SmokeLoader and NETXLOADER in the campaigns we observed.

Figure 19. Agenda ransomware attack chain

Defence Evasion

After the first stage of the.NET loader, the second stage of SmokeLoader shows behaviours similar to those of its earlier versions. This includes many anti-analysis techniques with only minor modifications.

T1027 - Obfuscated Files or Information

The second stage of SmokeLoader uses an anti-disassembly technique known as an opaque predicate. At first glance, the sample appears to contain two conditional jumps. However, it will actually perform an absolute jump to a specific location. This technique causes disassemblers to produce incorrect or "garbage" code when disassembling the instruction following the second conditional jump.

Figure 20. Opaque predicate used by SmokeLoader

Some functions in this stage are encrypted. They are decrypted only when needed and re-encrypted once completed.

T1027.007 - Obfuscated Files or Information: Dynamic API Resolution

SmokeLoader steers the Process Environment Block (PEB) to walk through a DLL's export table, hash each API, and compare it to the stored hashes of the APIs needed by the sample. When a match is found, it retrieves the API's address from the library and stores it in an API table.

T1480 – Execution Guardrails

SmokeLoader can only run on computers with Windows Vista or a newer Windows operating system version. It does this by reading the PEB and checking the OSMajorVersion [PEB+0xA4] flag.

It identifies the system's input language using GetKeyboardLayoutList and cheques whether it is Ukrainian (0x422) or Russian (0x419). If it is Russian, the malware terminates.

Figure 21. SmokeLoader checking the input language of the infected system.

When running as 6A90.vmt, SmokeLoader skips its anti-debugging, anti-VM, and anti-sandbox cheques and injects its next stage to explorer.exe.

T1622 - Debugger Evasion

The malware determines the next instruction to execute by checking the value of the BeingDebugged [PEB + 0x2] flag. If this flag is set to true, it will jump to an invalid memory address.

Figure 22. SmokeLoader identifies the OS using the OSMajorVersion flag and calculates the next instruction by checking the BeingDebugged flag.

Furthermore, SmokeLoader uses NtQueryInformationProcess to check the process debug port and determine whether it is being debugged.

T1134.002 - Access Token Manipulation: Create Process with Token (Can also be under Privilege Escalation)

The malware process cheques if it has at least a medium integrity level access token and relaunches itself using Wmic if it does not.

Figure 23. Smokeloader checking its current process integrity level.

T1622 - Virtualisation/Sandbox Evasion: System Cheques

SmokeLoader performs virtualisation and sandbox evasion by:

Detecting sandboxing and security modules
Searching for loaded DLLs related to Sandboxie (sbiedll.dll) and Avast Antivirus (e.g., snxhk.dll, aswhook.dll)
Sarching for virtualisation artefacts
Scanning the registry for entries linked to QEMU, VirtIO, VMware, VirtualBox, and Xen
Identifying virtualisation processes and hardware
Detecting processes associated with virtual environments and identifies virtual hardware components such as USB controllers, mouse devices, graphics adaptors, and memory drivers

T1055 - Process Injection

When none of the cheques mentioned earlier are successful, the next stage will be injected into explorer.exe. Unlike previous versions of SmokeLoader, this version does not use the PROPagate injection method. The injection starts by acquiring a handle to explorer.exe through GetShellWindow, NtOpenProcess, and NtDuplicateHandle. Next, using NtCreateSection, two shared memory sections are created between the current process and explorer.exe. One section is designated for modified properties, while the other is used for the code intended for the subsequent stage.

Figure 24. The created section for the third stage has a shared view of the current and explorer processes.

After this, SmokeLoader maps the created sections into the memory spaces of both the current process and explorer.exe using NtMapViewOfSection. This ensures that any modifications made to the sections are simultaneously visible in the explorer's process. Lastly, it will write the next stage to one of the sections and the modified property for the other before creating a thread in the explorer’s process using CreateThreadEx.

Figure 25. SmokeLoader creating the thread in Windows Explorer

Discovery

The final stage of SMOKELOADER involves injecting itself into the Windows Explorer process. This action is a key step in the malware's execution. Once the injection is successful, SMOKELOADER will create two separate threads using the CreateThread API to perform its tasks.

T1057: Process Discovery

The first thread is dedicated to monitoring the running processes on the system. It calculates each process name's hash and compares it against some hardcoded hashes. If the malware detects that one of these tools is running, it will terminate the corresponding process immediately.

Hash Value	Process Name
FFE73924	Autoruns.exe
A5F0C29D	idaq.exe
A5F0C4B7	idaw.exe
9A412518	idaw64.exe
44F0F7D3	OllyDbg.exe
A06B2518	P idaq64.exe
85D6E4EF	ProcessHacker.exe
5ADED7D3	procexp.exe
8D3AFAC6	procexp64.exe
52FFD0DD	procmon.exe
8E28921B	procmon64.exe
4FD0CDDC	Tcpview.exe
8EEA688B	Wireshark.exe
D99E88CF	x32dbg.exe
E79E85C8	x64dbg.exe

Table 2. List of terminated processes by SMOKELOADER

T1057: Application Window Discovery

The second thread uses the EnumWindows function, which cheques all open windows for specific titles. If it finds anything that matches a predefined list of target analysis tools, it terminates the corresponding processes using the TerminateProcess API. This process involves scanning all open windows on the system and comparing them against the target list.

Hash Value	Window Name
C8FAD451	Autoruns
17E7EA18	OllyDBG
D6C4192C	ProcessHacker
E4C7FE66	ProcExpl
3CD53CFF	PROCMON_WINDOW_CLASS
3CD53CFF	PROCMON_WINDOW_CLASS
CBE1CEF9	TcpViewClass
C3322209	Currently unidentified
CBE0E170	Currently unidentified

Table 3. List of terminated window names by SMOKELOADER

Command and Control

The process begins by obtaining a User Agent for Internet Explorer (IE) by querying the registry key Software\Microsoft\Internet Explorer for the values svcVersion and version. The retrieved User-Agent is then used in subsequent HTTP requests.

Before proceeding with the connection, SmokeLoader decrypts the C&C domains, which are encrypted and stored in this form

T1071.001 Application Layer Protocol: Web Protocol and T1573.001 Encrypted Channel: Symmetric Cryptography

SmokeLoader sends a POST request to its C&C server upon decryption. The payload is encrypted using RC4 before transmission.

If the server is accessible, it responds with an HTTP 404 status code. Despite this apparent error, the response includes the commands. However, during our analysis, the C&C server was offline, which prevented us from capturing any commands.

SmokeLoader also connects to the following URL to download the Agenda ransomware: hxxp[://]mxblog77[.]cfd/777/rh1jcr4[.]exe

Our investigation into the SmokeLoader file revealed its role in delivering the Agenda ransomware. SmokeLoader has been observed distributing NETXLOADER. This loader includes a version that deploys the Agenda ransomware, establishing a clear link between SmokeLoader and the ransomware.

The.NET-compiled loader attempts to load an assembly using a specified name. If this attempt fails, it falls back to loading an alternative assembly using a decrypted value. The loader then iterates through all types in the assembly, invoking a method named c0AqjVLHS on each type.

Figure 28. NETXLOADER decryption routine

It creates a batch script that renames executable files starting with 'rh' to 'rh111.exe' and ensures that it runs correctly with the '--password' parameter.

Figure 29. Created batch script file in the current user's temp folder

Next, the final payload, an Agenda DLL, will be loaded directly into memory using a technique known as DLL-reflective loading. This method enables the DLL to execute without being written to disc.

Figure 30. Agenda binary loaded in memory.

For a comprehensive analysis of the latest Agenda ransomware, refer to the detailed Virus Report here: https://www.trendmicro.com/vinfo/us/threat-encyclopaedia/malware/ransom.msil.agenda.thjcobd.

Conclusion and security recommendations

The Agenda ransomware group is continually evolving by adding new features designed to cause disruption. Its diverse targets include domain networks, mounted devices, storage systems, and VCenter ESXi. By transitioning to Rust, the group can easily target various operating systems,

Using custom packers helps it evade detection and enhances its ability to bypass scanners. Notably, the operators’ use of NETXLOADER is a major leap forward in how malware is delivered. It uses a heavily obfuscated loader that hides the actual payload, meaning you can’t know what it truly is without executing the code and analysing it in memory. Even string-based analysis won't help because the obfuscation scrambles the clues that would normally reveal the payload’s identity. This makes it difficult to determine exactly what malware is being delivered, sometimes preventing proper detection or classifying it into a known malware family.

To proactively defend against attacks utilising Agenda ransomware, SmokeLoader, and NETXLOADER, enterprises should implement a comprehensive security strategy that includes the following best practises:

Access control: Limit administrative rights and access privileges to employees only when necessary. Regularly review and adjust permissions to minimise the risk of unauthorised access.
Regular updates and scanning: Ensure that all security software is updated regularly and conduct periodic scans to identify vulnerabilities. Use endpoint security solutions to detect and block malicious components and suspicious behaviour.
Data backup: Regularly back up critical data and implement a robust recovery plan. This will be a failsafe measure against data loss in a ransomware attack.
Email and web safety: Exercise caution with email and web practises. Avoid downloading attachments, clicking on links, or installing applications unless the source is verified and trusted. Implement web filtering to restrict access to known malicious websites.
User education: Conduct regular training sessions for employees on recognising social engineering tactics and the dangers of phishing. This awareness can significantly reduce the likelihood of falling victim to such attacks.
Multilayered security approach: Adopt a multilayered defence strategy that includes endpoint, email, web, and network security. This approach will help protect against potential entry points into the system and enhance overall threat detection capabilities.
Sandboxing and application control: Use sandboxing tools to analyse files before they are executed, ensuring that any suspicious files are scanned for potential threats. Enforce application control policies to prevent the execution of unauthorised applications and scripts.
Monitoring for abnormal activity: Implement security information and event management (SIEM) tools to monitor for unusual script executions and outbound connections. This proactive monitoring can help identify and mitigate threats before they escalate.

Trend Micro™ Threat Intelligence

To stay ahead of evolving threats, Trend customers can access Trend Vision One™ Threat Insights, which provides the latest insights from Trend™ Research on emerging threats and threat actors.

Trend Vision One Threat Insights

Emerging Threats

Trend Vision One Intelligence Reports (IOC Sweeping)

Agenda Ransomware's Evolution: Unveiling the SmokeLoader Connection and NetXLoader Obfuscation
Unveiling NETXLOADER: A Technical Analysis of a Highly Obfuscated.NET Loader

Hunting Queries

Trend Vision One Search App

Trend Vision One customers can use the Search App to match or hunt the malicious indicators mentioned in this blog post with data in their environment.

Execution of Binary in Memory Netxloader

eventSubId: 901 AND objectAppName: DotNet AND (tags: MITRE.T1055 OR tags: XSAE.F4193)

File Creation of Logs AGENDA

(eventSubId: 101 OR eventSubId: 109) AND objectFilePath: /\\AppData\\Local\\Temp\\QLOG\\ThreadId.*LOG/

More hunting queries are available for Trend Vision One customers with Threat Insights Entitlement enabled.

Indicators of Compromise (IoC)

The indicators of compromise for this entry can be found here.

Agenda Ransomware Group Adds SmokeLoader and NETXLOADER to Their Arsenal

Authors

Trend Vision One™ - Proactive Security Starts Here.

Resources

Support

About Trend

Country Headquarters

Trend Vision One™ - Proactive Security Starts Here.

Resources

Support

About Trend

Country Headquarters

The Americas

Middle East & Africa

Europe

Asia & Pacific