Unmasking the Evolving Threat: A Deep Dive into the Latest Version of Lumma InfoStealer with Code Flow Obfuscation

By Mohideen Abdul Khader · April 21, 2025

Summary

Lumma Stealer, first identified in 2022, remains a significant threat to this day, continuously evolving its tactics, techniques, and procedures (TTPs) to stay aligned with emerging trends. It is distributed on the dark web via a subscription-based model, Malware-As-A-Service(MaaS). Lumma is designed to detect virtual and sandbox environments, allowing it to avoid detection by security systems that depend on the sandbox environment to assess the file behaviour. The malware is capable of exfiltrating sensitive data, including information from web browsers, email applications, cryptocurrency wallets, and other personally identifiable information (PII) stored in critical system directories.

The Trellix Advanced Research Center has been tracking recent campaigns by the threat actors behind Lumma Stealer and analyzing the evolution of their TTPs. In this blog we present our technical analysis on how Lumma performs the below objectives

• Infection chain
• Code flow obfuscation
• API hash resolving
• Heaven’s gate
• Disabling ETWTi callbacks
• Anti-Sandox techniques 
• Command and control, exfiltration

Infection Chain

A threat actor was observed distributing Lumma via obfuscated PowerShell scripts. These scripts contain two executable files in Base64-encoded format,

1. A .NET executable (loader) named GOO.dll
2. The Lumma payload

The PowerShell script loads the .NET executable using the Reflection API, then locates the "R2" Class within the assembly, and invokes its "Run()" method. The arguments supplied to the "Run" method are stored within the $YOO variable. The first argument is the path to RegSvcs.exe ("C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe"), and the second argument is the Lumma payload ($hgh).

The .NET binary, obfuscated with Crypto Obfuscator, injects the Lumma binary into the RegSvcs.exe process. The injected Lumma payload then continues to operate, masquerading as the legitimate RegSvcs.exe utility.

Technical Analysis of Lumma Stealer

During the analysis of the derived sample, the command and control (C2) servers were inactive, resulting in an incomplete behavioral analysis. To provide a thorough analysis for our readers, we have detailed the observed behavior of the latest Lumma sample, which may be delivered to the victim's environment via the technique previously discussed.

Sample hash (SHA256) : 80741061ccb6a337cbdf1b1b75c4fcfae7dd6ccde8ecc333fcae7bcca5dc8861

Performing code analysis on the Lumma’s binary, its main function begins by passing encrypted strings to a decryption routine. The first string to be decrypted is "ntdll.dll". Similarly, the names of other important libraries such as kernel32.dll, user32.dll, winhttp.dll, and crypt32.dll are also decrypted during runtime.

The decrypted string is passed as an argument to a function that leverages Process Environment Block (PEB) data structure in Windows to resolve the library's address in memory. With this technique, Lumma avoids calling very commonly monitored APIs like LoadLibrary and GetProcAddress, which are scrutinized by EDR and other security systems.

Code flow obfuscation

Lumma employs advanced codeflow obfuscation techniques to significantly complicate the analysis. As a result, this malware makes it difficult for decompilers(a commonly used tool in malware analysis) to fully decompile the code.

Due to this, static analysis methods are rendered ineffective in revealing the complete logic of the program.

From the image above, the larger box highlights the routine responsible for calculating the next jump, while the smaller box shows a jump instruction that contains the next instruction address in the “ecx” register. As a result, the code-blocks are scattered without any static links between them, the links (i.e.,addresses to the next valid code-block) are calculated dynamically, resulting in the decompiler failing to analyze the code accurately and the code-flow is broken. Lumma Stealer extends this obfuscation technique to control flow statements such as If-Else and Do-While, further complicating the analysis.

Additionally, the calculation varies with each jump, making it difficult to automate or clean the code effectively. In this case, the jump leads to the immediate next instruction at address ECX = 0067BCD6 (Refer Image). 

API hash resolving

Lumma uses an API hashing technique to dynamically resolve API functions during runtime, a common method employed by malware to locate APIs as needed.

Below listed are a few API’s resolved by Lumma dynamically,

• RtlAllocateHeap
• RtlReAllocateHeap
• RtlFreeHeap
• RtlExpandEnvironmentStrings

Also, APIs required for networking are resolved using the same function.

Lumma sample being 32-bit, it uses Heaven’s gate technique to run 64-bit code when it is executed on a 64-bit machine.

Heaven’s gate 

Lumma identifies whether it’s running on a 32-bit or 64-bit machine by comparing the value of the Code Segment (CS) register.

If the value is 0x23. Then it's a 32-bit machine.

