Infostealers vs Loaders: How Detection and Response Differ for Each

An infostealer alert and a loader alert can come from the same endpoint on the same morning, yet one means your identities are already gone and the other means something worse is about to arrive. Infostealers harvest credentials, session cookies, tokens and keys and send them away in one pass. Loaders exist to get a foothold, survive, and fetch the next payload, which may be a stealer, a remote access tool or the precursor to ransomware. Treating both as "malware detected, quarantine and close" leaves stolen sessions valid in one case and a staging point live in the other. This guide compares the two from the defender's side: where each sits in the intrusion, what each leaves behind, how to detect it, and how response priorities differ. It is written for SOC analysts, detection engineers, incident responders and identity teams. For the stealer economy in depth, see the Infostealer Threat Guide; for loader and dropper fundamentals, see the Malware Loaders and Droppers Guide.

Key takeaways

• The short answer is theft versus delivery. An infostealer's job is finished when the stolen data leaves the device; a loader's job is finished only when the next payload is running, and it often stays to deliver more.
• The blast radius sits in different places. Stealer damage happens later and elsewhere, in your identity provider, SaaS tenants and cloud accounts; loader damage grows on and from the infected host and its network.
• Response starts from opposite ends. For a stealer, revoke sessions and rotate every exposed secret before or alongside the rebuild; for a loader, isolate the host and hunt for second-stage payloads before anyone touches credentials.
• The categories overlap in practice. Loaders deliver stealers, and some stealers can install further malware, so every confirmed infection needs both checks: what was taken, and what was dropped.
• Machine credentials are the long tail. Stolen API keys, cloud access keys and service account passwords outlive any user password reset, and the Snowflake campaign showed stolen credentials still working years after the infection.

What each category is

Infostealer: malware built to collect stored secrets and identifying data from a device and exfiltrate them, usually in a single run. Microsoft's analysis of Lumma Stealer lists what a modern stealer targets: browser passwords, session cookies and autofill data from Chromium and Gecko browsers, cryptocurrency wallets and extensions, VPN configuration files, email and FTP client data, messaging data, user documents and system metadata. Most families are sold as a service, with affiliates paying for a panel that builds the binary and receives stolen data. The stolen sets, often called logs, are then used by the buyer or resold. See the Malware-as-a-Service (MaaS) Economy Guide.

Loader: malware whose main purpose is to establish execution on a host and then download and run further payloads. A dropper carries its payload inside itself; a loader fetches it from infrastructure. In practice many families do both, and the terms are used loosely. Loaders are the hinge in many ransomware intrusions: the US Department of Justice said in August 2023 that Qakbot, which spread mainly through spam with malicious attachments or links, could install other malware including ransomware, and named Conti, ProLock, Egregor, REvil, MegaCortex and Black Basta as groups that used it. Europol's Operation Endgame (27 to 29 May 2024) targeted IcedID, SystemBC, Pikabot, Smokeloader, Bumblebee and Trickbot as a dropper ecosystem. For two current families, see the Latrodectus and Bumblebee Loaders Guide.

Side-by-side comparison

Where each sits in the intrusion

A loader usually sits near the front: it turns a click on an attachment or a fake installer into reliable code execution, then hands over to whatever its customer pays to deploy. A stealer can sit in two places. It can be the payload a loader delivers, or it can be the whole operation on its own, delivered directly by a fake software download.

What happens next diverges sharply. After a loader, the next stage is typically on the same host or network: a remote access tool, a post-exploitation framework, credential dumping, then lateral movement and, in the worst case, encryption. After a stealer, the next stage is somewhere else entirely. The data is packaged and sold or used by a different party, who signs in from their own infrastructure with valid credentials or replays a session cookie. Mandiant's UNC5537 investigation into the 2024 Snowflake customer intrusions found that the threat actor used credentials stolen by infostealers including VIDAR, RISEPRO, REDLINE, RACOON STEALER, LUMMA and METASTEALER, from systems that had nothing to do with Snowflake. The earliest linked infection dated to November 2020. See the Snowflake breach analysis.

The overlap matters for triage. Microsoft reports that Lumma has been delivered as a secondary payload by loaders such as DanaBot, and that Lumma itself can install further malware such as clipboard stealers and coin miners. One host can show both patterns.

Threat model for each

Infostealers: the device is the source, not the target

What it exploits: secrets stored or cached in user context: browser password stores, cookie databases, developer tool configuration files, cloud CLI credential files, password manager exports left on disk, and documents containing keys. On Windows, the Data Protection API protects these from other users but not from code running as the same user, which is why stealers work without elevation.

Who is exposed: anyone whose credentials touch the device, including personal and unmanaged devices that sign in to corporate SaaS. Mandiant found that in several Snowflake cases the infection was on contractor systems also used for gaming and pirated software, and noted that one contractor laptop can expose many client organisations.

