Skip to main content
Return to Blog de Seguridad de TrendAI™
Cyber crimeIoT & endpointsRansomware

Agenda Ransomware Group Adds SmokeLoader and NETXLOADER to Their Arsenal

During our monitoring of Agenda ransomware activities, we uncovered campaigns that made use of the SmokeLoader malware and a new loader we've named NETXLOADER.

Ransomware & extortionEndpointsMalwareRansomware as a Service (RaaS)Healthcare & Life SciencesFinancial ServicesTelecommunicationsInformation technology

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 behavior.
  • 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 utilized 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 analyze. 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, among dozens of others, follow a distinct pattern: they combine words with randomized 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.

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.
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 standardized 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:

Initial code structure of NETXLOADER.
Initial code structure of NETXLOADER.
Figure 2. Initial code structure of NETXLOADER.

This highly obfuscated loader employs gibberish method names and hidden MSIL codes, making static analysis nearly impossible. Its complexity is further enhanced by the utilization 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.

Obfuscated loader using gibberish method names and JIT Hooking to evade detection.
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.

Detect It Easy (DiE) scan showing a .NET Reactor-protected 32-bit DLL with anti-tamper and anti-disassembly features.
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 utilized 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.

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

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

Obfuscated method with hidden code.
Figure 6. Obfuscated method with hidden code.
Deobfuscated method showing the real MSIL bytecode.
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:

Code snippet showing the retrieval of a resource stream for payload decryption.
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:

Code snippet showing the conversion of Windows API functions into delegates
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:

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

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

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.
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 initialized with the MemoryStream, set to CompressionMode.Decompress, and managed within a loop to handle the decompressed data correctly.

Code snippet demonstrating the decompression of the binary using the GZipStream class.
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:

Hex view of the memory containing the actual payload binary, which is delivered and 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
Marshal.Copy copies data to another memory
Figure 14. 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.

Class3.delegate17_0 as VirtualProtect
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:

Class3.delegate19_0 as CreateThread
Figure 16. Class3.delegate19_0 as CreateThread

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

Class3.delegate20_0 as WaitForSingleObject
Figure 17. Class3.delegate20_0 as WaitForSingleObject

Lastly, it terminates itself:

Terminates its current process
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.

Agenda ransomware attack chain
Figure 19. Agenda ransomware attack chain

Defense Evasion

After the first stage of the .NET loader, the second stage of SmokeLoader shows behaviors 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.

Opaque predicate used by SmokeLoader
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 checks whether it is Ukrainian (0x422) or Russian (0x419). If it is Russian, the malware terminates.

SmokeLoader checking the input language of the infected system.
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 checks 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.

SmokeLoader identifies the OS using the OSMajorVersion flag and calculates the next instruction by checking the BeingDebugged flag.
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 checks if it has at least a medium integrity level access token and relaunches itself using Wmic if it does not.

Smokeloader checking its current process integrity level.
Figure 23. Smokeloader checking its current process integrity level.

T1497.001 - Virtualization/Sandbox Evasion: System Checks

SmokeLoader performs virtualization 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 virtualization artifacts
  • Scanning the registry for entries linked to QEMU, VirtIO, VMware, VirtualBox, and Xen
  • Identifying virtualization processes and hardware
  • Detecting processes associated with virtual environments and identifies virtual hardware components such as USB controllers, mouse devices, graphics adapters, and memory drivers

T1055 - Process Injection

When none of the checks 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.

The created section for the third stage has a shared view of the current and explorer processes.
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.

SmokeLoader creating the thread in Windows Explorer
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

T1010: Application Window Discovery

The second thread uses the EnumWindows function, which checks 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
 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

Encrypted C2 URL structure
Figure 26. Encrypted C2 URL structure

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.

SmokeLoader HTTP Request
Figure 27. SmokeLoader HTTP Request

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.

NETXLOADER decryption routine
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.

Created batch script file in the current user's temp folder
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 disk.

Agenda binary loaded in memory.
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-encyclopedia/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 analyzing 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 utilizing Agenda ransomware, SmokeLoader, and NETXLOADER, enterprises should implement a comprehensive security strategy that includes the following best practices:

  • Access control: Limit administrative rights and access privileges to employees only when necessary. Regularly review and adjust permissions to minimize the risk of unauthorized 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 behavior.
  • 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 practices. 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 recognizing 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 defense 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 analyze files before they are executed, ensuring that any suspicious files are scanned for potential threats. Enforce application control policies to prevent the execution of unauthorized 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.