If the value is 0x33. Then it's a 64-bit machine.

When running on a 64-bit system, Lumma transitions to 64-bit code using the ‘jmp far 33’ instruction.

To invoke NTAPI functions, Lumma constructs a table that includes Syscall Hashes and Syscall Indexes. It traverses the export table of the ntdll.dll library to generate custom hashes for API names starting with "Nt" such as NtQueryInformationFile and NtOpenFile.

Lumma hashes syscalls based on their opcode pattern. Specifically,

• Syscalls that begin with the opcode B8 and end with a return opcode of C2 or C3 are considered for hashing

Below image depicts the syscalls matching above discussed pattern.

For example:

• NtYieldExecution syscall starts with B8 and returns using “C3” opcode
• NtAddAtom syscall starts with B8 and returns using “C2” opcode

On the other hand, syscalls like NtCurrentTeb, which do not start with B8, are excluded from the Syscall hash table.

Syscall hash/index table

The above image shows the syscall table, A DWORD (hash) followed by another DWORD containing “Syscall Index”.

For instance, the first DWORD is the hash value for the NtAcceptConnectPort/ZwAcceptConnectPort API (Index = 2) followed by the second DWORD consisting of the syscall index(2). Whenever Lumma has to Invoke a NTAPI, it finds the syscall index by traversing the table and matching on the respective hash.

NTDLL Re-mapping

Lumma leverages the syscall table to remap ntdll.dll based on the system architecture. The correct version of the DLL (32-bit or 64-bit) is determined by checking the value of the Code Segment (CS) register.

On a 32-bit system, knowndlls32/ntdll.dll is mapped.

On a 64-bit system, knowndlls/ntdll.dll is mapped.

Below listed NTAPI system call Indexes are resolved using their respective hash

Based on the remapped NTDLL, syscall table is re-generated, and the previously created hashtable is overwritten, it is unclear why the process is repeated twice. Probably, by loading NTDLL from disk, the malware aims on getting a clean, unhooked version of the DLL, which would prevent the EDR from detecting its activities because the hooks wouldn't be in place.

Below image depicts two NTDLL libraries loaded in memory, highlighted in red is the originally loaded NTDLL module library, highlighted in green is the remapped NTDLL library.

Post syscall generation, newly loaded NTDLL is unmapped using “NtUnMapViewOfSection “ and its handle closed using “NtClose”.

Disabling ETWTi callbacks

Lumma invokes the NtSetInformationProcess API, passing a structure that modifies the ProcessInformation class. By setting the Callback field to 0 in the structure, callbacks set by security softwares like ETW (Event Tracing for Windows) are removed and this prevents those software from monitoring the system calls made by Lumma stealer.

Above image shows NtSetinformationprocess’s parameters, with third argument (ProcessInformation) set to null the callbacks

Anti-sandbox techniques

To avoid detection in sandbox environments, Lumma checks for the presence of specific sandbox or antivirus-related DLLs. The malware verifies that these DLLs are not loaded into memory, using the hardcoded hash values stored in Lumma’s .rdata section.

After validation, Lumma proceeds to the next stage. We wrote a python implementation of the hashing algorithm to obtain the below list of process names verified by Lumma to detect sandbox environments.

For anti-analysis purposes, Lumma includes an optional feature to detect virtual machine (VM) environments. This check is performed based on the response from the Command and Control (C2) server, specifically by verifying if the response contains the property named “vm” set to "true". The command and control section below contains a detailed analysis of this feature.

Region specific execution

Lumma also includes a region-specific execution check. If the User Default Language is set to Russian (identified by the language code 0x419), the malware will exit with a prompt that the country is not supported.

Command and control, exfiltration

Dynamic analysis revealed that Lumma is calling multiple domains before calling the legitimate “steamcommunity.com”.

All strings related to C2 communications including domains, backup domains, header, and HTTP methods are stored in encrypted format.

For instance, an encrypted C2 domain is decrypted as “mercharena[.]biz”.

For each decrypted domain, a connection attempt (POST) is made with below request parameters

The response from the server is expected to be "ok".

Steam as backup Domain

Lumma checks if the primary domain is available, If not, it attempts to reach the backup domains. In the event that all backup domains are unresponsive, Lumma will use the gaming website Steam[.]com to generate a C2 URL.

Lumma initiates a request to a Steam community profile at the following URL:
hxxps://steamcommunity.com/profiles/76561199724331900

From the response, Lumma extracts the Steam username and uses it to derive the C2 URL. Below image shows the usernames, used by the threat actor in the past. The usernames represent the C2 domain name in encrypted fashion.