What raises the bar: Chrome's App-Bound Encryption on Windows (cookies from Chrome 127) ties stored secrets to the browser's identity through a privileged service, so user-level malware cannot simply read them. Google states that malware running elevated can bypass it and that injection remains possible, though more detectable. Device Bound Session Credentials bind a session to a device key so a copied cookie cannot be refreshed elsewhere. See the Device-Bound Session Credentials (DBSC) Guide.

Loaders: the device is the beachhead

What it exploits: users' ability to run content they downloaded or received: script hosts, Office child processes, signed system binaries used as proxies, and user-writable folders. Its value is reliability and stealth, so loaders invest in obfuscation (T1027) and in blending with trusted processes.

Who is exposed: the infected host first, then anything reachable from it with the user's or a cached administrator's rights. Because loaders feed ransomware affiliates, the realistic worst case is domain-wide encryption days or weeks after the initial alert.

What raises the bar: execution prevention (M1038): application allowlisting, attack surface reduction rules, blocking script hosts from launching downloaded executables, and restricting container and archive file handling. See the Application Allowlisting Guide.

What each leaves behind, with the NHI angle

The forensic footprint drives the response. A stealer may leave almost nothing on disk if it ran in memory and exited; the evidence that matters is what it read. A loader leaves persistence, staged files and network patterns because it needs to come back.

The non-human identity exposure is the part most programmes underestimate. A user password reset fixes the human account. It does nothing for the personal access token in a developer's Git configuration, the cloud access key in a CLI profile, or the database service account password saved in a client tool. These have no MFA, are rarely monitored for anomalous use, and are often valid for years: Mandiant found Snowflake credentials that had not been rotated for as long as four years. See the Infostealer Logs and Session Token Abuse Guide and the Non-Human Identity (NHI) Guide.

Detection: what to watch for each

Infostealer signals

• Credential store access: a process other than the browser opening browser login and cookie databases, or calling DPAPI decryption over browser data. Microsoft publishes a hunting query for AutoIt or .NET processes accessing browser data.
• Process hollowing into trusted binaries: Microsoft reports Lumma running inside msbuild.exe, regasm.exe, regsvcs.exe and explorer.exe; unusual network activity from these processes is a strong signal.
• Paste-and-run execution: new entries in the RunMRU registry key that launch script hosts or mshta (T1204.004, T1218.005). See the ClickFix and Fake CAPTCHA Paste-and-Run Attacks Guide.
• Identity-side replay: sign-ins or token use from new infrastructure without a matching interactive authentication, session use from two locations, or access keys used from an unfamiliar network.
• External exposure: corporate domains or SSO URLs appearing in stealer log feeds. See the Infostealer Logs Monitoring and Response Guide.

Loader signals

• Suspicious parent-child chains: Office, a script host or an archive utility spawning an executable from a user-writable path.
• Persistence creation: new Run keys, startup items or scheduled tasks pointing to user profile or temp paths shortly after a download or email open.
• Ingress transfer: a newly written process downloading further executables or DLLs (T1105).
• Beaconing: regular outbound HTTPS to young or low-reputation domains, often from a process that has no business talking to the internet.

On Microsoft Defender for Endpoint, attack surface reduction rules give a measurable control for both. Run them in audit mode first and review the advanced hunting action types before enforcing.

Microsoft's documentation notes that the Office child process rule is enforced only when Office is installed in the Program Files folders, and that the LSASS rule does not support warn mode. Other EDR and allowlisting products offer equivalent controls. See the EDR Guide.

Response: revocation first versus containment first

Confirmed infostealer

1. Establish the exposure window: when the stealer ran, which user profiles and browsers were present, and which secrets were on disk.
2. Revoke sessions for every identity used on the device: identity provider refresh tokens and sessions, then SaaS sessions that do not inherit IdP revocation. See the Global Token Revocation Guide.
3. Rotate secrets, not just passwords: cloud access keys, personal access tokens, API keys, SSH keys, database and service account passwords found in the profile. Use the Secrets Rotation Runbook Template.
4. Hunt for use of what was taken: sign-ins, token grants, key usage and data access from the exposure date onward, including personal accounts the user may have synced.
5. Check for a loader or other payload: confirm the stealer did not install anything else, then reimage.

Confirmed loader

1. Isolate the host through EDR network containment, keeping it powered for memory and volatile evidence where the team can collect it.
2. Scope second stages: every file the loader wrote or downloaded, every process it launched, and every domain it contacted. Search the estate for the same hashes, domains and persistence names.
3. Look for handover: remote access tools, post-exploitation frameworks, new local accounts and credential dumping. If any appear, escalate to a full intrusion response and assume lateral movement. See the Malware Outbreak Playbook.
4. Then handle credentials: if a stealer or credential dumping is confirmed, follow the infostealer steps above; otherwise rotate credentials used on the host as a precaution.
5. Remove persistence and rebuild, then watch the host and its users closely for at least one beaconing cycle.

