Redline Stealer Detection: SOC Analyst Checklist

To detect Redline Stealer, look for a process that is not a browser reading Chrome's Login Data or Firefox's key4.db, a .NET assembly loaded reflectively through PowerShell, screen capture calls from a freshly downloaded binary, and SOAP requests over HTTP or HTTPS to a newly registered domain. Two of those in one process tree within a minute warrant action.

Redline Stealer is an information-stealing malware first identified in early 2020 and sold as a service on underground forums, as a one-time purchase or a monthly subscription, so any threat actor with a target list and a phishing kit could deploy it. In October 2024 Operation Magnus, an international action the FBI and the US Justice Department joined, seized domains and servers used by its administrators, and US prosecutors charged one of its alleged developers. In February 2025 Singapore's CSA was still warning about RedLine, including new variants built on Lua bytecode. What makes Redline worth understanding is not its sophistication. It is not a zero-day framework. It is a commodity tool that accounts for a disproportionate share of credential theft because it automates four collection behaviors at once, and each one produces a trace in a different log source. Knowing which logs to check, and what the traces look like, turns a generic "malware detected" alert into a contained incident before the stolen data is sold.

What Redline Steals

Browser credentials and session tokens. Redline reads the SQLite databases where Chromium and Firefox store saved usernames, passwords, and cookies. ATT&CK tracks credential theft from browser stores as Credentials from Password Stores, and Redline automates the extraction end to end. The session tokens it steals are the real prize. A stolen cookie or OAuth token bypasses MFA entirely because the session is already authenticated, and ATT&CK splits the two: the browser cookie is Steal Web Session Cookie, the provider-issued token is Steal Application Access Token. Either one is why an infostealer infection that looks like a credential problem often escalates into a full account takeover with zero additional malware.

Screenshots. Redline takes a screenshot of the desktop while it collects data. Even when the user types credentials into a virtual keyboard or a password field that blocks copy-paste, the screenshot captures what the browser renders. In ATT&CK, Screen Capture is the technique, and it is the hardest collection behavior to detect through log analysis alone because the screenshot data itself does not traverse a monitored channel. What you look for instead is the BitBlt call behind .NET's Graphics.CopyFromScreen, which an EDR that records API telemetry can show coming from an executable with no legitimate reason to read the screen. Sysmon only gives you the process tree around it.

System fingerprinting. Redline gathers the hostname, OS version, installed programs, running processes, antivirus products, hardware specs, and geolocation data from the infected machine. This is not directly destructive. It is the reconnaissance that tells the operator whether the stolen credentials belong to a personal gaming PC or a corporate workstation with VPN access and a domain account, which determines the resale price of the log.

Cryptocurrency wallet extraction. Redline pulls wallet files, private keys, and seed phrases from common wallet applications and browser extensions. Draining those wallets is the payout stage ATT&CK files under financial theft, and the file read is usually the only part of it your logs ever see. For an analyst, this is lateral context more than a direct detection surface. The file reads that extract wallet data look identical to the legitimate wallet application accessing its own storage, which is why detection relies on the sequence: a process that has never touched wallet directories before, doing so moments after a suspicious binary execution.

Not the clipboard. MITRE's RedLine entry lists no Clipboard Data technique, and none of the analyses cited here describe RedLine reading what the user copies. ESET's analysis of the RedLine backend found a handler that once generated a separate clipper, which swapped cryptocurrency wallet addresses in the clipboard, and notes that the latest backend versions removed it.

How Redline Delivers Its Payload

Redline campaigns favor delivery methods that bypass email filters and URL reputation checks. Cracked software and game cheat downloads are the most common vector. The user downloads what they think is a free copy of a paid application or a game mod, runs the installer, and the installer drops Redline alongside whatever fake software it promised.

Phishing email attachments still appear, usually as ISO or ZIP files containing a shortcut that executes a PowerShell command. Drive-by downloads from malicious advertisements on file-sharing and streaming sites also deliver Redline, targeting users who have already bypassed the first layer of corporate browsing policy.

The common thread is that the user initiates the execution. The malware does not exploit a vulnerability. It persuades the user to run it, which means the process tree starts with a user-launched binary, not a service exploit, and the behavioral signal is in what that binary does next, not in how it arrived.

Detecting Redline in Your Logs

Redline is a .NET assembly, and the detection surface is larger than most commodity malware because it touches four distinct data sources to do its job.

PowerShell and .NET execution. When Redline runs, it spawns itself through a .NET runtime host or through a dropper that uses PowerShell to load and execute the assembly. Enable Script Block Logging (Event 4104) and Module Logging (Event 4103). A decoded script block containing [System.Reflection.Assembly]::Load followed shortly by file reads against browser SQLite databases is a strong signal. On a host where that policy was never turned on, PowerShell still writes a 4104 at Warning level for script blocks matching its built-in list of suspicious constructs, so a 4104 search filtered to LevelDisplayName Warning is worth running before you conclude the machine has no PowerShell telemetry. The raw base64 strings in the module load events are also where you decode the actual payload path.

Browser database access. Chrome stores credentials in %LocalAppData%\Google\Chrome\User Data\Default\Login Data, an SQLite database. Firefox stores them in logins.json and key4.db inside the profile directory. A process that is not a browser, reading those files, is the most specific indicator of an infostealer at work. Sysmon Event 11 (FileCreate) plus Event 4663 (an attempt was made to access an object) with the access mask ReadData against those paths is a high-fidelity signal. Even without Sysmon, Windows Defender ATP and most EDR platforms surface file read events with the process path and target.

Screen capture API calls. BitBlt, StretchBlt, or the newer Windows.Graphics.Capture API from a process that is not a screenshot utility, a remote support tool, or a video conferencing application. Sysmon Event 1 (ProcessCreate) gives you the parent process tree, which is where the verdict lives. A game cheat launcher spawning a child that calls screen capture APIs within seconds of execution is the behavioral signature of Redline collecting the victim's screen.

Network telemetry. Redline talks to its C2 server in SOAP messages through WCF's BasicHttpBinding, an unusual choice next to the JSON that most modern C2 frameworks send. In the sample SecurityScorecard took apart, that binding carried the SOAP over plain HTTP to a hardcoded host on port 17044, and MITRE also records samples reaching hardcoded C2 servers over HTTPS. BasicHttpBinding sends SOAP 1.1, so a request in clear HTTP carries Content-Type: text/xml and a SOAPAction header, readable in any proxy or IDS log that keeps HTTP headers. Over HTTPS you need a proxy that decrypts TLS to see them. Without decryption you still get a predictable request body size that deviates from normal web browsing patterns, and a SIEM that ingests proxy or firewall logs can flag repeated sessions to a newly registered domain as anomalous. Once the session is tunneled over an encrypted channel, the detection has to work at the metadata layer. Look at JA3/JA4 TLS fingerprints. A client's fingerprint comes from the TLS libraries it was built with, not from the C2 domain, so it survives a domain swap, though FoxIO notes that it changes when those libraries update.

Redline Detection Checklist

Run these against the suspect host, in this order:

1. Credential store reads. Event 4663 with access mask 0x1 (ReadData) on Login Data, logins.json or key4.db, where the process is not the browser.
2. Reflective .NET load. With the policy on, search Event 4104 for [System.Reflection.Assembly]::Load. Without it, filter 4104 to Warning level: PowerShell logs suspicious script blocks on its own, and the loader's FromBase64String decode is on that list. Assembly::Load is not.
3. Screen capture. BitBlt or Windows.Graphics.Capture calls from a child of a freshly downloaded installer or cheat launcher. Sysmon Event 1 gives you the tree.
4. C2 traffic. SOAP requests (Content-Type: text/xml plus a SOAPAction header) to a domain registered in the last 30 days, in clear HTTP or through a TLS-inspecting proxy. Without decryption, match the JA3/JA4 fingerprint, the domain age, and steady request sizes at a regular interval.

With two hits in the same process tree, isolate the host and revoke the user's sessions across IdP, SaaS and VPN before you finish scoping.

Triage Workflow When Redline Is Suspected

The alert text will vary. Sometimes the EDR names Redline directly. More often you will see a generic detection like "suspicious .NET assembly behavior," "credential store access from non-browser process," or "screen capture from an unsigned process." Here is a six-step workflow that works regardless of what the alert is called.

Step 1. Lock the process tree. Identify the parent process that launched the suspicious binary. Was it an installer the user downloaded minutes ago, a phishing attachment extracted from a ZIP, a game cheat executable? The parent is your containment target. Isolate the host. Revoke active sessions for the affected user across all applications, not just the domain: cloud identity providers, SaaS applications, and VPN concentrators need the same session revocation because Redline steals tokens that work everywhere.

Step 2. Pull the process command line and the file path. If Sysmon or EDR gives you the full command line, does it contain an obfuscated PowerShell cradle or a path inside a temporary directory? The hash of the binary on disk gives you two things immediately: a VirusTotal lookup and an IOC to scan across the rest of the environment. If the same hash appears on three workstations in the same hour, you have a campaign, not an isolated incident.

Step 3. Pivot on credential access. Search for file reads against Chrome and Firefox credential stores in the same time window on the same host. Windows Event 4663 with access mask 0x1 (ReadData) against the Login Data path from the same process ID is close to conclusive. If you find those reads, assume all credentials and session tokens on that host are compromised. The stolen data is already in the attacker's hands by the time the alert fires, so containment is about stopping the reuse, not the initial theft.

