Infostealer malware detection and removal must address both the infected endpoint and the credentials, tokens, or sessions the malware may have exposed. Isolate the device first, preserve evidence, rebuild it when integrity is uncertain, and recover accounts from a trusted system by revoking sessions before rotating passwords, keys, and recovery methods.
Effective infostealer malware detection requires more than identifying a malicious file on a device. Security teams must analyse endpoint activity, browser data access, network communications, and account behaviour to determine whether sensitive information was collected and exfiltrated. Because many infostealers operate quickly and quietly, evidence of compromise may first appear through unusual cloud activity, unauthorised sessions, or suspicious authentication events rather than a traditional malware alert. Detecting these indicators early helps organisations contain the threat, assess potential exposure, and begin recovery before stolen credentials or tokens are abused.
Infostealer malware detection and removal must address both the infected endpoint and credentials, tokens, or sessions the malware may have exposed. Isolate the device first, preserve evidence, rebuild it when integrity is uncertain, and recover accounts from a trusted system by revoking sessions before rotating passwords, keys, and recovery methods.
Why Infostealer Malware Detection and Removal Does Not End the Incident
An infostealer is built to collect information that attackers can reuse, trade, or sell. Common targets include browser passwords, authentication cookies, autofill records, cryptocurrency wallets, email data, API keys, developer secrets, screenshots, and device details. Some families can also install additional malware, giving attackers a route from one data-theft event into a broader intrusion. The central response problem is simple: data already sent to an attacker does not return when an antivirus product quarantines the executable. A clean scan can show that a known malicious file is gone. It cannot invalidate an exported password, terminate a copied cloud session, rotate an exposed API key, or remove an inbox rule created through a stolen account.
Google has described the same limitation in relation to cookie-stealing malware. Authentication cookies may continue to work after the malware has been detected and removed because the application still recognises the session. This is why Google has been developing device-bound sessions that make copied cookies less useful outside the device that originally received them.
A confirmed infostealer infection should therefore be handled as two connected incidents. The endpoint team must determine whether the device can be trusted again. The identity team must identify and invalidate the credentials, sessions, keys, and application access that may have escaped.
Treating only one side creates a predictable failure. Resetting accounts from a device that remains infected can expose the new passwords and sessions. Cleaning the device without resetting exposed access leaves the attacker free to use what was stolen earlier.
What an Infostealer Can Expose
The information collected depends on the malware family, its configuration, the operating system, installed applications, available privileges, and the state of those applications during execution. Responders should avoid both extremes: assuming nothing was stolen because telemetry is incomplete, or declaring every secret on the device compromised without considering how it was protected.
Browser passwords and autofill data
Browsers commonly store Website usernames, passwords, addresses, payment details, and other autofill information. MITRE ATT&CK documents browser credential theft under technique T1555.003 and notes that attackers may read browser-specific files, call operating-system decryption functions, or search browser memory for usable credentials.
Modern browser encryption increases the work required to extract stored information, but it does not make an endpoint safe after malware gains comparable access to the user or browser. A stealer may abuse supported decryption paths, inject into a browser process, capture information while the browser is running, or collect encrypted material for later processing.
Saved credentials found in a browser profile should enter the exposure review. Rotation priority should reflect the account’s privilege, value, reuse, recovery role, and evidence that the malware supported the affected browser.
Authentication cookies and cloud sessions
A browser cookie can represent an authenticated session. If an attacker obtains a reusable cookie, the corresponding service may accept the attacker’s requests without requiring another password or MFA challenge.
MITRE classifies the collection of web session cookies as Credential Access technique T1539. It separately documents the use of stolen cookies under T1550.004, where an attacker imports or presents a cookie to access a web application as the authenticated user.
The stolen cookie does not automatically unlock every cloud application. Access remains subject to the cookie’s service, scope, lifetime, server-side session state, device restrictions, and current policy. Yet a single valid session can still expose email, financial systems, cloud files, administrative portals, or SaaS applications available to that user.
Password resets alone should not be assumed to terminate these sessions. Administrators need to use the affected provider’s session and token revocation controls, then verify that the previously observed access has stopped.
Password managers and unlocked vaults
The presence of a password manager does not prove that its entire vault was extracted. Exposure depends on whether the vault was unlocked, which browser integrations were active, whether the malware captured the clipboard or keystrokes, whether exported vault files were present, and whether the attacker obtained the master credential.
MITRE notes that attackers may target password-manager databases, master passwords, or plaintext credentials held in memory after a vault has been unlocked.
Responders should identify the manager, review account and device history where the vendor provides it, and determine whether the vault was open during the likely compromise window. High-impact secrets should receive priority, even when complete extraction cannot be proven.
An organisation should not respond by abandoning password managers. An approved enterprise password manager remains safer than password reuse, browser sprawl, spreadsheets, or unprotected documents. The response should focus on strong vault protection, controlled recovery, restricted exports, managed extensions, and separation of privileged credentials from routine browsing.
Developer, cloud, and application secrets
Developer workstations often contain credentials outside the browser. An infostealer may search configuration files, shell history, source repositories, command-line profiles, email clients, VPN software, FTP applications, cloud tooling, and local documents.
Potentially exposed artefacts include API keys, personal access tokens, SSH private keys, package-registry tokens, cloud CLI credentials, database connection strings, environment files, signing material, and deployment secrets.
Rotation should be planned rather than indiscriminate. The response team must identify the secret’s owner, permissions, dependencies, production impact, and replacement process. A rushed rotation that breaks a production service while leaving another active credential unchanged does not improve containment.
How Infostealers Reach Windows and macOS Devices
The initial delivery method matters because the same path can reinfect the device or reach other employees. Current campaigns rely heavily on social engineering rather than a single software exploit.
Phishing and impersonated business services
Attackers continue to deliver stealers through links, attachments, archives, and messages that imitate normal business activity. In March 2025, Microsoft described a campaign that impersonated Booking.com and targeted hospitality organisations across several regions. The campaign used fake guest complaints, account-verification messages, and promotional offers to deliver credential-stealing malware through ClickFix instructions.
These campaigns are effective because the message fits the recipient’s work. A booking request sent to hotel staff or a shared-document notice sent to an office worker does not need obvious spelling mistakes to appear plausible.
Email filtering remains necessary, but detection should also consider the destination, the requested user action, the resulting process chain, and what the newly launched process accesses.
Fake CAPTCHA and ClickFix instructions
ClickFix replaces a conventional malicious download with instructions that persuade the user to execute a command. The page may claim that the user must complete a CAPTCHA, repair a browser problem, install a missing component, or verify the computer.
CISA and the FBI documented LummaC2 campaigns in which a fake CAPTCHA instructed users to open the Windows Run dialogue, paste clipboard content, and execute it. The pasted content launched an encoded PowerShell process.
Microsoft reported in August 2025 that ClickFix campaigns were targeting thousands of enterprise and consumer devices globally each day. Microsoft observed the technique alongside phishing, malvertising, brand impersonation, and compromised websites.
Training should address the exact behaviour. A legitimate CAPTCHA does not require a visitor to open PowerShell, Terminal, Command Prompt, or the Windows Run dialogue and paste an unknown command.
Fake utilities, advertisements, and software downloads
Infostealers are also distributed through fake updates, cracked software, poisoned search results, malicious advertisements, game modifications, cryptocurrency tools, converters, and counterfeit utilities.
Microsoft’s 2025 Lumma investigation found a flexible delivery ecosystem involving phishing, malvertising, trusted-platform abuse, traffic-distribution systems, rotating domains, advertising networks, and legitimate cloud services. The diversity of these channels allowed operators to replace blocked infrastructure and continue reaching new victims.
Managed software catalogues and application control are more reliable than expecting every user to judge every download correctly. Removing unnecessary local-administrator rights can also limit what a malicious installer can change, although user-level malware may still steal information available to the signed-in user.
macOS is not outside the threat model
Infostealers are no longer primarily a Windows problem. Microsoft reported in February 2026 that campaigns were using malicious disk images, fake applications, Python loaders, AppleScript, native utilities, and ClickFix-style Terminal instructions against macOS users. The observed stealers targeted browser credentials, Keychain data, cryptocurrency wallets, cloud credentials, and developer secrets.
A May 2026 Microsoft investigation documented another change: attackers placed malicious commands on blogs and user-content platforms that appeared to offer advice about macOS utilities or disk optimisation. Victims were instructed to run Terminal commands that delivered MacSync, Shub Stealer, or Atomic macOS Stealer.
Mac users should not be trained to expect only suspicious .dmg files. A copied Terminal command can bypass parts of the normal application-installation path and execute through legitimate system utilities.
What Recent Incidents Reveal About the Threat
Infostealers matter because the stolen data often outlives the original malware process. The operator who infects the endpoint may not be the criminal who later uses the account.
Lumma reached hundreds of thousands of systems
On May 21, 2025, Microsoft announced coordinated action against Lumma Stealer. Microsoft reported identifying more than 394,000 infected Windows computers between March 16 and May 16, 2025. The operation disrupted approximately 2,300 malicious domains supporting Lumma’s infrastructure.
Lumma operated as malware-as-a-service. Affiliates could obtain malware builds, manage command-and-control activity, and access stolen information through an operator panel. Microsoft also observed ransomware-related threat actors using Lumma in their campaigns.
The disruption reduced the malware’s operating capacity, but a takedown cannot restore compromised endpoints or invalidate data already sold, copied, or shared. Each affected organisation still has to perform its own endpoint and identity recovery.
Stolen credentials became a major initial-access route
Mandiant’s M-Trends 2025 report, based on more than 450,000 hours of investigations into targeted activity during 2024, found that stolen credentials accounted for 16% of observed initial-access vectors, making them the second most common intrusion method after vulnerability exploitation. This trend underscores the importance of infostealer malware detection, since credentials harvested from infected devices frequently provide attackers with a direct path into corporate environments.
That figure should not be presented as a universal percentage for all global breaches. It describes Mandiant’s investigated cases. It does show that stolen credentials have become a substantial route into organisations rather than a secondary consumer-fraud issue.
M-Trends 2026, based on more than 500,000 investigative hours covering 2025, also described a sharp difference between long-running intrusions and financially motivated operations that move extremely quickly. Mandiant warned that handoffs between initial-access and follow-on operators can occur in seconds, leaving little time for manual triage after an apparently minor alert.
Infostealer credentials enabled Snowflake account compromise
In June 2024, Mandiant reported that the UNC5537 campaign used customer credentials previously stolen by infostealer malware to access Snowflake customer instances. Mandiant and Snowflake notified approximately 165 potentially exposed organisations. Mandiant found no evidence that the campaign resulted from a compromise of Snowflake’s enterprise environment.
This case illustrates the separation between cause and impact. A credential can be stolen from one device, sold or transferred later, and used against a cloud service from unrelated infrastructure. The team investigating the cloud breach may have no telemetry from the original infected endpoint.
Personal devices can expose corporate identities
Verizon’s 2025 Data Breach Investigations Report reviewed infostealer credential logs and found corporate logins on managed and unmanaged systems. Verizon reported that 30% of the compromised systems in the reviewed data were enterprise-licensed, while 46% of systems containing corporate logins were unmanaged personal devices.
This does not mean that 46% of all corporate credential theft originates from personal devices. It reflects the dataset Verizon analysed. The finding still matters because unmanaged devices often sit outside corporate EDR, browser policy, patch management, and forensic collection.
How to Detect an Infostealer Infection
Infostealers are designed to collect data quickly and quietly. Some establish persistence; others execute once, transmit the results, and disappear. Detection must therefore connect endpoint activity with network behaviour and later identity use.
Browser-data access needs context
MITRE’s cookie-theft detection strategy recommends monitoring suspicious access to browser cookie storage, browser-process memory, injection activity, and tools that target Chrome, Edge, Firefox, or similar processes. Useful telemetry includes process creation, process access, and file activity.
A process reading a browser database is not automatically malicious. Backup software, migration utilities, password managers, browser-support tools, and security products may have legitimate reasons to access the same files.
The useful signal comes from context. An unsigned executable launched from a temporary directory, reading several browser profiles, creating an archive, and connecting to an unfamiliar domain deserves immediate investigation. A known corporate migration tool performing a documented task does not carry the same weight.
Process ancestry often exposes the delivery chain
Analysts should examine what launched the suspicious process and what followed it. Browser or Office processes spawning PowerShell, shell interpreters running from user-writable directories, unknown scheduled tasks, new autorun entries, and memory-access tools targeting browsers can reveal the chain even when the final malware file has disappeared.
Microsoft’s July 2026 analysis of ACR Stealer described two active ClickFix delivery chains. One used WebDAV, staged PowerShell, Python loaders, and persistence. The other relied on MSHTA, obfuscated PowerShell, steganography, and in-memory execution. Both sought browser credentials, authentication tokens, and sensitive documents.
Detection should not depend on one filename or hash. Process relationships, scripting behaviour, browser-store access, persistence changes, and outbound communication remain useful when malware builders change individual files.
Cloud activity may be the first reliable evidence
Some organisations first discover an infection when the stolen information is used. The endpoint alert may have been missed, the device may have been unmanaged, or the malware may have left few artefacts.
Investigators should correlate endpoint alerts with cloud sessions, new devices, unusual token use, OAuth consent, mailbox forwarding, inbox rules, bulk downloads, recovery attempts, and changes to MFA configuration. A valid password followed by successful MFA does not prove that later session activity came from the expected device or user.
External stealer-log intelligence can provide another signal, but it requires careful validation. A listing may be old, duplicated, incomplete, or associated with a personal device. Its presence should initiate scoping and credential review, not replace endpoint and identity investigation.
How to Contain and Remove Infostealer Malware
The response order is critical. Performing account recovery too early can expose replacement credentials to the same malware.
- Isolate the endpoint without immediately destroying evidence.
Use the EDR platform’s network-containment function where available. If active exfiltration is likely and remote containment is unavailable, disconnect network access. Avoid powering off the system unless the response lead determines that shutdown is appropriate. - Assess the user and device’s business impact.
A finance workstation, developer system, administrator device, or executive endpoint requires a wider scope than a low-privilege kiosk. Identify access to cloud administration, payment platforms, production systems, source code, regulated data, and privileged credentials. - Preserve the evidence required for investigation.
Capture volatile data, process telemetry, relevant logs, persistence, browser profiles, and disk evidence according to incident policy. NIST’s malware-handling guidance emphasises having established prevention and response capabilities rather than improvising destructive cleanup during the incident. - Establish the likely exposure window.
Determine when the malicious file arrived, when it executed, which processes it created, where it connected, and when security controls changed. Review what the user accessed during that period. - Inventory exposed applications and secrets.
Identify browser profiles, password managers, cloud tools, VPN clients, email applications, cryptocurrency software, developer utilities, and sensitive local files. This inventory drives the later rotation and revocation plan. - Choose eradication or full restoration.
A rebuild is safer when the malware gained elevated access, installed additional payloads, disabled telemetry, modified security controls, or affected a privileged workstation. Microsoft’s Lumma guidance states that severely compromised devices may require complete restoration from a clean source.
Manual deletion of files from Downloads, Temp, startup folders, or scheduled tasks is not proof that the endpoint is clean. Visible files may be only one part of the intrusion, and deleting them can remove evidence while leaving injected code, extensions, services, secondary malware, or policy changes behind.
Recover Identities From a Trusted Device
Identity recovery should begin from a known-clean, managed system. The affected endpoint must not be used to open the password vault, reset passwords, approve new factors, or create replacement sessions.
Start by restricting identities where active abuse is likely. Then revoke browser sessions, refresh tokens, remembered devices, and supported application sessions. Remove unauthorised OAuth consent, connected applications, mailbox rules, forwarding settings, delegates, and newly enrolled authentication methods.
Password and secret rotation should follow the privilege and exposure assessment. Prioritise corporate email because it often controls account recovery. Then address privileged cloud accounts, financial systems, password-manager access, VPN credentials, developer tokens, API keys, SSH keys, and any secret capable of reaching production resources.
Session revocation should come before or alongside password rotation. A copied cookie may remain usable until the service invalidates the underlying session, even after the password has changed. MITRE documents the use of stolen web cookies to continue authenticated access without repeating the original login.
When a password manager may have been exposed, review whether the vault was unlocked and which secrets were recently used. Rotate high-impact credentials first, document each change, and monitor dependent applications. A controlled sequence reduces the risk of breaking production while ensuring that critical access is not overlooked.
How to Verify That Recovery Worked
Recovery is not complete when the scanner reports no threats. The organisation needs evidence that the endpoint is trustworthy and that previously stolen access no longer works.
The rebuilt or remediated endpoint should meet the organization’s approved security baseline. EDR must be healthy, tamper protection active, patches current, browser extensions approved, and no unexplained persistence or outbound communication should remain.
The identity review should confirm that active sessions were revoked, unauthorised factors and devices were removed, OAuth grants were examined, and high-impact passwords and keys were rotated. Mailbox rules, external forwarding, delegates, file-sharing links, and application registrations should match legitimate business requirements.
Continue monitoring for renewed token use, repeated account recovery, unfamiliar devices, recreated inbox rules, unusual downloads, and access from previously observed infrastructure. Any of those events indicates that containment was incomplete or that another account, device, application, or credential remains compromised.
Prevent Reinfection and Reduce the Blast Radius
Infostealer prevention works best when the organisation limits what users can execute and reduces the amount of reusable access available on one device.
Application control can block unknown binaries and scripts. Removing unnecessary local-administrator rights limits system-level changes. Managed browsers can restrict extensions, unsafe downloads, credential storage, and synchronisation. DNS and web filtering can interrupt malicious delivery and command infrastructure, while EDR provides the process and file telemetry needed for investigation.
Privileged accounts should not share the same browsing environment used for email, general web access, downloads, and consumer services. Dedicated administrative workstations or isolated browser profiles reduce the chance that one malicious advertisement or fake utility exposes high-value cloud sessions.
Sensitive applications should require managed devices where possible. Device-bound sessions can further reduce replay. Google made DBSC publicly available for Windows users with Chrome 146 in April 2026 and said macOS support would follow in a later Chrome release. DBSC uses hardware-backed keys and short-lived cookies so an exported cookie becomes less useful without the original device. Deployment still depends on browser, operating-system, hardware, and application support.
Training should be specific rather than generic. Employees need to recognise fake CAPTCHA instructions, counterfeit troubleshooting pages, fake browser updates, cracked software, malicious advertisements, and websites that ask visitors to paste commands into system tools. The goal is not to make users responsible for every attack. The goal is to remove the behaviours that current campaigns repeatedly exploit.
Unmanaged Devices Remain the Downstream Exposure
The hardest detection gap may exist outside the managed device fleet. Employees often reach corporate email, SaaS platforms, developer services, and cloud consoles from personal systems that do not provide corporate EDR, browser policy, application control, or forensic telemetry.
Organisations should align bring-your-own-device policy with the value of the applications being accessed. Low-impact web services may tolerate a broader device population. Financial systems, security consoles, cloud administration, source-code platforms, and sensitive data stores usually justify managed-device requirements or isolated access.
The objective is not to assume that every personal device is infected. It is to prevent an unmanaged endpoint from becoming an invisible route to high-impact business access.
An infostealer infection should end as a contained endpoint event with a documented identity recovery—not as a delayed cloud compromise discovered weeks later. That outcome depends on the response order: isolate first, preserve evidence, rebuild when trust cannot be restored, revoke existing access, rotate exposed secrets from a clean device, and verify that the attacker no longer has a working path.