StealC is a rented infostealer that empties a Windows browser of passwords and session cookies in seconds and can then install whatever its operator chooses, including other stealers, remote access trojans and, in at least one observed chain, ransomware. It has been sold as malware-as-a-service since January 2023, was rebuilt as StealC V2 in March 2025, and was the main target of a Europol-coordinated Operation Endgame action in June 2026. This guide profiles StealC for defenders: how the service works, how infections arrive, what changed in V2, what it collects, and the endpoint, browser and identity controls that limit the damage. It builds on the Infostealer Threat Guide, which covers the stealer economy as a whole, and is written for SOC analysts, endpoint engineers and identity teams. It is defensive only: no samples, commands or indicators that would help anyone run the malware.
Key takeaways
- StealC is a service with many customers. One developer sells builds and panel updates; affiliates run their own campaigns, so two StealC infections can lead to completely different follow-on activity.
- It is a stealer and a loader. V2 can deliver EXE, MSI and PowerShell payloads before or after theft, and Proofpoint saw it pull down Amadey, Vidar, RedLine, SmokeLoader, AsyncRAT and LockBit Black.
- Session cookies are the identity payload. Microsoft reports StealC taking cookies from Chromium and Gecko browsers, including a bypass of Chromium App-Bound Encryption, which lets an attacker skip MFA by replaying a signed-in session.
- Takedowns do not undo theft. Operation Endgame seized infrastructure and recovered 27 million compromised data sets in June 2026, but every credential already sold stays valid until it is rotated.
- Respond as an identity incident. Reimaging the endpoint is step one of many: revoke sessions, rotate every password, token and key the device held, and watch for sign-ins that look legitimate.
What StealC is and how the service works
Sekoia reported that StealC was first advertised on 9 January 2023 on Russian-speaking cybercrime forums, later on Exploit and Telegram. The developer described it as built from the code ideas of earlier stealers (Vidar, Raccoon, Mars and RedLine), and Sekoia assessed it as a copycat that shares their habit of downloading legitimate third-party DLLs to read browser databases. Zscaler ThreatLabz describes it as "an information stealer and malware downloader" sold since January 2023, with StealC V2 introduced in March 2025.
The business model matters to defenders more than the code. The seller keeps control of encryption keys and command and control (C2) settings and ships panel updates as archives; affiliates buy a build and a web panel and choose their own lures and follow-on payloads. ThreatLabz describes a builder in the panel that sets delivery rules by geolocation, hardware ID, build ID, markers found in stolen data and installed software, with Telegram bot notifications to the operator. In practice that means an affiliate can decide automatically that a machine with a crypto wallet or a corporate VPN client gets a second-stage payload, while a sandbox or an uninteresting home PC does not. See the Malware-as-a-Service (MaaS) Economy Guide for how these markets operate.
| Element | What sources describe | Why it matters to defenders |
|---|---|---|
| Seller | Single developer selling builds, updates and support (Sekoia, ThreatLabz) | Capability changes arrive for all affiliates at once, so detections age quickly |
| Affiliates | Run campaigns, pick lures and payloads; Proofpoint saw overlap with other stealer and loader ecosystems | Attribution to a single group is rarely possible; follow-on activity varies |
| Panel and builder | Payload rules by geography, hardware ID, stolen-data markers and installed software; IP and hardware ID blocking (ThreatLabz) | High-value corporate devices are more likely to receive a second stage |
| Loaders that deliver it | Amadey most often cited; Trellix reported Amadey pulling StealC from a compromised self-hosted GitLab instance (via Microsoft) | A loader detection should trigger a stealer response, and the reverse |
| Output | Credentials, cookies, wallet data and files sold or used for fraud and initial access | The real incident often starts days or months later on a SaaS or VPN sign-in |
StealC has no MITRE ATT&CK software entry at the time of writing, so this guide describes behaviour in plain terms rather than mapping it to a software ID. For the families that do have ATT&CK entries, see the ATT&CK Infostealers Software Hub.
How StealC infections arrive
StealC does not exploit vulnerabilities to get in. Every documented route depends on a user running something or on another piece of malware already present. Microsoft's June 2026 analysis lists four main routes.
- Search poisoning and malvertising: trojanised software, "cracked" applications and game cheats promoted through search results and ads. Sekoia's first report described a fake cracked-software catalogue linked from YouTube videos posted through hijacked accounts, delivering a password-protected RAR archive. See the Malvertising and SEO Poisoning Guide.
- Paste-and-run lures: ClickFix pages that persuade the user to paste a command into the Windows Run dialog or a terminal. See the ClickFix and Fake CAPTCHA Paste-and-Run Attacks Guide.
- Phishing: used especially for targeted campaigns, according to Microsoft.
- Loaders: Amadey is the loader most often seen deploying StealC. ThreatLabz has also seen StealC V2 used to deliver Amadey-linked payloads, so the relationship runs both ways. See the Malware Loaders and Droppers Guide.
The kiosk mode credential trap
One campaign shows how StealC is combined with social pressure. OALABS reported, in coverage by BleepingComputer, that since at least 22 August 2024 Amadey dropped a script that opened Chrome or Edge in full-screen kiosk mode on a Google password change page and disabled the F11 and Escape keys. The aim was to frustrate the user into signing in, and possibly saving the password, so that StealC could then collect it from the browser store. The defensive lesson is simple and worth putting in awareness material: a browser that suddenly locks into full screen and demands a password is a symptom of infection, not a login requirement. Users should not type credentials, should report it, and the device should be treated as compromised.
What changed in StealC V2
ThreatLabz analysed V2 in May 2025. The changes push work from the infected machine to the operator's server and make the loader function more flexible.
| Area | Earlier StealC (Sekoia, 2023) | StealC V2 (ThreatLabz, 2025) | Defensive implication |
|---|---|---|---|
| C2 protocol | PHP gates with form fields such as hardware ID and build | JSON requests (create, upload_file, done, loader), RC4 encryption later enabled, HTTP on port 80 only | Network signatures written for V1 miss V2; plain HTTP from unusual processes is still a strong signal |
| Browser decryption | Downloaded legitimate DLLs such as sqlite3 and nss3 from C2 to read browser stores locally | Decrypts stolen data on the server; supports Chrome v20 App-Bound Encryption | Less on-disk evidence; focus on processes reading browser profile files |
| Payload delivery | Basic download and execute | EXE, MSI (silent msiexec with retries) and PowerShell, before or after theft | Treat any StealC hit as possible multi-stage compromise |
| Sandbox checks | Exited on known emulator names; hard-coded expiry date | Anti-VM checks removed | Detonation sandboxes see more behaviour |
| Collection | About 22 browsers, 75 extensions, 25 desktop wallets, messaging apps and a file grabber | Unified file grabber, multi-monitor screenshots, server-side credential brute forcing | Documents on the desktop and in profile folders are in scope |
| Clean-up | Deleted itself and the downloaded DLLs | Self-delete routine in newer builds | The binary may be gone by the time an analyst looks; rely on EDR telemetry |
Version details change with each update the seller pushes. Treat this table as a description of documented behaviour as of the cited reports, not a permanent profile.
What StealC takes, and why it is an identity problem
Microsoft's 2026 analysis lists what StealC collects: saved passwords and session cookies from Chromium and Gecko browsers, autofill and saved card data, browsing history, cryptocurrency wallet extensions, messaging app data, email client credentials such as Outlook and Foxmail, WinSCP session credentials, Steam session files, files matching grabber rules, screenshots and system information. ThreatLabz adds instant messengers, VPN clients and gaming applications to the target list.
For an organisation, four of those categories carry most of the risk.
- Session cookies for SaaS and the identity provider: a cookie copied from a signed-in browser lets an attacker continue the session elsewhere without the password or MFA. Microsoft notes that intrusions may begin 48 to 72 hours after theft or stay dormant for months. See the Infostealer Logs and Session Token Abuse Guide.
- VPN, SSO and cloud credentials on unmanaged devices: Microsoft highlights that infections on personal or unmanaged machines expose corporate VPN, SSO and cloud logins. Staff who sign in to work from a home PC used for games and downloads are a common route.
- File transfer and administrative tools: stored WinSCP sessions can hold server hostnames and credentials used by administrators and automation, which are often long-lived and not covered by MFA.
- Machine credentials in files: the file grabber collects documents and configuration files by rule. On a developer or operations workstation that can include API keys, cloud access keys and tokens in plain text. These non-human credentials do not expire when the user signs out. See the Compromised Developer Workstation Playbook.
Proofpoint reported that the Operation Endgame action seized more than 25.6 million unique credentials stolen from over 385,000 compromised systems. Numbers on that scale mean any organisation of meaningful size should assume some of its staff credentials have passed through StealC or a similar stealer at some point.
Operation Endgame and the June 2026 disruption
| Item | What the primary source states |
|---|---|
| Action week | 15 to 19 June 2026, announced 24 June 2026 (Eurojust) |
| Families targeted | StealC, Amadey and SocGholish (Eurojust) |
| Infrastructure | 326 servers and 142 domains neutralised across the action (Eurojust); Proofpoint reports 66 domains and 296 servers in the StealC and Amadey disruption |
| Data recovered | 27 million compromised data sets (Eurojust) |
| Countries named | Germany, Belgium, Denmark, France, the Netherlands, the United Kingdom, the United States and Canada, coordinated by Europol (Eurojust) |
| Private sector role | Proofpoint and IBM X-Force supported with research and infrastructure monitoring; Microsoft's Digital Crimes Unit filed a civil action against alleged enablers of StealC and Amadey |
| Panel weakness | Proofpoint found a directory traversal flaw in the StealC C2 panel in early 2026, which the developers patched in February; law enforcement used it during the operation |
The pattern from earlier stealer disruptions applies here. After the May 2025 action against Lumma, Trend Micro saw activity recover within weeks (see the Lumma Stealer Guide). Disruption raises the cost of operating StealC and may push affiliates to other families, such as Rhadamanthys, but it does not make stolen logs less valid. The defensive priority stays the same: assume exposure and rotate.
Detection and measurement
Detection signals
Behavioural signals last longer than hashes or C2 addresses, which change with every build. The table describes what to look for; translate each row into your EDR, SIEM or identity platform's own query language.
| Signal | Where to look | Source and notes |
|---|---|---|
| A non-browser process reading browser profile files (Login Data, Cookies, Web Data) or wallet extension folders | EDR file access telemetry | Core stealer behaviour; StealC targets Chromium and Gecko browsers (Microsoft) |
| Unexpected text and staging files directly under C:\ProgramData, named after a hardware ID | EDR file creation events | Microsoft describes IPC and staging files at this location |
| Process injection into suspended browser helper processes | EDR injection and memory alerts | Microsoft describes APC injection used around App-Bound Encryption |
| Chrome event ID 257 in the Application log | Windows event logs | Google: emitted when App-Bound verification fails; also useful for spotting tampering |
| Plain HTTP POSTs on port 80 with JSON bodies from a newly created process | Proxy, firewall and network detection logs | V2 uses HTTP on port 80 only (ThreatLabz) |
| msiexec or PowerShell launched by a recently written, unsigned executable shortly after browser file access | Process creation with command line (Sysmon event 1 or Security event 4688) | V2 loader function (ThreatLabz) |
| Browser launched in kiosk mode by a script host | Process creation command lines | Kiosk trap campaign (OALABS via BleepingComputer) |
| Antivirus names such as Trojan:Win32/Stealc, Trojan:Win64/Stealc, Behavior:Win64/Stealc, TrojanDownloader:PowerShell/StealC, plus Amadey detections | Endpoint protection and XDR alerts | Microsoft; treat a blocked detection as possible partial theft if it fired late |
| A known session or refresh token used from a new device, IP or ASN without a fresh MFA event | Identity provider and SaaS sign-in logs | Often the first sign seen when the endpoint was unmanaged |
Metrics that show the controls are working
- Time to revoke: minutes from a stealer alert to session and refresh token revocation for the affected user. Target under one hour.
- Rotation completeness: percentage of credentials identified on an infected device (passwords, tokens, keys, VPN profiles) rotated within 24 hours.
- Exposure rate: corporate accounts seen in stealer log monitoring per month, and the share already rotated before discovery.
- Protection coverage: percentage of Windows endpoints with tamper protection, cloud-delivered protection and block-mode EDR on.
- Bound sessions: percentage of sign-ins to critical applications from managed, compliant devices or bound sessions.
- Repeat infections: users or devices infected more than once per quarter, a sign that the delivery route is still open.
Prevention and response
Prevention, in rollout order
- Endpoint baseline first: Microsoft's StealC guidance is to turn on cloud-delivered protection, tenant-wide tamper protection and always-on protection, and to consider the DisableLocalAdminMerge setting so local administrators cannot add exclusions that override policy. Use the equivalent settings in any other endpoint platform.
- Attack surface reduction in audit mode: Microsoft recommends the "Use advanced protection against ransomware" rule. Run it in audit mode for two to four weeks, review hits with application owners, then enforce. Roll back an individual rule to audit if it blocks a business application, rather than disabling the set.
- Remove local administrator rights: Google's advice for App-Bound Encryption is to stop users running downloaded files as administrator, because the protection can be bypassed by code running with elevated rights. Standard user accounts make StealC rely on noisier techniques such as injection.
- Close the download and paste routes: install software only from a managed catalogue, filter newly registered and ad-delivered domains at DNS, and restrict PowerShell and the Run dialog for users who do not need them through application control. See the Application Control and Endpoint Prevention Buyer's Guide.
- Harden the browser: keep App-Bound Encryption on (the ApplicationBoundEncryptionEnabled policy), allowlist extensions, and prefer an enterprise password manager over browser-saved passwords on managed profiles. See the Browser Security Hardening Guide.
- Bind sessions to devices: use phishing-resistant MFA, device compliance for critical applications and short session lifetimes. Where applications support Device Bound Session Credentials, Chrome stores a private key in hardware such as a TPM and issues short-lived cookies that cannot be renewed on another device. Pilot with a small group first, because Chrome falls back to standard cookies when hardware key storage is unavailable.
- Move machine credentials off endpoints: replace API keys and cloud access keys in files with a secrets manager or short-lived federated credentials, so a file grabber finds nothing reusable.
Response when StealC is found
- Isolate the device and preserve the EDR timeline from first execution, including any child processes, MSI installs or PowerShell launched afterwards.
- Check for second-stage payloads. StealC's loader function means a second family may still be running after the stealer has deleted itself.
- List what the device held: browser-signed-in accounts, saved passwords, wallets, VPN profiles, WinSCP sessions and files that could contain keys or tokens.
- Revoke sessions and refresh tokens in the identity provider and key SaaS applications, then reset passwords. Order matters: resetting a password alone may leave existing sessions valid.
- Rotate machine credentials found on the device and review their recent use in cloud and SaaS audit logs.
- Reimage, then monitor the user's accounts for sign-ins from new locations for at least 30 days. See the Infostealer Logs Monitoring and Response Guide.
Decision guidance
- Small organisations: standard user accounts, a managed browser with extension allowlisting, an enterprise password manager and MFA on everything deliver most of the benefit. Buy stealer log monitoring rather than building it.
- Large organisations: invest in automated token revocation triggered by EDR stealer alerts and in session-replay detection at the identity provider; this closes the window between theft and use.
- Personal and unmanaged devices: decide whether they may reach admin portals, VPN and data platforms at all. If they may, require device compliance or a managed browser, because StealC campaigns favour home machines used for gaming and downloads.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Malware protection and EDR | DE.CM-09 | SI-3, SI-4 | Control 10 Malware Defenses | A.8.7 Protection against malware |
| Preventing unauthorised software | PR.PS-05 | CM-7 | Control 2 Inventory and Control of Software Assets | A.8.19 Installation of software on operational systems |
| Least privilege on endpoints | PR.AA-05 | AC-6 | Control 5 Account Management | A.8.2 Privileged access rights |
| Authentication and session protection | PR.AA-03 | IA-2, SC-23, AC-12 | Control 6 Access Control Management | A.8.5 Secure authentication |
| Eradication and credential rotation | RS.MI-02 | IR-4 | Control 17 Incident Response Management | A.5.26 Response to information security incidents |
Common failure patterns
- Reimage and close: the device is rebuilt but sessions, tokens and keys taken from it are never revoked, so the attacker keeps access through SaaS and VPN.
- Password reset without session revocation: the user changes their password while a stolen cookie remains valid for days.
- Treating a blocked alert as safe: an antivirus detection that fired after the stealer ran still means data may have left. Check the timeline before closing.
- Ignoring the loader: responders remove StealC but miss the second payload it fetched, which may be a remote access trojan.
- Unmanaged devices with full access: staff sign in to corporate VPN and SSO from home PCs that the security team cannot see. The Snowflake breach showed how infostealer credentials from personal and contractor machines, used against accounts without MFA, reached about 165 customer environments.
- Keys in files on developer machines: long-lived cloud and API keys in configuration files outlive every password reset unless they are found and rotated.
Practitioner checklist
- Confirm tamper protection, cloud-delivered protection and block-mode EDR on every Windows endpoint.
- Remove local administrator rights from standard users and keep App-Bound Encryption enabled in Chrome policy.
- Hunt for non-browser processes reading browser profile files and for unexpected staging files under C:\ProgramData.
- Block software installs outside a managed catalogue and restrict paste-and-run routes for standard users.
- Require phishing-resistant MFA and device compliance for VPN, SSO and cloud consoles.
- Write a stealer playbook that revokes sessions before resetting passwords and checks for second-stage payloads.
- Move API and cloud keys from developer workstations into a secrets manager or short-lived credentials.
- Monitor stealer logs for corporate domains and rotate any exposed credential within 24 hours.
- Add the kiosk-mode lock screen to awareness training as a sign of infection.
Standards and references
- Microsoft Threat Intelligence: StealC and Amadey, Breaking Down Infostealers and the Cybercrime Services That Deliver Them
- Eurojust: Operation Endgame Continues, International Coalition Takes Malware Offline
- Zscaler ThreatLabz: I StealC You, Tracking the Rapid Changes to StealC
- Sekoia: Stealc, a Copycat of Vidar and Raccoon Infostealers Gaining in Popularity
- Proofpoint: StealC You Later, Proofpoint and IBM X-Force Support Operation Endgame
- Google Security Blog: Improving the Security of Chrome Cookies on Windows
- Chrome for Developers: Device Bound Session Credentials
- BleepingComputer: Malware Locks Browser in Kiosk Mode to Steal Google Credentials
Related NHI Mgmt Group resources: Infostealer Threat Guide · Lumma Stealer Guide · Rhadamanthys Infostealer Guide · ATT&CK Infostealers Software Hub · Session Hijacking and Cookie Theft Guide