Step 4. Check for screen capture artifacts. Look for BitBlt/GraphicsCapture calls from the same process ID or its children. These confirm the infostealer collected secondary data beyond browser credentials.

Step 5. Check network connections from the same process. What external IPs and domains did the process reach? If the proxy or firewall log shows outbound HTTP or HTTPS to a domain registered in the last 30 days, and the request body shows a SOAP XML envelope (in clear HTTP, or through a TLS-inspecting proxy), you have the C2 destination. Block it at the perimeter and submit it to threat intel platforms. In the firewall log that callback is one allowed web session among thousands, and its steady byte count is what gives it away. You can rehearse that search on simulated traffic in our firewall log training console, free tier included. Also check lateral movement signals. Redline itself does not spread laterally, but the credentials it steals do, and an attacker who bought a Redline log this morning can authenticate to the VPN this afternoon using a stolen session token.

Step 6. Write the escalation. Communicate scope, not just detection. An escalation that says "Redline Stealer detected on host A" is incomplete. The version that moves the response forward is: "Redline Stealer executed on workstation W-FIN-04 at 09:12 UTC by user j.doe. The same process read the Chrome credential store and captured a screenshot. Assume Chrome-stored credentials and any MFA tokens active in the same browser session are compromised. C2 destination is 203.0.113.42 (registered 2026-08-05). No lateral movement from this host observed yet. Containment: isolate W-FIN-04, revoke j.doe's sessions across IdP, SaaS, and VPN, rotate credentials after reimaging."

How to Answer the Interview Question About Infostealers

If you get asked about commodity malware in a SOC analyst interview, Redline is a strong answer. It demonstrates you understand that not every detection is a novel APT tool, and that the analyst's job is recognizing behavioral signatures across log sources more than dissecting binaries. Here are the answers that show you grasp the operational side. "How do you detect an infostealer without signature-based antivirus?"

The signatures are in behavior, not hashes. A process that is not a browser reading browser credential stores. A .NET assembly loaded reflectively through PowerShell. A short-lived binary spawning from a user-downloaded file and connecting to a domain with no reputation. None of these alone is conclusive, but two or three in the same process tree within a one-minute window is enough to act on even if the binary hash is unknown.

"What makes an infostealer harder to detect than ransomware?"

Ransomware announces itself. It encrypts files, displays a note, and by the time the first alert fires, every endpoint in the blast radius knows something happened. An infostealer completes its job silently. The stolen data leaves through the same outbound HTTPS that every business application uses. No files are encrypted, no ransom note appears, and the first symptom is usually a credential reuse alert from a cloud provider three days later. The detection window is smaller, and the signal lives in application-layer telemetry rather than volume anomalies.

"Which log sources are mandatory for catching this kind of malware?"

Endpoint process creation with command line arguments. File system audit events, specifically reads against credential stores. PowerShell Script Block Logging at minimum, Module Logging if your SIEM licensing allows it. A proxy or firewall log that records destination domains, plus content-type headers if the proxy inspects TLS. You can triage Redline with Sysmon alone, but you cannot scope it without network telemetry, because the C2 connection is where you confirm exfiltration and find other compromised hosts sharing the same destination.

Key Takeaway

Redline is not the most advanced malware you will encounter, but it is among the most consequential for a SOC analyst because it turns a single endpoint compromise into a cloud-wide account takeover with no additional exploitation. The infection itself takes seconds. The reuse of the stolen credentials and tokens can take weeks. Closing the gap between those two timelines, by recognizing the behavioral signatures across process telemetry, file system logs, and network metadata, is what moves infostealer triage from a reactive cleanup to a proactive containment.

The techniques you are applying during that triage map directly to Screen Capture (hunting unauthorized graphics API calls from non-media processes) and Steal Application Access Token (scoping the session token theft that turns a malware alert into an identity incident). Recognizing the technique within the alert is what transforms an event description into a containment plan.

Sources

• MITRE ATT&CK: RedLine Stealer, Software S1240.
• US Department of Justice, Western District of Texas: U.S. Joins International Action Against RedLine and META Infostealers.
• eSentire Security Advisory: Increase in Redline Stealer Observations.
• SecurityScorecard Research: A Detailed Analysis of the RedLine Stealer.
• CSA Singapore Advisory: Defending Against RedLine Stealer Malware.
• Microsoft Learn: BasicHttpBinding Class (sends SOAP 1.1 over HTTP).
• W3C: Simple Object Access Protocol (SOAP) 1.1, section 6 (text/xml and SOAPAction on HTTP).