RedLine Stealer Malware Detection Guide
Behavioral Indicators
RedLine Stealer exhibits several distinct runtime behaviors that can be detected through process monitoring and API call analysis. The malware typically executes from a user-writable directory, often masquerading as a legitimate application. A common process creation chain involves a parent process like a web browser or document reader spawning an unusual child process, such as rundll32.exe or regsvr32.exe, which then loads a malicious DLL or executes a script that ultimately runs the stealer payload.
Key API calls to monitor include those related to credential harvesting and data collection. RedLine Stealer extensively uses Windows Credential Manager APIs (CredEnumerateW, CredReadW) to dump stored credentials. It also calls CryptUnprotectData to decrypt browser-stored passwords, cookies, and autofill data from Chromium-based browsers (Chrome, Edge, Brave) and Firefox. The malware enumerates files using FindFirstFileW/FindNextFileW to locate cryptocurrency wallets, FTP client configurations (FileZilla), and messaging application data (Telegram, Discord). It will also query system information via GetComputerNameW, GetUserNameW, and GetSystemMetrics to fingerprint the infected host.
Look for processes making rapid, sequential accesses to multiple browser data directories (%LocalAppData%\\Google\\Chrome\\User Data, %AppData%\\Mozilla\\Firefox\\Profiles) followed by network connections. The malware often creates a mutex with a semi-randomized name (e.g., RL_MUTEX_*) to avoid re-infection. Suspicious memory allocation patterns, such as a process allocating a large memory region and writing executable code to it (a potential reflective DLL injection), are also indicative.
Network Indicators
RedLine Stealer communicates with its command-and-control (C2) server primarily over HTTPS, using TLS to encrypt its traffic. The initial beacon uses a POST request to a hardcoded URI path, often something generic like /gate.php or /panel/index.php. The user-agent string in these requests is frequently spoofed to mimic a legitimate browser (e.g., Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36). However, the order of headers or minor deviations from standard browser strings can be a detection point.
DNS queries often precede the HTTPS connection. These queries are for domains with a high likelihood of being algorithmically generated (DGAs) or newly registered domains (NRDs) with a low reputation score. The domains may have a high entropy in their subdomain or name (e.g., x7f9k2p1.cloudservice[.]top). The beaconing interval is typically configurable but often falls between 30 seconds and 5 minutes of idle time. After the initial handshake, the malware sends exfiltrated data in structured POST requests. The exfiltrated data is often compressed and/or Base64 encoded within the HTTP body.
Data exfiltration signatures include POST requests containing structured key-value pairs with names like hwid, os, token, logs, or credentials. The size of the outgoing POST request body can be significant (hundreds of kilobytes to several megabytes) if it contains bundled stolen data like browser profiles. Monitoring for processes that first perform extensive local data gathering (as described in Behavioral Indicators) and then initiate an HTTPS POST to a suspicious domain is a strong network-based correlation.
File System Artifacts
RedLine Stealer is commonly dropped to user-writable locations to avoid requiring administrative privileges. Common paths include:
%AppData%\\or%LocalAppData%\\under a folder named after a legitimate program (e.g.,GoogleUpdate,MicrosoftEdge).%Temp%\\with a randomly generated folder name.- The Public user directory or the Downloads folder.
The initial dropper or the final payload often uses a name that blends in, such as setup.exe, installer.msi, document.pdf.exe, or chrome_update.exe. The final payload, which may be a standalone executable or a DLL, typically has a size between 200 KB and 500 KB. It is often packed or obfuscated, resulting in a high entropy score when analyzed by file analysis tools.
After execution, RedLine creates working files. Look for temporary .tmp or .dat files in %Temp% that are created, written to rapidly (as data is collected), and then deleted. It may also create a log file in %AppData%\\Local\\Temp\\ or a similar location with a name like log.txt or output.dat containing stolen data before exfiltration. The malware frequently creates a copy of itself in a hidden folder within %AppData% for persistence (see next section). Timestamps can be anomalous; for instance, the creation time of the malware file may be very recent and out of sync with other system files, or the last modified time of browser login data files may be updated due to the stealer’s access.
Registry and Persistence Mechanisms
RedLine Stealer employs multiple methods to achieve persistence on Windows systems. The most common is the creation of a Run key in the Windows Registry:
HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\RunHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce
The value name may be generic (e.g., System, Update), and the data will point to the path of the persisted malware executable.
It also frequently creates scheduled tasks for persistence. Tasks are often created in the user’s task folder via the \Microsoft\Windows\ path with names like GoogleUpdateTaskMachine or OneDriveStandaloneUpdate. The action will trigger the malware, often with a delay or at user logon. The task may be configured to use rundll32.exe to call an exported function from a persisted DLL.
Other observed persistence mechanisms include:
- Creating an LNK shortcut file in the user’s Startup folder (
%AppData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\). - Modifying existing legitimate scheduled tasks or services (less common, as it often runs without admin rights).
- Using fileless techniques by writing a script (VBS, PowerShell) to a registry key like
HKCU\\Environment\\UserInitMprLogonScript.
The malware often creates a specific registry key to store its configuration or a unique bot identifier, such as under HKCU\\Software\\ with a name resembling a legitimate company (e.g., HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Applets).
YARA Rule Guidance
When developing YARA rules for RedLine Stealer, focus on its consistent string patterns, code structure, and embedded configuration data. Target plaintext strings found in unpacked samples. Common hardcoded strings include:
- Paths to browser data:
/User Data/Default/Login Data,/Profiles/,/Web Data. - Function names related to stealing:
GetCookies,GetCreditCards,DumpPasswords. - API function names used in clear text:
CryptUnprotectData,CredEnumerateW. - Mutex name prefixes:
RL_MTX,Global\\RL_MUTEX. - Error or debug messages:
Failed to get,Stealer Log.
Look for the structured configuration block often stored within the binary. This can contain the C2 server address, encryption keys, and a list of target software. This data may be stored as a JSON-like string or as a series of null-terminated strings. Searching for specific byte patterns can help. For example, the malware often uses a specific sequence of instructions to resolve API addresses dynamically. Identifying unique code fragments from the entry point or the string decryption routines can yield high-fidelity signatures.
Analyze the resource section (RT_RCDATA) of PE files, as RedLine samples sometimes store encrypted configuration or additional payloads here. Finally, consider writing rules that match on a combination of low-entropy, high-prevalence strings (like common Windows paths) with high-entropy strings (like potential C2 domains) to reduce false positives.
For the latest samples, IOCs, and a general overview, please refer to the dedicated RedLine Stealer pages: