Introduction
Lumma is a sophisticated information stealer, written in C/C++, that has been active in the wild since at least August 15, 2022. The first publicly identified sample appeared on Malware Bazaar on December 20, 2022. By late 2022, the threat actor “Shamel,” operating under the alias “Lumma,” began promoting the malware on Russian-speaking cybercrime forums.
The malware was marketed via a Telegram channel with around 1,700 subscribers as of September 2023 and a now-defunct website. Pricing on platforms such as XSS forum ranged between $250 and $1,000. Notably, LummaC was sold as a lifetime subscription for $1,000.
Key Telegram Channels
• Channel for updates: @LummaC2Stealer
• Support channel: @lummaseller126
• Bug reporting channel: @Lummanowork
• Purchase Subscription: @lummaseller126
• Customer reviews: @LummaC2Services
• User chat: @LummaC2Team
• Bug reports: @Lummanowork
• Escrow service: @lummaescrow_bot
• Logs market: @lummamarketbot
Key Events Timeline
• April 25, 2022: Promotion of a malware called “7.62mm Stealer” posted on underground forums.
• April 2022: Lumma Stealer (under the alias “LummaC”) begins to be promoted in underground forums.
• August 16, 2022: Official promotion of Lumma Stealer posted on the XSS forum.
• October 3, 2022: Author “Shamel” introduces a major update, adding new features like “Statistics by Workers”
for managing infected systems.
• December 21, 2022: Rebranded as “LummaC2 Stealer” with a new marketing push on underground forums.
• January 31, 2023: Distributed via phishing sites posing as VLC player downloads.
• February 6, 2023: Spear-phishing campaign targets South Korean YouTuber, using a Dropbox link to download Lumma Stealer.
• February 6, 2023: YouTuber’s account was compromised and renamed “Tesla US”.
• February 22, 2023: Distributed through phishing sites disguised as legitimate software downloads.
Capabilities and Functionality
Lumma Stealer is designed to exfiltrate a wide range of sensitive data from infected devices. It specifically targets:
• Cryptocurrency Wallets: Lumma Stealer is adept at locating and stealing data from cryptocurrency wallets, allowing attackers to gain access to digital assets.
• Browser Extensions: The malware scans for sensitive data stored in browser extensions, particularly those related to security and cryptocurrency management.
• Two-Factor Authentication (2FA) Codes: It is capable of stealing 2FA codes, which could grant unauthorized access to accounts that employ multi-factor authentication.
• Logins and Passwords Stored in Browsers: Lumma extracts stored credentials from web browsers, including usernames and passwords, allowing attackers to access online services and accounts.
• Sensitive Files: The stealer searches for files on the infected device that contain valuable or sensitive information, exfiltrating them for further exploitation.
These capabilities make Lumma a potent tool for attackers looking to gain unauthorized access to various types of personal and financial data.
Attack Chain Overview
Attackers send a phishing email impersonating a legitimate entity (e.g., Bandai Namco).
• The email contains a Dropbox link, which delivers a ZIP file with a video and a malicious PDF.
• The victim downloads the ZIP file and opens the PDF, unaware of its malicious nature.
• This triggers the execution of a secondary malware, Pure Crypter, from a Command & Control (C&C) server.
• Crypter Loading: Pure Crpyter is a tool written in C# and developed by an individual known as “PureCoder,” which is available for sale on underground forums in the form of software as a service (SaaS). This tool includes features designed to bypass security products, including obfuscation and process injection, and is commonly used to drop additional malware. This tool injects the Lumma Stealer payload into the victim’s system using process hollowing, a technique that hides the malicious code by replacing legitimate system processes
• Once Lumma Stealer is now active
Spreading Methods
Lumma Stealer employs a variety of tactics to distribute its malware, capitalizing on common cybercriminal techniques to maximize its reach.
1. Phishing Emails
One of the most effective methods for Lumma Stealer’s distribution is through phishing campaigns. These attacks involve sending fraudulent emails to potential victims and impersonating legitimate companies or organizations. The email typically contains links to malicious files hosted on platforms like Dropbox, or attachments disguised as legitimate documents.
• Spear-Phishing: High-profile targets such as YouTubers or social media influencers are often victims. Attackers impersonate trusted companies (e.g., Bandai Namco) and deliver malicious files via email, designed to look like important business documents.
• Fake File Attachments: The phishing email might contain ZIP files that include video files and malicious PDFs, which appear harmless but trigger malware installation upon being opened
2. Fake Software Downloads
Lumma Stealer is commonly distributed through websites masquerading as legitimate software download portals. The malware is bundled with popular software applications, enticing users to download what they think is a trusted program.
• Phishing Sites: Attackers create fake websites that look like official software pages (e.g., for VLC Media Player) and trick users into downloading Lumma Stealer disguised as a legitimate installer.
• Adware Bundles: Lumma Stealer has been observed as part of bundled software packages that are hosted on fake software distribution sites, exploiting users who are searching for free versions of commonly used applications.
3. Social Media and Streaming Platforms
Attackers exploit popular social media and streaming platforms to spread Lumma Stealer. They target individuals or organizations by sending direct messages or embedding malicious links in comments or profiles.
• Account Hijacking : Lumma Stealer can compromise popular online accounts (e.g., YouTube) and alter channel names (e.g., “Tesla US”) to impersonate well-known brands or individuals, further spreading the malware, like what mentioned in this article: https://gridinsoft.com/blogs/youtube-videos-cracks-lumma-stealer/
3. Malicious Advertisements
Cybercriminals use malvertising, or malicious advertisements, to infect victims with Lumma Stealer.
These ads, placed on legitimate websites, redirect users to malicious sites or initiate automatic downloads.
• Drive-by Downloads: Some websites automatically download Lumma Stealer when a user clicks on an infected advertisement without the user’s knowledge or consent.
• Pop-up Ads: Attackers use pop-up ads that pretend to offer free software or updates. Clicking on these ads redirects victims to a site that downloads Lumma Stealer in the background.
5. Exploit Kits
Lumma Stealer can also be delivered through exploit kits, which are tools used by attackers to automatically exploit vulnerabilities in victims’ systems.
• Web Browser Exploits: Exploit kits take advantage of browser or plugin vulnerabilities to download Lumma Stealer without requiring the user to click any links.
• Watering Hole Attacks: Attackers inject exploit kits into compromised websites frequented by their target audience. Once the target visits the site, Lumma Stealer is silently delivered through an exploit.
6. File-Sharing Platforms
Lumma Stealer is often distributed via popular file-sharing platforms like Dropbox or other cloud services.
• Dropbox Links: Attackers send Dropbox links in phishing emails, leading the victim to download ZIP files containing Lumma Stealer. These files are designed to appear legitimate (e.g., PDFs, software installers).
7. Underground Forums and Telegram Channels
Lumma Stealer is heavily promoted and sold on underground cybercriminal forums like XSS, as well as through dedicated Telegram channels run by the malware’s author.
• Malware as a Service (MaaS): Lumma Stealer is offered as a service to cybercriminals, who pay for access to the malware and use it in their campaigns. These services are often advertised on underground forums.
• Telegram Updates: Buyers of Lumma Stealer receive updates and technical support via private Telegram channels, ensuring that the malware remains effective despite improvements in security defenses.
Lumma’s IDAT Loader
The IDAT loader technique is employed by threat actors to embed malicious payloads within the IDAT section of PNG image files, leveraging the fact that PNG files are typically considered safe by security systems. This technique is particularly effective for evading detection. Both Vidar and Lumma Stealer operators use this method to enhance the stealth of their malware distribution.
Here’s an overview of how the IDAT loader works:
Mechanism
1. C2 Communication: Attackers use a Command and Control (C2) server to deliver PNG files that contain malicious payloads hidden within the IDAT section. Normally, the IDAT chunk in a PNG file holds image data, but in this case, it is repurposed to deliver a hidden malicious payload.
2. Malicious IDAT Section: Upon downloading, the malware reads the IDAT section of the PNG file. Although the PNG file appears legitimate, the data within the IDAT chunk is crafted to execute malicious activities once processed.
Dynamic Imports and Execution
Dynamic Imports: The IDAT loader employs dynamic imports to obscure its operations. The loader uses the %APPDATA% environment variable, expanding it using the ExpandEnvironmentStringsW API call.
Folder Creation: It creates a new folder under %APPDATA%, naming it based on the output of the QueryPerformanceCounter API call and randomizing the name to evade detection.
File Handling: Dropped files by MSI are copied to the newly created folder. The IDAT loader then creates a new instance of VMWareHostOpen.exe using CreateProcessW and exits.
Execution of Malicious Code: A second instance VMWareHostOpen.exe operates similarly until it reaches the stage where the IDAT injector code is called from the mshtml.dll memory space. At this point, the IDAT loader implements the Heaven’s Gateevasion technique.
Heaven’s Gate Technique
Heaven’s Gate is used by threat actors to evade security tools by executing a 64-bit process within a 32-bit process or vice versa. This technique is particularly useful for bypassing security measures that are not equipped to handle such transitions.
The technique involves changing the process mode from 32-bit to 64-bit or the other way around. This is achieved by initiating a call or jump instruction using a reserved selector. For instance, the selector “0x0033” is used, followed by a far call or far jump to execute the transition happens as shown
The IDAT injector then expands the %TEMP% environment variable by using the ExpandEnvironmentStringsW API call. It creates a string based on the QueryPerformanceCounter API call output and randomizes its value.
Next, the IDAT loader gets the computer name by calling the GetComputerNameW API call, and the output is randomized by using rand and srand API calls. It uses that randomized value to set a new environment variable by using SetEnvironmentVariableW. This variable is set to a combination of %TEMP% path with the randomized string created previously.
The IDAT loader runs a new cmd.exe process as follows:
- Running cmd.exe:
- The loader starts a new cmd.exe process.
- It creates and writes data to a file at %TEMP%\89680228.
- Injecting Code into cmd.exe:
- Create and Map Memory Sections: The loader creates a new memory section in cmd.exe and maps it to both the local malicious process and the remote cmd.exe process, then writes malicious code into the local memory section.
- Control Threads: It suspends and then resumes the main thread of the cmd.exe process to execute the injected code.
- Cleanup: The loader deletes the initial malicious file (vmtools.dll) once the injection is complete.
- Decrypting and Using Configuration Data:
The loader uses the Heaven’s Gate technique to hide its activities, then It retrieves and decrypts data from the %TEMP%\89680228 file to get configuration details. - Injecting into explorer.exe Using Process Doppelgänging: The loader uses Windows’ Transactional NTFS feature to replace a legitimate file with a malicious one through the following steps:
- Final Payload: The final malicious payload injected into explorer.exe is identified as Lumma Stealer.
Lumma Stealer API Hashing
API hashing is a technique commonly employed by malware developers to obscure the usage of Windows API functions, adding complexity to the malware analysis process. By using this method, malware can hide suspicious API calls, making them less apparent within the Import Address Table (IAT) of the Portable Executable (PE) file.
The approach for API hashing can generally be broken down into three main steps:
- Hash Generation: The malware precomputes hashes that correspond to specific Windows API (WINAPI) functions.
- Module Enumeration: When an API call needs to be made, the malware queries loaded modules through the Process Environment Block (PEB) and Loader Data Table (PEB.Ldr) structures to find the necessary module.
- Hash Matching: The malware iterates through the module’s exported functions, applying a hashing algorithm to their names until the hash matches the precomputed one.
Parsing PEB and LDR with Lumma Stealer
By analyzing Lumma Stealer with IDA Pro, one can observe how it leverages API hashing. Specifically, after the main function, there is a routine dedicated to parsing the PEB and LDR structures to resolve the necessary APIs via hash matching.
mov edx, aKernel32Dll_0 ; The DLL module to search (kernel32.dll)
mov ecx, 0x7328f505 ; The hash of the desired API function
In this example:
- edx is set to point to kernel32.dll, a system library that contains critical functions such as LoadLibrary, VirtualAlloc, and other APIs frequently used in malware.
- ecx holds a hash value, which likely corresponds to a specific API function exported by kernel32.dll. The hash function is used to compare against the hashed names of the functions within the DLL until a match is found.
This code is part of a wrapper function that is responsible for resolving the API call through hashing, enabling the malware to dynamically retrieve function addresses at runtime while evading traditional detection mechanisms.
Hash Resolving Routine
The function sub_4082D3 is a key part of this mechanism. It takes the module name (e.g., kernel32.dll) and the hash of the desired API function as inputs, then iterates over the export table of the module, comparing the hash of each function’s name to the precomputed hash (0x7328f505 in this case). Once a match is found, it returns the address of the corresponding API, allowing Lumma Stealer to invoke it.
Let’s get deeper in the function:
The code begins by retrieving the Process Environment Block (PEB) pointer and continues with subsequent operations to gather the required structures for resolving Windows API calls.
Code Breakdown
- Retrieve the PEB Pointer
mov eax, fs:[30h] ; Retrieve the PEB base address and store it in eax
The fs:[30h] instruction accesses the Thread Information Block (TIB) to retrieve the PEB pointer, which is stored in the eax register. This pointer is crucial as it gives access to various internal structures of the process, including information about loaded modules like kernel32.dll.
Access the PEB Loader Data (PEB_LDR_DATA)
mov eax, [eax+0Ch] ; Retrieve the PEB_LDR_DATA structure
The eax+0Ch offset points to the PEB_LDR_DATA structure inside the PEB. This structure is responsible for managing the process’s loaded modules, and this instruction stores the pointer to the loader data in eax.
Retrieve the InLoadOrderModuleList
mov edi, [eax+10h] ; Load the InLoadOrderModuleList
The eax+10h offset points to the InLoadOrderModuleList, which contains a doubly linked list of loaded modules (DLLs) in the order they were loaded. The malware uses this list to iterate over the loaded modules and find the necessary module (in this case, kernel32.dll).
PEB_LDR_DATA and InLoadOrderModuleList
To understand what happens next, it’s important to examine the structure of PEB_LDR_DATA:
PEB_LDR_DATA (x64 Architecture):
Offset 0x10h: Points to the InLoadOrderModuleList, which is a linked list containing LDR_MODULE structures that store information about each loaded module (such as kernel32.dll).
The instruction mov edi, [eax+10h] is used to access the head of this linked list. The malware will iterate through this list to locate kernel32.dll, which contains important functions like LoadLibraryA and VirtualAlloc.
Parsing LDR_MODULE Structures
Following the collection of InLoadOrderModuleList, the malware proceeds to iterate over the LDR_MODULE structures, which contain details about each loaded module. Specifically, it looks for kernel32.dll by examining the module’s name within each LDR_MODULE structure.
Once kernel32.dll is identified, the malware can begin its API hashing routine.
Final Block: Resolving the API Function
At the end of the code, a hash value is used to resolve the required API function (likely functions like LoadLibraryA or VirtualAlloc) within kernel32.dll:
- Iterate Over the Export Table: The malware iterates over the export table of kernel32.dll, applying a hash function to the name of each function.
- Hash Matching: The malware compares the computed hash with the pre-stored hash (mov ecx, 0x7328f505). When a match is found, it stores the address of the corresponding API.
- Function Call: The resolved API function is then called, allowing the malware to perform actions like loading additional modules or allocating memory.
The process can be summarized in two key steps:
- The function 4082D3 sets up the necessary variables (the DLL base address and hash) and calls the hash-resolving function 40832A.
- The hash-resolving function (40832A) loops through the exports of the loaded module, hashes the function names and returns the pointer to the function that matches the provided hash.
To explore the routine that collects function names from a DLL and performs hashing to find a match with the input name, let’s break down the process step by step:
1- The code begins with the instruction mov edi, ecx, where ecx holds the base address of the module being analyzed. This is key because edi now points to the module’s base, setting up access to its structures.
From here, the code accesses the PE header and the Export Directory, which contains pointers to the module’s exported function names (AddressOfNames) and ordinals (AddressOfNameOrdinals). Using these, the code iterates through the export names, applying hashing to compare the function names against a target, enabling dynamic API resolution
2- Once the code successfully finds a match for the exported function name, the next step is retrieving the actual function pointer. The match triggers the use of the AddressOfNameOrdinals structure to get the ordinal number associated with the function.
This ordinal number serves as an index into the AddressOfFunctions array, which holds the real function pointers. By referencing this index, the code retrieves the pointer to the matched function, completing the process of dynamic API resolution
Analyzing the hashing routine
Lumma Stealer uses the Murmur2 hash function which processes 4 bytes at a time to compute a hash. Here’s a simplified breakdown:
Byte Processing: The loop loads 4 bytes from memory (edi), combines them into a 32-bit value (ecx), and multiplies by the constant 5BD1E995h.
Hashing: The hash value is XORed and shifted to mix the bits.The result is accumulated in esi.
Loop:The loop continues until all bytes are processed.
Information Gathering
LummaC2 collects various system details from the victim’s machine and saves this information in a file named System.txt. This file is then compressed and exfiltrated.
The details gathered include:
- Username
- Hardware ID
- Screen Resolution
- Additional System Metrics
Windows API Calls Used
The following Windows API functions are utilized to gather the system information:
- GetComputerNameA: Retrieves the computer’s name.
- GetUserNameA: Obtains the username of the currently logged-in user.
- GetCurrentHwProfileA: Provides hardware profile details.
- GetSystemMetrics: Fetches system metrics such as screen resolution.
- GetSystemDefaultLocaleName: Retrieves the system’s default locale name.
- cpuid: Provides CPU information.
- GetPhysicallyInstalledSystemMemory: Gets the amount of installed physical memory.
This collected data provides an overview of the victim’s system configuration and is essential for the attacker to tailor subsequent actions or further exploits.
File Theft by LummaC2
LummaC2 targets important files on the victim’s machine, specifically looking for .txt files. Here’s how it operates:
- Target Files: All .txt files located under %userprofile%.
- File Collection Path: Files are saved under Important Files/Profile.
- Traversal Method: LummaC2 performs a recursive search within %userprofile% with a maximum recursion depth of 2 directories.
Targeted Software by LummaC2
After collecting system information and important files, LummaC2 focuses on stealing cryptocurrency wallet data. The targeted software includes:
- Binance
- Electrum
- Ethereum
After the initial exfiltration to the Command and Control (C2) server, LummaC2 shifts its focus to gathering data from web browsers.
The malware targets the following browsers
- Chrome
- Chromium
- Edge
- Kometa
- Vivaldi
- Brave-Browser
- Opera Stable
- Opera Neon
- Mozilla Firefox
To extract the following data :
- Login Data
- History
- Cookies
- Other relevant information
Communications & Data Stealing
After such a long detection and analysis evasion cycle, Lumma eventually switches to its main function — information stealing. But beforehand, it reports about the new instance to the command server.
This is done using an HTTP POST message; each sample carries the list of encrypted C2 addresses (1 main + 10 backup) that malware starts resolving after being launched.
The first one to be responsive is then used for all further communications, including data exfiltration.
Once the initial connection has been established, the malware starts scanning the user data in the system, seeking the files related to crypto wallets, user browser profiles, and browser extensions of crypto wallets.
As Lumma developers say in the promo post, it is possible to add the needed crypto wallet extension to the seek list in a couple of clicks. Under one of the tariffs, hackers offer to steal persistent cookies — a vulnerable type of ones that provide access to the compromised account even after the password change.
When data collection is over, the malware encrypts the resulting package and sends it to the C2.
Conclusion
Lumma Stealer (LummaC2) is a sophisticated infostealer that employs a range of techniques to compromise and extract sensitive information from infected systems. Its capabilities include:
- Initial Access: Through phishing and malicious downloads, LummaC2 gains access to victim systems.
- Information Gathering: It collects and exfiltrates system details such as usernames, hardware IDs, screen resolutions, and more, saving this data in a file named “System.txt.”
- File Theft: The malware identifies and steals important files, particularly text files within the user’s profile directory, using a recursive directory traversal method.
- Crypto Wallets: It targets cryptocurrency wallets for Binance, Electrum, and Ethereum, ensuring financial data is stolen.
- Browser Data: Post initial exfiltration, LummaC2 gathers extensive browser-related information, including login credentials, history, cookies, and other sensitive data from major browsers like Google Chrome, Mozilla Firefox, and Microsoft Edge.
By leveraging these capabilities, LummaC2 poses a significant threat to individual and organizational security. Its use of various evasion techniques, including API hashing and sophisticated data exfiltration methods, underscores the importance of robust security measures and vigilant user behavior to mitigate the risks associated with such malware.
MITRE ATT&CK
Initial Access
- Drive-by Compromise (T1189): Lumma Stealer spreads through fake software download sites and malicious advertisements, leading users to unknowingly download the malware.
- Spearphishing Link (T1566.002): The malware is distributed via phishing emails, often containing malicious links to Dropbox or other cloud file-sharing platforms.
Execution
- User Execution (T1204): Victims manually execute Lumma Stealer by opening disguised ZIP files or clicking on malicious links. The files often appear as legitimate documents or software installers.
- Shared Modules (T1129): Lumma Stealer leverages shared modules that link functions dynamically at runtime on Windows systems, enabling it to load its malicious payload.
Defense Evasion
- Deobfuscate/Decode Files or Information (T1140): Lumma Stealer utilizes techniques like deobfuscation to decode and execute its payload, bypassing security mechanisms.
- Obfuscated Files or Information (T1027): The malware encodes its data using XOR and encrypts it using RC4 PRGA to avoid detection by security solutions.
Credential Access
- Credentials from Password Stores: Credentials from Web Browsers (T1555.003): Lumma Stealer specifically targets web browsers to extract stored passwords and other sensitive data.
- Unsecured Credentials: Credentials in Files (T1552.001): The malware searches for unsecured credentials stored in files on the compromised system, harvesting login information and sensitive data.
Discovery
- System Information Discovery (T1082): Once Lumma Stealer is executed, it collects information about the infected system, including operating system details and hardware information.
Command and Control
- Application Layer Protocol (T1071): Lumma Stealer communicates with its Command and Control (C2) servers using legitimate application layer protocols, such as HTTP, to blend in with normal network traffic.
Exfiltration
- Exfiltration Over C2 Channel (T1041): Stolen data, including credentials and sensitive information, is exfiltrated to the attacker’s C2 server over HTTP traffic, disguised to look like legitimate browser activity.
Yara Rules
rule LummaC2 {
meta:
description = "This rule detects LummaC2 Stealer samples."
author = "Dexpose Team"
date = "2024-09-10"
sharing = "TLP:CLEAR"
sample = "277d7f450268aeb4e7fe942f70a9df63aa429d703e9400370f0621a438e918bf"
strings:
$hashing_routine = { 0F B6 4F 03 0F B6 47 02 C1 E1 ?? 0B C8 69 F6 95 E9 D1 5B 0F B6 47 01 C1 E1 ?? 0B C8 0F B6 07 C1 E1 ?? 83 C7 04 0B C8 69 C9 95 E9 D1 5B 8B C1 C1 E8 18 33 C1 69 C8 95 E9 D1 5B 33 F1 83 EB 01 75 BF 5B }
// 0F B6 4F 03 | movzx ecx, byte ptr [edi+3]
// 0F B6 47 02 | movzx eax, byte ptr [edi+2]
// C1 E1 08 | shl ecx, 8
// 0B C8 | or ecx, eax
// 69 F6 95 E9 D1 5B | imul esi, 5BD1E995h
// 0F B6 47 01 | movzx eax, byte ptr [edi+1]
// C1 E1 08 | shl ecx, 8
// 0B C8 | or ecx, eax
// 0F B6 07 | movzx eax, byte ptr [edi]
// C1 E1 08 | shl ecx, 8
// 83 C7 04 | add edi, 4
// 0B C8 | or ecx, eax
// 69 C9 95 E9 D1 5B | imul ecx, 5BD1E995h
// 8B C1 | mov eax, ecx
// C1 E8 18 | shr eax, 18h
// 33 C1 | xor eax, ecx
// 69 C8 95 E9 D1 5B | imul ecx, eax, 5BD1E995h
// 33 F1 | xor esi, ecx
// 83 EB 01 | sub ebx, 1
// 75 BF | jnz short loc_4083B6
// 5B | pop ebx
condition:
uint16(0) == 0x5A4D
and $hashing_routine
}
