Ransomware
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.
Save to Folio
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.
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.
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.
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.
By deobfuscating the sample, it reveals the real MSIL bytecode.
To begin its routine, it retrieves a resource that will be used to decrypt the payload:
Then, it turns a list of Windows APIs into delegates, making the analysis difficult:
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:
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:
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.
The result is the actual payload binary which will be 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:
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.
Then it calls the Delegate 19 (CreateThread) to spawn a new thread and immediately execute the function pointed on the payload:
Using Delegate 20 (WaitForSingleObject), it waits indefinitely until the thread terminates.
Lastly, it terminates itself:
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.
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.
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.
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.
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.
T1497.001 - 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.
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.
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 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 |
| 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.
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.
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.
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
- Unveiling NETXLOADER: A Technical Analysis of a Highly Obfuscated.NET Loader ,
- Agenda Ransomware's Evolution: Unveiling the SmokeLoader Connection and NetXLoader Obfuscation
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.