Decision criteria

• Unsure which it is: run both tracks. Start containment and a session revocation for the affected user at the same time; the cost of an unnecessary revocation is a sign-in prompt.
• Developer, cloud admin or contractor device: treat any stealer as a non-human identity incident as well as a user incident, because these profiles hold keys and tokens with broad reach.
• Unmanaged or personal device: you will not get endpoint telemetry, so detection depends on identity signals and stealer log monitoring. Require compliant or managed devices for privileged and data platform access.
• Small organisations: prioritise phishing-resistant MFA, managed browsers with credential saving disabled for corporate accounts, and a documented revoke-and-rotate procedure. Full loader hunting may come from a managed detection provider.
• Large organisations: build separate playbooks and detection content for each, plus automation that triggers revocation when a stealer verdict is reached.

Worked scenario

A developer searches for a code editor, clicks a sponsored result and runs an installer from a cloned site. EDR raises a medium alert for an unsigned executable writing to the user profile, then a second alert for msbuild.exe making outbound connections. The analyst quarantines the file and the host reports clean.

Handled as a single malware alert, the story ends there. Instead, the analyst asks two questions. What was taken? The process accessed Chrome and Edge credential stores and a cloud CLI credentials file, so the identity team revokes the developer's sessions, rotates two cloud access keys and a Git personal access token, and finds one access key already used from an unfamiliar network an hour after the infection. What was dropped? The installer also wrote a scheduled task that fetched a second executable, so the host is isolated and reimaged, and the domain is blocked estate-wide. Two other hosts that contacted it are found and contained before any hands-on activity begins.

Detection and measurement

• Time from stealer verdict to full session revocation: target under one hour for privileged users.
• Secrets rotated per stealer incident against secrets found in the profile: target 100 percent, including non-human credentials.
• Loader alerts with a completed second-stage hunt: share of loader incidents where downloaded payloads and contacted domains were searched across the estate.
• ASR and allowlisting enforcement coverage: percentage of endpoints with the rules above in block mode rather than audit.
• Stealer log exposures closed: share of corporate credentials found in external feeds that were reset within the agreed time.
• Repeat infection rate: hosts or users infected again within 90 days, which points to an unfixed root cause.

Common failure patterns

• Closing on quarantine: the file is gone but the cookies, tokens and keys it took are still valid. In the Schneider Electric Jira breach, credentials from a Lumma-infected employee machine were reported to match the attacker's access, including migration service accounts.
• Resetting the password and stopping: session cookies and refresh tokens survive a password change on many platforms unless sessions are explicitly revoked.
• Forgetting non-human credentials: cloud keys and API tokens in developer profiles are rotated weeks later, if at all.
• Treating a loader as a single file: the dropped payloads and a second persistence mechanism are missed, and the host reinfects after cleanup.
• Ignoring contractor and personal devices: the infection happens where you have no telemetry, as in the Snowflake intrusions, and the first signal is a sign-in from someone else's infrastructure.

Framework mapping

See the CIS Control 10 Malware Defenses Guide for safeguard-level detail.

Practitioner checklist

• Classify every confirmed malware incident with two questions: what was taken, and what was dropped.
• Write separate playbooks for stealer response (revoke and rotate) and loader response (isolate and hunt), with a combined path when both apply.
• Include non-human credentials in every stealer playbook: cloud keys, tokens, SSH keys and service account passwords.
• Deploy attack surface reduction or equivalent rules in audit mode, review, then enforce on all endpoints.
• Monitor stealer log feeds for corporate domains and SSO URLs, and route hits into the revocation workflow.
• Require managed or compliant devices for privileged, developer and data platform access.
• Bind sessions to devices where your platforms support it, and keep session lifetimes for sensitive apps short.
• Measure time to revocation and second-stage hunt completion, and review repeat infections quarterly.

Standards and references

• Google Cloud (Mandiant): UNC5537 targets Snowflake customer instances for data theft and extortion
• Microsoft Security: Lumma Stealer delivery techniques and capabilities
• US Department of Justice: Qakbot malware disrupted in international cyber takedown
• Europol: Largest ever operation against botnets hits dropper malware ecosystem
• Microsoft Learn: Attack surface reduction rules reference
• Google Security Blog: Improving the security of Chrome cookies on Windows
• Chrome for Developers: Device Bound Session Credentials
• MITRE ATT&CK: T1105 Ingress Tool Transfer

Related NHI Mgmt Group resources: Infostealers vs RATs, Initial Access Brokers Guide, Malvertising and SEO Poisoning Guide, Lumma Stealer Guide, ATT&CK Loaders and Droppers Software Hub.