For example, the HTML title tag in the profile page might be:

• <title>Steam Community :: ytvzwlj-czxlyzg.df</title>

The username is initially encrypted, but the Lumma decrypts it to obtain the final C2 URL, which is:

• hxxps://nikolay-romanov[.]su/

For this sample, the domain “mercharena[.]biz” was active and returned the expected “ok” response. Then, Lumma sends another POST request with body containing action(act) property as “recive_message” (with the misspelling of the word receive), version as “4.0” and  license ID as “f9tVYj--testik1”

“act=recive_message&ver=4.0&lid=f9tVYj--testik1&j=”

C2 returned an encrypted configuration file. After decryption, the contents revealed a malware configuration file in JSON format, which detailed the specific data Lumma intends to exfiltrate, including browser data, wallet information, password manager details, and critical file paths.

The image below displays the decrypted configuration file in JSON format.

Anti-VM

Analysing the JSON file, the "v" property indicates the version of Lumma. The "se" property which is set to “true” appears to be responsible for taking screenshots.
The "vm" property is set to “false” in this sample, but when enabled, Lumma uses the "CPUID" instruction to check if it's running in a virtual machine environment.

The CPUID function passed with an EAX value of 0x40000000, and the return value in ECX is compared against the following VM values:

• 564B4D56 - VMware
• 43544743 - QEMU
• 4D566572 - VMware
• 786F4256 - VirtualBox
• 65584D4D - Xen

Exfiltration

Lumma's configuration includes around 89 application names related to wallets, crypto applications, password managers, authentication apps, payment apps, and more, which are targeted for exfiltration.

Wallets targeted

1. MetaMask
2. 1Password
3. Braavos
4. AgrentX
5. Coinhub
6. LeapWallet
7. Safepal
8. LastPass
9. RoninWallet
10. BladeWallet
11. Evernote
12. MultiversXWallet
13. ForniterWallet
14. FluviWallet
15. GlassWallet
16. MorphisWallet
17. XVerseWallet
18. CompasWallet
19. HavahWallet
20. SuiWallet
21. VenomWallet
22. MetaMask
23. TrustWallet
24. TronLink
25. RoninWallet
26. OKX
27. BinanceChainWallet
28. Yoroi
29. Nifty
30. Math
31. Coinbase
32. Guarda
33. EQUA
34. JaxxLiberty
35. BitApp
36. iWlt
37. EnKrypt
38. Wombat
39. MEWCX
40. Guild
41. Saturn
42. NeoLine
43. Clover
44. Rabby
45. Pontem
46. Martian
47. Bitwarden
48. Nami
49. Petra
50. Sui
51. ExodusWeb3
52. Sub
53. PolkadotJS
54. Talisman
55. CryptoCom
56. Liquality
57. TerraStation
58. Keplr
59. Sollet
60. Auro
61. Polymesh
62. ICONex
63. Nabox
64. KHC
65. Temple
66. TezBox
67. DAppPlay
68. BitClip
69. SteemKeychain
70. NashExtension
71. HyconLiteClient
72. ZilPay
73. Coin98
74. Authenticator
75. Cyano
76. Byone
77. OneKey
78. Leaf
79. Solflare
80. MagicEden
81. Backpack
82. Authy
83. EOSAuthenticator
84. GAuthAuthenticator
85. TrezorPasswordManager
86. Phantom
87. UniSat
88. Rainbow
89. BitgetWallet 

In addition to application names, the Lumma configuration includes paths to browsers, wallets, FTP applications, VPN software, Telegram, cloud-service provider applications, Anydesk, and password managers. Below table highlights the directory path(p), search terms(m), destination path(z), directory recurse depth(d) and exfiltration filesize(fs) - which is typically 20971520(20 MB).

Here is a table based on the provided JSON data:

The image below illustrates the file paths that Lumma searches. If a specified path is found, the file is read and stored in the designated directory path before being exfiltrated to C2.

Lumma is also capable of stealing data from below listed mail applications,

• TheBat
• Pegasus
• Mailbird
• EmClient

Conclusion

In conclusion, Lumma Stealer continues to pose a significant threat to data security. It constantly adapts its TTPs and payloads to bypass security defenses. Trellix remains committed to persevering in the fight against this ever-evolving malware, ensuring the protection of our customers' data.

IOC’s and artifacts

Tactics, Techniques, and Procedures

Trellix ENS detections

Trellix EDR Detections

Discover the latest cybersecurity research from the Trellix Advanced Research Center: https://www.trellix.com/advanced-research-center/